A reading list for software engineers

A mega list of all the advice and articles I think are really worth investigating

07 June 2019

NB: Got suggestions? Comment on the Gist I use to keep this updated!

You should know in advance that I have a bias towards hacker and maker culture as having shared roots in creativity and creative thinking; that I ~like~ love functional programming, and I think that somehow (at least in the UK) in the software engineering game we manage to simultaneously do down both the importance of strong tech skills and of strong people skills (sigh). Both of these skills can be learned, as can, well, pretty much anything if you’re a true hacker. Anyway.

The most important stuff

This is the basics for working in a professional context. Your side hacks are largely a different game entirely.

Absorb what is useful. Reject what is useless. Add what is essentially your own.

Bruce Lee

Finally, decision making is hard. To be a doer, you have to get good at making decisions and owning the consequences. My friend Jake used to say “you’ve gotta pick a path!” whenever there was a quandry, and most of the time any decision is likely to pan out better than not making one at all.

Or, as Rush had it, because they enjoy contradicting me, “if you choose not to decide, you still have made a choice”

Getting good at owning mistakes and dealing with failure will make this easier to commit to over time, and you’ll usually find you learn more from the failures than from the successes.

Engineering skills and career advice

Don’t focus on any one thing - learn general principles you can apply everywhere.

Learning how to learn is the most valuable skill you can optimise.

Learn about:

I could put zillions of recommendations here, but I’ll mainly recommend a few videos (in this order):

  1. Inventing on Principle - Bret Victor
  2. Simple Made Easy - Rich Hickey
  3. Web Development is Distributed Systems Programming - Mikaela Patella
  4. Turning the database inside out with Apache Samza - Martin Kleppmann
  5. Hammock Driven Development - Rich Hickey
  6. Death to Bullshit - Brad Frost


Whenever I’ve had management responsibility, I’ve subconsciously put people into two buckets. Problem solvers take a problem I have and make it go away. Problem transformers take a problem I have and solve it by bringing me the next problem. (I’m omitting non-performers who don’t solve problems at all as beyond the scope of this post.)

Erik Dietrich, from The Polyglot’s Dilemma.

Life at startups and small companies vs big ones

Even before I got into engineering, I’d mainly worked for small companies, although I have also worked for national retailers and for the NHS.

I could write about this one forever.

Programming languages

I might have to expand on this in future, as I don’t really know where to start (or end!)


Again, so much to post here, so I will update as things spring to mind.


I don’t think I’ve managed people long-term enough to really write about it myself, but luckily there are plenty of people that have.

Most of it boils down to:



I’ve only ever participated in the hiring and interview process for a large organisation, and maybe I’ll blog about that some time. Until then, read Joel Spolsky and PG:

Yeah, so smart people that get things done, and no assholes. Sounds simple, right?

A few big things I learned, however, I will write about here:

Personal and professional development

Consider the value apex when thinking about your job - is it a fair trade in terms of knowledge, or is it all take, no give on their side?

The reason that skilled employees quit, however, is a bit more complicated. In virtually every job, there is a peak in the overall value (the ratio of productivity to cost) that an employee brings to [their] company. I call this the Value Apex.

On the first minute of the first day, an employee’s value is effectively zero. As that employee becomes acquainted with [their] new environment and begins to apply [their] skills and past experiences, [their] value quickly grows. This growth continues exponentially while the employee masters the business domain and shares [their] ideas with coworkers and management.

However, once an employee shares all of [their] external knowledge, learns all that there is to know about the business, and applies all of [their] past experiences, the growth stops. That employee, in that particular job, has become all that [they] can be. [They have] reached the value apex.

If that employee continues to work in the same job, [their] value will start to decline. What was once “fresh new ideas that we can’t implement today” become “the same old boring suggestions that we’re never going to do”. Prior solutions to similar problems are greeted with “yeah, we worked on that project, too” or simply dismissed as “that was five years ago, and we’ve all heard the story.” This leads towards a loss of self actualization which ends up chipping away at motivation.

Skilled developers understand this. Crossing the value apex often triggers an innate “probably time for me to move on” feeling and, after a while, leads towards inevitable resentment and an overall dislike of the job. Nothing – not even a team of on-site masseuses – can assuage this loss.

Up or Out

If your current job isn’t working for you then continue to…

Getting jobs, changing jobs

Here’s a non-exhaustive list of questions I will try and ask a prospective employer:

If you get an offer, make sure you negotiate politely but firmly to get to a mutually beneficial arrangement.


Fork me on GitHub