3 Reasons Why You Are Not Yet A Good Software Engineer
or — how to be one
Whether you realize it or not, you have certainly met some of them — or you may be one of them. I’m talking about people who believe to be sound software engineers, but their way of working leaves the rest of us a bit nervous, trying to find ways to avoid working with them.
It is true that some people indeed need time to develop professional skills and attitudes, and that’s normal. However, some will remain where they are in terms of skills forever — their insufficient focus and attitude habits will make sure of that. You undoubtedly know a few of those people.
I tried to discuss the common professional denominators of the people we tend to avoid working with colleagues. From the outcomes, I excluded the following:
- Attributes that are a matter of acquiring more experience (such as non-toxic behaviors of beginners, failed projects, etc.)
- Attributes stemming from bad working conditions and bad management practices.
- Attributes that show bad professionalism in general. Let’s focus mainly on Software professions.
What was left from our conversations were three major points that all my fellow software engineers have encountered at least once in their lives and are blockers in a person’s professional development in Software.
Just for the sake of argument, let’s pretend that you are one of those people. So what are some things that make you a bad Software Engineer?
You avoid getting out of your comfort zone.
Being faster and more productive using a particular technology matters. After all, that’s what you get paid for. Who would want to pay a premium salary to an unproductive person?
But there is a difference between excelling at the job you get paid for and excelling at trying to keep your job the same so that you can continue to excel. The first one concerns you trying to become better at what you do. The second one is you trying to drag everyone else inside your comfort zone so that you won’t ever have to be uncomfortable. This is not going to work.
You are the person that avoids doing work unless it is exactly what you have been doing for the past years. You are a Java developer refusing to make some database queries because that’s the DBA’s job. You are a NodeJS developer who refuses to touch shell scripts because it’s out of your job description. Or maybe you are a microservices developer that refuses to learn how Kubernetes works because “that’s a DevOps area.”
This attitude is not going to allow you to progress much, though.
In the last dozen years alone, many new technologies and trends have emerged that made one thing sure: The Only Constant Is Change.
Let me bring up a few examples to prove it:
- Were microservices and containers such a buzzword a decade ago? Did Docker exist ten years ago?
- The iPhone was introduced in 2007. Do you remember the world of handhelds before that? Do you remember how fast it took over and made all other platforms and operating systems obsolete? Can you identify what happened to the software industry? Do you also remember Objective C and Swift?
- Do you remember the world before server-side-javascript? Reactive programming? Sure, it existed before NodeJS changed the way we look at threading models — but especially nowadays, it has become a necessity.
I could go on for hours. My point is that whatever the tech you are developing right now will not be there for long; therefore, you must be resilient. Exploration will be a big part of your Software Engineering career, and you must develop the skills to master it, not just learn to tolerate it when you are required to perform it. And I’m not just talking about learning radically new technologies.
There is value in also being available to perform tasks outside of your primary area of focus. To help your colleagues solve a problematic issue by taking a peek into an external system and many more things that will allow you to broaden your horizons and be a better colleague altogether.
Let’s not forget that Software Engineering is about identifying each technology’s core principles and then associating those principles with problem patterns in real life. If a developer cannot explore new areas with ease, then every business problem encountered will either be solved with a potentially unfitting method or not at all. This pattern hurts you and everyone around you.
Professional comfort zones are meant to be violated every once in a while. Please do the right thing and embrace those changes as they come.
You decide based on tech buzzwords, not your business model.
On the opposite side of the situation mentioned before, some people tend to perform changes and adopt radically new methodologies just for a change.
If you are that person, maybe you find yourself performing more Google searches to identify which technology is better or who is the new kid on the block instead of taking full advantage of the technology you are currently using.
You are constantly proposing that the team use some new technology/methodology you read about in Quora / Twitter or (..insert social medium here) without understanding exactly how that technology would integrate with your business model or understand its fundamentals.
Moreover, you sometimes get angry when others don’t share your perspective and accuse your team of being anachronists or being afraid to leave their comfort zone. You may end up quitting because you so firmly believe that.
This behavior is as toxic for your career as if you belonged in the first category. Professional software engineers know when to take risks and when to take the safest route. They do that because their experience has taught them to examine new technologies, develop proofs-of-concept before adopting new technologies, and always consider the human factor; how can the rest of the team adopt something like this without disrupting their workflow.
Not to mention the most critical aspect — the business — meaning that you have to consider the maintainability, architecture, developer pool, etc.
As it happens with everything in life, there needs to be a golden rule here. Yes, adopt new technologies, learn new things, push for changes — but only after careful consideration and team discussion. Otherwise, you are putting the entire company (and possibly your job) at risk should the business fails.
As a rule of thumb, put the product and your team’s morale first; the technology you use comes second. Not the other way around.
You fail to understand the Human Aspects of Software Engineering.
You are one of those people that believe in Coding — and you don’t want to invest time into anything else during the day. You need your tasks to be clearly defined — and you excel at completing them on time. You write the code, and that’s it. All other aspects of the project/product are none of your business. That’s why we have a Product Owner, a Tester (and possibly some technical leader), correct? They can take care of all other aspects of what needs to be done so that you can invest 100% in coding, right?
Well, yes and no. It’s great to have a team with clear roles to tackle the business so that you can be left alone to focus only on the technical implementation of each task. However, this constitutes an oversimplification of the role of a Software Engineer. I would also dare to say that this situation fits best in a programmer’s job description, rather than of a Software Engineer.
I can’t even begin to tell you how many people I have met in my career believe that the most important interaction they need to have during the day is with their computers. However, this is not what Software Engineering is about.
Software Engineering is about converting business rules to technical expressions so that computers or other Software Engineers can understand them. A large part of the work that needs to be done has to do with communication. It has to do with humans. A few examples:
- Clarifying points, making vague input more specific.
- Translating abstract business input to technical specifications.
- Code refactoring, so that your code can be used as a means of communication with another person and not just with a computer.
- Writing documentation (yes — this is as important as writing your code).
- Adjusting your VCS systems so that you can serve the release schedule better.
- Identifying potential issues with the business or the technical decisions being made and discussing them.
There are many similar points like the above that I can mention. What do all these points have in common? They are all about interaction with human beings, not just implementation using a computer.
I’ve seen excellent coders that write code like the inventors of the languages they use. Their implementation is perfect, their unit tests are unparalleled, and their speed is unmatched. However, they are sometimes left wondering why they lost the promotion they so badly wanted and worked for to a person that may not be so proficient in technology as they are. It’s because human interaction is not considered their area of professional focus.
If you are not a good communicator, you will never become a successful Software Engineer. Do not underestimate the human aspects of Software Engineering.
Conclusion
These are not the only things that differentiate a bad Software Engineer from a good one. But they are some prominent ones, easy to encounter in practitioners of Software Engineering.
If you have one of those attributes, do yourself a favor and adopt the mindset of people most admired by the community — a more open-minded perspective regarding what is one of the fundamental pillars of your life; your profession.
Affiliate Links