How to be a good developer
You have decided that you want to become a developer. Good. There is a huge demand and salaries are high. But what does it take to succeed at this job?
Forget about coding skills
During my first years as junior developer I had a tendency to idolize my more senior colleagues that were able to refactor my five lines of code into a single one using some language feature. To me that was a sign of seniority and I started focusing on that. There is nothing wrong there. One day you will find yourself being that developer that is able to synthesize several actions into a single map call. But is that it?
I’ve seen several developer with excellent coding skills that I wouldn’t consider good developers. They can code in a cool way. Sure. But being cool doesn’t make you better. Is just a sign that you have been writing code long enough so that you started micro-optimizing your time.
So, if it’s not your coding skills, what is it then?
It’s all about the team
Don’t get me wrong. You need your coding skills. You need them in the same way a football players needs to know how to kick the ball. But that alone won’t make any difference. Coding is, at most, 50% of the job.
If you are working for a company chances are that the rest of the time you are going to be caught in meetings. Planing sprints, discussing requirements, grooming tickets or reviewing someone else’s code. And let that last one sink for a second. Reviewing code.
Maybe that surprises you, but a lot of your time is going to be spent reading code. And then you start thinking twice before naming a new function or deciding whether to use shorthand argument names while writing code. Because you should choose clarity over coolness. Readability over compactness.
Use your time wisely
Another thing I’ve experience multiple times is someone approaching a problem trying to provide a solution that will also solve future potential problems. Are these problems known? Is it a requirement? If the answer to both questions is no, maybe you should rethink your approach there.
In my experience it is better to write less code. Because the lesser the code, the easier it is to delete and replace.
We often whine about legacy code. Well, that last pull request that you just merged into master… that one just became legacy code.
Say no
Push back. Say no. Don’t be shy. Is this new feature compliant with the rest of the app? Are the designs consistent? Can we use a native feature that will save us time compared to building everything ourselves?
Your work will be product driven. And hopefully your product managers will know what are they doing. But that won’t always be the case. It is your job to guide them whenever is required. To know and defend help your PM to better understand the constraints and possibilities of your platform1. To say no whenever you think you should.
Don’t be that developer pulling tickets from a backlog, processing them and putting them to Done.
Care. Because your work is a reflection of yourself. Care. Because caring is indeed what will make a difference.
A change suggested by a good friend of mine. A PM himself 👮♂️ ↩︎