I grew up in humble surroundings, my family was for the most part “working class”, I moved around a bit as a kid, moved schools a few times, and lived in state/council housing. At one point as a child (due to some unfortunate circumstances) we lived for a short time in a “homeless” hostel – a transitional place whilst waiting for state housing to be allocated. In one area that I lived as a child I had a knife pulled on me outside a local shop, I learned then how quickly I could run! Today I live in a nice safe suburb, drive a decent car, and generally don’t have to worry too much about personal safety or not having a roof over my head. This is due to some kindnesses I’ve been shown along the way and also by investing. Investing in myself…

I recently completed reading Tony Robbins  Money Master the Game, it is a good book for those new to investing - with a few chapters being somewhat US-centric. (Other books you may find interesting if you’re just starting out your investing journey include The Little Book of Common Sense Investing and A Random Walk Down Wall Street.) While Money Master the Game contains a lot of information about how to attempt to maximize your financial returns and  ways to diversify your portfolio, in it Tony also talks about  how you can add more value.

One way to improve your financial investments is by by investing in yourself.

One nice idea is that by investing in yourself you can add more value and if you can add more value you can earn more and if you can earn more you can invest more.

I had some help and kindnesses shown to me in my journey and like everyone I’ve also some challenges to deal with along the way. Even though I come from a somewhat humble  background, and as a white heterosexual male I’ve never had to deal with prejudice, I am lucky that I have always loved to learn. I became fascinated by computers and programming from an early age and was lucky enough to borrow one for a time when I was younger. Eventually my interest and enthusiasm meant I was lucky enough to get my own machine.

Over the many years I continued to learn and was eventually privileged enough to be able to attend university to study computing. Even after starting my first job I continued to learn in my own time, in the evenings and at weekends, always interested in learning more.

As I look back now, at the time I was just following my natural curiosity, but looking back what I was really doing was investing in myself.

About 2 and a half years ago I stepped into a gym for the first time in my life. I look back now and smile, my first experience was not pleasant, I didn’t know what exercises to do, I tried bench pressing with an empty bar and wobbled all over the place, while the muscular guy next to be hoisted 50kg dumbbells to the sky. I went home feeling awful and a little stupid. Two days later I went back, and I kept going back. I devoured Arnold Schwarzenegger's Encyclopedia of Modern Bodybuilding and eventually paid for some personal training sessions to learn how to clean and press and bench press properly. Whilst I am not a shredded muscular bodybuilder, I did lose 14kgs over 2 years and add some amount of muscle mass and some strength. This is another example of investing in you, this time the physical you. Oftentimes, as developers we don’t always take the best care of ourselves, but I believe investing in the physical you carries over to the work/business you.

As the adage goes, "if you want better answers, ask better questions". One question I’m asking myself this year is: how can I continue to add more value than anyone else? As a software developer and “techie-minded”, in the past I would have thought of a question like this as being big-headed or management-speaky. But if you want to help others you need to help yourself and if you want to help yourself you need to offer value to others.

If you want better answers, ask better questions

It’s good to take a step back sometimes and ask ourselves some questions, especially as we get laser focused on the test we’re writing or the feature we’re working on or the sprint that we’re in, or the next project that might be coming along.

I’m grateful for the opportunities I’ve been given in life, I’m grateful for the challenges and failures and what I’ve learned from them, and I’m grateful for the gift of my lifelong love of learning.

Whilst somewhat dramatic, there is some truth to the phrase “if you’re not growing you’re dying” and if you want to grow you have to invest in you.

SHARE:

It’s often useful to take a step back and look at the bigger picture, this is true in different aspects of life such as health or wealth or relationships, and is also true of software development.

When it comes to creating automated tests (as with other aspects of software development) dogmatism and absolutist schools of though can exist.

As with all things, the decision to write tests (and how many tests, what type of tests, test coverage aims, etc.) ultimately should boil down to one question: do they add value to what you are doing?

To be clear, I absolutely believe in the creation of automated tests in many cases, however it is good to not be dogmatic. For example if there is a niche market that is ripe for capitalizing on, and time-to-market is the most important thing to capture this market, then an extensive suite of automated tests may slow down getting to that initial release. This of course assumes that the potential market will have some tolerance for software defects. It also depends on what the product is; medical life-critical software is probably going to have a higher quality requirement than a social media app for example. This can be a trade-off however with shorter term delivery speeds being quicker but at the expense of delivery speed in the long term, if you’re overwhelmed fixing production outages you have very little time to add new features/value.

Another aspect to consider is that of risk. What are the risks associated with defects in the software making their way into production? Different features/application areas may also have different risk profiles; for example  the “share on social media” feature may not be deemed as important as a working shopping cart. It’s also important to remember that risk is not just monetary, in the previous example a broken “share on social media” feature may bring the business into disrepute, aka “reputational risk”.

