Or stayed out with friends long after bedtime? Or — God forbid — taken the shortcut through the park where shady people lurk, instead of going the long way over the main road? Or, yes oh yes, which programmer hasn’t violated one of those etched-in-stone best practices, you know, one of the ones that you should follow at all costs? It’s safe to say that many, if not most, of us have done this before. But maybe your rule-breaking is exactly why your code was better than average. At least it didn’t make you lose your job. Or make your computer explode at runtime. Sure, breaking rules is never without risk. If you’re a brain surgeon, you really should follow the rule of “never cut this piece off.” (Forgive me for my bluntness, I’m no medical expert.) But if you’re building software, what’s the worst case? Sure, if you’re designing killer drones or software for electric grids or support systems for spaceships you might want to go slow and follow the rules. But those programmers who don’t have high stakes like that — and that’s most of us — you might want to question your rulebook from time to time.
Copy-pasting code isn’t the root of all evil
The die-hard open-sourcers and the die-hard purists may argue otherwise. But, in all earnesty, who hasn’t copy-pasted code snippets from StackOverflow and other places of the big wide internet? First of all, if you have a problem that takes five seconds to google, you wouldn’t go annoy your coworker for ten minutes to make them fix it. And if the answer is on Stack, then, well, the answer is there. The purists would argue that you shouldn’t copy anything because you might not understand what’s going on in the copied code. And they have a point. But if you’re googling around anyway, you’re quite likely going to check the manual pages of the function that you’re copying over anyway. Plus, you’re probably going to need to adjust a few variable names and understand where to put that snippet of code. That’s not possible without a minimum of understanding. Another point for the purists is that your ready-to-copy-paste code may contain non-printable characters. These are characters like a backspace or a horizontal tab that you can’t see on your screen, but that can have an effect on the output anyway. Purists would therefore argue that if you’re going to copy code, at least type it yourself so you don’t accidentally copy non-printable characters and make a mess of your project. That’s cool advice, but personally I don’t know anyone who has ever bumped into a non-printable character and messed up their code. I do know someone, though, who introduces typos everywhere: me. To be clear, I agree with the open-sourcers that copying entire open-source codebases to a proprietary project is bad. Not only is it unethical; it also makes your code vulnerable because you might not be in the loop for important security updates any more. Unfortunately, there will always be programmers who leech of open-source code and pay a bitter price later. Log4j, for example, is a piece of open-source code that parses log information to system administrators. In late 2021, news broke that a vulnerability had allowed hackers to hijack the servers of Cloudflare, Minecraft, and Twitter, among many others. We don’t want this to happen of course. So go ahead and copy code, but do so ethically and open-source your code if you can.
Always owning your code is silly at best
Back in the old days, people used to argue that your code is like your child: you built it, so you’ll be responsible for anything it does until the day you die. Or some version of this. That’s B.S. at its best. Yes, you can’t hand off your code to a colleague and put your hands up in the air whenever they have a question about it. And questions will arise even with the best documentation. So be available when your coworkers use your code, especially in the first few weeks and months after you hand it off. That being said, of course you should hand off your code! Life gets in the way sometimes, your family needs more attention or you have two dozen other projects on your plate, and stressful deadlines lurking everywhere. And hey, programmers’ burnout is real. Plus, if a seasoned developer has amassed eight dozen different projects and needs to maintain them all, it’s going to be very hard to take another one or two projects onboard, however interesting they may be. That’s incredibly silly because it stunts future growth. And if there’s one thing that developers want, it’s learning more and growing. Also, not every code project is a free-time endeavor. People change jobs, you know? You can’t really ask a coder to maintain their old projects at Microsoft when they’ve been working at Facebook for the last two-and-a-half years now. Now it’s the team’s responsibility to keep the code in shape. Also, teams shouldn’t fall into the pitfall of assigning different pieces of code to different people. This seems cool in the short term, but quite quickly you’ll get silos, and that’s not good at all. Of course people will know the sections best that they’ve written themselves. But if you make the authors responsible for their code, no-one else will look at it unless they really have to. The authors miss out on important feedback and fresh ideas for their code. Ownership is important because it adds a sense of responsibility and an incentive to keep bugs and vulnerabilities far, far away. But it should always be a shared responsibility, where several people maintain a project.
Unit tests slow you down massively — the experts agree
Back in 2008, when StackOverflow was founded, there was no obvious way to build a Q&A site at a large scale. Today this type of project is a textbook task. But back then, before AWS, no-code web development, and graphic point-and-click database management… StackOverflow, above everything else, wanted to be a website that works for the user. So they decided to make performance their number-one priority and put testing somewhere in the lower end of the list. Yes, StackOverflow, home to the gurus of programming, didn’t test everything. They didn’t test very much at all in the beginning! These days, not only is testing mandatory, but there are even best practices for testing itself. Yup, you heard me right. This best practice breaks down to many more best practices, that’s just how important it is to some people. So what’s the deal? Don’t you want to make sure that your code works? Yes, but… Tests take time. You don’t always have time galore. First of all, tests take time to execute. You don’t want to spend 20 minutes executing a website’s tests to death when the user on the other end just wants to, say, read a blog post. Second, tests take time out of developers’ days. Every time a developer wants to add a new feature, they will have to add or custom-build the necessary tests and find the right place for their tests in the existing test suite. Over time, this just gets expensive. There are two ways around this: Either you have a full test suite but only test for the most important things when a user wants something. Or you only write the most necessary tests in the first place. This sounds very shaky, but you can make the architecture itself more robust so you don’t need so many tests. Need an example? StackOverflow is your friend, as usual.
The bottom line: Best practices get in the way of speed
I don’t want you to throw your whole rulebook out the window and code like a chaotic berserker. But if you can, please don’t follow the rulebook to the letter either. If you copy-paste a snippet from StackOverflow or any other site, you won’t be punished. As long as you understand that piece of code and are able to make the necessary adjustments anyway. Copy-paste an whole open-source project into your own proprietary project and you’re in legal trouble. Don’t keep your copy-pasted stuff up-to-date and you might get in trouble with hackers who exploit your vulnerabilities. Ownership, certainly single ownership, is bogus. Try to assign every project to multiple people. Learn to let go of your code projects and give them to other people. Free your mind and your calendar for new things! And don’t test your code to death. Test where things could go wrong, and where you suspect hackers could do harm. Test where it’s necessary, and let the architecture take care of the rest. I’m not suggesting you do a 180 to everything you did. Instead, try breaking every rule in ways that make sense for the task at hand. Besides, breaking the rules is fun — whether it’s having a forbidden cookie, hanging out with friends for too long, or coding in unconventional ways. You can build good things by following all the rules. You’ll build great things by following all the rules that make sense, and throwing all the rest away. This article was originally published on Medium. You can read it here.
