Every now and then in the life a self-respected programmer, there comes a time of self-assessment and evaluation of one’s progress. Am I going in the right direction? Am I developing fast enough? Is there something I should be doing differently? What should I focus on next?
Striving to be a better programmer reminds me of a road full of potholes. Mainly because your growth depends on a lot of factors that are not dependent on yourself that you need to put up with every day.
As an example - your colleague Greg, who earns an ok salary and knows the fundamental things needed to create a simple web page in PHP, feels very safe in his current position both in the project and in the company. He prefers not to lean out too much, do his job fast and go home. Greg is not dedicated to getting out of his comfort zone and confronting his knowledge with his peers. He doesn’t really care, so he’s doomed to make the same mistakes over and over again. You get annoyed at Greg when you pair-programme a feature with him because he’s no good influence and even worse, he slows you down, because of his attitude.
Next example - the company you work for is focused too much on delivering the product to the client and is not giving it’s programmers the freedom they need to expand into new technologies and make mistakes. And oh boy you need to make a lot of mistakes in dev to call yourself a senior!
I believe it’s crucial to not give in to obstacles like that (after all, the obstacle is the way), but still, you need to accept their existence and most importantly, do something about them. If you want to develop, you need to be sceptical, get out of your comfort zone often, and learn from your mistakes.
Ok, but why would we do that? What is it that we’re all striving to be? What is the end goal? What to focus on when struggling with the obstacles?
These are critical questions, so I prepared a small list of attributes that I believe we all should have in mind when having moments of doubt. So these are the traits that I believe make a perfect developer, starting with:
Our perfect developer is a renaissance man. He knows how to deploy his React app on a bare Ubuntu 18.04 machine. He acquired enough knowledge about CSS to fix a small input misalignment on the landing page when his fellow Frontend colleague is on a sick leave. He’s able to advise the client about how to organize his team in terms of task management and git-flow. He listens to other people’s development stories even if they are about Go language and he’s a Ruby developer. He feels comfortable discussing things he’s not fluent at and he’s learning by doing it. At last, he’s able to maintain a conversation with his fellow Java developer.
This one is obvious and I was wondering whether I should mention it. Whether he’s a web developer, mobile developer, software developer - there must be this one technology that he excels at. Something that makes him light up when it’s mentioned in public. Something that he knows all in-and-outs of.
There are a couple of stages every developer goes through: at the beginning of your career, after doing your first tutorials, you are excited about things you can do with programming - just by writing HTML and CSS you can make simple, but nice looking web pages. Just by following instructions on a 15-minute Rails tutorial video you can create your own blog. You start feeling powerful and gain confidence. At this stage, all you care about is the end product.
Next, you meet people that are better programmers than you. They point out bad things in your code and show you how to write things better. You realise how unschooled you were and you start feeling a bit of shame over your old code. You realise how many things you don’t know and how long it will take to become like your experienced friends. You start putting more attention to the performance of your code, to how it’s organized within the project, whether the variables are named correctly and so on.
So then you start reading about clean code, design patterns, architectural patterns, you learn different technologies and become someone who knows how to develop apps and someone who has enough experience to know how to work efficiently in a team. Now depending on your environment, there are two extremes toward which you may lean here:
if placed in an environment where there is a lot of attention put into code quality, you can become a perfectionist. You start putting too much
attention to clean code. You strongly believe that methods should have max 12 lines and should operate only on the same level of abstraction.
You DRY everything. You get annoyed by the fact that there is no space between brackets in function(){ and don’t you dare merge this before it’s fixed,
dear colleague developer! At last, you can spend 2 hours to find just that right solution, which works 12ms faster than the one you could have done
in 10 minutes. People are terrified of your code reviews.
if placed in an environment where people just “do their work and go home” and where management puts a lot of pressure to meet unrealistic deadlines, you may reach the other end of the spectrum, that is you become someone I decide to call a machinegun. You work fast. You deliver but leave a mess behind. After each feedback loop, you have to fix 4 things and make 6 changes. People look at your code and pray it’s not their next project. Tests only take precious development time. Project managers love you because you always meet your deadlines and have solutions for everything.
So where does our perfect developer stand in this spectrum? Well, I think that somewhere in between. He understands the importance of writing clean code.
It’s crucial to create solutions that are flexible and understandable to other developers. A perfect developer does code review not only to check for clean code
but also to check whether business logic is in line with client’s needs. On the other hand though, he understands that done is better than perfect.
As Paulo Coelho Linus Torvalds said:
“without users, your program is not a program, it’s a pointless piece of code that you might as well throw away”.
Code has to be delivered and used. What’s the point of having flawless code that’s just sitting there, alone, in the depths of GitHub? It’s a waste of client’s money and of developer’s time. That’s why a perfect developer has a business‑first approach. He’s able to maintain a balance - a common sense so to speak - between delivering the product and maintaining code quality. He has seen enough MVPs go bad for a plethora of reasons to realise that delivering a working product is THE most important thing. It’s fine if a couple of things are not as they should be. Successful products need to be delivered with technical debt. And it’s fine as long as everyone (including the client) is aware of its existence.
A perfect developer separates his ego from his programming skills. He understands that it’s not a shame to not know something. Development is such a vast field that it’s natural to make mistakes and discover something new all the time. If he has problems with a tool or a concept, he knows it’s much faster to ask someone (or delegate his work) than to figure out everything on his own. He doesn’t get angry when getting his code reviewed and also he’s not hesitating to point stuff out when doing the review. He challenges ideas of people more experienced than him, but he does it in a pride-less way (with an honest goal of finding the right solution)
Being in one place for a long time can slow down one’s advancement. You could have exhausted all that your current environment had to offer for you. If you have become the best developer in your surrounding then it’s time for a change. You also could simply get bored of being in one place and lose motivation. Being exposed to the same type of projects and the same technologies can do that.
A perfect developer is devoted to his current environment, but he seizes the right moment to risk pursuing new opportunities. He chooses to stay in a place where he’s giving the most value but takes into account his own well-being and what’s best for him in the long-term.
Social skills are important basically everywhere and programming is not an exception. How would you like pair-programming with someone who’s grumpy and speaks with half-sentences? Would like to have a team lead with totally NO sense of humour? What about something as simple as the ability to correctly articulate your ideas to your colleagues? These are all soft skills and are AS IMPORTANT as technical, hard skills. Of course, people have different personalities and it’s fine, but we all should strive to be a pleasant company. Fortunately, skills are still skills and can be learned.
That’s it! These are the 6 traits toward which I’m aiming and I believe many good developers do too. Think about these next time you get stuck in your journey! I’m sure there many more worth mentioning, but I’ve put down the ones I think are the most important. What do you think about this? Can you think of any more traits that should appear on this list? Let me know what you think in the comments below!
Thanks for reading!
Przemek