It feels a little odd even to write this post, but I receive quite a few emails asking me for advice on how to get better at programming, how to get through interviews, whether it’s better to be a generalist or a specialist etc. I want to make it very clear right from the start, I am not a career guidance expert. I have very little evidence that this is good advice, and it may well not be good advice for you even if it’s good advice in general. Oh, and don’t expect anything shockingly insightful or original, either. You may well have heard much or all of this advice before.

So, with those caveats out of the way, my random thoughts…

Communication, communication, communication

Software is all about communication, whether you’re writing a design document, answering questions on Stack Overflow, giving a talk at a user conference, being grilled at an interview, or simply writing code. In fact, writing code is about communicating with two different audiences at the same time: the computer (compiler, interpreter, whatever) and whoever is going to read and maintain the code in the future.

In fact, I see improved communication as one of the primary benefits of Stack Overflow. Every time you ask or answer a question, that’s an opportunity to practise communicating with other developers. Is your post as clear as it can be? Does it give just the right amount of information – nothing extraneous, but everything that’s relevant – in a coherent way? Does it strike the right tone with the reader, suppressing any frustration you may currently be feeling either at the problem you’re facing or the perceived flaws in someone you’re replying to?

Stack Overflow is just one way you can improve your communication skills, of course. There are many others:

• Write a blog, even if you think no-one will read it. You may be surprised. If you write about something you find interesting – and put time into writing about it well – it’s very likely that someone else will find it interesting too. If you enjoy this enough, consider writing a book – there are plenty of options for publication these days, from traditional publishers to online-only approaches.
• Find opportunities to give presentations, whether that’s at user groups, conferences, or at work. I do realise that not everyone likes presenting to large groups of people, even if I find that frame of mind hard to empathise with. (Who wouldn’t want to be the centre of attention? Yes, I really am that shallow.)
• Take pride in your communication within code. Spend a little bit longer on documentation and comments than you might do normally, and really try to think about what someone reading it might be trying to discover. (Also think about what they ought to know about even if they weren’t aware that they needed to know it.)
• Read a lot, and reflect on it. While we’re used to commenting on the quality of fiction and perhaps blog posts, we don’t tend to consciously consider the quality of other written work. Next time you’re reading the documentation of some library you’re using, take a moment to ask yourself how effective it is and what contributes to the quality (or lack thereof).

You may well find that improving your communication also improves your thought processes. Clarity of ideas and clarity of expression often go hand in hand.

Coding and reflecting

Write code and then look back on it – ideally after significantly different periods of time. Code that appears "cool" today can feel immature or self-serving six months later.

Of course there are different kinds of code written under different constraints. You may find that if you’re already a professional software engineer, you aren’t given enough time for critical evaluation… but you may have the benefit of code reviews from your peers. (Code reviews can often be regarded as a chore, but if you approach them in the right frame of mind, you can learn a lot.) If you’re contributing to an open source project – or perhaps creating one from scratch – then you may find you have more opportunity to try multiple approaches, and look back at the code you’ve written in the past.

Reading other people’s code can be helpful too, though I find this is one of those activities which is more talked about than actually done.

Specialist or generalist?

Eric Lippert has written about how he was given advice to pick a subject and become a world expert on it, and I think there’s a lot of sense in that. On the other hand, you don’t want to be so constrained to a niche area of knowledge that you can move in the wider world. There’s a balance to be struck here: I’m a "generalist" in terms of having relatively few skills in specific business domains, but I’m a "specialist" in terms of having spent significant time studying C# and Java from a language perspective. Similarly I’m very restricted in terms of which aspects of software I’m actually competent at: I’d like to think I’m reasonable at library or server-side code, but my experience of UI development (whether that’s web or native client) are severely limited. I’m also familiar with fewer languages than I’d like to be.

You’ll need to work out what’s right for you here – but it’s worth doing so consciously rather than simply drifting. Of course, making deliberate decisions isn’t the same thing as executing them: a few months ago I decided it would be fun to explicitly concentrate on application development for a while (WPF, Windows Store, Android and iOS via Xamarin) but so far there have been precious few results.

Sometimes people ask me which technologies are good in terms of employment. That can be a very local question, but my experience is that it doesn’t really matter too much. If you find something you’re passionate about, then whatever you learn from that will often be useful in a more mundane but profitable environment. Technology changes fast enough that you’re almost certainly going to have to learn several languages and platforms over your career, so you might as well make at least some of those choices fun ones.

Interviews

A lot of advice has been written about interviews by people with far more experience than myself. I haven’t actually been an interviewee very often, although I’ve now conducted quite a few interviews. A few general bits of advice though:

• Don’t exaggerate too much on your CV. If you claim you’re an expert in a language and then forget how to write a method declaration, that leaves a bad impression.
• Find out what the company is looking for beforehand, and what the interview is likely to consist of. Are you likely to be asked to code on a whiteboard or in a text editor? If so, it wouldn’t be a bad idea to practise that – it feels quite different to writing code in an IDE. If you’re likely to be asked questions about algorithmic complexity but university feels like a long time ago, brush up on that a bit.
• Be interesting! This often comes down to being passionate about something – anything, really. If the only motivation you can give is "I’m bored with my current job" without saying what you’d find interesting, that won’t go down well.
• Listen carefully to what the interviewer asks you. If they specifically say to ignore one aspect of coding (validation, performance, whatever it might be) then don’t justify your answer using one of those aspects. By all means mention it, but be driven by the guidance of what the interviewer has specified as important. (The balance may well shift through the interview, as the interviewer tries to evaluate you on multiple criteria.)
• Communicate as clearly as you can, even while you’re thinking. I love it when a candidate explains their thinking as they’re working through a difficult problem. I can see where their mind leads them, how intuitive or methodical they are, where they may have weaknesses – and I can guide them with hints. It can be worth taking a few seconds to work out the best way of vocalising your thoughts though. Oh, and if you do write on a whiteboard, try to make it legible.

Conclusion

So that’s about it – Jon’s entirely subjective guide to a fun and profitable software engineering career. If you choose to act on some of this advice, I sincerely hope it turns out well for you, but I make no guarantees whatsoever. Best of luck either way!