Investing in your skills development – how do you choose where to invest? (part 2).

I’ve written before about the importance of keeping your skills up to date, and this is a followup to a previous post, answering the question ‘how do you decide where you should spend your time?’

You can never keep up with everything, every new programming language, every new tech stack, every new trend; you need to understand and acknowledge that first.

Next, decide what matters to you, and where you want to spend your (limited) time keeping up to date. This is different for everyone, but it could be any combination of:

– keeping up to date with the tech you’re currently working with (all or parts of)

– keeping (or getting) up to date with ‘something else’ that maybe next on your horizon

– keeping an eye on upcoming and emerging tech trends. Trends come and go over time, some last longer than others. You can’t jump on every new thing that comes up, so you need to make your own decisions on whether something is likely to be part of your future or not. In other words, would it be worth investing your time in this trend or not?

The last point is hard when starting out because you have no past experience to compare against, but spending some time reading the chatter online will give you a rough feeling of whether something is increasing in popularity or not.

As with everything, you need to sensibly assess tech trends in order to work out what is pure hype and will never go anywhere, vs things where there’s some substance and is likely to evolve into something you should get more familiar with.

It takes time to learn your first programming language

New developers frequently post online questions like “how long does it take to learn JavaScript” or “how long to become proficient with Java”. The thing is, everyone is different, we all learn differently, we all learn at different rates. Don’t pay any attention to whether some other developer learned language xyz in 1 week or whatever time they say.

Rather than focus on fixed time goals, it’s important that learning to develop software is an ongoing and continuous activity. You don’t ‘finish’ learning how to code, there is always something new to learn because the industry is still evolving, or tools, libraries and frameworks are always evolving. Trends also change. What’s the hot new frontend framework today may be replaced with something completely new 6 months from now.

It’s impossible to give a precise answer to ‘how long will it take me to learn language xyz’. Instead of thinking about a finite journey, you need to accept that a career in software development is a career of continuous and endless learning, and to keep your skills relevant and up to date you need to commit time and effort to your skills development.

Why every developer should write a blog

It’s unavoidable at some point, if not on a regular basis, that as a developer you will need to produce some type of content in written form to share with your team or others. Since clear and concise technical writing takes practice, it makes sense that you should make a proactive effort to practice your writing. Writing a blog is a perfect (and easy, low or no cost) opportunity to get some practice.

There’s plenty more reasons however why blogging is beneficial and useful for all developers. In no particular order, here’s a list of reasons why you should be blogging:

Note Taking

Technology in software development changes and evolves fast. Chances are you came across at least one thing new over the past couple of days, and if it’s not going to be something you’re going to use on a regular basis, it helps to keep notes that you can refer back to at some point in the future. I can remember that I came across something similar a few months back even if I can’t remember the exact details, so creating a short one pager with some notes to refer back to later is incredibly useful.

Sometimes I also keep notes on the approach I took to solve a problem if it was something that took several steps. If I come across the same problem again several months from now, I’d rather refer back to my notes than working it out from scratch again. If the problem or the steps to solve it were interesting or I think may be interesting to others, I usually capture these steps as a blog post and share on my blog.

Collecting Snippets of useful code

Depending on what the information is, I vary how I capture the information. If it’s something that would be useful to capture as step by step in instructions with additional explanations and details, I usually capture these as a blog entry. If it’s something I don’t want to publicaly share, I sometimes create private posts that are not shared, or keep them separate in a notebook in Evernote.

If it’s a snippet of useful code, for simple, short lines of code I collect snippets using Github’s Gist (here’s a link to my public Gists as example of what I keep there), or for longer worked examples I create a project on GitHub and commit a code example there (the majority of my projects on GitHub are code examples where I was looking at something new and put together a worked example as part of learning whatever that new thing was – you can can take a look at the type of thing I keep on GitHub here).

Sharing Lessons Learnt with Others

The majority of time when I search for info on how to use a new library or framework, the most useful content that I find is usually an article written by a developer who worked through the steps on how to use something.

That content would not be there online unless that other developer took time to create the content and share. The great thing about the internet for software development is that content is easy to find if you Google, but that content would not be there unless those people took the time to write and share in the first place. If you have something to share, even if you think it’s obscure or might not be useful, there’s always someone else who is working on something similar, and they might be struggling to work something out – help out your fellow developers and share your knowledge.

Every developer has something they’ve worked on that would be useful to another developer trying to learn and get up to speed on that same thing. Even if you’re a new developer with a few months experience, you still have lessons you’ve learnt from your own experiences that would be useful to another developer with less (or even more) experience following their own skills development path.

Learning by doing

I’m often asked ‘how do I learn [insert something new here]?’, or ‘what approach do you use for learning something new?’. You can learn many ways, we all have different styles of learning so you should experiment to find out what works for you

In software development, learning by doing should never be ignored as a useful technique. It’s one thing to learn something at a high level by listening to a podcast, reading something online or in a book, but the next step if you really want to learn the ins and outs is to do it yourself.

Here’s an example of why this approach is valuable. You overhear a guy talking about how a machine is turned on: ‘to turn on the machine you press this button’. Some time later someone else asks you how to turn on the machines, and remembering the conversation earlier, ‘you press this button here’ – the other guy presses it, and nothing happens. Huh, what went wrong?

If you’d tried to turn on the machine yourself earlier you would have found out, probably by trial and error, that there’s a key and it needs to be turned to the ‘on’ position before you press the button. There’s no way you would have learned this just by the earlier conversation, but if you’d tried to turn on the machine yourself, if the key was in the ‘off’ position then the button wouldn’t have worked and so you would have started to investigate further, get the manual, or go and find the other guy and ask some questions.

This is rather contrived example to make a point, and how much detail you need or want to know about any given topic of course varies. However, in software development, I don’t think anyone would argue that you don’t learn to program by reading a book; you learn by doing, you learn by writing code. Go write some code, you might learn something.