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 hu...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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?
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.
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.
"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?
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.
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 🙉
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.
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.
Great post. Just added you to my Feedly. Thanks for writing.
Great post. Thank you very much.