Career and skills advice

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.


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.


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!

18 thoughts on “Career and skills advice”

  1. I always find there is a missing piece of advice when defining what makes a good programmer. And that is speed. In this business environment your handlers generally want you to knock out code as quickly as possible. And there are many programmers who knock out code as quickly as they can type. But nobody seems to talk about that.


  2. @Blaidd: I’m fortunate enough to have worked in places which do actually care about the code being maintainable. Lots of people can write code quickly. Very few people can write *good* code quickly. (I’m not one of them.)


  3. @skeet Yep – I’m with you on that one. But there has to be a tension between writing perfect code and just getting the thing out the door. I’m not really sure what the answer is.


  4. Thanks, Jon. Your advice is much appreciated. I discovered that I’m pretty bad at interviews (even though I thought otherwise if I’m honest), my brain shuts and I start rambling. :) I guess it comes down to confidence and like you said – communication skills, which are apparently much more important that I’d like.


  5. @Dimitar Dimitrov: As with all skills, you’ll become more confident once you start doing it more.

    Whether it’s giving a presentation, interviewing or debugging; do it more often and you’ll get better at it and as you get better at it, you’ll become more confident.


  6. @Patrick Huizinga: Yeah I agree, I think part of my problem is that people like Jon Skeet, Eric Lippert, Joe Duffy (I can go on) seem to be on a different planet in terms of knowledge about computing, it’s quite frustrating. I mean, when I’m doing an interview I feel like I’m expected to know something close to that, it’s a bit overwhelming. I hope I’m making sense. There are so many things to study, try, work with – it’s hard. For example, recently I started working on a compiler for my own toy programming language (nothing at all fancy), but just by venturing into this, I’ve opened a universe of topics that I didn’t know much about. It’s a bit of a rabbit hole, I doubt it ever ends. Certainly you don’t need all this knowledge to “ace” an interview, but I sure as hell feel like I need to and I panic (in my own way). I think I’m rambling again :)


  7. Thanks for the advice John. I really appreciate your communication section. Although most of it isn’t new it is good to read it from time to time, it helps to remember and reflect.


  8. “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”

    That’s my favourite bit of advice – you don’t realise how much easier you are making the next dev’s job (for large 10+ teams) if you leave just a summary in a method, or a readme! Particularly when the people have left the company, and you have to effectively reverse engineer a large stack trace of 5-10 classes to figure out what’s going on. I think it also shows thought a little extra thought and care on your part and not just churning out code.


  9. I think, being specialist in one area requires familiarity with adjacent areas. For example, being a C# expert(for example, Jon Skeet) you require familiarity with AOP in general, event based programming, functional programming(Linq), and meta-programming(reflection, codegen, etc).

    For being a Javascript expert, you again, need to know all the nuances of Javascript and browser quirks, which lead to (at least generalized) understanding of how browsers work internally and that leads to learning web programming at least in general.

    So I see the best advice I got here was the one Eric Lippert got, be a specialist in an area, and you will become a decent generalist in areas in the vicinity.


  10. Thanks for the all great points you made there, Jon.

    I was wondering what your opinion is on current trend where most employers are asking candidates to go through academic style algorithm questions – both on coding platforms or in-person live-coding. These interviews affect many senior programmers, because most of them are not working on algorithm related things on day-to-day basis. Even though someone has years of experience building successful software for several companies, he/she may have to struggle to answer questions, real time under the interview pressure, that some PhD solved long time ago.


    1. I do know what you mean – I think some ability to express your understanding of algorithms is important, but I certainly wouldn’t expect someone to be able to implement a hash table in an interview, for example. What I think can be useful is working through a relatively simple algorithm with help from the interviewer, nudging along etc.

      Is it entirely realistic of day-to-day coding? No… but for all that we sometimes hear of companies getting interviewees on-site to work alongside them for an entire day, I suspect that’s out of reach for many companies.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s