One day while I was on the road heading back home, I heard a loud sound coming from the back of my car. The noise was familiar but couldn’t point out what happened. I was happy the car didn’t stop and I kept going hoping I’ll reach a repair shop soon.
After a couple of weeks waiting, I made it to the mechanic. A quick inspection and he gave me the news: The brake disc broke.
This is something that happens when the brake pads are due to be replaced and creates unnecessary pressure on the disc.
I said earlier the sound was familiar because it happened before. It happened to my old car, back in the day, and I repaired it myself. I’ve been given the tip that if I leave it in the summer sun heat for the whole day, it will melt back in place. So, I did.
I’ve asked the mechanic if we could try and heat the brakes and see if this works. I was hoping to get to use the car for a couple of more months before I’ll have to pay for the reparation.
He said: “Sir, I am afraid we can’t do this here. Here, in this workshop, we do an honest job, we can’t cut corners and risk your life and the good name of this workshop”.
This is called work ethic.
Now be honest. How often do you deliver your best, state of the art piece of code? If the answer is often, congratulations!
Unfortunately, more often than not, like in no other professional trade, programmers are quick to cut corners to meet the ends with a low regard for code quality which will most of the time create problems later on.
Here’s what you can do to make sure you’re giving your job the due respect:
Have some manners (standards)
Be it PHP or JavaScript, make sure you and your team understand the necessity of respecting a coding standard. I’m not saying the whole world should go out of their way and have a single identical style to write code. Some put a comma after the last item in an array, some don’t (PHP). Pick a side and stick to it.
- It will be easier for your team to read through team code and jump in the code base right away.
- It will help control code acrobatics (I’ve made up the word, it means to write code that works but it makes no sense to the naked eye, or it involves techniques not usually recommended for the situation)
- The on-boarding process will run smoother
Debate it with your team and come to common grounds. It is necessary that everyone is on board with whichever decision you come up as a team. Unanimity is required.
Enforce.
Use a linter to make your life easier.
The one we use at Graffino and I recommend to you is XO for Javascript. But you’re free to choose out of the many that are available out there.
Plug it in your build tool as well as in your editor for real-time feedback on your poor discipline.
Following a community style guide will make sure you rise to the expectations of the community.
No matter what tools and tricks you choose to use, make sure you involve some sort of automatism
Stop compromising
Delivering in time is mandatory. Still, try instead of cutting corners every time, to take your time and fix the process. Estimate correctly.
You’ll hear people talk in terms of which is more important, deliver tons of features fast, or prefer high quality. This should not be a discussion. The two are not exclusive.
- Don’t skip code reviews. Use pull-requests and make sure it is unmergeable until it has been reviewed and approved by your fellow programmers.
- Pair program. From time to time. It is the fastest way to discover unhealthy partners in your colleague’s programming style and help them adjust in a timely manner.
- Build your tests. Before or after you write your code? At this point, it doesn’t matter and I don’t care. But have them written down. It helps you reason better about your code; will help you maintain what you’ve written and others better understand what you want to achieve.
- Refactor. Refactoring is not only code tinkering but also a personal process in which you admit to yourself that past you, be it 30 minutes ago or 30 days, is less savvy than today you and is your responsibility to make things right.
Raise your standards
Your last project should be your best project.
Every new project you add to the portfolio is the quality the client expects to get in change.
An agency should deliver like the agency, not like the team or the guy who worked most of the time on the project. This means that it requires the team to put effort into bringing everyone up to a certain level and encourage collaboration and self-development.
Of course, a time will come when you’ll have to call it a day, push your day’s work, pack up your stuff and go home. Of course. But when you do it, do it proudly, knowing that you did a great job and nobody can tell you otherwise.