“Don’t expect to be motivated every day to get out there and make things happen. You won’t be. Don’t count on motivation. Count on Discipline.”
Jocko Willink
I love this quote, and I think about it everytime I feel lazy or tired and I don´t want to wake up early, workout, finish that course on Udemy, wash the dishes or whatever.
I love climbing and I would climb every day, but the sweating, screaming and going through the sore muscles of a full workout, well that sucks! But it´s important! And you can get all the benefits of it, once it becomes a habit.
In coding, we can be motivated in writing clean and good quality code because we just learned a new concept, or we found out a new cool trick, or maybe because we just started on a fresh clean repo or we just joined a new team, or project.
Or or or, if if if.
The truth is that over time we might get bored, and sloppier. And then we don´t care anymore if in that method there is a typo, or if we duplicated the same or similar thing ten times.
Copypaste is easier, Job done!
Other times, we might have good reasons, or good excuses that legitimate us from writing good quality code:
Deliver! Deliver! Deliver!
Well, this might all be true, but I remain still convinced that writing quality code is a good habit, and like most habits, it needs discipline and dedication. You have to commit to it, somehow force yourself into it.
Then it becomes an attitude, and you will find yourself writing good code without even thinking about it. Quite the opposite, it will feel very weird and difficult to write sloppy code.
Have you ever opened your IDE thinking:
Oh - I am in a hurry - let's write shitty code - but let's get shit done.
or
Good, sprint is planned, now I have plenty of time to design and implement things properly. Let´s do that sloooow and goood. Oh Yeah, baby!
I don´t think so. But both thoughts might be sneaky and underlying our coding style if we don´t have the discipline and right attitude.
If it takes us lots of effort to write good code, at the first opportunity, we will simply give up.
But that´s a prototype, code does not have to look nice!
Recently we worked on a prototype, and we were all very excited about the new project, we wanted to iterate fast, and we wrote lots of messy code.
But, what does messy code mean?
During a prototype phase speed is more important than quality.
The goal is iterating fast, and during iteration, you will change functionality and delete code all the time.
It might even be frustrating to throw away very good ideas, but it is how it is, that´s the point, trying out things, show them to the client, iterate. The idea ( and the piece of code that is shipped with it) might be awesome, but simply doesn't fit the project, the client doesn´t like it or they have simply changed their mind and changed the requirements.
Keeping this in mind, allows you to take some shortcuts:
- you don´t fix all the linter errors before committing,
- you allow some ( /lots of) duplication,
- you hardcode some values or entire data providers,
- you can skip writing all the PropTypes for your React Component,
- you are allowed to style the component inline and so on..
There are high chances that everything will be thrown away anyway!
All this is ok, but you also have to remember that some code, won´t be thrown away. Over many years, I have never seen a prototype being used only as a proof of concept. As soon as the concept is approved, most of the time you start building other features on top of it.
Many parts of its codebase, therefore, will make it in the final project, so the better they are the faster you can refactor them, or build on them. Also, that code will become somehow the starting point - the standard - the reference of any code that will be written after, for all the developers to come.
So, even if it´s a prototype, don´t write shitty, sloppy code, just because it is a prototype. Have discipline, stick to quality code, somehow force yourself into choosing with awareness some shortcuts, but don't allow the "don´t have time" excuse sneak into you.
But I need to be quick!
Another reason to not write sloppy code is that Yes!, you need to deliver fast, but that does not always mean that you are rushing into the deadline.
Most of the time the development team is involved in the estimation of when a feature could be ready. So the delivery date is not always imposed from above. You have the chance to ask for the right amount of time to not be stress and not be forced into writing shitty code.
In my career, I found many colleagues that during the code reviews, were saying,
I know that code is bad, but we will refactor it as soon we will get some buffer for Technical debt.
This will rarely happen.
Stakeholders will always push for features ( functional requirements ) vs Quality / Refactorings / Non functional requirements).
From the outside the application is working, why change it?
Why spend time just for gold plating, for something that is not visible from the outside and brings nothing to the end-user, when we could invest in new features, that will bring new users or more money?
But
without periodic and aggressive refactoring, we can't produce sane, maintainable code. quote from The coding Horror
and without discipline, we will always find valid excuses
You have to plan for your tickets properly, sometimes you have to fight your way out of an accurate and reasonable estimation/delivery date.
You have to share with your colleagues and project managers the definition of done and consider as part of the feature unit tests and quality code.
You have to force yourself into all this practice. Some of it might be uncomfortable, or difficult, or plain boring, but with discipline, it will become a good habit.
Top comments (12)
Many startup companies that I joined in my country hate me because I am too discipline to prevent them to write shitty and sloppy codes. Every time I look at their codes, either existing or new project, I always say
Motherfuckin my head. One thing particular is they love making product presentations like fairytales in front of the stakeholders or to their audience. But the product, in reality, sucks in every single way.I feel this. I'm not the neatest code writer but I always try to write it properly, albeit of the process being slow.
And by proper I don't mean the most efficient way to do it. As the quote from Coding Horror, we've to refactor it in the end.
But the thing you're implementing now should at least be compatible and sane enough to be used by the rest of the team.
Don't necessarily look for optimal solutions but always try to look for clean ones. You'll find the best ones along the way.
I've heard too many discussions in my life, between my employees, who and what is more important, developer, designer, sales, management. Usually they had similar tone to your post (rant?). However, in reality, company or a startup project) is so much more than any individual part of it. Sorry, but i dont get tolerance, nor any effort to see a wider picture from your post. Clean code in most cases is desirable, but not in 100% of cases. It's impossible to judge based on the data in your post. But thats not even the most important part. Your comment on their sales and presentation of the product just sounds really bad. What other than that you expect? That they market it as a junk? Id say their sails does great job!
From perspective of a person in this business for 30 years, worked everything from junior developer, over project manager to CEO and owner, my guess is that companies you mention don't have issues with your clean code ideas, but with a way how you present them and (maybe) try to enforce them in the company.
Well, thanks for the compliment. I love my rant. Which makes me a better veteran electronic and software engineer. Please... Do not hire me if any chances.
Yep. i guess that could be a problem in many startup that are alwasy rushing and moving from Prototypes to MVP to Fullfledge App in a matter of weeks ( and with the same code base.. )
Great topic and some good points. I suppose lots of people can relate with this topic.
However, experience thought me that you should not count on self-discipline. You need to have a system. And be consistent with that system. A set of rules that produces consequences when you brake them. That makes creating habits more likely to happen.
Loved this post! Youre so right, the times we actually get to go back and have the time to refactor are hard to prioritize!
I love how you explained how the code you right can become a habit, so focus on the habits and good code will come.
I wrote something along similar lines about motivation, and I too quoted Jocko. lol scottistern.com/motivation/
Thanks. I checked your post out. Very nice.
That's exactly the point. I ask myself that question all the time, and the answer is, because I am scared, because it is difficult, because I don't know how to do it.. And those are exactly the reassons why I must do it 😅
Heck. All the excuses you gave about quickly writing functionnal code and not bothering with code quality and sturdyness, I already heard them from my boss every 2 or 3 days.
I learnt the hard way at a precedent job with TDD, code coverage, law of Demeter, ... and here, it's all about delivering features, 500 lines of code for a function, copy paste everywhere. And everytime I want to apply and justify the need for good practices, the answer is "do a functionnal code that works, we will see later for adding sparkles to it. Don't do quality code for the sake of doing it, the feature is the priority".
Awesome article. Loved the first quote.
interesting. i didnt know the quote was from Milton Friedman. I've always known the generic version of "the temporary solution" :-)
and the Design Stamina Hypotesis link is priceless. thanx