I’m not convinced that most developers got into it because of ‘a thirst for creative outlet, technical curiosity, and a desire for mastery’. I would have guessed that a great many are there because they were looking at Faculties, saw Computer Science and said ‘oh, I heard that pays well’. Certainly a lot of devs only program from 9 to 5, and certainly a lot of devs write bad code.
Still, I think there is something about the corporate environment that tends to sap our creative problem-solving ability. In a small company there’s a pressure to ship something ASAP, and if the management is nontechnical they’ll probably make this worse by hiring inexperienced developers. The code is a mess from day one, and as the money rolls in, the pressure builds to add more features ASAP. At some point, they have to hire only senior developers because juniors are simply not able to fathom the codebase.
“Refactoring?” says the boss. “Use words I can understand.”
“Well, the code is… horrible. It’s a complete disaster area, worse than anything I’ve ever seen before. At this point we almost need to rewrite from scratch. It wouldn’t even take that long…”
“We don’t have the budget for that. Our clients aren’t asking for that. Even the other developers aren’t asking for that. It’s time you got used to how things are done around here.”
This is based on one experience I had (in which I was fired), but I hypothesize that less severe versions of this play out in most companies. There is a drive to write bad code partly because almost everyone spends part of their career as a novice or intermediate developer, and partly because there is a drive to reach market quickly, which then perhaps causes developers to give up on mastery of their craft because it is not needed or rewarded. Code reviews? Takes too much time. Understanding the problem? Takes too much time. Writing code to be understood by others? Not my problem. Writing appropriately general abstractions? We don’t need generality, we only need to serve subset X of customers in market Y. Rare is the person who is promoted for doing a great job really slowly.
And even in a company where good work is welcomed, there are still compelling reasons to give in to the pull of the past: our existing infrastructure lacks tests and we can’t afford to break it; thousands of lines of code assume the old (bad) architecture so it can’t be changed; customers are used to the weird way it works, and we don’t want to have to explain a new UI, even if it’s easier and more intuitive.
Of course, if we had better tools, maybe it wouldn’t take so long to do a good job.
But who is paid to make better tools? Oh right — most tools are open source. Almost no one is paid to make better tools! There is money for “science”, and even “computer science”, but in science the job is only to discover something. You waste a ton of time applying for grants, you get a grant, you maybe discover something or not, you write a paper, and you shop around for journals willing to publish it. The End. It’s not a great process, but at least it’s a living.
But for people like me who write tools as a hobby, there is no money. I make tools because I believe they should exist. But it’s relegated to evenings and weekends, always a lower priority than working out bugs in the Company’s Product. And it’s solitary, no team with whom to discuss ideas or socialize with. And there’s no time to polish, so the tools we make have rough edges and lousy websites.
When on occasion a corporation decides to make a tool, it’s For Them. Google has Kotlin for Android, Apple has Swift for iOS, Microsoft has C# for Windows (C# has become really good for cross-platform work, but it could be argued this is mainly because MS now makes so much money from Linux VMs). Some of the most innovative languages — say, Nim, D, ClojureScript, Unison, Idris — have no big corporate backing and little or no budget, and so it’s kind of natural that they are rarely used in real-world projects. Other open-source tools, such as tools to juggle your C# code or your Linux virtual machines, or libraries of functionality, have an easier time being adopted due to their compatibility with the more popular tools, but again, I really think the lack of money contributes to a limited degree of quality.
