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 light saber 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 thigs 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 bare with me while I try to re-figure this thing out.
1. Don’t stress it
You won’t see a lot of senior developers in the office after the work day 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 came 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 fix 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 so as 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 at the same time that you just thought off 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 under the impression that 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 of 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.