The Fine Line Between Terrible & Awesome Developers
I recently had to let go of a developer working with me for over 5 months after countless efforts to make them see the development world in a new light.
After putting my thoughts together, I’ve decided to share some insights on what differentiates an average developer a.k.a “terrible” from the great ones a.k.a “awesome”.
Thoughts expressed here are solely mine and have formed over the years from working with several developers across multiple projects with varying scope and timelines.
Now, let's get to it.
There are 6 essential things that easily differentiates an awesome developer from a terrible one. After reading this, if you are a developer or engineer of some sort, you will know where you belong without a doubt and therefore know the things you need to work on to move further and beyond.
In no particular order, these are:
- Linear Thinking
- It Works
- Do Smart; Not Act Smart
- Possible Impossibilities
This, in simple terms, is like the difference between a linear equation and a quadratic one.
When a developer thinks in a linear fashion, they see their code as a highway with no intersections, traffic, and external obstructions. In a perfect world, thinking this way is fine, but unfortunately, the world is far from perfect and so is the world of programming. Things go wrong. Planes crash. Cars clash.
Hence, it is essential to think more broadly than your immediate scope.
In the linear equation a = mx +b, a linear thinker is only concerned with adding the values and getting a result for a. An awesome thinker first asks what the constraints are for the range of values in the equation. Integers? Floating Point, Non-Zero, Undefined, Negatives, etc. This way they end up with a better implementation as opposed to a naive one that only works when the world is perfect, which rarely is the case.
Inexperienced and terrible developers assume once something work on their local development machine, it works everywhere. This is in line with the first thought above. The linear way of thinking. While a linear thinking developer writes code for a rainy day, an awesome developer writes codes not just for the rainy day but thinks about the sunny and snowy day as well.
Definition: an attitude of superiority manifested in an overbearing manner or in presumptuous claims or assumptions.
The phrase I’m interested in here is “presumptuous claims or assumptions”. Terrible developers assume a lot. Even without concrete evidence or research. This can be one of the worst behaviors to have as a junior or inexperienced developer. Your thoughts/knowledge doesn’t always reflect the state of the world. Do your research. Learn new things. Be open to learning new things and opinions. Solutions to problems come in ways you least expect.
Do Smart; Not Act Smart
You can fool people that you know what you’re doing, but if you really don't, eventually it will show and you will be on the wrong side of history when that happens. Admit your ignorance when you do not know. Ask questions. Again, research.
As a developer, your code tells a lot about your experience level
In a lot of corporate settings, you will find inexperienced people who do not know but like to act as they do. As a developer, your code tells a lot about your experience level. It's not easily hidden. While you can jump on stack overflow and copy-paste code, without a proper understanding of what the code does, you easily find yourself facing a brick wall. So do that research. Read that documentation. It will only take 30 minutes of your time and you will end up in a much better and confident place to implement a solution. Yes, you can make a case for time constraints, but those few minutes saved becomes technical debt you will have to pay sometime in the future and mostly in a terrible way.
Terrible developers are quick to jump to conclusions. They love the words “It wouldn’t work”, “It's impossible”. But again, your thoughts do not always reflect the state of the world. Because you don’t know how to do it, doesn’t mean it can’t be done. You just don’t know how to do it yet.
Countless times, I have heard developers get stuck and say “It’s not working” or “It won’t work”, and barely having a third eye look into the problem proved them wrong most of the time. So take that extra time, research wide, ask questions, and be the magician that makes things just work. Scope down the problem, identify the root cause, structure your thoughts and you will see impossibilities become possibilities before your eyes.
Overengineering is simply the act of making a simple problem more complex than it really is. It can also be making something unnecessarily complicated for its intended use.
Simple problems should have simple solutions. Complex problems should have simple solutions. And yes, you read that right. When you think in this light, your goal as an awesome developer is to break down the complex problem into simpler form in your code so it's easy for the next person who jumps on it to understand without going through the thought process you had initially gone through. If you can achieve this, your co-workers will love and value you.
It’s great to know how to solve difficult problems. But it's even better to know how to break them down into simple forms everyone can understand.
A very common form of overengineering by inexperienced developers is “spaghetti code” This happens when your code begins to look like a spiral with no start or end, then you have found yourself in an implementation hell. Modularization can help with this but again, be careful not to “over modularize” introducing new problems in your code.
And that’s it.
6 essential things that can help you escape the inexperienced newbie/terrible developer loop. To summarize, these are Linear Thinking, It Works, Arrogance, Do Smart; Not Act Smart, Possible Impossibilities and Over-Engineering
Till next time…