Seven Blockers From Being Senior Software Engineer
Seven habits that you need to change to practically move to the next level in your career, but not theoretically on paper.
Join the DZone community and get the full member experience.
Join For FreeIn the previous article (Rethinking of Software Engineer Levels), I introduced a more accurate grade scale (more transparent, experience-based, and relevant for a particular company). This one partially covers transitions from random solutions to simple ones, from tasks to streams of activities. I will cover what seven habits you might have in your work that stop you from being a real senior software engineer (SWE) or "Simple-Way Complex Problem Solver" and what does not allow you to break the glass roof.
1. CV-Driven Design
Have you ever seen people who try to apply new and fancy technologies to real products without any relevant experience? That might not bring any real value, creating another technology stack inside one company to maintain and dilute the quality of implementation. This habit is dangerous because you get used to checking technologies in an environment where it is extremely hard to replace something and must be maintained long-term.
How to improve? You might play with any technology you wish while working on your pet project or propose to analyze and compare different appropriate technologies first.
2. “We Cannot Do That!” Mindset
We all have different backgrounds, and sometimes, people grow up in an environment that trains learned helplessness. People stop believing that finding a solution to any situation is possible, and when they see complex tasks, they retreat.
How to improve? I’m not a psychologist, but replacing “We cannot do that!” with “I don't know how to do that yet” should help from my experience. Also, try to stop thinking about resources and imagine Ideal Final Result. This practice will help to jump much closer to the solution.
3. Technology-Focused Decisions
Sometimes, we already know what technologies we are going to use, just hearing about a new task and meanwhile slightly forgetting to think about actual requirements. However, every new or changed requirement needs to design a solution and check for stack compatibility (even if you don’t do that).
How to improve? Create a checklist and change your development workflow to guarantee that you at least think about alternative options and validate that your tech stack is still relevant incrementally.
4. Poor Communication Skills
This is a pretty wide topic, but it is obvious that you cannot efficiently mentor, explain your point of view, and collaborate, having weak communication skills.
How to improve? Communication skills are pretty hard to train. Unfortunately, it is not about one framework or something like that. Start by receiving feedback about the results of your work and about collaboration with you. Eagerly request for this type of information but stay open and patient for what you hear.
5. Single-Task Responsibility
Suppose you have insane hard skills but don’t want to think wider than one task. I have bad news for you. “Thinking wider” is essential for every senior engineer.
How to improve? Ask more questions on planning. Ask to make your own draft plan for implementing a complex activity and delivering value on time.
6. Do Not Learn From Mistakes
Good for you if you can predict all potential problems of your project, but probably not. Problems will occur, sometimes because of mistakes. If you do not fix the root cause, the problem will impact your results repeatedly.
How to improve? Start from retrospectives and post-incident reviews. They will help to identify root causes and improve your results.
7. “Let’s Rewrite” Thinking
Fairly often, I heard: “It is too complex to change. Let’s rewrite”. People forget that creating something new is a ton of extra work needed to launch and extra risks of incompatible implementation. Also, this approach weakens your discipline, and you lose an opportunity to practice strategy.
How to improve? Prepare for changes, for evolution. Improve existing components instead of introducing new ones. Think in advance about your future architecture for different scenarios. Try to keep a balance between flexibility and relevance (real need of something). If you see that you can make something to support evolution, do that.
Published at DZone with permission of Ivan Osipov. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments