How to stop being a good software developer and be an awesome one instead
As of 2016, being a software developer is a way cooler job that it was when I started 11 years ago. I see more and more people joining our ranks and picking up the lightsaber of — insert language of choice here — to build bigger and better applications.
Now in the face of this inflow of talented newcomers there are still some things that “old” chums like me can bring to the table.
Below are some of the tricks I picked up during the years and some of the most common mistakes that young developers make.
This article is my first after a two-year pause, so please bear with me while I try to re-figure this thing out.
1. Don’t stress it
You won’t see many senior developers in the office after the workday is over. Well, maybe if something went horrible wrong, but usually, they are the one who leave on time.
The reason for that is simple. Tired people write horrible code, there is no exception to this rule. That innovative fix you wrote at 2:00 AM, look at it the next day, does it still look innovative?
“But my manager will notice that I give 120%”. No, he won’t and even and if he does, he will just be grateful for the save and remember you for the next time he needs a guy to stay overtime (trust me, is a never-ending circle).
In the end, your code quality and build quality is a much better way to prove yourself.
2. Stay in scope
In my entire life, did not come across a single big application or mildly successful startup with a clean codebase. Even the strictest coding standards cannot prevent trash code from somehow seeping in to a codebase.
It is but part of an application life. Approaches thought good are now seen as crap; Approaches seen as crap in the past are now seen as good (yes, I am looking at you anonymous functions).
The first impulse is to try to address those problems and go out of scope. That is a bad idea, and it leads to hours wasted on trying to improve something that already works.
Cleanup tasks can be just as well part of a development circle, but they need to be tracked to have any effect.
I am still waiting to meet a developer that doesn’t look through a full codebase and exclaims every 200 lines “what the f***, man, WTF ?!?”
3. Keep it simple, stupid
This really cool new way of adding and updating things in the database while you just thought of, and you are now forcing in to the codebase of a 5-year-old poorly written website. Did you try running it by a senior first?
You probably should since we already have that in place. Or better yet, we don’t need it since there is already a procedure that does that in the database.
Now this one should be easy, but it isn’t.
Most of the people coming to this field are thinking developing software is this exciting adrenaline filed job where they can apply their knowledge to build the next piece of code that will improve search results retrieval time by 500%.
I am not saying that you won’t end up doing that in a few years. But usually, a new developer is assigned to maintenance tasks and bug fixes, which are roughly about 60% of all the development being done inside a DEV department.
I know, it sucks, but someone has to do it, and newcomers are the perfect guys / gals since they need to understand the code first before they can move forward and write features.
Also have in mind that changes you make while you are working on maintenance should be “ninja” changes. And by “ninja”, I mean small incremental improvements that have a low chance of breaking the code, not massive refactors that change entire flows.
The name of the game is “patience”.
4. Never stop learning
Now this one you already knew.
Stay on top of the industry and don’t be afraid to try new programming languages, systems, software, tools, and so on.
