Lorenzo PasqualisThis post was first published on CoderHood as 9 Software Engineering Career Mistakes To Avoid At All Costs. CoderHood is a blog dedicated to the human dimension of software engineering.
Taking risks and making mistakes is part of the learning path to greatness. Failing quickly and often is a hallmark of success. Nevertheless, aiming to avoid making the same mistake more than once should be somewhere high on your priority list.
Personal experience is the most powerful way to learn. But, knowledge acquired through other people's experiences can shortcut your way to success and save significant pain. In particular, being aware of common mistakes that other people make can prevent falling into avoidable traps.
Let me give you a parallel example. I am into woodworking and when I bought my table saw I read all I could find on table saw accidents and how to prevent them. Table saw mistakes can cost your fingers, your hand or even your life. The bad experience of others can prevent serious injuries. You do not have to suffer the loss of a limb before you learn how to use your new tool.
Software engineers are not going to be physically injured when they make a blunder. They can, however, miss on years of career building opportunities by not realizing they are doing something wrong. Many mistakes in software development manifest in ways that do not translate directly into obvious learning opportunities. They slow down people's career progression and keep them from reaching their highest potential.
9 Mistakes To Avoid At All Costs.
As a software engineering, you are making a mistake if you are:
1 - Not Testing Your Work.
When you write code, you must test it. Before I continue, let me give define some of the terms related to testing; it will help with the rest of this topic.
Testing Related Definitions
- Happy-path: a series of operations, data flows and user actions that exercise the business logic of the code as designed.
- Unhappy-path: any deviation from a happy-path caused by factors such as:
- Error conditions.
- Unexpected inputs.
- Bad configuration or system setup.
- Missing or exhausted resources (memory, disk space, network, etc...).
- Hardware failures.
- Unexpected scale / concurrency conditions.
- Formal testing:Â Exhaustive testing done by someone who didn't write the code. That could be a tester, QA Engineer, another developer or a vendor. Formal testing takes into consideration many things, including the spec (if any), documentation written by the programmer and knowledge of the user and business context.
- Development testing: This is the testing a developer does to get ready for the formal testing. Development testing must include:
- Manual testing. Exercising the business logic as an end-user would.
- Unit testing. Creating repeatable tests for units of the code.
- Automated testing. Code that tests end-to-end a system or part of it.
With this in mind, just because your code compiles with no errors or just because the happy-paths seems to work, it does not mean the work is ready for formal testing.
To avoid this blunder, you must:
- Perform development tests for all happy paths.
- Perform development tests for all easy-to-test unhappy paths you can think of.
- Document all the non-easy-to-test unhappy paths you can think of. Evaluate and discuss those with the formal testing team to decide who should do it and how to approach it.
2 - Hiding Your Mistakes.
In most situations, hiding a mistake is worse than whatever mistake you are trying to hide. You should always be transparent about what went wrong, how it happened, what you are doing to fix it and what you are going to do to prevent similar things in the future.
I have never seen anyone getting fired for a mistake they made and admitted. However, I have seen people getting fired for mistakes they tried to hide. Hiding a mistake will destroy your credibility; gaining it back can be very difficult.
To avoid this blunder, be loud when you make a mistake. Let the people that might be affected know and admit full responsibility openly and immediately. You should feel the weight of whatever you are hiding as something that you need to release before it crashes you.
3 - Feeling a Strong Sense of Individual Code Ownership.
I wrote about this topic in 12 Reasons To Avoid Individual Code Ownership. Sometimes individual code ownership is part of the engineering culture of the organization you work for. Other times it is a mistake you perpetuate because of ego or pride. Avoid it if you can. If you don't, it will come back to haunt you.
To avoid this pitfall, do not become protective of your code. Look at it as a sidewalk that you built for others to walk on.
4 - Documenting The Code For Yourself And Not For Others.
When you document your code, you should do it for the developers who will work on it months or even years from now. Since you do not own the code, the documentation should be targeted to explain to others what you did and why.
If your documentation is understandable only by you, nobody else is going to be able to work on the code efficiently, and you are going to become the de-facto owner. That leads you to a path of individual code ownership and as a consequence getting stuck into a self-made career prison.
Additionally, poor documentation is one of the most visible signs of poor code. It might be difficult to tell how bad a piece of code is, but it is effortless to tell how bad its documentation is. When you leave bad documentation all over your work, you are going to become associated with the bad code.
It is typical for prototype systems built in a hurry --- especially in the early stages of a startup --- to have poor documentation. Code written in that context is not meant to last for a long time. It is often written as a proof of concept. Unfortunately, prototype code tends to stick around indefinitely. For that reason, I recommend writing all code as if it is going to be touched by many developers for years and years. Most of the time it does.
To avoid this mistake, write all your code comments keeping in mind the image of a developer that is going try to modify it years from now. Give that developer a face and a name. Mine is Bolbo, he has dark hair, a square face, wears glasses and has a very cynical sense of humor. I even drew it. Don't ask.
5 - Fighting The Development Process.
Development processes such as Scrum and Kanban are designed to allow teams to scale. They facilitate collaboration and shared ownership of projects, ensuring that enough planning is done and that the execution of the plan is coordinated.
Developers who fight formal processes create friction that burns energies and slows down the scalability of teams. That is a problematic trend that tends to relegate the naysayers to solo initiatives. That isolation can be a career killer for a software engineer. He or she is going to be seen as incapable of collaborating and working in a team.
Different organizations choose to adopt various formal processes. If you have strong opinions on the matter, it is important to help to make that choice and shape the selected process into something that works. If you fight it because you prefer a cowboy-style coding methodology, you might want to consider a smaller organization that does not have team-scalability aspirations.
To avoid this mistake, internalize the need and advantages of development processes. If something doesn't work for you, help to fix it. Do not fight it hoping to go to a cowboy-style no-process environment.
6 - Doing 90% Of The Work And Switching To Other Things Before You Are Done.
If you hire a painter to paint the inside walls of your house, you expect a finished job. By the time you sign the check, the walls should be painted, the room clean and ready to be used. If what you get is a room with blue tape still on the trims you are not going to be satisfied.
Code that is 90% done is not done. Some developers like to prototype proofs of concept, and they are good at it. However, making "prototyping" a habit is a slippery slope. When it comes to bringing a deliverable to a shippable state, they often fail to complete important finishing touches and polishing work.
Unfinished work cannot be released. If the person who did the majority of the work doesn't finish it, somebody else needs to. This kind of behavior translates in teams not getting anything done.
The solution is always to finish your work. Do not wait for others to pick up where you left off. Look at it as helping a toddler cross a busy street. You wouldn't want the kid to cross the most dangerous part of it without holding your hand, right?
7 - Not Checking-In Your Work.
Some developers are not in the habit of checking-in the code they are working on. It might seem strange, but it is especially common in the following situations:
- Experimental or early stage projects.
- Build scripts.
- Infrastructure code.
- Test code.
- Configurations.
- Deployment scripts.
- Scripts meant to run once.
All code must be checked in as soon as possible and as often as possible. If you use GIT, branching makes it a breeze. You should work with the mindset that files that are not checked-in do not exist.
8 - Not Understanding The Value Of Estimations.
Software organizations are subject to the law of economics. I wrote about this topic in a post titled The Economy of Software Development. In particular, organizations need to be able to decide if they should or shouldn't invest in the development of a product, feature or enhancement. To make that decision they need to have an estimation of the cost and the value of the result. Without such estimations, it is impossible to make such an evaluation and decisions end up being made in a vacuum.
Developers sometimes become convinced that it is impossible to estimate the effort required to complete a project. I agree that it can be difficult, but with practice and experience estimations become more and more accurate. Developers who are willing to improve their estimation skills go further in their career compared to developers who don't.
The solution to avoid this mistake is to internalize the business value of estimations and to make it a career priority to become better at it.
9 - Not Sharing Knowledge With Others For Fear of Becoming Unimportant or Irrelevant.
I discussed aspects of this topic in a post titled Career advice: work yourself out of your job and also in 12 Reasons To Avoid Individual Code Ownership.
Keeping knowledge close and protected from your teammates is a very self-damaging habit. The fallacy is that being the keeper of knowledge provides job security; in reality, it makes it difficult for you to acquire new responsibilities.
A promotion is commonly associated with a larger area of influence. If you keep knowledge hidden, you are going to be seen as someone who can't delegate and influence others or work in a team. You are going to be seen as a worker-bee who holds a critical position but cannot move to other things or scale to more senior roles. As soon as your tenure with the company starts to not align with the value you bring, you'll notice a shift in how you are perceived. The knowledge you hold will eventually become outdated, more dynamic engineers will eventually re-build what you have been protecting, and you'll no longer be seen as valuable as you used to be.
The solution is simple but not easy. Share what you know. You can do so by writing documentation, training others, delegating some of the work, hosting brown-bags, etc. Try to never hold for a long time the one key to a great vault of knowledge.
