Being a valuable developer: it’s not only about the code 🤷🏻‍♂️

Photo by heylagostechie on Unsplash

💡 While code and knowledge of basic programming is of course super important, this does not necessarily make you as valuable to your team or company as you might think. There’s a bunch of soft skills that come with the job of a developer that are as — if not more — important than knowing what consts and functions to write. This article will cover clear communication, a learning attitude and providing valuable feedback.

Without trying to sound like an absolute tool right away, I’d like to think of myself as a non-typical developer. Yes, I do enjoy a good run of focus-mode hours with my headset on while coding. And I’m excited when I wrote a piece of code that ‘just feels right’. But the code itself is merely the outcome of a different, more interesting process:

1. Understanding the real problem 🤔
2. Outweighing possibilities, based on impact and complexity ⚖️
3. Recognising what steps to take (and where it belongs in your codebase) 🗒️
4. And finally: executing the steps necessary — writing the code 👨🏻‍💻

Let’s swiftly go over these 4 steps to see why I think these steps matter.

Understanding the real problem 🤔

This step was, in my opinion, heavily underexposed during my education. To me it seems that this step is what separates you — the creative, smart professional — from a production company. Instead of blindly executing what the client asks you, you try to understand what they’re really asking you. Most of the times this requires listening carefully to your clients and reading between the lines. This could also mean that you’ll be challenging your client; the idea they came to you with might not necessarily be what could bring them the most benefit. Perhaps there’s an easier (and cheaper) alternative to reach the goal. Or maybe you can poke holes in your client’s train of thought that makes them realise they might be sitting on a potential (project cost) landmine here. From my experience, clients will not take your opinion as disobedience, but rather see it as valuable feedback. You’re in a relation here that works both ways — or at least, you should try to be 🙂

Outweighing possibilities ⚖️

After fully understanding the problem that needs solving, there’s probably a bunch of ways you could handle it. Rather than diving headfirst into the first solution that pops into your mind, I think it’s important to explore various options, at least these:

• The Path Of Least Resistance; what’s the easiest and quickest way to deliver value? Even if this means hardcoding a bunch of variables or logic that — in an ideal world — shouldn’t be there, maybe for now it’s exactly what you client needs.
• The Ideal World; what if there was unlimited time and budget? How would you solve it? Would you perhaps setup a separate service for this specific purpose? Or would you refactor a different part of the code that has some overlap with this case? Or is there a particular library you haven’t used before but seems promising?
• The Golden Mean; is it possible to meet halfway?

I also think it’s not enough to only outline what option you’re advising your client to go for. As a client I would like to know a couple of things:

• What do you recommend — and why?
• Are there advantages to a specific approach in the future — and which?
• What is the estimated price range for each option?

It’s my opinion that by including a client into your own train of thought, a mutual understanding is created; The client feels that you know what you’re doing, and you develop a gut feeling to what your client finds important. This can prevent your clients from having the wrong expectations from you, and vice versa.

Recognising technical steps 🗒️

Whenever I have settled on a solution — most of the times I already do this in the previous step — I like to map out the various parts of the code that I will need to touch upon. We use Asana as the tool to track our projects, so I’ll jot down the steps in a ticket. This way, I’m forced to already think about if there’s any dependencies between parts of the code and double check if all the steps I’ve written down will actually solve the initial problem. In the past I’ve found myself stuck on a particular task that seemed to be never-ending, simply because I made too much assumptions about the actual work beforehand.

By adding this step to your workflow, you could reduce the amount of awkward conversations with your client about a task exceeding the budget. Most of the times, by writing down the steps before actually executing it, you can have this conversation before you started the task. This creates a different sentiment, to my experience.

Executing the steps 👨🏻‍💻

It goes without saying that this is the most important step, as we all ❤️ our code 🤓. To me it seems that a valuable developer not only writes the code that actually works, but also makes sure a couple more things are handled:

• Documentation and commenting; so that in the future it’s easier (for other developers) to follow along and understand choices you’ve made along the way. 📄
• Code duplication is reduced as much as possible. This could require a refactor of an existing component (let’s say for an image) to add a few extra settings or properties, instead of having an ImageWithShadow component and an ImageWithHeavyShadow component — for example.
• Inform your client with clear instructions on how to test and use the functionality you’ve just provided them with. By doing so and letting your client accept the functionality by testing it, they’re less likely to come back with questions afterwards. I find it really rewarding to be able to — also mentally — consider a task done and completed ✅
• Keep an eye on your time (and therefore your budget). ⌛👀 I think we can all agree to the statement that ‘Our time is valuable, since it’s limited’. Not only professionally, but also personally. When working on a task, keep in mind that the goal is not only to deliver the value to your client, but also to deliver it within a certain timeframe so that you’re also valuable to your company (or if you’re a freelancer — to yourself).

Too many times we’ve forgotten this last step, and found ourselves enthusiastically trying to deliver the extreme maximum of value to our client (or to feed our own egos 😉) and spending way too many hours in the process. This not only means that you’re working ‘for free’ (which isn’t per se an issue), but it also means that you’re not available to do (paid) work for other clients. That’s time that you’ll never get back, no matter how hard you work on the next task.

It’s inevitable that this will happen; you bump into an unexpected issue that needs solving. But, doing so will require some time you didn’t account for. Instead of burying your head into your laptop and trying to still finish it in time, take a breather. Try to think about how this will affect your initial estimation. Most of the times when I encountered this, calling the client and explaining the issue ánd the solution I have in mind (including revised estimation) was the best way to go. Most of the times they would understand certain tasks required a bit more work than expected, and the budget would be corrected. ⚡

Final words / disclaimer

I’d like to finalise by saying that all of the above is what I think makes a valuable developer. In no way it’s meant to come across as a Holy Set Of Rules That You Should Obey Or You’re A Lousy Developer. As always, it could work very differently for you. These are just some of the things I think are important in doing my job as a developer properly in a small, digital agency. Perhaps in your company, understanding the problem is done by someone with a different job title. Or maybe the budget is closely monitored by somebody else. Probably, when you’re working in a product development team, your tasks are estimated by complexity — not hours — therefore making it harder to monitor it as rigid as hours*.

💬 If you found this to be useful, or have feedback, please let me know. I’m curious if and how this applies to you.

* The argument of keeping track of your budget, even if it’s in complexity, still applies I think