If you’re into lifting weights, one of the first things we should do is work on our grip strength, though not many people do. Without proper grip, we’re not going to be able to lift the heavy weights, and we could end up hurting ourselves.

Off the top of the dome, unclean code is: 

•  code we can’t understand
• code that makes it hard to find what we’re looking for
• code that’s poorly formatted, untestable, and inflexible
• code that you and your team are afraid to change
• expensive

Unclean code kills companies

Unclean code kills companies. Unclean code kills companies because it results in re-work, wasted time and money, and failed projects.

Clean code is your grip strength. It’s your form. We need to get it right before we take on the heavy weights. Writing clean code is not everything, but it’s worth investing in learning how to do right— building good habits, following well-known best practices, and being responsible. It’s worth your dedication today because unclean code compounds and becomes unmanageable later

Developer mindset

To optimize our efforts going forward, let’s foster the best developer mindset possible.

• Understand what makes programing a trade, the goals behind the software crafts manship code of honor, and why we need a standardized set of ways to build software.
• Produce better designs by cultivating a growth mindset, utilizing positive and negative feedback effectively, and acknowledging imperfections as growth opportunities.
• Learn how to increase the discoverability of your designs with the essential humancentered design principles traditionally only used by UX designers.

Unclean code doesn’t just sneak up on you like seasonal affective disorder. Here are ways it can manifest.

When we try to go fast with arbitrary deadlines and really need more time. Have you ever done anythingwell being rushed? When we skip out on planning and estimation or find ourselves needing more time for whatever reason, instead of pushing back, we rush to tie up loose ends. This usually results in suboptimal, and unclean, code.

When we don’t write tests. You might curse me out for this one, but I do believe that code without tests is unclean. Code without tests is code that cannot be refactored or changed safely. Since more time is spent on maintenance and improvement than on initial development, and change is always a constant factor, we need to feel like we can change code safely. Code unable to be changed safely induces unnecessary stress and anxiety. It also introduces risk. Code without tests is bad for your sanity, and it’s certainly not clean.

When we don’t care about the domain. I can admit to this one. Sometimes you just really don’t give a s**t about the project you’re working on. It’s less likely the next person will be able to maintain the code if we don’t care about the domain, and the names don’t reflect the business. Language is a huge part of software development. Not only might names be bad, but code ends up in the wrong place, abstractions get missed, architectural boundaries are illegally crossed, and things inevitably become a mess.

When we don’t care about the longevity of a project. I get it. To some, programming is just something you do for a paycheck. Maybe you got pinched throwing together a website for your aunt. Let’s get it done, and get the hell out, right? That’s a very irresponsible way to look at your job

When we don’t care about craftsmanship. When we don’t care about craftmanship, any solution will do. If the code works, it’s good enough. When we don’t care about craftsmanship, a mess that works is acceptable. When we don’t care about craftsmanship, we won’t challenge our peers’ code with constructive criticism. Potential conflict is scary, and people that don’t care about craftsmanship won’t figure out ways to have productive discussions. Apathetic developers will tolerate bad code to stay comfortable.

When we’re too scared to have design discussions with other developers. Social anxiety is all too common in the programming industry. It’s really unfortunate, because some of the best design decisions I’ve ever made came from more than one developer’s point of view. Through tools like Slack, GitHub, and Jira, we can build collaboration into the process of developing software- but it takes will-power

When we try to get clever with our code: I used to use the ~ (tilde) operator in JavaScript because it made me feel really cool and clever. What didn’t make me feel cool and clever was watching my teammates avoid the code I wrote because they couldn’t understand it. Writing clean code often means avoiding finesse, even when it’s fun to do so.

When we our design skills are poor: There are two groups of people that we’re writing software for: our users, and ourselves (you, your teammates, future maintainers). As we’ve said several times throughout the duration of this book so far (and we’re only in Chapter 3), making code work onceisn’t enough— the initial completion of a project is only the starting point. Design dictates if the project can endure or not: and design relies on empathy, a basic understanding of the psychology behind how we learn how to use things, and how to make things discoverable and understandable. They ain’t teachin’ that in school, bub.

When systemic issues in the way we educate developers exists. We live in a society that prefers to take a reactive approach to dealing with problems rather than a preventative one. Like most politics, a lasting change to this problem is hard and straightforward ways to fix them in the real-world don’t exist. If developers are making messes in production codebases, potential ways to fix it are to: a) invest in better onboarding and training, b) educate developers with practical coding skills in post-secondary education and boot-camps, c) standardize practical coding skills instead of new technologies.