Learn to code… then get endlessly better at coding…
- Be good at coding.
- The end.
- … but wait, there’s more.
There is truly endless training available for getting better at the craft of being a developer:
- For programming languages:
- There’s online courses, in-person courses, video training, coding Katas, live programming playgrounds, free courses, reaaaaly expensive courses, or you could just sit with language documentation and an editor and compiler and just learn by doing.
- There’s training for all the mainstream programming languages such as C#, Javascript or Ruby
- Or maybe you could learn more about languages that might give you a new angle on things such as Erlang, Haskell or Lisp and then bring those concepts back to the current language of your project making you a better and more well rounded programmer.
- Then there’s the frameworks such as Rails, NodeJS, ASPNET etc which are all huge things to learn in there own right. Again there’s many ways to learn these tools of the trade such as:
- Read the docs
- Take a Pluralsight / Coursera / course
- Try building something and do a lot of stackoverflow searching
- Pair with someone else or work on a team and learn together and from each other
I could probably go on all morning thinking of all the ways to learn more about the pure skill of programming, or “sharpening the saw” as Jonathan Stark likes to call it.
Becoming a programmer, then becoming excellent at the raw skills of programming is of course something that’s been done to death, because it’s a fundamental skill. You can’t be a programmer at all by just learning SCRUM if you still don’t to know how to write an if-else statement. I don’t have much more to add to what’s out there on this, if you want to learn to code or want to be a better programmer you don’t even need to spend money these days, just go and do it. I don’t mind lending a hand if you get stuck, but it’s not like I hold some magical secret as a programmer. I am not a member of some Pratchett-esque “Ancient Guild of Programmers” with access to the only true source of ancient’s algorithms; it’s all out there, it’s just tricky to wrap your head round turning a pile of ASCII into stuff that works, and then trickier still to make it maintainable and easy to iterate on as needs evolve change. This is a critical foundation of the skill and not something to be skipped. In fact if you’re a programmer reading this you’d do well to read the article by Tanya Reilly titled “Being Glue” (also a very good talk if you prefer video) before paying too much heed to the next section.
There is however a reason I am taking up your time in an era of all-the-information-you-can-eat. There are other aspects to being a truly great programmer that go beyond ingenious use of raw code. Having been around for a while I’ve started to see patterns in what makes for great teams that are a pleasure to work in and who get things done. I want to get that captured here so that good programmers can learn how to be one of those sought-after people, and to help leaders and managers know what to filter for when building great teams.
Beyond coding - being a really great developer
- Leave ego at the door.
- Be humble.
- Speak up when you think things need to be different, even if it’s not a programmer thing.
- Focus on success/failure of the project above individual productivity.
- Focus on small iterative delivery
- Not just knowledge of agile structures such as scrum, xp and kanban but a drive to see them done well and iterated on.
- Ability and desire to educate upwards - you are the expert, help those above and around you understand.
- Belief that team output is more important than personal output.
- Ability to separate ones own ego from a technical opinion - so when an idea is debated it is not viewed as a personal attack.
- Constant iteration in personal productivity, e.g. learning to touch-type, creating aliases for common commands. It’s not so much that this makes you faster, it’s more about what it says about the attitude you bring to everything. If you don’t constantly improve your own things, would you constantly improve your client/company things? These things pay compound returns, particularly by freeing up mental space for the next thing.
- A drive for simplicity.
- An avoidance of “clever” - valuing future maintainability and legibility for other programmers over your own programmer ego. (This one is straying into pure programmer skills but I mention it as it’s not something you’ll get from a course on C#).
- Consider how code and systems could behave not just under perfect “happy path” conditions, but how it would behave under unexpected conditions, failure, bad input, maybe even when in the hands of a hostile attacker. Would it be catastrophic? Would it be easy to troubleshoot and fix? Would it give a hacker a leg-up to even greater evil powers?
- Empathy for your team.
- Empathy for your users, including a11y needs.
- A desire to be in contact with end-users (whether or not the organisation is supportive of this, I love that GDS style teams have dedicated “user research” functions to connect programmers to end users).
- Know when it’s important to polish and when to just ship fast.
A lot of this is down to personal growth, which takes a lot of work. I’ve recommended some books that are relevant to this in A book list for my children, and there’s more scattered around my goodreads list. If you’re a programmer then work on these things. If you’re a hiring manager then be sure to filter for these things, you can’t train them in time it takes to run a project, and maybe not even over an entire employment.