Contrary to popular stereotypes, effective developers are not the ones who ‘live and breathe code,’ stay up through the night to fix bugs and know their code by heart. An effective developer spends time solving the right problems in the right way… at least according to Sven Peters.
Sven has been working in developer advocacy for more than ten years (on top of being a software developer for ten years). He has led many initiatives helping developers to be more effective and “do the job of their life.”
He shared some advice at the Infobip Shift conference that will help you work smarter, not harder.
Take your time
The best, or the most efficient developer, is not the one churning lines of code as fast as possible. Writing good code takes time and a lot of thinking.
The job of a developer is sometimes just to stare at their code and think. A good developer writes code that their colleagues can read and understand (fun fact: developers spend more time reading than writing code).
Don’t show off
Resist the urge to write “clever code,” the one that is as concise as possible. Not only your colleagues won’t be able to understand it, but you yourself probably won’t get it three months after you write it.
Resist the urge to show off, to prove to yourself and everyone else that you know how to write clever code. Instead, strive for somewhat simpler code – everyone in your team needs to understand what you are doing.
Make code reviews more pleasant
The point of code reviews is to inspire junior devs and to ensure consistent code quality. Still, a lot of teams struggle to do that. Not everyone is comfortable having their code scrutinized and tested by coworkers.
I suggest you get inspired by the BitBucket team, who introduced a couple of simple rules for code reviewers:
1. Before commenting on anything, try to understand
2. Criticise ideas, not people
3. Don’t rant; make suggestions
4. Don’s spoon feed: Never say, “replace this with that”
5. Comment on positive things as well
Your team does not have to adopt all of their rules, you can make your own, but the general idea is to try and make code reviews more pleasant. Better code review experience leads to doing it more often – and that, in turn, leads to better code.
Learn and unlearn
I’ve been there. A junior developer who is super excited about every new technology that comes my way. A new frontend framework?! Let’s rip out the old code and replace it with a new one.
As you get older and you’ve been through buzzwords and technology cycles a couple of times, you become dismissive about new tech. New frontend framework, not again?! You become what’s known as Grumpy Developer.
Regardless, you still have to keep up with the ever-changing industry. You can do it by listening to podcasts or audiobooks during your commute, regularly going to meetups, starting a book club with your team (even if it means reading a chapter of a book every week and meeting to discuss it), or Video Fridays when you watch a video and discuss it with your colleagues.
You also have to unlearn things because software development is constantly changing. I myself had to unlearn the waterfall way of managing software projects because that’s what I was taught when I started in the industry!
Experiment to be more effective
We all have known unknowns. Maybe there is a better solution, a new technology? Do we miss opportunities by developing this feature instead of something else?
My advice would be: Don’t be shy; just try. I suggest learning a new programming language. At some companies where I’ve worked, we would get 1.5 hours a week to get away from what we were working on and learn new technologies and languages. It was not necessary for the business. It was just to get the feeling of them.
The same goes for tool training. Software developers use 20 to 30 different tools. How do you know you use every feature effectively, or you’re keeping up with all the updates? Why not dedicate half an hour a week to gathering and sharing knowledge to learn about the features and tools your team is using?
Work on what matters
Before starting to work on anything, ask yourself: What problem needs to be solved? Why do you want to solve it? What is the validation data saying you’re on the right track to solve it?
And when faced with multiple projects, choose to work on those that affect most of your customers. Don’t think that’s something product managers have to think about; you’re a software developer, and it’s not your job to think about what’s affecting users, your job is code.
I wish engineers spent less time understanding the product and more time coding – said no one ever. If you’re a junior developer, you could focus on the code, but once you’re a couple of years in the business, you know the product and you should care about it.
There is a movement of becoming product engineers. That’s someone who knows the product, knows the problems users face, and knows how to solve them with code. And that’s a very powerful role!
