We're bringing you seven cautionary tales to keep your programming habits on the straight and narrow. 😈 We'll be highlighting serious programming sins that you should avoid, so fasten your seatbelts, tighten your syntax, and prepare for some spooky stories!
New to BearPeak?
- Explore our software studio.
- Learn more about us.
1. Greed - Code Duplication
There once was a world full of software developers. One of them, a developer named Greed, had a nasty habit: Instead of creating reusable components, Greed would duplicate code.
"Copy and paste, copy and paste," Greed chuckled.
Greed had many excuses for this behavior: "My work is too fast-paced! Our deadlines are too tight! The design phases are insufficient! And code reviews? They rarely happen! No one communicates! Besides," Greed said, "One of my tasks is a legacy project. Programmers have been duplicating code throughout it for years! Do you realize how long it'd take for me to find and revise every duplication?"
Deep down, Greed wasn't confident enough to create reusable components. They were too afraid to cause bugs, or worse, destabilization. Sections of the code were duplicated again and again, and changes became harder and harder to make.
Duplicating code can lead to maintenance nightmares. When changes need to be made in multiple places, the chance of introducing errors only increases. A greedy programmer considers short-term gain over long-term pain, refusing to create and share reusable components with other developers, and excessively accumulating redundant content. It's a selfish way to code.
Instead, take the time to accurately create reusable functions and components, participate in code reviews, and follow best practices for modular and maintainable code.
* NOTE * There are situations where code duplication is justified or necessary, such as when creating specialized, highly-optimized routines. However, it's still essential to prioritize code reusability.
2. Pride - Not Seeking Help
Across town, two siblings named Shy and Pride worked as software developers, too. They sat at home, desks at opposite ends of the house, and worked on their programs alone. Both siblings refused to collaborate with other programmers, even each other. Worse, when they got lost in their work and couldn't find the answer, they both refused to ask for help.
The first sibling, Shy, was simply too nervous to ask for help (we've all been there). But Shy eventually came out of their shell and met other programmers they trusted. Problems were fixed and Shy excelled.
The second sibling, Pride, never asked for help because they were too stubborn. They continued to waste time trying to solve problems on their own, and progress was never made.
If you're spending an excessive amount of time trying to debug a complex issue without asking for help, you're wasting time and effort. Prideful developers hesitate to ask more experienced colleagues for guidance out of fear that it will make them appear less competent. Refusing to participate in programming forums, Stack Overflow, or other online communities displays a similar reluctance.
Prideful software developers avoid code reviews and become defensive when their work is critiqued. They refuse to attend training sessions, workshops, or courses; places that would reveal gaps in their knowledge and skills.
They take on more tasks than they can handle and insist on working alone. This excludes team members from collaboration, ultimately limiting the project's potential success. Pride makes it difficult for a programmer to admit their mistakes, leading to cover-ups and unresolved issues.
So what's the solution? Reach out! It can be tough, awkward, even embarrassing at first, but you'll become a better programmer from it. Here are just a few of the resources at your disposal:
- Your personal network
- Professional mentors
- Code-pairing partners
- Official support channels (if using commercial software or a paid service)
- Official forums (ex. the Python community has the Python Developer's Forum)
- Stack Overflow
- GitHub
- Subreddits like r/programming and r/learnprogramming
- Official program documentation
- Online tutorials
- Developer meetups
- Local user groups
- Coding bootcamps (in-person and online)
- Coding books and ebooks
3. Lust - Overcomplicating
Lust loved the complicated details. It felt so good to understand them inside and out, and incorporating them successfully felt even better. But Lust was so obsessed with fancy techniques that they were tempted to incorporate them just for fun, even though simpler solutions would've sufficed.
"Can I somehow squeeze in Singleton, Factory, and Observer? I love them all so much; so much detail, so much complexity. Ooh, and I love if-else statements!" Lust squealed with excitement. "And loops! I can't leave those out. You know, this code would look even prettier with more switch cases! Forget the boring, simple arrays and dictionaries; I'll customize my own!"
An excellent programmer doesn't pack their code with tool they've ever learned. Instead, they know when to simplify. Sure, frameworks and libraries can streamline development, but it's important to identify when a project has become more complex than it needs to be.
Lustful developers create deeply nested if-else statements, loops, and switch cases, making the code hard to read and debug. Instead of using basic data structures, they implement intricate, custom ones that are harder to understand and maintain. In object-oriented programming, lustful developers might create deep class hierarchies with multiple levels of inheritance, leading to even more complexity and confusion.
Overusing functional programming concepts like higher-order functions, monads, or currying can make code harder to understand for those who are not well-versed in those techniques. They may use intricate regular expressions for simple text parsing tasks when simpler methods like string manipulation would be more appropriate.
In all these cases, the temptation to overcomplicate code can be compared to the deadly sin of lust – the desire for complexity and sophistication even when there's a more practical solution. In the world of programming, simplicity and clarity often lead to maintainable and bug-free code.
4. Envy - Not-Invented-Here (NIH) Syndrome
Envy always had a problem sharing. Instead of using well-established existing solutions, Envy would reject them and create their own instead.
While Envy would say that other's solutions were inferior, they were really just jealous that someone else came up with them first.
Programming projects are rarely the time and place to reinvent the wheel. Wasting time and missing out on pre-made solutions may be driven by a desire for control, ego, or a belief that in-house solutions are superior. It's called Not-Invented-Here (NIH) Syndrome.
Replacing a framework like Angular, React, or Vue means waiting for a whole new front-end framework to be built from scratch. Passing on an established encryption library, algorithm, or user authentication system (such as OAuth or OpenID) introduces new potential security risks. Rejecting standard data structures (e.g., arrays, linked lists) in favor of creating custom ones means implementing less efficient and less-tested content, all in the name of being unique.
NIH syndrome often leads to wasted time and resources, increased maintenance burdens, and potential security and reliability issues. While there may be legitimate cases where a custom solution is warranted, developers should be cautious not to reject established, well-tested solutions without well-grounded reasons.
5. Gluttony - Over-Engineering
Gluttony saw the other programmers' bad habits and wanted them all: They stuffed the whole software system full of unnecessary features, components, and architectural elements, far exceeding the project's requirements.
"It's better to be prepared for any eventuality, right? You can't blame me for that," Gluttony bellowed as they packed the program with more complexity. They would argue "what if we need this later?" while hoarding content that they, in fact, would never need.
Whether you fear change, feel pressure to impress, or simply lack team communication or the experience to properly arrange your project's priorities, over-engineering is a gluttonous act. It consumes unnecessary memory, processing power, and development time, resources that could be allocated to more critical aspects of a project.
A gluttonous developer might argue that over-engineering is necessary to accommodate future changes or requirements that are not yet defined. They may claim that adding extra features prioritizes flexibility and scalability, believing those qualities to be more important than delivering a minimal viable product.
Developers who are unwilling to compromise on technical aspects may over-engineer to avoid making hard decisions about what to include in a project. They may believe that every possible feature or architectural choice is essential.
The key problem with over-engineering is that it can lead to higher development costs, longer project timelines, increased maintenance burden, and reduced user satisfaction. It can, however, be addressed by refocusing the development effort on essential features and components, aligning the project with its actual requirements.
6. Wrath - Anger
Nothing's wrong with a messy desk, but Wrath's was on a whole other level: Crumbs filled the empty keys missing from the keyboard. Angry scribbled notes had heavy blotches of ink where the pens had broken and bled. The missing keys could be found on the other side of the room, below a dent in the wall where Wrath most often aimed their keyboard when throwing it.
One laminated task list was taped to the wobbly monitor, and Wrath lived by its instructions:
1. Ignore program documentation.
2. Try to solve problem the easy way.
3. Fail.
4. Rant in the code comments.
5. Make hasty changes without analysis or testing.
6. Fail.
7. Play blame game with team members.
8. Fail.
9. Point fingers at libraries and external factors.
10. Vent in the commit messages.
11. Consider inventing a huge, time-consuming, unnecessary custom solution.
12. Have another fit of frustration.
13. Give up and call it a day.
Every programmer gets frustrated. But when that fit of anger isn't calmed, a developer is prone to make poor decisions. Low code quality, hasty changes, rushed deployment, and new bugs are some of the obvious consequences. But an angry programmer may also resort to overworking, staying up late into the night, leading to burnout and only further exacerbating the issue.
In extreme cases, a developer might become so angry or frustrated that they give up on solving a problem altogether, leaving it unresolved.
Managing wrath is essential to maintaining a productive and positive work environment. Practice patience, seek support from colleagues, take breaks, and approach challenges with a clear, rational mindset. Addressing problems systematically and calmly is much more likely to lead a successful solution.
7. Sloth - Laziness
Sure, Sloth completed the bare minimum, but it was always an unmaintainable mess. Picture a submitted product full of debugging statements and code in the production codebase. Sloth used more straightforward algorithms (a trait we praised earlier), but in circumstances when a simple algorithm was inefficient. Optimization? Sloth hadn't heard of it. Pair programming code review? Sloth slept through it.
Where Wrath saw every issue as the end of the world, Sloth could not be bothered. They hardcoded values directly into the code, neglected errors, and gave every variable a one-letter name.
Lazy programming leads to inefficient solutions, unmaintainable code, and missed opportunities to improve. Neglecting to handle errors properly can lead to unexpected failures. If a programmer chooses to hardcode values directly into the code rather than using variables or configuration files, it will be challenging to make future updates. Lazy programming results in a codebase that is difficult to understand, maintain, and extend, with increased technical debt, security risks, poor performance, and long-term issues.
Instead, put in the effort. Write clean, efficient, and well-documented code, and your work will pay off.
Reflect on These Sins of Programming
That's where our frightening stories end, dear reader. Did these characters remind you of programmers you know? Did any remind you of yourself?
In order to keep greed out of your work, prioritize quality over quantity. To avoid being prideful, stay humble and accept feedback. As fun as complicated details are to know and use, avoid lusty code over-complication. To keep your envy in check, celebrate other's success and utilize tried and true tools. Refocus on the essential features to prevent becoming gluttonous. Stay calm to avoid counterproductive wrath. And unless you want to be tagged as the lazy one on your team, don't cut corners. Be thorough, diligent, and collaborate to make your project the best it can be.
Comments