I once took Software-Defined Radio (SDR) as a hobby. Back then, one of the best SDR programs was open-source. That was great because I could study it to learn how it worked. After some time, its author learned that some people had included parts of his program in theirs, didn’t like that, and changed his program’s license to be more restrictive. Later, he saw others writing similar programs, thought they had copied his source code, got angry, and added even more restrictions. Finally, one day he took the program off the Internet, along with its website and any traces of its existence.
Many programmers identify strongly with the programs they write, sometimes so much so that they take any criticism or “misuse” of the program by others as a personal attack. In the worst cases, some programmers end up imposing so many restrictions on the program that it becomes useless; sometimes, they even withdraw it so nobody can use it, just like the dragons from Germanic myth, who hoarded gold and riches in a big heap and lay on top of it, not doing anything with all that wealth but not letting anyone else benefit from it either.
I shouldn’t have to say that it’s not good to have such a sense of personal ownership of the software one writes. If we can’t separate our work from our egos, we won’t be able to bear any critiques of it. I’m not talking about criticism like “this program is so terrible,” but critiques like “maybe the program would be faster if it used this other algorithm instead,” “it should use the same typeface as the rest of the operating system UI,” or “I’m asking it to add 2 and 2, and it says 5”. We can’t only live on praise and congratulations; we need critiques and suggestions to improve as programmers.
Therefore, if you thought I was talking about you in the previous paragraph, you should create some distance between you and your work. You should be able to look at it critically and appreciate which parts are good and bad and how to turn the bad parts into good.
Keeping this distance is an important skill, especially for people who work in a team, because the other team members will see all the code you write. Other people will modify it in ways you didn’t expect. They may even delete it! What will you do when someone sends you a push request that removes five thousand lines you wrote? I know what I do: I send a “good job” message with a thumbs-up emoji. Sometimes I even add the flamenco-dancing woman.
That’s even more important when we develop software professionally. In a company, people often change projects and teams, or projects get transferred, and you can’t take your code with you: you must leave it with the team that will work on it. I know of people who, even weeks after changing projects, still snoop on the version control system to keep tabs on “their” code. I hope you aren’t one of those.
I understand people with an emotional investment in the programs they write. It is common among people with creative jobs: artists, artisans, writers, designers, or architects. It is very satisfying when, after spending many hours thinking of how to do something, it finally takes shape thanks to your effort. But, just like artists and artisans must let their creations loose in the world, programmers must also learn to do the same with their programs.
The illustration for this Coding Sheet has been adapted from “Siegfried and the Twilight of the Gods.”