How Not to Quietly Grow into a Mediocre Software Developer
Fantastic Tips to Help You Become a Great Dev
Nobody wants to push their career as developers toward mediocrity.
However, certain behaviours push developers to become terrible software developers.
If you don’t want to push your career towards mediocrity, you have to keep looking for ways to improve.
Here are things you need to do so you don’t stop your career growth.
“Know how to use your IDE well” is BS Advice
Everyone in the tech industry keeps saying “you have to know how to use your IDE properly”.
It will save you time and accomplishing tasks will be easier.
IDEs like VSCode, Eclipse, PyCharm and thousands of others exist. With the help of IDE, developers don’t have to worry about the small details of the build process. They make us more productive.
But they have many downsides.
We keep using IDE and they keep screwing us.
Due to these IDEs, we do not know what is happening behind the scenes. We click a few buttons, some magic happens, and an executable file appears.
We never get to know what happened. We never understood what the heck our IDE had done, so an executable file came along.
These IDEs make a lot of decisions for the developers and we don’t understand what they are doing. We don’t understand how it’s done.
I’m not saying don’t use IDE at all.
But for at least a couple of projects, use the command line build tools instead of using an IDE. You will become more confident in your abilities as a developer.
Once you’ve gone through the entire process of creating executable files, you’ll be able to understand the exact steps of how the IDE works. You will learn what happens behind the scenes.
You will know new details that you would never have thought of.
The advice given to the developer should change concerning the IDE.
It should be:
“Use the command line build tools at least once before fully understanding your IDE.”
The ego is the enemy
No one likes to work with a person who considers themselves the smartest person in the room.
If you have 15 years of work experience, you feel the need to comment on every discussion and have the last word on every topic. In that case, your experience is useless because nobody will be willing to collaborate with you.
As you begin to gain experience with each passing day, you must become more humble. You don’t have to behave in such a way that you know everything about every language.
You don’t have to show that you have mastered more than 10 javascript frameworks. Don’t try to show off your amazing coding skills and achievements to every member of the team.
Show-off developers are the most hated on the team.
Read other’s code to know your code quality
Different developers think about and approach problems in different ways. Sometimes their code writing style varies.
That’s why most developers don’t want to read code written by other developers.
Even if they start reading the code, they want to rewrite it after reading the first hundred lines.
They feel that other developers have made the codebase messy. They will give reasons like the code has bad variables and function names.
Once they found that the code is difficult to read. They will stop reading it and only think about fixing it. They want to rewrite the entire codebase from scratch.
If they ignored their tendency to rewrite code and continue to read it, think about what kinds of things they could learn.
You can get information about things that make code difficult to read:
Is the code not formatted correctly?
Does the code contain large functions?
Does the code have duplicate segments?
Does the code contain unnecessary context?
Does the code have poor variable names?
Are the functions doing more than one thing at a time?
Does the code contain dead code?
Is the chosen design pattern wrong?
Have the wrong data structures been chosen?
You could dig as deep as possible.
Bad code can teach you many things. Do not ignore it. Bad code will help you improve the quality of your code.
You could learn from the mistakes of others and try not to repeat them when writing your code. You don’t need to write perfect code, but you could avoid writing code with bad practices.
Learn from good code
If you go through a codebase and enjoyed reading it. You might as well learn different things from that codebase.
You could ask questions like:
What makes the code so clean?
How a particular design pattern has been implemented.
Why a different data structure would not have been appropriate in this case.
How the names of variables and functions have been written.
How each duplicate code is merged.
Once you review the code written by others, you need to open the code you wrote a month before.
Now you can compare your code with the good and bad code you have read. You will be able to understand why your code sucks or looks good.
In this way, you will improve your code-writing process.
You are not your code
In software engineering, any type of criticism is not personal.
If a group of programmers points out your mistakes it is because they want you to write better code or they want your project to be successful.
When your peers criticize your work, you must remember that they have your best interest in mind. He or she doesn’t think you’re a loser or a bad programmer.
Not getting attached to your code helps you accept criticism as a developer.
When you keep telling yourself that you’re not your code. You stay detached from your code. If you stay detached from your code, you won’t feel attacked even when someone criticizes your work.
You don’t give overly emotional responses to either the code reviewer or the person attacking you for your code.
Treat documentation like code
Developers hate documenting their code.
There is no immediate benefit to documenting the code for the code author. That’s why they don’t want to document their code.
Let’s take code testing as an example.
When you write tests for your code, you have immediate benefits as the author of the code:
Testing allows code to have fewer bugs. Catching bugs by writing proper test cases is easy.
If the dependencies of a particular project are changed and the test breaks, it can be discovered quickly.
Code reviews become easy. A reviewer spends less time verifying whether the code works or not if the tests ensure that it handles all edge cases.
Proper test cases give teams the ability to launch the application with great confidence. The team strongly believes that the app will not fail with good testing.
Since there are so many immediate benefits to writing the test. Most engineers prefer to write tests.
When it comes to documentation, they tend to skip it because there are no immediate benefits.
There are also other reasons developers skip writing it.
Most developers don’t see themselves as writers. They see both software development and writing as separate skills.
Developers find it boring to write documentation. They see writing as a burden and think their job is to build things, not write manuals.
Every organization needs to make writing documentation simple and easy for developers. Otherwise, they will continue to avoid writing documentation.
Even if they agree to write the documentation and write a messy one, it will never serve its purpose.
Therefore, developers must be motivated to write good documentation; otherwise, no future programmer will understand the codebase.
What could be done
Documentation should be treated as code.
Organizations should encourage developers to write documentation.
They need to start giving rewards to developers who write good documentation. As it is the organization that benefits from the documentation.
Peer recognition works like a great reward.
They need to tell developers the importance of writing documentation:
Writing documentation helps developers question their design decisions.
In the future, maintaining the codebase will be easier. When you’re trying to add features to an app you wrote three years ago, correct code comments can be a god blessing at that point.
In the future, when someone reviews developer code, they will have fewer questions to ask if the code has been properly documented.
If engineers started treating documentation as part of the code.
It will save them a lot of future efforts to explain the code.
Summary for your memory
Understand how to use the command line build tools.
Ego will never benefit you.
Other people’s codes can teach you different things.
You are not your code.
Documentation plays an important role in the long run.
Great information that's for sharing and being so detailed. I can tell you really care about others success just like yours.