The capital sins we as software developers should not commit are nothing more than a list of big no-nos that we should avoid at all costs.

Either because they make us look terrible in the eyes of our colleagues or because they work against us and against our career development.

However, no matter how great we think we are (even if you’re right and you ARE a great developer), at one point or another of our careers we’ve fallen prey to some of them. This is why for the sake of everyone new in our industry (and the not-so-new as well), I’ll take you through what I think are the 7 worst things you can do as a software developer.

Ego

What else can we say about this one? Software developers have huge egos. Maybe it’s the god complex that we’ve developed over the years after seeing ourselves as creators.

Maybe it’s the fact that we work inside an industry that no everyone understands and that because of it, we’re seen like masters of technology. I do have to acknowledge that this is happening less and less every year (and every generation) thanks to the different educational systems that try to turn people into digital citizens. Showing people how technology works will breach the gap that was created at the beginning of our industry.

But whatever the reason for this is, we need to understand that Ego is not the right approach. We can’t think of ourselves as better than others.

Have you ever caught yourself calling non-tech folk “muggles”? Because I have. It was meant as an inside joke, but then again, it’s a small glimpse into the uncontrolled ego we have developed over the years.

And others don’t even bother keeping it under control because they confuse confidence with ego. One will help you reach roles and positions you never imagined, while the other will only help in making you look like an idiot. Make sure you understand the difference.

Confidence is about believing you can achieve a task, or learn a new programming language, or understand a complex bit of logic while others have failed in the task. Ego is believing you’re the only one who can do these things because you’re special.

Newsflash! You’re not special. So keep that ego in check, it’ll help you foster a better work environment, learn faster by accepting help from others and move forward in your career.

Fall in love with your code

Granted, this one might be a stretch given I’m using it for “lust”) but bare with me for a second.

Falling in love with your own code is definitely a big no-no for us. Why? Because solving a problem, designing an algorithm or even architecting a whole platform is never about you. It’s only about the project, and the moment you fall in love with your own work, you’ll have trouble seeing that there might be a better solution out there, one that maybe runs faster, requires less code or is easier to understand.

Whatever the reason is, we need to remember to keep thinking about code objectively. If you need to replace a piece of code because the alternative will improve the overall result, then do it. Do not hesitate simply because you spent 3 days working on it.

Who cares if the code you’re changing is yours or someone else’s? Nobody should. The only thing that matters is the project, the development schedule and the overall timeline. If you affect any of them because you’re too blind to see a better alternative when it hits you in the face, then you have a problem my friend.

We tend to think that our work is similar to a work of art, and trust me, I agree with you. When we write a piece of software, no matter how small it might be, we’re putting a part of ourselves in there. Either in the way we write the code, in the way we solve the problem or even in the way we write the code comments. We can leave our footprint in many different ways.

But we must also think about the project. If you like your solution so much, then save it somewhere else so you can use it later, or print it and hang it on your wall. Who cares? Just remember that there is a bigger picture that can’t be affected by your personal feelings towards a piece of code.

Trying to do it all yourself

While this one might also fall inside the “Pride” category, I’m thinking about it from a “Greed” perspective. Either way, this one is another big “no-no” we need to avoid as much as we can.

Your average project for a paying customer should include:

• Coding.
• Automated Testing.
• Manual Testing.
• Documentation.
• Deployment.
• Maintenance.

And within the “Coding” section, you also have things such as picking up the right tech stack, understanding which 3rd party libraries you’ll have to use (i.e which UI framework you’ll go with, what database driver, etc).

There is a lot involved in the creation of a project and depending on the specifics of each case, that list can grow exponentially. So what makes you think you can deliver on time, with the expected quality and documentation required all by yourself?

How many hours a day do you work for?

And even if you do have work days of 18 hours, and you do know how to do everything yourself, let me ask you a simple question: Do you think you’re the best person to test your own code? Don’t you think there might be a bit of creator’s-bias in there keeping you from seeing your own mistakes?

There is a reason why software companies usually have teams composed of very different roles: because a single person can’t do everything right.

By thinking you can, you’re only hurting yourself, your personal life and the project itself.

Another variant of this, is thinking you need to code the whole thing, without depending on any 3rd party library. As if by doing so, you’d introduce some kind of impurity into the system.

I’ve seen developers who think that they can’t rely on 3rd party code and therefore need to develop their own libraries and frameworks.

I mean, I get it, there is always a chance that a dependency might be deprecated or that it might introduce a security risk. Yes, it’s happened in the past, but there are also ways to mitigate that risk and you should look into them. Otherwise you’ll fall into the scenario I described above.

Comparing ourselves with dev-celebs and thinking we’ll never get there

Envy is a bitch, and social networks are a terrible source of it. In my case I’ve seen many developers affected by comparing themselves to others on Twitter (the social network might change but the result is the same).

We’ve all seen the Florin Pops, Telmos and Jack Forges of the #TechTwitter scene. With their huge audiences and successful careers. And they absolutely deserve it, but you can’t compare yourself to them, actually, scratch that, you can, but you shouldn’t.

