(This piece is based on my current Javascript development stack, but the principle applies almost anywhere.)
So, the whole premise of coding in a complex project, with an environment that is itself likely quite complex, is to be able to conserve your attention. To focus it like a laser on the Things That Matter, and to notice those things, when they appear. But that becomes impossible if you’re surrounded by noise that drowns out the Things That Matter.
Consider your browser’s Javascript console, which you ideally have open all the time while you develop. Also, chances are you’ve got a terminal/TTY window open as well, running your servers/builds while you work. Consider that, too.
If there are two unusual things in there, you’re likely to notice both of them. And you can do something about them. But if there are 107, you’re likely not to. So,
PREMISE #1: CLEAN UP ALL THE CRUFT IN YOUR RUNTIME CONSOLES BEFORE THIS BECOMES A BAD NEIGHBORHOOD
`console.log()` statements pile up like the fine snow that begins a blizzard. At first, you barely notice the light layer of fuzz, and everything feels cozy and lived in. And then suddenly you can’t see your mailbox anymore and you’re wondering whether your kids and dog made it inside alive. It’s pretty much an exponential curve.
Or, call it the ‘broken windows theory of console statements’: it only takes the first couple of them ruining the place and suddenly it’s urban blight that nobody will bother to maintain, or could if they wanted to. And instead of just fixing the first few broken windows when they happened, it gets out of control, and you find yourself needing a wholesale urban restoration initiative. People lock their doors and roll up their windows when they drive by your console. You don’t want that.
Further, there’s even some pretty heavy-duty research about the effect of messy workspaces on human productivity. One methodology that describes this is the 5S approach to manufacturing. So… 5S your consoles.
So, it’s OK if you scatter some `log()` statements around while you’re working. Heck, even if you commit them. But clean them up before you push, or otherwise make your work permanent. Even if it’s a repo of one, it’ll quickly become a dark alley that even you don’t want to travel down after dark. And if it’s a repo you share with others, it gets out of control much more quickly.
Make use of something like ESLint to warn you about them. You can run it as part of your PR sequence, or during your local build. But one way or another, you want something to nag you annoyingly to get rid of them before you push and inflict them on everybody else on your team. Or get used to them yourself. Because if nothing’s nagging you to fix them, you’ll be buried under them before you know it.
PREMISE #2: WHY IS THAT ERROR HAPPENING? YOU *NEED* TO KNOW WHY THAT ERROR IS HAPPENING!!!
The problem with letting your cruft pile up is that you stop noticing things. Nothing sticks out any more. So, even a really important error that actually explains why everything just broke – or will, soon – is just another signal buried in the noise.
All that noise makes you numb. It’s sensory overload. You desperately need to cut down on the noise, so unexpected errors grab your attention when they happen.
And when they do happen, you need to jump on them. Even if you just file an Issue for now while you wrap up something else, it needs to be remarked upon and tracked down, until you can at least understand why it’s happening. And if you’re OK with the reason once you understand it, then feel free to leave it there.
For a little while. But once you have more than one of those, it counts as cruft and noise that drowns out the signals you need to see. <GOTO: PREMISE #1> And thus you need to find a way to get rid of it.
But if you don’t understand it, and if the existence of that signal doesn’t bother you… you’re a problem. When I interview people whose sample code produces random errors they don’t understand, they don’t get hired. I need you to need to understand what’s causing that error. I don’t actually care, under the right circumstances, if you fixed it. But if you didn’t care enough to even understand it, or try, or even to ask about it, you’re toast.
And if you’re working on a project with me and you do that? If we’ve both – and perhaps our colleagues, too – poured weeks or months of blood and sweat into something, and it doesn’t bother you that you created something that’s pumping out errors from our lovely code… then we have a problem. You’re hurting the project. You’re making me sad. Please, please, don’t make me sad. Figure out what’s causing the error.
Or, use this principle: Say No! Then Go! And tell someone you trust! Seriously: it’s OK if you really don’t understand an error yourself. But you gotta’ ask for help.
Because accepting bad things like that without a fight, and letting it ride indefinitely is… well, it’s a lot like having some big oozing sore on your forehead that you haven’t bothered to wonder about or treat. People won’t like you. The other kids at school will make fun. Parts of you will fall off and die. That sort of thing. Don’t recommend it.
Conclusion: It’s Not Just Aesthetics, It’s Effectiveness
To conserve your attention, you need to be able to focus on what matters. That means cutting down on useless signals that try to distract you, and make it harder for you to do your work. 5S up your consoles: you’ll be glad you did.
And, then once you have a clean console and can see what’s right in front of your eyes: don’t ignore it. Whatever is still left is there for a reason. Understand it, or your missing the point, and making it harder to keep a clean workspace.
That Software Guy 