Avoid These Mistakes If You Want To Be A Senior Developer
these things get you stuck
As developers, we all crave greatness, relevance, and growth.
A newbie is striving to build her first app, gulp the fundamentals, or even launch her first algorithm. Junior developers are hungry for senior roles, senior developers shoot for world-class, everyone hammers on best practices, clean code architecture, efficient design pattern, and whatnot. But if we are not careful enough we might be locked in our own shit with no substantial improvement and that might ruin the ecosystem.
Just last week, Akintunde Sultan the cofounder of Devcareer and Talent QL posted a tweet showing concerns of how much junior developers lag behind on their strive to take senior roles and its possible aftereffects.
Are developers not striving enough?
I remember writing a crappy article of fewer than 300 words, though that was my first, citing the science of learning and how much you can learn anything no matter how hard it seems at first.
Following my career as a developer, I have come to a realization that one of the reasons why improvement appears hard, despite our efforts, isn’t because we are not a genius at learning but we are rather stuck with wrong learning processes.
In this article, I will highlight several mistakes I made and how you can avoid them as a developer in order fast track your way to senior levels.
- Cram/Know It All Syndrome: This is mainly found at the newbie level and even worse when you don’t have a network with more experienced developers. To understand how this reflects, let me narrates a scenario:
Imagine you move to a new city and you don’t know where to find a grocery store. You won’t beat yourself up — it’s normal. You simply use Google Place to find it or ask someone around.
After you’ve been there several times, you won’t need to use Google Maps again — but, at first, you need Google Maps, then you learned the location, get accustomed, and no longer need it.
You learn it without intentionally trying to memorize every road and all possible paths that lead to the destination.
It takes the same route to learn programming.
New software developers may feel bad that they’re not memorizing sufficient syntax —since they still need to frequent the documentation. Some even see this as a sign that software development is not for them — I was once locked at this stage.
Here are some wrong questions you might be asking yourself:
- How should I be able to learn all this syntax?
- How long will it take me to master it and write without referring to the documentation?
The notion that the volume of syntax memorized really matters or proves one as a good programmer is fallacious. See what top engineers have to say:
These testimonials should give you courage — you don’t have to be ashamed that you can’t remember every detail of the syntax. The truth is, you don’t need to memorize everything as you go.
Rather, one thing you have to understand relative to the scenario I showed earlier is; the more you code, the familiar you grow with the syntax.
I can’t keep count of the times I googled Flutter Provider implementation whenever I want to use it on a project and now it seems like something I had known for decades. These days, it surprises me when I do complex State manipulations without consulting Google.
You can also get to that level — all you have to do is keep building, search Google often, and how quickly you get to master all the syntax and coding practices will astound you.
2. Asking wrong questions :
This does not necessarily mean that you ask wrong questions, but that you do not ask the correct questions. I cannot stress enough how important it is to be able to articulate your exact problem before you can get it solved.
A good question already has 50% of the solution. When you master this technique, nothing will be able to stop you. There is even a debugging strategy that is based on asking questions, the rubber duck debugging.
“Great engineers know how to formulate good queries.” — unknown 😂
Another problem with questions is that junior software developers tend to ask a lot of them. This does not sound like a bad thing, but a developer should have a degree of independence and a sense of responsibility.
If it is a minor issue, like naming a variable or deciding which CSS attribute to use, it is best to make a simple judgment call and bear the responsibilities thereof. If it breaks, you fix it. It is the only way to truly learn.
3. Not learning enough:
This is a problem most frequently present in egocentric developers, but not limited to them. While you can start working with a bare knowledge of HTML, React, Laravel, or Flutter, you should expect to learn new stuff for as long as you are a software developer. Not only there are dozens of design patterns, algorithms, and libraries that every developer should know, new ones manifest every minute. Frameworks get upgraded/deprecated and new implementations released.
Why stuck with Laravel 5 while Laravel 8 comes with outstanding performance, code improvements, and tons of new features yet to be explored.
Why not try the new State management library of Flutter?
Why not learn how to build packages for your framework?
Why not explore the concept of code reusability?
There is so much to learn about code performance, code structure, design pattern, data integrity, semantics, and lots more.
If you want to be indispensable in the labor market, you should continuously self-educate, which includes but not limited to: reading books/articles/blogs/news, trying new things inside projects, contributing to the Open Source Community, or at least reading through the source code of your favorite libraries, going to conferences, and connecting with fellow developers.
4. Not experiencing enough:
Have you ever got stuck on a bug or when trying to write an algorithm and later get to know it can be fixed with syntax or algorithm you already know?
What’s the problem? — Is it that you don’t have enough experience or you simply don’t experience enough?.
One of the fundamental skills of a developer is problem-solving which is your ability to identify problems and explore your web of knowledge to derive efficient programmable solutions. If you lack deep knowledge of the usage of an algorithm or unable to think deeply about other approaches in which you can use such an algorithm it can hinder your growth.
Just as much you try to learn new things, you need to double click on those things you are learning and the ones you knew to see through their contexts, contextuality, and context continuous nature.
5. Avoiding responsibility:
As a junior developer, no one expects much from you. Your supervisors understand that you need time to grow and learn at your pace and will not assign to you critical tasks that may ruin the product if you fail (hopefully). But you should start taking responsibility for minor issues, as well as code ownership.
Many senior developers and project managers prefer not to micro-manage junior devs, they want you to have a degree of independence. You will never learn and become responsible unless you are willing to get your skin in the game, take risks, and face the possibility of getting burnt.
6. Lack of proper planning before coding:
During my early stage, I was always eager to code. As soon as the project idea is been shared with me, I bounce on the IDE and start coding. Over time, I realized that this set me back a lot as I would eventually spend time fixing issues I should have noticed during planning.
Whether it’s on a whiteboard, or a notepad, or on an actual piece of paper, write down your problem statement and draw out possible solutions. This allows you to identify gaps and seek clarity before you write a single line of code. Programming is a lot more enjoyable when you fully understand what you are implementing.
7. Not asking for help:
Follow the ‘30 minutes rule’. If you are stuck on a problem for up to 30 minutes, ask for assistance. The solution to that problem might be staring at you in the face and you are completely oblivious to it.
As a young developer, never shy away from asking questions or seeking clarifications from team members or senior developers who can point you in the right direction. Ego can be a great enemy on this journey. Lower your guard, and ask for help.
8. No Unit tests:
Coding without unit testing is wrong on all levels, regardless of the years of experience you have gathered. Once I open a codebase without any proper unit tests, I automatically consider the developer a rookie.
Yes, we all test manually, however, this is not good enough. Automatic unit tests should run on start and should be triggered again every time there is a modification. This helps you to detect bugs early and fix them in time.
Always write proper unit tests or follow the Test-driven Development approach where possible. The advantages of unit testing cannot be overemphasized. The more you test relative to how the user will use the software the better your shot at shipping a more efficient product.
9. Not ‘Googling’:
Trust me, you are not the first person to face that very issue. As opposed to trying to fix it all by yourself, simply google it, scroll through the pages, and open the links to possible solutions. One of the links will lead you to StackOverflow, an answer on Quora, a blog post, or some other resourceful sites.
Just as Timmy Brain often echoes; “ You are just a google search away”. As a programmer, there is absolutely nothing you want to do that someone hasn’t attempted. Just seek and you shall find; ask and receive.
Also, don’t copy and paste code snippets as soon as you think they will solve your problem. Read through the explanations and understand the usage before implementation.
10. Not Placing the End-user’s Experience as Priority:
Always implement your solutions having the end-user in mind. If I were the user, what sort of experience would I want to have on this application?
Put yourself in the user’s corner to better understand their viewpoint. You should make your application as simple and as usable as possible.
Running with this philosophy will greatly transform how you code and solve problems. You will no longer roam with pressure to be grandiose with your code, you simply thrive to solve a unique problem in a unique way that truly caters to the user.
Final Thoughts
It is not that you are good enough or you lack the cognitive ability to move your stack up the ladder, you are most certainly getting the process wrong.
“You can achieve the exact result if you follow the exact process that got the first result.”— Timmy Brain
All results are born of process. If you hope to become a better programmer, adopt a better process.