Seeing how other developers show pictures of them working from the beach as freelancers, or that latest trend of “thanking” a programming language for their huge houses or expensive cars.

I understand where they’re coming from and I understand a very important point which sometimes is lost in newcomers: this didn’t happen overnight.

Seeing success in others and thinking you’re failing because you’ve not gotten there is a terrible feeling. But when you compare yourself and your path to what you see on social networks, it’s the equivalent of cheating at solitaire (you know? that card game you play by yourself?).

Social network posts tend to show the end result of a hard-earned reward, but they fail to show the path that took them there. Whether because the “influencer” (notice the quotes here please) thinks that aspect of the journey is not interesting to others, or because they want to transmit a message of “overnight success”, the truth is they had to work their asses off to get where they are. And if you’re already putting that much effort, then you should not feel bad about these posts, but rather, consider them as a glimps into your future.

Good things come to those who pay the blood price.

That should be a quote from somewhere, but it’s also very true. If you show up every day, and put in the consistent effort that’s required, you’ll reach your goal. Whether that is working from the beach, traveling, having your own start-up, or whatever. Just remember to compare “apples to apples” (instead of apples to oranges) when you’re looking at those pictures.

Leaving “TO-DO: Fix later” all over the code

I mean, how much do I have to say about this one to show you it’s an actual sin?

Heck, maybe ONE of those comments actually required a big-enough effort to merit waiting a bit to fix it. However, I’m willing to bet that 90% of those comments could’ve been fixed right there and then.

Procrastination is a real problem for developers, we add that comment assuming we’ll have time to fix that workaround later. The problem? We never do, there is always something else to work on, some other problem to solve and your comment will live there and, most likely, will be deployed to production unless you have some kind of linter automatically checking for them.

And even then, the solution to the linter blocking your deployment is removing the comment, not fixing the actual issue.

There are two potential ways of solving this sin:

1. Avoid it at all costs. Whenever you find yourself writing this comment, fix the issue. Don’t run away from the work, even if you think it’ll take you some time, you’ll probably come out of it having learned something new and next time, you’ll do it faster.
2. Turn each comment into an issue in your backlog of work. Whatever system you’re using to track the pending work, make sure you turn each of these “TO-DO” comments into an actual issue you can later add to your work iteration. That way you make sure that the requirement is not lost within the sea of code. It might take you 3 days or 3 months to take care of it, but you’ll get there.

There are occasions when time is not on our side, and the idea of fixing those “trivial” issues might not seem possible, just make sure you either make the time or track the pending work so you can do it in the future.

Never stop consuming tutorials

The hunger for learning, fed by the fear of not knowing everything before starting your project is one that many new developers suffer.

“Tutorial hell” they call it, others call it “analysis paralysis”, whatever name it feels right for you, the symptoms are the same: you keep watching tutorials and making notes on how to tackle certain tasks, but you always find something new you’ve never done, so instead of trying to solve it yourself, you decide to watch or read another tutorial.

It’s a never-ending cycle, you’ll always find things you’ve never seen before. The solution and the only way of breaking this vicious cycle is to jump into the water.

After all, the best way to learn is by doing and by facing unknown situations, those are the ones that will take your skills to the next level.

I like to call it the “swim or sink” approach. The trick here is that sooner or later you’ll find out that you’ll always be able to swim. The moment you try to tackle a problem you can’t solve, you’ll jump back online with a question. This time though, it’ll be very specific and focused, so the answer you find will also be short and specific.

That in turn, will give you just about the information you needed to keep going on your own.

Swim or sink, think about it next time you mentally chose to go for another tutorial instead of starting that project you’ve been neglecting.

Roasting other devs during code reviews

Code reviews are meant to be a moment of learning, both for the reviewer and for the reviewee.

If instead, you take this time to denigrate the work of the other developer you’re essentially wasting everyone’s time.

Whether you’re doing it out of fear or envy because their work is better than yours, or because you’re angry that you’re not that good, you need to remember: this is not personal.

Code reviews aren’t personal evaluations of a developer’s skills. Instead, they’re “double-checks” to make sure the one who wrote the code didn’t miss anything important. Be it a bug, a missing coding standard or a complete use case. This is when those types of mistakes are found and highlighted.

And the same thing can be said for the other side, when you are on the receiving end of a code review. Make sure you don’t take the feedback as an assessment of yourself. You should receive it as an objective impression of the code you wrote and any problems found along the way should be considered a learning experience. Any improvement you’re suggested is a learning opportunity and something you should take into consideration for your next commit.

Taking criticism as a personal attack will only keep you from seeing the actual learning. Try to keep yourself separate from your work and analyze the feedback given objectively. That way you’ll make the most out of the review.

We’ve all been there, at one point or another you (and I) have committed one of these 7 sins, that I’m not here to point a finger at you saying you’re a terrible developer. Instead, I hope that you’re able to see the problem in them and try to avoid them in the future.

Whether you’ve fallen prey to pride, lust, greed, envy, sloth, gluttony or wrath, you can now understand there is a better way of doing things.

Have you witnessed an instance of these sins happening in the wild? Share your stories in the comments so we can show other examples of what we should avoid as a group!