• 5 min reading time

9 Aug 2019

3 Things That Make a Professional Programmer


Let’s be honest. Anyone can become a programmer today. Open Youtube, type in: How to make my first App, follow the tutorial for a couple of hours, and Voila! You have built an app and become a programmer in just 2 hours!


Photo by Alexander Schimmeck


A question I have been recently asking myself is what makes a professional programmer. You know the one that does a lot of it and makes money doing it? What is their approach to programming compared to an amateur programmer?


I have been an amateur programmer in the beginning; in fact, doing amateur projects is how I have fallen in love with this beautiful wizardry. After some time, I wanted to reflect on the things I am doing differently since turning professional. Thinking back to being an amateur, and doing everything I could to turn professional, I wished someone would have told me those things as I wanted to know what makes a pro.


Here are three things I have learned that I believe separate an amateur from a professional.


1. Taking on feedback

The famous peer reviews(PR’s) are the professional’s gatekeeper to filter out the non-agile code. A professional knows that there are good and bad ways to write code. The trick is that both types of code work in that given scenario and requirements from the team. However, only clean and testable code can survive within agile environments where teams have to make decisions quickly, the requirements change or expand overnight, and the code needs to be changed.


In the early days of my career I have sometimes found myself thinking something like: “I had three espressos today already, my head hurts, and I would like to get my PR merged in and start working on a new feature.” Or something like: “This sprint ends tomorrow, so I have no time to refactor. It works. The UI looks exactly like our designer created it.”


I was lucky enough that as soon as one of my seniors have seen my code and shared their thoughts with me on it, which would tell me how I could have done it better. Whenever that happened to me, it was the most beautiful gift, and ego hit someone could have given to me. It was hard to put my code on the side, critically evaluate it and refactor.


With time I learned to only take the positives out of PR, put my code (my ego really) on the side, and do the better thing. Professional knows that it is essential to learn to take on feedback for their code to become great.


2. Endless refactoring

As a professional, I am always building my knowledge, and to be frank, if I only do my day-to-day job well, I am frequently learning something new, like diving into an API that I haven’t worked with before.


This constant and inevitable betterment of skills also leads to feeling that the code I wrote 3, 6, or 12 months ago is inadequate and completely non-representative of my new learned skills. So I turn to refactor everything and anything in my code that I believe I could write better.


As an example, I have recently developed a working prototype of a social media app in my favourite language, Swift, alongside a backend to add to my portfolio. I started the project to learn some new skills, and see what the challenges and limitations of designing and implementing such an app would be. I have taken my time with it, and as new ideas kept popping up by the end of it, I had majorly refactored the iOS App and database structure no short of 5 times (anything from UI, class methods, constant names, routing,..) before I was happy with the outcome.


Having completed the work on the App a few months ago, I am resisting very hard not to try to look at it again and figure what I could do better with the knowledge I have right now. Soon I realised I wasn’t alone in that beautiful “struggle”. I have seen it time and time again in professional programmers around me keep finding new, better, and cleaner (referring to Clean Code principles here) ways of doing things and endlessly refactoring. An amateur programmer doesn’t usually need to trouble to refactor as there is no need for it if their program works at a given moment in time. Constant refactoring, however, I believe, is an expected and natural expression of a professional programmer and a bridge between an amateur and pro.


3. Code also when you don’t feel like it

With my background as an athlete and working within a few different industries until I found my love for programming, this one has been a constant. Imagine a day waking up after a good nights sleep all refreshed; you drink a large glass of water infused with lemon, put your favourite T-Shirt on, the sun is shining, you’re wearing your headphones listening to this catchy new tune. You think of an excellent way to solve that problem that has been bugging you for a few days. You can see the code typing in front of your eyes, and you cannot wait to sit down in front of your computer to cement it into your branch and raise that PR.


Your life suddenly seems like a diamond carved out of brick. You feel like you can move the world with almost no effort. You feel grateful for everything that led you to this moment, proud, excited, and supercalifragilisticexpialidocious.


The truth is: everyone loves to code in that state. Everyone can find a solution to a problem on that train to happiness or while riding a unicorn who is dancing in the field of daisy’s — ok went a bit too far there, but you get it.


On the other hand, coding after you had a bad nights sleep, waking up restless and the last thing in the world you want to do is solve “interesting technical problems” as many of the programming jobs promise is an art. Some days no matter how much you love coding, you feel like you cannot write any of it, and that’s ok. It’s ok to feel that way.


Nevertheless, as a professional, it is not ok to not do anything about it. A professional is expected to perform and deliver projects on time. A professional knows about the Jing Jang, and that there is no one thing without the opposite. No highs without the lows. No victories without tears. A professional is stoic in their approach to programming, expecting the worst, and cherishing the challenges that they overcome. Professional programs as though they are a professional at their job and does their work both when times are challenging and when the times are good.


I hope you enjoyed this article and learned something new on the way.


If you have any thoughts on this article, I would love to hear them!
You can always get in touch with me via Twitter or LinkedIn 🙂


Cheers,


Tim