The winding path of being a developer

Learning to code is a lifelong endeavour. Around every corner, you find more to learn that you didn’t know existed.

I talk to a lot of compsci students, and many of them are under the impression that they learn to code at university, and then just go apply that knowledge in their career. Maybe they’ll learn some “business stuff” along the way. Professional coders will know that you’re barely at the start of your journey on graduation day.

After a conversation with @PrototypeAlex where we discussed the many stages we have seen developers at, I felt inspired to write them down. In the 30 years I’ve been coding, I’ve gone through almost every stage below, some more painfully than others.

Can you recognise yourself at any of these stages? And what have I missed? There are a bunch more stages that are invisible to me; we never stop learning and discovering. Leave your thoughts below.

The Copypaster

Coding is hard, but other people have solved your problem before! Your browser goes to Stack Overflow when you type “s” in the location bar, and you grind through your hours pasting in different code fragments to see which one does what you need it to do. It’s frustrating at times, but you generally come up with some working code.

What you’ll learn: You realise the only way you’re going to get good at coding is to work through problems yourself. Even though it slowed you down, you only access Stack Overflow a couple of times a day. Your coding skills improved and now you’re a lot faster and way less reliant on other people’s code.

The Large Methodist

You’re good at coming up with code that does what you need it to do, but nothing ever works first time, does it? And requirements are always changing. So you stick in some code, and mess with it until it’s going. Looks like it works? Ship it! You’re crazy productive and getting praise from your product manager.

What you’ll learn: It clicks that code is read by computers, but also humans. You started working with other people on projects, and they struggled whenever they had to read your code. You hadn’t written any tests, and so they couldn’t even refactor your code to make it better without worrying that they’re going to break it.

You realise that taking the time to make the intentions of your code clear might make you slower to start with, but means your code can be easily maintained in the future. Your teammates are way happier with you now, and you’re delivering long-term value to your company.

The Clever Coder

You’ve learned the tricks of your favourite language now, and found you can compress some code down into a clever little method. You sit back and congratulate yourself on how compact it is! That’s some great code right there that really shows off how skillful you are.

What you’ll learn: Being clever might be satisfying, but you realise that it’s not very sociable. Other people’s brains don’t work the way yours does, and even though they’re good coders, it takes them a while to understand your “clever” code. It’s way better when your code has really clear intentions to everyone who reads it. Now you’re leaving being “clever” for the Friday code golf competitions!

The Commentor

It’s important for people to understand your code, so you make sure it’s really well commented. Every few lines you explain what’s going on. This is so readable!

What you’ll learn: You realise that often the comments don’t accurately describe what the code does, and that surprisingly makes it harder to read. You decide that you’ll use comments to explain why the code is written the way it is, not what the code does.

Now your code itself is highly readable, using descriptive variable names and plenty of well-named methods. Your high-level methods almost read like English! You’ve only got comments where you couldn’t make the code explain something.

The Code Refactorer

This code is shit. It’s legacy — over five years old — and we should just chuck it out and start again. Seriously, we could write it so much better. It’d be so much clearer and way easier to work on if we did.

What you’ll learn: The profits made from the “legacy code” are what is paying your salary. You’ve worked on a few codebases now, and realise there isn’t a mature codebase in the world that’s not horrible in places; you know there is always technical debt and hindsight is 20/20.

You now keep your refactoring to a minimum as part of your day-to-day changes, only touching what is required to ship your change. You champion modest refactoring projects from time to time, to target the very worst and most touched parts of the codebase. You put your effort into making sure new code is well factored. You recognise that there needs to be a good business case to refactor.

The 100% Adherent

You’ve got your editor tricked out to auto-lint your code to a standard, and you run metrics on your work every time before you check it in to make sure it’s “good code”. Everything you write is done test driven, and your tests have 100% coverage. You get a warm, cozy feeling knowing all your work is quantifiably great.

What you’ll learn: Although most good code has good metrics, you find out that not all code with good metrics is good code. You realise you had been leaning on metrics, standards and best practices too much, instead of using your skills to make sure your code was well-factored.

Now you actively engage your mind to write beautiful code, read it over when you’re done, and get code reviews to make sure you’re on the right track. You’ve learned the principles behind what the tools measure, instead of just trying to write code that makes the metric a certain number. You still use metrics tools, but across the codebase to get a high-level understanding of where the code is at and what could be looked at next to improve.

