This 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.
Latest comments (14)
Definitely a must-read for all of my colleagues! Nice job, Lorenzo!
"Failing quickly and often is a hallmark of success" - I like that most points are rather applicable to life, not only to software engineering.
Okay, if it comes about general programmer's philosophy, let me share my two cent to the topic: here the guys talk about best practices litslink.com/blog/what-are-softwar.... I'm sure, most points go without saying, still it's always good to remind.
What a great article! I think you made really good points!
Great post. Thank you very much.
Great post. Just added you to my Feedly. Thanks for writing.
Point 9 (Not Sharing Knowledge) and point 4 (Documenting The Code) are very similar and I've noticed in my 18 years of software development that the first people who leave a company are exactly these kind who are secretive about their code and too lazy to document their code. They may claim to have found a better job and therefore they leave the company, but they leave a mess and I would never hire them again.
The problem is also that documenting code and writing howtos is not forced by the superiors.
So good. Just posted to LinkedIn. This post is applicable to anyone in software development very easily. Really, by analogy at least, it applies to anyone with a job.
I think this is a fairly good list for the 80% of pitfalls that will occur in a Software Developer's career. I think more can be said about the following topics however:
When and how to fight battles over code quality/ architectural design
This one has been very common in all the jobs I've had in my career. A simple mistake in these matters can and will lead to being ostracized by the team, and perhaps even termination from the company.
The main reason this is so hard is because egos are involved. I've joined up in companies where just about everything about the architecture of the systems is wrong. Everything about how the software is organized is wrong, and it's leading the company down a bad path of unpredictable, untestable systems living in production. Merely pointing this out to your new colleagues might be a bad move depending on the personalities of those who have perpetuated the bad system.
The worst case is when the most senior person on the team will not hear feedback, or want to improve the system. Worse yet is when they would like to improve the system, but the person with the purse strings is adamantly against ongoing software house-keeping.
I wish I had good answers for this problem, but I don't even know where to start. Sometimes it seems like resigning is the only correct solution.
Navigating which projects you get put on
This one is another difficult challenge that all of us will face at some point in our career. Being able to tell which project to avoid at all costs, and which will put us in a favorable light with the powers that be. Many projects have hidden pitfalls, and you might find yourself in too deep, trying and failing to fix an unfixable problem. Perhaps the project was barely functioning before you got put on it, and now that you're making any changes at all, it suddenly starts failing all the time. Whether you like it or not, people around the company think you are the reason for these failures.
The opposite can also happen, where you just luck into a project that everyone loves, and are regarded as a hero. Again, I wish I had more advice in this area, because it is quite difficult to navigate without lots and lots of experience.
1 It's really important to test and avoid bugs.
6 It's my biggest problem. I'm not done and my boss wanted to start another project. He doesn't know how to prioritize. Everything is important, everything must be coded right now and Everything has to be on production for yesterday and without test. To finish those projects I work at nights and weekends, but no more, I got tired of this mess
100% of 1 thing actually done-done is better than 20 things each 90% done.
Although I think too many developers are willing to call something 100% done-done and not follow-up the work with refactoring and clean-up. Because to do a good job at the refactoring and clean-up that takes about as long as implementing the feature itself.
I liken that follow-up with a painters analogy. When I had my house painted, inside and out, it took the painters about 3 days to prep everything. They spray-blasted the outside to clean it, caulked the cracks, put a coat of something protective on the wood deck, laid out tarps, got all the materials delivered. Inside the house they taped, took down some doors (temporarily), put down tarps. Then they painted everything, which took about 2 days. Then they cleaned up, which took 3 days (and some touch ups, and had to bring in a machine to respray "popcorn" on the ceiling).
I think programming is about the same. There some prep time (we call that time a "spike"), there's implementation, and then the follow-up to clean up the implementation.
Without that follow-up, it would be like the painters just leaving all their junk behind for the owner to deal with.
Yes, exactly! I learned that in the bad way. I always refactor and clean to keep code improved. Now we are doing everything to real 100% done-done, It's more work but everyone will thank you later, even yourself.
"Not Sharing Knowledge With Others For Fear of Becoming Unimportant or Irrelevant." who does that? Who hides knowledge with the purpose of being the only source of truth?! Not only this holds back the whole team, it holds you back as well because without knowledge sharing how do you expect to grow?
Maybe put a different spin on some of these:
Test your stuff
Sure, do. Make a good automated suite and keep it sanitary. TDD if you can.
If your company has no testers because they fired all of them, pad your estimates so you can do real automation of the "sad path" stuff too.
Hiding your mistakes
Okay, this is pure soft skills.
Or, just read the first chapter in Pragmatic Programmer on "Give options, don't make lame excuses."
Fighting the Development Process
Nuance: Understand the way the wind is blowing, so to speak, but don't be a sycophant. Lots of shops use crappy, ill-designed, badly-implemented development processes. Don't accept them out of hand.
Insist on doing better, but in small ways. Enact the "Think globally, act locally." How can your team be better? How can you influence the whole org to be better?
All of these points are spot-on.
#3 in particular is a good one. Unless you own the company... you do not own the code. The developers are the stewards of the code. They take care of the code, make the code better, enhance the code. But they do not own the code. They are paid by their employer to do those things, and if they get all prickly about their little corner of the code things won't go well for the developer.
This sounds like a too perfect world, if you live and code in such an environment good for you, you are in Heaven already 😀
Usually the non-tech boss just want their 💩 done today, maybe tomorrow, you can try to pronounce things like "tests" or "processes", but is like speaking to a wall 🙉