When it comes to the myriad of different types of tests (unit, integration, subcutaneous, etc.) the testing pyramid is an oft-quoted model of how many of each type of tests to have in the test suite. While the testing pyramid may be of great help for someone new to automated testing to help them learn and navigate their initial steps, as experience grows the model may no longer be optimal to some of the projects that are being worked on. Beyond the testing pyramid the different aspects of test types can be considered such as execution speed, breadth/depth, reliability/brittleness etc.

Automated tests also do not exist in and of themselves, they are part of a bigger set of processes/considerations such as pair programming, code reviews, good management, well-understood requirements, good environment management/DevOps, etc.

If you want to take a step back and look at the big picture, or know a developer or manager who wants to understand the trade-offs/benefits check out my Testing Automation: The Big Picture Pluralsight course.

You can start watching with a Pluralsight free trial.

SHARE:

In software development we already have the technical debt metaphor that helps describe the the fact that a quick and dirty approach now, may create problems in the future. For example getting a feature into production sooner but compromising the quality/design/testability/etc. may make future changes harder or more costly: hence paying interest over time for the technical debt that was just created.

The technical debt metaphor is easily relatable to by non-developers and can help facilitate discussions with business owners/stakeholders.

In the real world, paying interest is an acceptable part of life and loans in various forms are not seen as problematic for the majority of people in modern society.

Even though they are an essential part of society however, most people dislike the thought of taxes.

Would the metaphor of a software development tax provide a more visceral reaction and encourage higher quality software where appropriate?

For example, there are “taxes” that come from everyday software development, such as bug fixing or introducing code duplication. Rather than saying “this will add some technical debt to the project…”, we could say “that’s going to increase the amount of tax we have to pay to deliver this…”.

SHARE:

As another (Gregorian) year edges ever closer, it’s a period that offers a natural reflection time on what happened in the past year and the forging, often weakly, of “New Years Resolutions”.

One interesting question to ask for your work (or personal) life is: “what would easy be like?”.

For example, looking back to the past year where was the pain, sadness, frustration, long hours, constant overtime, feelings of falling behind in new technologies, failed deployments, the same bugs re-occurring over and over again, unsupportive management, mean co-workers, feelings of inadequacy, disappointed customers, etc.

you should feel like you’re doing your best work

Take some time. Make a list. Write them all down.

Now imagine what it would feel like if all of the things on the list did not exist in the upcoming year – what would easy be like?

Fixing some of the things may mean radical decisions such as quitting your job and moving employer.

Some things may not be quite as radical: better automated testing to catch bugs earlier.

You probably won’t be able to fix everything on your list. Starting from the point of view that things should be easy, that you should feel like you’re doing your best work, can be a powerful way to frame where you’re currently at and where you want to be by this time next year.

SHARE:

As the year 2015 starts its last slide into 2016, it’s the time of year that I start to think about what my 3 Wins are going to be for next year.

If you’re not familiar with the 3 Wins concept, it’s similar to goal setting but rather than focus on “what will I tick off my todo list” it’s more along the lines of “what will make me feel great, like I’ve accomplished something, like I’ve made progress…”. One way to help come up with three wins is to imagine how your future self will feel when you look back on the year and have accomplished all your 3 Wins.

It’s important to make your 3 Wins achievable, otherwise not achieving any of them could be disheartening and demotivating.

One technique to guide you, while being sounding very “managementy”, is the concept of SMART criteria.

SMART is an acronym that stands for:

• Specific
• Measurable
• Attainable
• Realistic
• Time-related (or Time-bound)

Using SMART may help if you are struggling to create your own 3 Wins.

You might have 3 Wins for your work/career and you may also have 3 Wins for personal/health/family/etc. related things. Also you can use 3 Wins daily, weekly, monthly, quarterly, or at any scale you wish; you could even have decade or lifetime 3 Wins.

SHARE:

In a previous post (5 Ways to Contribute to Open Source - It’s Not All Code) I mentioned the simplest way to be involved in open source is to simply Tweet about the project or by saying thanks to the creator/contributors. In the post i said “Most open source authors don’t get paid, saying thankyou is not only nice but is good encouragement for the authors to keep the project going”.

I’d like to propose the hashtag #opensourcethanks – it would be great to see the Twitter search for this hashtag fill up with thankyous :)

If you’re benefitting from an open source project, take a minute to send a thankyou Tweet.

SHARE:

I’m a white male. I’ve never been subject to discrimination in the workplace because of these things, so I wondered whether I have any claim to write about women in IT.

I have worked in all-male teams and in teams with (limited) numbers of women. I’ve also had (mostly) male managers and (occasional) female managers. Whilst it’s not very scientific, those teams with women in them felt different, a different energy or dynamic. There may be evidence to support this: according to this article in HBR “if a group includes more women, its collective intelligence rises”.

