Quality in Code, Quality in Everything
- Kiranbir Sodhia
- Apr 7, 2013
- 2 min read
I was recently tasked with teaming up with developers to create a presentation. For most of us, this was out of the norm as we spend our days coding and debugging. We all split a few slides, someone collated them, and it was sent out for group review. I started noticing one person’s slides was a steaming pile of shit.
They used inconsistent abbreviations and capitalization. Sometimes a term was wifi, Wi-Fi, or WiFi.
Greek alpha characters were used for measurement units in some places, and missing in others. They used ns for nanoseconds but wrote out microseconds because they couldn’t find the µ symbol.
Arrows were represented by alphanumeric characters. <—- I’m seriously pointing here.
So I listed the necessary grammatical and formatting modifications along with actual content suggestions. I was surprised in the next draft, that the author only took into account my content suggestions and told me the presentation wasn’t a big deal, and style did not really matter.
On one end I could relate to them. That dev might have been busy with other tasks. Then my mind started wandering, and I started questioning whether this developer cares as much about their code as they did about this presentation. Do they put curly-braces on new lines in some functions but not in others? Do they not test as much because they have more code to write? Do they write shitty code when they know nobody will look at it.
I think it’s all attitude. It’s not easy to make someone care about something. It’s definitely wrong and far-fetched for me to assume my colleague’s attitude towards their code. I guess, regardless of how boring, unrewarding, or demeaning a task, I think people should put in honest effort and try to do a good job.
“A great carpenter isn’t going to use lousy wood for the back of a cabinet, even though nobody’s going to see it.” ~ Steve Jobs


Comments