Stop! You’re a programmer, and you’re about to cross the terrible red line which no programmer should ever cross!
Except if anybody actually said that to you, s/he would first need to know the answer to a particularly tricky question: what is that red line? What is the greatest DON’T that a programmer absolutely should never DO?
I gathered together five of our top programmers & coding instructors working at WBS CODING SCHOOL and asked them exactly that. This is what they said.
What is the one rule you would never break as a programmer?
Alexis: For me, programmers should never forget the human element in their work. What I mean by this, is that when they code, they should always keep in mind what the implications of their code will be for others. It’s easy to forget the way those little symbols and variables on a monitor can impact the lives of real people in so many ways, but if one invents an incredibly efficient automation system, for instance, that invention will probably lead to people losing their jobs. This holds true even within the confines of your own team, so that if your code makes the company run 2% slower, that means less business, which in turn could mean your fellow team-members lose their bonus. The positive flipside to this is that new platforms can be developed which provide people and communities with ways to connect.
Aria: My personal rule, which I’ve made sure not to break for the past two years, has been never to code serious work after 3pm. I am one of those ‘morning people’ who are at their most productive not too long after the rooster crows, so committing to in-depth, technical stuff too late in the day achieves nothing (unless getting frustrated counts as an achievement). This doesn’t mean I can’t do absolutely anything after 3 – I just shift to the ‘softer’ business, like planning for the next day, meeting with my colleagues or reviewing the day’s work. Naturally, how to apply this rule is subjective – if you’re not a morning person, and you code best only after the sun’s gone down, then adjust the arms of your clock accordingly.
Chris: Ah, I get the same, except my cut-off point is eating – my brain goes into automatic standby after lunch. But for me, the golden rule is to keep my approach to coding problem-driven. It is generally much better to solve one small problem at a time, rather than going off and worrying about too many hypotheticals, or which editor to use, or which programming language do I want. Making a list of “things I should be doing” typically ends up as a list of “things I will never actually do”. Learners are particularly susceptible to scuppering their motivation in rabbit-holes and tangents, so this rule is especially important for them.
Ben: I guess my rule is less hands-on and more general: stay humble. The fact that you have been programming for ten years does not necessarily make you a great programmer, because there is a world of difference between doing one year’s worth of innovation and then repeating that for another nine, against actually spending ten years constantly, consciously challenging and improving yourself. Luckily, I am reminded of this rule every day with my students. I’ve honestly lost count of the times I thought I had a solid grasp on a workshop problem, only for one of my students to come up with a solution I’d never even thought of. For me this is absolutely essential: that whenever I tackle a problem for the second time, I should know more about it than I did the first time.
Fey: I owe my rule to Tim Peters, and the gold nuggets of imperishable wisdom in The Zen of Python. I mean this one: ‘If the implementation is hard to explain, it’s a bad idea.’ Basically, if the implementation takes too long, involves too many hypothetical statements and is generally brain-twisting, then it’s probably going to be bad for readability and maintainability, not to mention your own sanity. And this remains the case even when you think you have a deep understanding of the main concepts. Avoiding implementations that are hard to explain should not be confused with shying away from a challenge – it’s about sparing your code intractable bugs, sparing your colleagues confusion, and sparing yourself a ton of trouble further down the line.