I recently tweeted “I'm wondering if we should seek gender-neutral versions of craftsman and journeyman in #IT?  "crafter" and "journey____" ?? #WomenInIT” and this spurred me to write this article.

Is “craftsman” too gendered a term? If so something like “crafter” is quite an easy change to make “software craftsman” becomes “software crafter”, I actually quite like this.

“Journeyman” seems a little harder, “journeyperson” seems a little clunky; perhaps “journeying software developer”? I’m not sure.

There is sometimes the view that this is all “political correctness gone mad”, so it’s probably a good idea to start with what we want our industry and our day-to-day work lives to be like.

If we accept that women improve our teams, and better teams make better software, and better software improves the world; then we need more women in IT. If this means that we (that is the “male we”) need to use a few different words here and there then so be it. We just need to think of good, non-patronising, sincere, gender-neutral (and hopefully still catchy) versions of these words.

There is of course a whole lot more to encouraging (or not discouraging) more girls to take an interest in IT, from schooling systems to general societal gender-biases.

Ultimately if I as an individual want the benefits of more women in the teams I work in, then I need to ask myself what can I do to help make this happen.

Often discussions such as these turn into “I only believe in meritocracy, I don’t care what gender you are” type statements. I too ultimately believe in the “best person should get the job” type thinking, however I also recognize that as a white male I’ve never had to deal with discrimination.

Diversity in general is usually a good thing: religion, gender, race, technical background, age, etc. A team, comprised of 10 people that are all the same, with exactly the same skills and outlooks will be weaker overall than a more diverse team.

How can we represent the world with our software if we don’t represent it within our development teams?

SHARE:

So I just listened to episode 1000 of .NET Rocks. I’ve been listening to this podcast for many years, through biting snow-covered walks in England to the cosseted comfort of an air-conditioned car in Australia when it’s 43C outside.

1000 episodes is an amazing achievement and it got me thinking.

There’s a lot of popular talk at the minute on advancing your career, becoming an outlier, and building a personal brand. The thing is there’s one underlying trait that successful people seem to possess: showing up.

"if the rope breaks nine times, we must splice it together a tenth time"

Fear is a big motivator, for the longest time (like so many other developers I’ve met) fear was present; fear of not knowing everything, fear of looking stupid, fear of not being able to find another job. For the most part I’ve let this fear fly away and one of the ways I think I’ve done this through persistence, thorough showing up.

I think if you take an approach of continuous personal improvement you will. Don’t be afraid to put yourself out into the world, whether this be blogs, user groups, Twitter, or lunchtime “brown bag” sessions presenting to your colleagues where you work.

There are always going to be people who criticize, but there are also always going to be people who say “thanks”.

There’s a Tibetan saying that “if the rope breaks nine times, we must splice it together a tenth time” – this is showing up, even when you feel you have nothing to contribute, are fearful of criticism, or feel like you can’t get anywhere – there are always choices, and showing up is one of them.

As Jim Carey says: “you can fail at what you don’t want, so you might as well take a chance on doing what you love”.

SHARE:

Open source is cool. Most of us use at least one open source project in our daily work. Even if we don’t, the websites we visit probably do.

It’s easy to contribute to an open source project, even if you don’t write code.

This diagram shows some of the different ways to contribute.

Tweet About the Project

The easiest way to contribute to a project is to either Tweet about it to tell people that it exists, or send a Tweet to the contributors / creators. Most open source authors don’t get paid, saying thankyou is not only nice but is good encouragement for the authors to keep the project going.

Submit a Bug or Idea

Don’t like something about the way a product works? Wish it had a killer new feature? Don’t remain silent, instead head over to GitHub or CodePlex or wherever the project is hosted and create a new Issue or Bug “ticket” to tell the authors about it. Even if you think your idea may not be useful to other users, submit it anyway and let the project team decide.

Contribute Documentation or Design

Even if you’re not a programmer or you don’t have time to submit code to the project you can still help. There are some great open source projects out there, unfortunately sometimes the documentation for these projects is either non-existent, out of date, or lacking. Helping to make better documentation is a quick win for everyone.

Another contribution you can make is to the project design. Maybe you’re a graphic designer or know someone who’s an artist. Help the project team out by designing the project website CSS or by contributing a logo design. A lot of projects have limited time and so focus on the code, they don’t have time for design and logo-making. This is a great non-coding contribution to make.

Contribute Code

Contributing code to open source projects is a great gift of our valuable time and keystrokes. We can make the products better for ourselves and others. It’s also a great opportunity to learn.

If you’re running an open source project consider creating a label for easy issues/bugs/work items that a newcomer can tackle.

Create a Project

This is a biggie. If you’ve got an idea for a project, go for it! It’s super easy to get started on GitHub or CodePlex.

SHARE:

I did a little survey to ask what people’s favourite albums were to code to, here’s the results. Hopefully will give some ideas for some different aural code fuel.

I’ve removed spurious entries and also those without albums which included:

SHARE: