What Does Engineering Mean These Days?
I started my career as a JavaScript developer.
JavaScript was — and still is — one of the most popular programming languages in the world. It was used by many of the world’s biggest companies, promoted by famous developers, and surrounded by an enormous ecosystem. Naturally, I assumed that this popularity reflected technical quality.
I invested years in learning it.
Then I started getting punched in the face by its problems.
That pushed me to explore other languages: Rust, OCaml, Swift, and others. They showed me that many things I had accepted as unavoidable facts of software development were merely consequences of the tools I had learned first.
Entire categories of runtime errors could be prevented. Invariants could be expressed in types rather than comments and conventions. A type system could make many invalid states impossible to represent. All these great things I had not known were possible.
It became evident that JS was far from the pinnacle of programming language design, to say the least. It was a language with layers of tooling piled on top to compensate for its broken foundations. Worse, it had trained me into habits that I later had to unlearn. I then spent several more years fixing it by learning and working with languages designed around stronger ideas.
This is not really a post about JavaScript, though. It is about what I think engineering means.
Recently, I found myself analyzing what shaped me as a person. My favorite childhood book was Jules Verne’s ”The Mysterious Island”, which I have reread too many times throughout my life. I eventually realized that Cyrus Smith, one of its main characters, had become something of a role model for me. His dedication, breadth of knowledge, willingness to share it, and ability to turn understanding into practical solutions shaped my earliest image of what a real engineer should be.
Subconsciously, these core principles influenced my vision of software engineering: evaluating and promoting technology based on its actual engineering merits and real-world application, not merely on its popularity, profitability, job market, or proximity to venture capital.
Business constraints are real. Sometimes a particular technology is the most practical choice. Browsers run JavaScript. A company may already have a large TypeScript codebase. Rewriting everything would be irresponsible.
But there is a huge difference between saying:
We have to use this technology today, even though its foundations are broken. We should remain aware of its limitations, communicate them honestly, and continue pursuing something better.
And saying:
JavaScript is a great choice! It is what we use at our company, and its enormous ecosystem makes us incredibly productive. I teach the same approach in my course, and our platform makes deploying it effortless.
While being silent about fundamental problems and lesser-known but better-designed alternatives.
The first is engineering under constraints. The second is... I don’t know, call it however you like.
Silicon Valley has made the two increasingly difficult to distinguish. Technical advocacy is often attached to a career ladder, a startup, a consultancy, or a personal brand. Perhaps some/most of the people involved sincerely believe what they say — either because they never really went outside their ecosystem or for whatever other reasons. But the incentives are also obvious. People benefit from praising a technology and encouraging others to use it. They rarely benefit from pointing out its flaws — especially when their careers or businesses depend on it.
As a beginner, I did not understand that. I mistook market success for engineering consensus. I trusted people I thought were evaluating technology as engineers, when many of them were — consciously or otherwise — participating in a hype-and-money machine.
I do not appreciate it.
I want to make it perfectly clear that I don’t have anything against people who sincerely believe in JS/TS. I respect their choice.
This post had been sitting in drafts for quite a while, and Andrew Kelley’s recent publication prompted me to finally pack and ship it. While I think Andrew expressed his case in a needlessly personal and hostile way, I recognize where some of that hostility comes from. I do think sincerely expressed opinions are healthy and balance things out when they are free of personal attacks and the like. The industry needs more of those.
To close, I want to emphasize that, to me, engineering does not mean always choosing the most academically elegant language or pursuing perfection at any cost. It means being honest about trade-offs and remaining loyal to better engineering.