The Latest Hotness

Using the latest technology means your code is cutting edge! You love trying out everything new in your production codebase. You’ve got a functional programming style going in Ruby, and you were first on to the NoSQL scene for your form-based application. These new technologies are much more productive and elegant. It’s so exciting and you know you’re delivering great value to your employer; they’re not going to be left behind in the dark ages.

What you’ll learn: The latest hotness feels good, but you find problems with it. You spent a lot of time working around the edge cases in the new technology that no-one’s really come across yet. There weren’t a whole lot of support or libraries available for the new framework you were using, and there weren’t many people you could hire with experience using it. One of the products had a failure condition that lost some data, and that was professionally embarrassing for you.

It is a more “boring” route because you really love new tech, but you realise using established technologies for your production products delivers a lot better value for your company. You spend your evenings dabbling with pet projects to keep the excitement alive and your skills up for when the latest hotness becomes cool enough to bank your business on.

The Pattern Purist

Clever people have come up with elegant patterns to describe good code, and you use them in your code. All the time. A lot of conversations you have with your workmates revolve around the best pattern to use, or how something could be written better with a different pattern. You know that by taking this approach, your code would be loved by the clever people who discovered these patterns.

What you’ll learn: After watching your peers get a lot done in the time it takes you to do something small, you realise that maybe you’re a bit too attached. After all, a pattern is just a rough template; they’re not gospel, but something to guide you to making something useful.

You find that now you’ve internalised these patterns, you can stop thinking about “implementing the X pattern” and just code using your intuition and experience. This allows you to deliver a lot of pragmatic code. (And your workmates are happy you’ve stopped talking about patterns, too.)

The Premature Optimiser

Monoliths are inelegant, and you’re all about elegance in your architecture. Small microservices, each managing a single concern of your application, with a clever messaging solution in the middle, is clearly the way to develop your new application. You start as you mean to go on, and this will ensure your application can go to Internet Scale.

What you’ll learn: You find that microservices slow down development a lot by introducing all sorts of complexities you wouldn’t have had in a monolith. You think you would have been able to get to market a lot faster, and therefore making money to fund your development faster, if you had gone with a more simple design to start with.

Because you’ve worked in larger teams, you know it’s hard to have 40+ people working on the same codebase; everyone has to know everything about the system to work effectively on it, and that doesn’t scale. Now you see the pros and cons, you delay your decision to refactor to services until the time when it makes business sense.

The Oracle

Your code is amazing. Everyone tells you so. You’re respected in your industry. People at your company form a line beside your desk to get your opinion on their code. Your job is stressful because of the demands on your time, and you feel worried that you’re a linchpin in your organisation. Bad things tend to happen when you’re away sick.

What you’ll learn: You realise being an oracle is not great for the health of your organisation. Instead of sitting by yourself, writing amazing code, you spend your time now proactively training the developers in your organisation. You get a lot less code written, and your team’s output falls as a consequence. But you know that if you can upskill every developer on your team, they’ll eventually make up for the code you’re not writing and then surpass it.

You find that developers are now more confidently making their own decisions, and although sometimes they’re not the right ones, they’re learning from their mistakes and becoming great developers thanks to your guidance.

The Defender

You’re among the most senior developers in your big organisation, or the lead developer in a smaller one. You help out with business decisions, and train your developers to be amazing. But management/your clients are always trying to make bad decisions, and you must defend your team against their incompetence. They want stupid features that don’t make sense, or the features are going to complicate the codebase. A lot of your time is spent fighting battles to protect your codebase and developers, and you’ve damaged some relationships because of your passion to keep your team happy.

What you’ll learn: After many broken relationships, you realise your codebase, and job, is at the grace of your management and clients. You accept that sometimes non-technical people can miss the technical consequences of their requests, and make it your mission to be part of their team and give them good information and advice so they can make good choices. The way you’ve found to do that is to form strong and trusted relationships with them.

Once you’ve said your piece, you know the best strategy is to get out of their way so they can make the right decision for their business. You’ll be there to support them if anything goes wrong, but you’ve found that, quite often, things don’t go wrong because you’ve built great relationships and the worst decisions are being headed off early.