JavaScript Fatigue: Realities of our industry (2017)(lucasfcosta.com)
lucasfcosta.com
JavaScript Fatigue: Realities of our industry (2017)
https://lucasfcosta.com/2017/07/17/The-Ultimate-Guide-to-JavaScript-Fatigue.html
75 comments
(2017), please.
Update: previous discussion, https://news.ycombinator.com/item?id=14861886
Update: previous discussion, https://news.ycombinator.com/item?id=14861886
> Technology is not a goal. Nobody cares about which programming language you are using, nobody cares about which frameworks your team has chosen, nobody cares about how elegant your data structures are and nobody cares about how good is your code.
100% that!
> JS Fatigue happens when people use tools they don't need to solve problems they don't have.
Many JavaScript developers are scared (by scared I am paralyzed in the face of death catatonic scared to the most possible irrational extreme) to write original code when often times original code takes less time and is a better fit to the immediate problem. This is called Invented Here Syndrome and is internally coddled when developers are appeased by writing configurations opposed to logic.
https://en.wikipedia.org/wiki/Invented_here
It is so bad that at my current employer somebody recommended I use a different editor to write code, because it had this kiss ass extension called Atom Beautify. They were pretty forceful in their recommendation. I am a collaborator on that project and wrote one of its beautifiers. People are scared to death to write software themselves or use any software from people they know, but so long as they don't I wrote any of it its great (to them).
> Even though the ECMA spec is becoming more and more solid these days, we still need Babel.
I have always believed this is one of those not real problems the paper talks about immediately prior. Writing cross browser JS is like writing CSS. Everybody bitches about it but once you've nailed it you got it with ease forever.
> My first advice for anyone suffering from JS Fatigue...
Learn the standards. Code to the standards first. Then optimize your workflow to become more efficient. This is the very essence solving for premature optimization.
100% that!
> JS Fatigue happens when people use tools they don't need to solve problems they don't have.
Many JavaScript developers are scared (by scared I am paralyzed in the face of death catatonic scared to the most possible irrational extreme) to write original code when often times original code takes less time and is a better fit to the immediate problem. This is called Invented Here Syndrome and is internally coddled when developers are appeased by writing configurations opposed to logic.
https://en.wikipedia.org/wiki/Invented_here
It is so bad that at my current employer somebody recommended I use a different editor to write code, because it had this kiss ass extension called Atom Beautify. They were pretty forceful in their recommendation. I am a collaborator on that project and wrote one of its beautifiers. People are scared to death to write software themselves or use any software from people they know, but so long as they don't I wrote any of it its great (to them).
> Even though the ECMA spec is becoming more and more solid these days, we still need Babel.
I have always believed this is one of those not real problems the paper talks about immediately prior. Writing cross browser JS is like writing CSS. Everybody bitches about it but once you've nailed it you got it with ease forever.
> My first advice for anyone suffering from JS Fatigue...
Learn the standards. Code to the standards first. Then optimize your workflow to become more efficient. This is the very essence solving for premature optimization.
It's also the same logic you can observe everywhere in business : pushing down responsabilities, outsource resources, leave a paper trail etc.
> Many JavaScript developers are scared (by scared I am paralyzed in the face of death catatonic scared to the most possible irrational extreme) to write original code when often times original code takes less time and is a better fit to the immediate problem. This is called Invented Here Syndrome and is internally coddled when developers are appeased by writing configurations opposed to logic.
I think this is true of a much larger category of developers than JS developers (though one could argue that defining yourself by a specific language is indicative of belonging to this category), that is developers who can't do more than plumbing, i.e. developers who can't actually solve problems properly on their own.
The flighty attraction to the new shiny is somewhat driven by a lack of understanding of how either the new or the old shiny actually work. If you understand the job you're setting out to do you're in a much better position to decide upon tools, frameworks, what to do in house, etc. If you don't you're stuck gluing black boxes together, because any actual code you write will be far worse.
JS being an "accessible" language and a mandatory part of practically all software companies with a front facing website makes this the most apparent in both the constant flow of new tools and libraries and the view that the new tools and libraries must be adopted. But any novice developer can fall prey to this behavior regardless of their choice of language, JS just makes it easier.
I think this is true of a much larger category of developers than JS developers (though one could argue that defining yourself by a specific language is indicative of belonging to this category), that is developers who can't do more than plumbing, i.e. developers who can't actually solve problems properly on their own.
The flighty attraction to the new shiny is somewhat driven by a lack of understanding of how either the new or the old shiny actually work. If you understand the job you're setting out to do you're in a much better position to decide upon tools, frameworks, what to do in house, etc. If you don't you're stuck gluing black boxes together, because any actual code you write will be far worse.
JS being an "accessible" language and a mandatory part of practically all software companies with a front facing website makes this the most apparent in both the constant flow of new tools and libraries and the view that the new tools and libraries must be adopted. But any novice developer can fall prey to this behavior regardless of their choice of language, JS just makes it easier.
It depends.
Lets step away from the front end for a second, on the server side you use a reasonble MVC framework.
* You get to stop worrying about how to structure your code.
* The guidence should use Depency Injection, allowing you to easily Unit Test.
* You get a templating language that helps with XSS.
* You get a validation language that helps with input.
* You get session handling that projects you against jacking, etc.
* You get an ORM that makes SQL easy and projects you against SQL Injection.
* You get Security Headers, etc.
Typically, the junior developer needs the above help, the mid level developer thinks they can do it all himself, and the senior doesn't think it's worth reinveting the wheel.
JavaScript has arguably been the wild west, and if you're creating a SPA, a lot of the above is no longer your consideration, but it alos doesn't neccessairly mean we should all write everything from scratch.
Now there are counter arguments where you can DIY your own framework using community modules, and this is how the Golang community seems to work, but this seems better when you have something like PHPs PSRs ala https://www.php-fig.org/ defining how this should fit together.
Lets step away from the front end for a second, on the server side you use a reasonble MVC framework.
* You get to stop worrying about how to structure your code.
* The guidence should use Depency Injection, allowing you to easily Unit Test.
* You get a templating language that helps with XSS.
* You get a validation language that helps with input.
* You get session handling that projects you against jacking, etc.
* You get an ORM that makes SQL easy and projects you against SQL Injection.
* You get Security Headers, etc.
Typically, the junior developer needs the above help, the mid level developer thinks they can do it all himself, and the senior doesn't think it's worth reinveting the wheel.
JavaScript has arguably been the wild west, and if you're creating a SPA, a lot of the above is no longer your consideration, but it alos doesn't neccessairly mean we should all write everything from scratch.
Now there are counter arguments where you can DIY your own framework using community modules, and this is how the Golang community seems to work, but this seems better when you have something like PHPs PSRs ala https://www.php-fig.org/ defining how this should fit together.
I'm not arguing that one should write things from scratch. I think I may have poorly articulated my position, but that you and I actually share the same opinion here.
I don't think you should reinvent the wheel unless for some reason all available wheels are insufficient for your case. But knowing this requires that you have some understanding of how wheels work, how to compare them, and how to hew your own out of raw materials if the need arises.
I would say JS is partially a wild west due to title inflation and the relative numbers of lesser experienced developers in the space relative to, say, your pool of Erlang engineers.
I don't think you should reinvent the wheel unless for some reason all available wheels are insufficient for your case. But knowing this requires that you have some understanding of how wheels work, how to compare them, and how to hew your own out of raw materials if the need arises.
I would say JS is partially a wild west due to title inflation and the relative numbers of lesser experienced developers in the space relative to, say, your pool of Erlang engineers.
Yup. And it’s hard to even evaluate these things sometimes (and I have 20 years experience to guide me now).
We’re doing some frontend stuff at the moment and we needed a nice way to wire up keyboard shortcuts. After a week of false starts with other people’s libraries we wrote our own in a day that a) works how we need and b) is so small that anyone can understand it.
We’re doing some frontend stuff at the moment and we needed a nice way to wire up keyboard shortcuts. After a week of false starts with other people’s libraries we wrote our own in a day that a) works how we need and b) is so small that anyone can understand it.
Yeah, fair enough. I agree, there is an over reliance on libs that often don't do much. :)
> I think this is true of a much larger category of developers than JS developers (though one could argue that defining yourself by a specific language is indicative of belonging to this category), that is developers who can't do more than plumbing, i.e. developers who can't actually solve problems properly on their own.
> The flighty attraction to the new shiny is somewhat driven by a lack of understanding of how either the new or the old shiny actually work. If you understand the job you're setting out to do you're in a much better position to decide upon tools, frameworks, what to do in house, etc.
I agree with this. Many developers never think to ask clients "why do you want to do this?" also. Sticking boxes together, cleaning up code and coming up with clever coding tricks is fun and distracting; it's easy to lose sight of or never even learn of what high-level problem you're meant to be solving.
> The flighty attraction to the new shiny is somewhat driven by a lack of understanding of how either the new or the old shiny actually work. If you understand the job you're setting out to do you're in a much better position to decide upon tools, frameworks, what to do in house, etc.
I agree with this. Many developers never think to ask clients "why do you want to do this?" also. Sticking boxes together, cleaning up code and coming up with clever coding tricks is fun and distracting; it's easy to lose sight of or never even learn of what high-level problem you're meant to be solving.
>The flighty attraction to the new shiny is somewhat driven by a lack of understanding of how either the new or the old shiny actually work. If you understand the job you're setting out to do you're in a much better position to decide upon tools, frameworks, what to do in house, etc. If you don't you're stuck gluing black boxes together, because any actual code you write will be far worse.
Writing my own sort routine? Pointless but pretty harmless.
Writing my own docx parser? Sure, that will be one mythical man century of work.
Sometimes we are using black boxes because we have created so much accidental complexity that we can't do better than "this works, we don't know why and we dare not change it". The browsers js must target are some of the biggest black boxes even though they are open(ish) source.
Writing my own sort routine? Pointless but pretty harmless.
Writing my own docx parser? Sure, that will be one mythical man century of work.
Sometimes we are using black boxes because we have created so much accidental complexity that we can't do better than "this works, we don't know why and we dare not change it". The browsers js must target are some of the biggest black boxes even though they are open(ish) source.
> Writing my own docx parser? Sure, that will be one mythical man century of work.
I'm not sure that's actually a great example. I had a project a while ago where I needed to extract certain information from Word and Excel files, and it was less work to just write my own parser (it's just XML in a ZIP file) that got exactly the information I needed than to figure out all the complexity of using a full-blown docx/xlsx parser. It ended up being 100 lines of Haskell, and half of that was imports.
https://gist.githubusercontent.com/duairc/db3e99a7808668e84e...
Edit: The docx part of it is only 10 lines of code.
I'm not sure that's actually a great example. I had a project a while ago where I needed to extract certain information from Word and Excel files, and it was less work to just write my own parser (it's just XML in a ZIP file) that got exactly the information I needed than to figure out all the complexity of using a full-blown docx/xlsx parser. It ended up being 100 lines of Haskell, and half of that was imports.
https://gist.githubusercontent.com/duairc/db3e99a7808668e84e...
Edit: The docx part of it is only 10 lines of code.
There's a slight difference between extracting a few tags from an xml file and building an manipulable ast of it.
There is, but if your problem requires just the former, it's faster and better to build it yourself than to pull in a heavy third-party dependency (of which you'll use 1% anyway).
Yes but if it requires the latter you end up with an uncontrollable mess of regular expressions which can accidentally parse the language needed to summon the great elder ones.
The media wiki parser is a perfect example of what can go wrong with simple solutions.
The media wiki parser is a perfect example of what can go wrong with simple solutions.
That's a pretty neat trick.
> sort routine? docx parser?
You immediately went for two examples that are precisely not the kind of thing the author is talking about. Consider leftpad.
You immediately went for two examples that are precisely not the kind of thing the author is talking about. Consider leftpad.
There's absolutely nothing wrong with using black boxes, and I'm not arguing that it should be totally avoided. I'm arguing that a lack of understanding of how to solve your problem leads to only gluing black boxes together as you lack the understanding with which to make more nuanced decisions, and to solve any part of the problems you have yourself.
It's also not necessarily required that you understand all of what you're doing down to the logic gates, but if you don't (to crib your example) understand some of what docx parsing may entail, or can't actually write any sort function (nor understand how to compare them), you're stuck with black boxes at even the highest levels, and then you're very likely to be exposed to the article's defined fatigue as you continually jump to whatever looks shiniest, lacking the understanding with which to properly compare your options.
It's also not necessarily required that you understand all of what you're doing down to the logic gates, but if you don't (to crib your example) understand some of what docx parsing may entail, or can't actually write any sort function (nor understand how to compare them), you're stuck with black boxes at even the highest levels, and then you're very likely to be exposed to the article's defined fatigue as you continually jump to whatever looks shiniest, lacking the understanding with which to properly compare your options.
> nobody cares about how good is your code
the person who has to maintain it?
the person who has to maintain it?
When you walk into a restaurant, do you notice if they have an efficiently laid-out kitchen with mise-en-place, good relationships with their suppliers, or a refrigerator at the proper temperature? No.
But you do notice when you food is slow to arrive, the food doesn't taste fresh, or the chicken gives you food poisoning.
——
You also probably notice if they are using roof tiles as plates, but that doesn’t make them good cutting boards in the kitchen.
——
You also probably notice if they are using roof tiles as plates, but that doesn’t make them good cutting boards in the kitchen.
Yes. I notice those things.
I notice if they have an A or B or C rating, which is a reflection of some of those. I notice if they are in business, which after 5-10 years, is a reflection of some of those. I notice if the employees seem happy or frazzled which is a reflection of some of those.
The same goes for software projects. It's not always clear to me what the code quality is beneath the products I use, but the products I use for the long-haul almost certainly either A.) have reasonably high quality code or B.) are reasonably complete, because they are well maintained and don't sink beneath the weight of technical debt, and they persist over the course of the years.
I notice if they have an A or B or C rating, which is a reflection of some of those. I notice if they are in business, which after 5-10 years, is a reflection of some of those. I notice if the employees seem happy or frazzled which is a reflection of some of those.
The same goes for software projects. It's not always clear to me what the code quality is beneath the products I use, but the products I use for the long-haul almost certainly either A.) have reasonably high quality code or B.) are reasonably complete, because they are well maintained and don't sink beneath the weight of technical debt, and they persist over the course of the years.
You can also rephrase that as a business concern. Instead of how ugly the code is or how challenging it is the more important factor is how long does it take to accomplish a given change.
The challenge there is if you have isolated yourself to a happy path you have no idea what the edge cases are, what the regulatory concerns are, or what prior business concerns have already been addressed. You really have no idea how long the task will take to complete or the scope of actual work. It is a big risk to leave your framework dream world and embrace reality.
By living in reality I know how to account for those various concerns. I can provide a more accurate estimate of effort and still get it done 8-12x faster. You don't get better at anything by closing off reality and hiding from failure.
The problem with using a bunch of unnecessary abstractions and tools is that you have to choose between two really horrid scenarios. Do you give up on speed of delivery and product quality to work within the tools in place? Or, do you account for all the business concerns and deliver quickly by creating a one-off and possibly fighting those existing tools to do it?
The best way to know what to add to a project (dependencies) are those things you known you will deliberately never maintain and that require a one time configuration. For example I use a linter to check my code. It is a dependency that I never modify, I never reconfigure, I never look into its code, and I almost never update. If I were forced to peer into the code and read all about how it works and really get intimate with it I might as well just write it myself, because you will be maintaining it just the same anyways.
The challenge there is if you have isolated yourself to a happy path you have no idea what the edge cases are, what the regulatory concerns are, or what prior business concerns have already been addressed. You really have no idea how long the task will take to complete or the scope of actual work. It is a big risk to leave your framework dream world and embrace reality.
By living in reality I know how to account for those various concerns. I can provide a more accurate estimate of effort and still get it done 8-12x faster. You don't get better at anything by closing off reality and hiding from failure.
The problem with using a bunch of unnecessary abstractions and tools is that you have to choose between two really horrid scenarios. Do you give up on speed of delivery and product quality to work within the tools in place? Or, do you account for all the business concerns and deliver quickly by creating a one-off and possibly fighting those existing tools to do it?
The best way to know what to add to a project (dependencies) are those things you known you will deliberately never maintain and that require a one time configuration. For example I use a linter to check my code. It is a dependency that I never modify, I never reconfigure, I never look into its code, and I almost never update. If I were forced to peer into the code and read all about how it works and really get intimate with it I might as well just write it myself, because you will be maintaining it just the same anyways.
Or the business owner who is frustrated that their product still lists Czechoslovakia as a country.
(Yes, this is true of ADP)
(Yes, this is true of ADP)
Yeah, somebody has to work super hard, to make somebody elses job super easy. Write it yourself, or maybe you cant, and blaming someone elses code is a distraction to take the attention away from yourself.
It is a poor carpenter who blames his tools. Why? Because a skilled carpenter has money to buy the best tools.
Tools matter.
Developer experience matters. Cognitive cost matters when tools are used by non-infinite brains. If you don’t believe that, then build a product with a confusing UI and try selling it.
New != good though.
Tools matter.
Developer experience matters. Cognitive cost matters when tools are used by non-infinite brains. If you don’t believe that, then build a product with a confusing UI and try selling it.
New != good though.
A skilled carpenter has the tools that are necessary for the job, their price doesn’t matter.
In a couple of industries I have worked in there is a tier of expensive tools that are basically ways of extracting free money from professionals (when someone else is paying) and rich amateurs who want to feel superior to their friends
In a couple of industries I have worked in there is a tier of expensive tools that are basically ways of extracting free money from professionals (when someone else is paying) and rich amateurs who want to feel superior to their friends
> A skilled carpenter has the tools that are necessary for the job, their price doesn’t matter
Very true. A skilled carpenter is discerning about his tools and know where it matters to spend more money.
Very true. A skilled carpenter is discerning about his tools and know where it matters to spend more money.
It's rare that new ever equals good, even the best stuff takes time to mature into good.
It starts with interesting and then moves on to good later I think.
It starts with interesting and then moves on to good later I think.
Ok. The guy writes about js fatigue. He appears to be chai.js maintainer. Ok, let's check it out. Oh, this is a library that lets you use three different styles to say the same thing
chai.should();
foo.should.be.a('string');
var expect = chai.expect;
expect(foo).to.be.a('string');
var assert = chai.assert;
assert.typeOf(foo, 'string');
Lol, are these assert libs mimicking badly written English still a thing? I thought we grew out of this a few years ago.
[deleted]
[deleted]
[deleted]
[deleted]
Really? All it takes for language fatigue is syntax? I’d hate to hear what you think of English.
Agreed. I'm pretty sure is one reason for the fatigue because some people just believe changing the word without changing semantic makes differences.
For Chai, I also found RSpec/Jasmine/Chai styled testing is not much different from Minitest/Xunit/Tape test. Meanwhile, there was a hype of advertising so-called BDD interface several years ago.
But there are still a lot of people testing detailed implementation instead of business value with RSpec styled testing framework.
There are several things are pretty similar, I'm sure there's more:
* Pretending BDD with RSpec styled testing, instead of testing business invariant.
* Pretending continuous integration with Jenkins. Instead of incremental value delivery in high frequency.
* Pretending agile software development with Jira and abused task-splitting. Instead of preserving e2e business value in one task.
For Chai, I also found RSpec/Jasmine/Chai styled testing is not much different from Minitest/Xunit/Tape test. Meanwhile, there was a hype of advertising so-called BDD interface several years ago.
But there are still a lot of people testing detailed implementation instead of business value with RSpec styled testing framework.
There are several things are pretty similar, I'm sure there's more:
* Pretending BDD with RSpec styled testing, instead of testing business invariant.
* Pretending continuous integration with Jenkins. Instead of incremental value delivery in high frequency.
* Pretending agile software development with Jira and abused task-splitting. Instead of preserving e2e business value in one task.
This is so much out of scope for the article - it has literally nothing to do with it. Your critique is about Chai choosing an API design you do not agree with.
Your critique isn't focused on JS fatigue but a single lib. JS fatigue is about having to choose between Chai, Mocha, Karma (dead nowadays?), Tape, Istanbul, testdouble, Qunit etc. And also: knowing what does what.
Your critique isn't focused on JS fatigue but a single lib. JS fatigue is about having to choose between Chai, Mocha, Karma (dead nowadays?), Tape, Istanbul, testdouble, Qunit etc. And also: knowing what does what.
> Your critique is about Chai choosing an API design you do not agree with.
I am not criticising the design choice but rather the inability to make a choice.
> JS fatigue is about having to choose between Chai, Mocha, Karma...
And once you made that choice you still have to choose between three different api styles, apparently.
I am not criticising the design choice but rather the inability to make a choice.
> JS fatigue is about having to choose between Chai, Mocha, Karma...
And once you made that choice you still have to choose between three different api styles, apparently.
You're still mixing apples and pears. A single libs API is not JS fatigue. One could argue that it's actually the opposite; supporting three different APIs might make the transition from another lib easier.
> "The more you decrease cost and increase revenue, the more valuable you are..."
I've also heard it said: How much you're worth is a function of the size of the problems you solve.
Technical chops =/= real world biz problem solving.
I've also heard it said: How much you're worth is a function of the size of the problems you solve.
Technical chops =/= real world biz problem solving.
I agree with this, but there is a nuance. Given the same problem, someone solving it with Excel typically gets a smaller employee reward than someone solving it with some complex sounding stack.
> Complaining about JS Fatigue is just like complaining about the fact that humanity has created too many tools to solve the problems we have, from email to airplanes and spaceships.
No, complaining about JS Fatigue is just like complaining that we should actually try to launch a spaceship instead of tearing the last one we started into pieces just so we can put some shiny new thing in the middle of it, and that we should try to actually finish an airplane and send an email while we're at ooh React Hooks! Hang on, I really need to start my post again and do it perfect this time now that it's possible. Bear with me a sec, trust me I'll be finished soon, hopefully you still have enough money to pay me.
No, complaining about JS Fatigue is just like complaining that we should actually try to launch a spaceship instead of tearing the last one we started into pieces just so we can put some shiny new thing in the middle of it, and that we should try to actually finish an airplane and send an email while we're at ooh React Hooks! Hang on, I really need to start my post again and do it perfect this time now that it's possible. Bear with me a sec, trust me I'll be finished soon, hopefully you still have enough money to pay me.
Your comment makes it sound like we're all one amorphous developer building one giant email, unable to airplane it because we're constantly switching to whatever hits the top of HN, when the reality is that you just saw a random HN article and made absurd assumptions about a huge number of individual developers who are emailing airplanes and airplaning emails daily and aren't fatigued by the tiresome burden of having 1 or 2 out of 30 articles on HN being something something javascript, even during the dark times known as the week of react hooks.
> Software solves business problems
Not entirely correct. Software solves problems in general, they don't have to be business problems.
> Software does not exist to please us as programmers
Nope. Examples: Pretty much any good development tool. There is a lot of software out there that exists to please programmers and to make their lives easy.
> Nobody cares about which programming language you are using, nobody cares about which frameworks your team has chosen...
Not really. I have come across managers and even investors who care about what was being used. Why? They need to ensure that it won't be too expensive to hire more people to work on the software when there is a need.
Not entirely correct. Software solves problems in general, they don't have to be business problems.
> Software does not exist to please us as programmers
Nope. Examples: Pretty much any good development tool. There is a lot of software out there that exists to please programmers and to make their lives easy.
> Nobody cares about which programming language you are using, nobody cares about which frameworks your team has chosen...
Not really. I have come across managers and even investors who care about what was being used. Why? They need to ensure that it won't be too expensive to hire more people to work on the software when there is a need.
Companies who have managers, who think that all the problems of the business can only be solved by IT, have no customers, just a dream that maybe someday they will.
I disagree with "Try to understand bottom-up". The whole point of abstraction is to use it without understanding it. Trying to understand bottom-up is actively harmful. At most, attempt one or two levels below you.
For god's sake, don't go study quantum mechanics (or semiconductors, or CPU architecture) when you are writing JavaScript.
For god's sake, don't go study quantum mechanics (or semiconductors, or CPU architecture) when you are writing JavaScript.
> The whole point of abstraction is to use it without understanding it.
No. No, that not "the whole point" of abstraction. To benefit from reasoning and describing problems on a suitable level of abstraction you certainly do need to understand your building blocks.
> don't go study quantum mechanics [...] when you are writing JavaScript.
No, that would be as just silly as to wait for a doctate in thermodynamics before cooking an egg, but please have a decent understanding of HTML and HTTP before you write javascript web apps professionally.
No. No, that not "the whole point" of abstraction. To benefit from reasoning and describing problems on a suitable level of abstraction you certainly do need to understand your building blocks.
> don't go study quantum mechanics [...] when you are writing JavaScript.
No, that would be as just silly as to wait for a doctate in thermodynamics before cooking an egg, but please have a decent understanding of HTML and HTTP before you write javascript web apps professionally.
Re: abstraction. You need to understand interface, but "not understanding implementation" IS the point.
You gave an example of HTTP, so let's discuss that. Understanding of HTTP concepts is useful for web programming. Details of HTTP implementation mostly aren't. Studying HTTP/2's header compression or HTTP/3's forward error correction IS NOT necessary.
You gave an example of HTTP, so let's discuss that. Understanding of HTTP concepts is useful for web programming. Details of HTTP implementation mostly aren't. Studying HTTP/2's header compression or HTTP/3's forward error correction IS NOT necessary.
The point of abstraction is that you can use it without understanding what's behind it, not that you should. There are diminishing returns after couple of levels, but abstractions in general don't come from thin air, and it's a massively easier to use an abstraction if you have some understanding of a level or two below it. It gets even more important when an abstraction is buggy, leaky, incomplete, or imprecise.
So yeah, quantum mechanics may not help you much when writing JavaScript, but understanding of lower-level programming, of how memory and networks work, just might.
So yeah, quantum mechanics may not help you much when writing JavaScript, but understanding of lower-level programming, of how memory and networks work, just might.
That “just enough to get by” mentality is dangerous. When I see somebody who has put together a monstrosity that they can’t get under control it’s always somebody who didn’t really understand what was going on “under the hood”.
I can read anybodies plain old javascript code, and figure it out. But if the author uses some kind of fancy vendor lock in framework, that had a life span in the community of six months, never to be seen again, well that is a pain in-the A to reverse engineer, i dont even bother reading the code anymore, i packet sniff, and see if the network has any value, and guess what, no customers, and all that effort. those who spout the spec, are indicative to me, as never having seen a customer in there life.
Saying that though, you should check out the future of web development,
https://github.com/Sean-Bradley/Seans-TypeScript-ReactJS-Red...
Typescript will win.
All you react/redux gods will be automated out of a purpose, what is the problem you are fixing again? Oh thunk, thunk will fix it, yeah, yeah, distractions, i get it, the problem. Solved, keep up the good work. Were fixing the problems of internet and were not finished yet,
[deleted]
While there are some good ideas brought up in this post, in my opinion, author misses the main point about JS and, JS fatigue, which leads to the vague advice like "solve problems".
The point is, as Fred Brooks put it, in software there are two kinds of complexity – essential and accidental complexity. First one – is exactly those "problems" author talks about – it's the complexity of the real-world problems we try to solve with software. Second one – accidental complexity – is the complexity we bring into the process by using our tools, frameworks and languages. And JS ecosystem is largely revolves around accidental complexity.
Let's be clear – JS is a historical accident that, by unpredicted twist of events, became the only language in the unexpectedly dominant platform – web. We, developers, did not have choice – if we need to reach users/customers via web – we were forced to use JS. Language, poorly designed under the pressure in 2 weeks, coupled with incredibly sloppy and constantly changing technologies like DOM and CSS, accidentally became the only way your business can reach users.
Of course, people started to solve those problems of the JS/DOM/CSS poor design, by creating more tools, more frameworks, more solutions – bringing more accidental complexity, which required new hacks, tools and solutions to solve that. The process then repeats itself, as web world was changing and growing.
Accidental complexity in JS world is astronomical. But the worst thing is that newcomers, unable to see perils of that through the prism of experience, accept it as a normal state of things. They embrace this madness and happy to write more hacks and tools, for solving problems, created by other tools.
The whole JS ecosystem thus is a huge mess of hacks on top of hacks. Most of developers' time is spent in not "solving the problems", but dealing with tooling and accidental complexity.
And that's exactly what software engineering should fight with. But it's really hard and challenging task.
As Edsger Wybe Dijkstra said in 1984: “Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.”
So, I think JS fatigue is exactly what happens when you find yourself inundated in accidental complexity and ugly designed tools and frameworks.
The point is, as Fred Brooks put it, in software there are two kinds of complexity – essential and accidental complexity. First one – is exactly those "problems" author talks about – it's the complexity of the real-world problems we try to solve with software. Second one – accidental complexity – is the complexity we bring into the process by using our tools, frameworks and languages. And JS ecosystem is largely revolves around accidental complexity.
Let's be clear – JS is a historical accident that, by unpredicted twist of events, became the only language in the unexpectedly dominant platform – web. We, developers, did not have choice – if we need to reach users/customers via web – we were forced to use JS. Language, poorly designed under the pressure in 2 weeks, coupled with incredibly sloppy and constantly changing technologies like DOM and CSS, accidentally became the only way your business can reach users.
Of course, people started to solve those problems of the JS/DOM/CSS poor design, by creating more tools, more frameworks, more solutions – bringing more accidental complexity, which required new hacks, tools and solutions to solve that. The process then repeats itself, as web world was changing and growing.
Accidental complexity in JS world is astronomical. But the worst thing is that newcomers, unable to see perils of that through the prism of experience, accept it as a normal state of things. They embrace this madness and happy to write more hacks and tools, for solving problems, created by other tools.
The whole JS ecosystem thus is a huge mess of hacks on top of hacks. Most of developers' time is spent in not "solving the problems", but dealing with tooling and accidental complexity.
And that's exactly what software engineering should fight with. But it's really hard and challenging task.
As Edsger Wybe Dijkstra said in 1984: “Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.”
So, I think JS fatigue is exactly what happens when you find yourself inundated in accidental complexity and ugly designed tools and frameworks.
It doesn’t help that these tools are very terribly documented, and changing all the time either. I learned AngularJS a few years ago. I didn’t learn it because I had a specific problem I was trying to solve and I needed a “framework” to solve it - I learned it because the team I was on was using it, and I had to learn it to be productive. And they didn’t use it because they had a specific problem to solve and needed a “framework” to solve it - they used it because it was trendy and had some press around it. So nobody actually understood what it was. Not just in the “how do I do _x_ in Angular” sense but in the “why does Angular even exist and how is using Angular better than using nothing at all?” sense. I couldn’t admit that it didn’t make a lot of sense to me, because they were all pretending that they understood it (which I only verified later, after I actually did understand it, that they didn’t), but I could read the documentation. It was awful. There were a couple of online tutorials that stepped through some incredibly trivial problems that could be much more easily solved with plain-old Javascript. I picked up a couple of books that weren’t much better (and lost weeks reading them). I finally ended up mostly just reading through the codebase to make sense of it and when I finally figured out really what Angular did and what it was for I realized that the reason nobody ever explains that is because it sounds so trivial, although it’s actually fairly important.
> You are not paid to write code [...] The only thing that somebody cares about is how much does your software cost and how much revenue it generates.
I have a real trouble with this sentiment, and it is repeated often here on HackerNews due to this site's entrepreneurial focus.
As a developer and a professional, where does my responsibility end? I'm a developer, not a manger, and not a shareholder of the company.
Would you say it's a pilot's responsibility to point out and act in ways that reduces the cost of running the airline business or that increases its revenue? How about a surgeon or a medical doctor? At the end of the day most professionals work for a private company, a private company exists to generate profit.
Why must software developers have an entrepreneurial mindset while other professionals do not? Can someone help me understand?
I have a real trouble with this sentiment, and it is repeated often here on HackerNews due to this site's entrepreneurial focus.
As a developer and a professional, where does my responsibility end? I'm a developer, not a manger, and not a shareholder of the company.
Would you say it's a pilot's responsibility to point out and act in ways that reduces the cost of running the airline business or that increases its revenue? How about a surgeon or a medical doctor? At the end of the day most professionals work for a private company, a private company exists to generate profit.
Why must software developers have an entrepreneurial mindset while other professionals do not? Can someone help me understand?
I'd say this mindset makes it easier to drink the kool-aid when management asks you to do something unprofessional/unethical, by justifying it on the grounds that it generates revenue.
"This codebase is a ticking time bomb, but it's ok because we're moving fast!"
"No, I'm not writing a spambot, I'm building a growth hacking tool!"
"The code I'm writing might intentionally cripple the user experience, but it's driving engagement!"
"This codebase is a ticking time bomb, but it's ok because we're moving fast!"
"No, I'm not writing a spambot, I'm building a growth hacking tool!"
"The code I'm writing might intentionally cripple the user experience, but it's driving engagement!"
> The only thing that somebody cares about is how much does your software cost and how much revenue it generates.
This is one of those "motte and bailey" statements, which can be interpreted narrowly or widely, depending on how you want to use it in given situation.
When you are in a generous mood, you can admit that -- of course! -- other things are important too, because they have an indirect impact on the cost and revenue. For example, a software full of bugs can make the customers unhappy, and can make them replace you with your competitor, thus reducing your revenue. A horribly designed code and bad management can make the good developers avoid you, because they have a choice, and that will reduce your team's productivity, and increase the costs. See what a smart statement this is? Everything relevant is included there, because everything has an indirect impact on cost and revenue.
The next day, when you are in a bad mood, you can turn this accepted piece of wisdom against your developers. No, you are not going to do this refactoring thing! It only costs me money, and the customers don't care about your hierarchy of classes or immutability of objects. Keep adding new features; and if the whole thing starts collapsing under its own weight, get ready for some overtime!
> As a developer and a professional, where does my responsibility end?
It ends exactly where you decide it does. Just like in any other human interaction, the more you let other people push you, the more you get pushed. Of course there is the possibility that if you decide not to get pushed too far, but someone else is okay with that, you might get replaced. But this, too, is just like in any other human interaction.
> Why must software developers have an entrepreneurial mindset while other professionals do not?
It makes sense if you are starting your own company. (Which is what Y Combinator wants you to do, I guess. For some people this is a good advice; others may lack the necessary skills and character traits.) Otherwise, you are simply doing an entrepreneur's job for an employee's salary... in addition to doing the employee's job, of course, because all this strategic thinking about costs and revenues does not get you rid of the duty to produce the software, fix the bugs, etc. It's not like when you volunteer to do the manager's job, the manager will do a part of your job in return.
This is one of those "motte and bailey" statements, which can be interpreted narrowly or widely, depending on how you want to use it in given situation.
When you are in a generous mood, you can admit that -- of course! -- other things are important too, because they have an indirect impact on the cost and revenue. For example, a software full of bugs can make the customers unhappy, and can make them replace you with your competitor, thus reducing your revenue. A horribly designed code and bad management can make the good developers avoid you, because they have a choice, and that will reduce your team's productivity, and increase the costs. See what a smart statement this is? Everything relevant is included there, because everything has an indirect impact on cost and revenue.
The next day, when you are in a bad mood, you can turn this accepted piece of wisdom against your developers. No, you are not going to do this refactoring thing! It only costs me money, and the customers don't care about your hierarchy of classes or immutability of objects. Keep adding new features; and if the whole thing starts collapsing under its own weight, get ready for some overtime!
> As a developer and a professional, where does my responsibility end?
It ends exactly where you decide it does. Just like in any other human interaction, the more you let other people push you, the more you get pushed. Of course there is the possibility that if you decide not to get pushed too far, but someone else is okay with that, you might get replaced. But this, too, is just like in any other human interaction.
> Why must software developers have an entrepreneurial mindset while other professionals do not?
It makes sense if you are starting your own company. (Which is what Y Combinator wants you to do, I guess. For some people this is a good advice; others may lack the necessary skills and character traits.) Otherwise, you are simply doing an entrepreneur's job for an employee's salary... in addition to doing the employee's job, of course, because all this strategic thinking about costs and revenues does not get you rid of the duty to produce the software, fix the bugs, etc. It's not like when you volunteer to do the manager's job, the manager will do a part of your job in return.
> It ends exactly where you decide it does.
> Otherwise, you are simply doing an entrepreneur's job for an employee's salary...
Thank you... I'm beginning to realize this but it's still sort of a professional identity crisis for me. Of course employers want employees who think, and I'm happy to think in terms of revenue and profit, but at the end of the day it's not my responsibility.
> Otherwise, you are simply doing an entrepreneur's job for an employee's salary...
Thank you... I'm beginning to realize this but it's still sort of a professional identity crisis for me. Of course employers want employees who think, and I'm happy to think in terms of revenue and profit, but at the end of the day it's not my responsibility.
I am just guessing here, but when I think about the possible origin of the idea "good developers think about cost and revenue, bad developers think about code", I imagine something like this:
* There are stories about how two or three people started writing code in their garage, and became billionaires later.
* Some guy thinks: "Huh, I happen to have an empty garage and some extra money... perhaps I should hire two or three nerds to write code and make those sweet billions for me."
* A few years later: The nerds wrote some code, and it works relatively quickly and flawlessly... but the promised billions are still not coming. The boss is frustrated, because this is not how the stories have described it.
* Now the boss could blame himself for being gullible, or for not noticing the selection bias (just because some nerds made billions, doesn't mean all nerds do). But it is psychologically more convenient to blame the employees.
* He cannot really blame the employees for writing bad code, because the code happens to be good. So instead he blames them for, essentially, not doing his homework, too.
In other words, I would expect this to happen in small companies. Most strongly when there is no intermediate layer between the company owner and the software developer.
A large company has people, such as managers and salespeople, who are responsible for minimizing costs and maximizing revenue. The software developer may feel the result of this pressure -- if the situation is bad, there may be slow computers, small screens, and a lot of overtime -- but the developer is still expected to focus on coding, not to make financial decisions.
Trying to look at the problem from the perspective of the boss... hey, of course I would like to own a pet nerd who is great at coding, but also at making his colleagues redundant, and who works hard on maximizing my revenue! The only question is why would such person work for me, as opposed to starting his own company and maximizing his own revenue. The more perfect I imagine my hypothetical employee to be, the less it makes sense for them to be my employee.
-
More seriously: people have different skills and traits. There are skills and traits required to be a good software developers. There are skills and traits required to be a good entrepreneur. Some people are blessed by nature and have both these sets. Some only have one of them. Some have neither.
If you happen to be a person who could become a great developer and also a great entrepreneur... and you happen to work as a developer now... it is useful to remind you that you are probably using the less profitable of your options. That you are either not using the skills that are highly rewarded by market, or you are using them in order to make some other person rich instead of making yourself rich. Such advice may encourage you to start a new career, and perhaps improve your life.
But saying that you are not a good developer unless you are also an entrepreneur, that's wrong. From that perspective, Mark Zuckerberg would be a better developer than Donald Knuth. Nope, that's stupid. It is something entirely different to say that you would rather be Zuckerberg than Knuth. That is a legitimate preference, and if you have what it takes, go ahead. But I don't think that Donald Knuth or any other coder should have a professional identity crisis whenever he catches himself thinking about something other than cost and revenues.
* There are stories about how two or three people started writing code in their garage, and became billionaires later.
* Some guy thinks: "Huh, I happen to have an empty garage and some extra money... perhaps I should hire two or three nerds to write code and make those sweet billions for me."
* A few years later: The nerds wrote some code, and it works relatively quickly and flawlessly... but the promised billions are still not coming. The boss is frustrated, because this is not how the stories have described it.
* Now the boss could blame himself for being gullible, or for not noticing the selection bias (just because some nerds made billions, doesn't mean all nerds do). But it is psychologically more convenient to blame the employees.
* He cannot really blame the employees for writing bad code, because the code happens to be good. So instead he blames them for, essentially, not doing his homework, too.
In other words, I would expect this to happen in small companies. Most strongly when there is no intermediate layer between the company owner and the software developer.
A large company has people, such as managers and salespeople, who are responsible for minimizing costs and maximizing revenue. The software developer may feel the result of this pressure -- if the situation is bad, there may be slow computers, small screens, and a lot of overtime -- but the developer is still expected to focus on coding, not to make financial decisions.
Trying to look at the problem from the perspective of the boss... hey, of course I would like to own a pet nerd who is great at coding, but also at making his colleagues redundant, and who works hard on maximizing my revenue! The only question is why would such person work for me, as opposed to starting his own company and maximizing his own revenue. The more perfect I imagine my hypothetical employee to be, the less it makes sense for them to be my employee.
-
More seriously: people have different skills and traits. There are skills and traits required to be a good software developers. There are skills and traits required to be a good entrepreneur. Some people are blessed by nature and have both these sets. Some only have one of them. Some have neither.
If you happen to be a person who could become a great developer and also a great entrepreneur... and you happen to work as a developer now... it is useful to remind you that you are probably using the less profitable of your options. That you are either not using the skills that are highly rewarded by market, or you are using them in order to make some other person rich instead of making yourself rich. Such advice may encourage you to start a new career, and perhaps improve your life.
But saying that you are not a good developer unless you are also an entrepreneur, that's wrong. From that perspective, Mark Zuckerberg would be a better developer than Donald Knuth. Nope, that's stupid. It is something entirely different to say that you would rather be Zuckerberg than Knuth. That is a legitimate preference, and if you have what it takes, go ahead. But I don't think that Donald Knuth or any other coder should have a professional identity crisis whenever he catches himself thinking about something other than cost and revenues.
I think the biggest factor is that the product of a company is rarely software, but the job it performs. If your software could be replaced by some humans then your company doesn't sell software at all, it sells a process fulfillment. In that case the quality of the software doesn't matter to anyone but the developers, and developers are a smart bunch and clue in to that fact, and they work to the requirements.
I have worked at companies that value quality over all else, as our position in the market was a premium, reliable provider and we charged enough to make the economies of that decision make sense. I was happy to be able to write software I could be really proud of while there and lucky to get paid to do it.
I've also worked at companies where the stakeholders make it clear that they want results, and they don't care how. In circumstances like that, where you have strong time pressure and limited resources, no one but you cares about the code quality. So do you spend your own time staying late and making perfect code, or do you do what you get paid for and exercise your passion somewhere else?
There is a lot of good coding that takes just as much time as writing bad code, so the second situation for good developers is mostly an exercise in pragmatism. Reliable, solid code, but some concessions where it saves time.
This is answering the question of where the sentiment comes from, which only partly answers the question of "Why is so much code bad".
I have worked at companies that value quality over all else, as our position in the market was a premium, reliable provider and we charged enough to make the economies of that decision make sense. I was happy to be able to write software I could be really proud of while there and lucky to get paid to do it.
I've also worked at companies where the stakeholders make it clear that they want results, and they don't care how. In circumstances like that, where you have strong time pressure and limited resources, no one but you cares about the code quality. So do you spend your own time staying late and making perfect code, or do you do what you get paid for and exercise your passion somewhere else?
There is a lot of good coding that takes just as much time as writing bad code, so the second situation for good developers is mostly an exercise in pragmatism. Reliable, solid code, but some concessions where it saves time.
This is answering the question of where the sentiment comes from, which only partly answers the question of "Why is so much code bad".
There is a difference between code quality and software quality. Users dont care about the code quality at all as long as it meets their needs and requirements.
You should strive for both but if you had to choose one, quality software written with bad code is more valuable than bad software written with good code.
While quality code adds value when it comes maintenance and scaling, it is often overvalued by developers who think it is the end goal in itself.
You should strive for both but if you had to choose one, quality software written with bad code is more valuable than bad software written with good code.
While quality code adds value when it comes maintenance and scaling, it is often overvalued by developers who think it is the end goal in itself.
It is likely there is confusion amongst the managers because software is a young industry. Take accounting as a reference. The job of an accountant is well understood, and the skills an accountant has are well understood. Analysts and managers (as a profession) have come to understand over the centuries how to estimate the magnitude of a businesses accounting problems and how many accountants they need to deal with them.
Compare that to software, where I doubt there has been time for a solid understanding to develop. Especially since the underlying hardware economics keep changing. There are scant business lore stories that I've heard of saying "you need to have X many developers maintaining your code base or you will suffer catastrophic consequence Y like suchandsuch megacorp did".
As the software and electronics industries move from discovery and change to more maintenance oriented tasks it seems likely that software engineers will professionalise like all the other engineering disciplines.
Compare that to software, where I doubt there has been time for a solid understanding to develop. Especially since the underlying hardware economics keep changing. There are scant business lore stories that I've heard of saying "you need to have X many developers maintaining your code base or you will suffer catastrophic consequence Y like suchandsuch megacorp did".
As the software and electronics industries move from discovery and change to more maintenance oriented tasks it seems likely that software engineers will professionalise like all the other engineering disciplines.
Same philosophy should apply to EVERY `surgeon or a medical doctor`. I'd be grateful if there was a consensus in medical industry:
we are not getting paid to push pills, we are getting paid to keep people well! Surgeons: we are not getting paid for cutting people open, we are getting paid for fixing people. etc.
we are not getting paid to push pills, we are getting paid to keep people well! Surgeons: we are not getting paid for cutting people open, we are getting paid for fixing people. etc.
The equivalent approach in medicine would be:
"We are not getting paid to make people healthy; we are getting paid for reducing the hospital's costs and increasing its revenue. Health is just something nerdy doctors obsess about, because they are too busy thinking about all those Latin words."
Get competent doctors feel guilty about spending too much time studying medicine and curing people, and not having entrepreneurial skills instead -- that would be equivalent to telling software developers that software doesn't matter at all, only costs and revenues do.
"We are not getting paid to make people healthy; we are getting paid for reducing the hospital's costs and increasing its revenue. Health is just something nerdy doctors obsess about, because they are too busy thinking about all those Latin words."
Get competent doctors feel guilty about spending too much time studying medicine and curing people, and not having entrepreneurial skills instead -- that would be equivalent to telling software developers that software doesn't matter at all, only costs and revenues do.
[deleted]
But as a developer with a place to make a decision, its part of the responsibility to choose a solution that provides the most value to your company or customer, even if you are part of a larger team. Also, a pilot and a developers job are much different. A pilot is responsible for ensuring that his passengers have a safe and smooth flight, which directly affects the company business. It's not like they just sit in the cabin and push buttons without a care in the world. Same for doctors. Point is if you are paid well enough, chances are your actions will directly or indirectly affect your companies revenue to some extent and you should keep that in mind while taking any decisions.
"software is not poetry"
The more experience I have, the more code I saw, the more I think software development is more of an art then actual science. Obviously there are mathematical formulas you can't alter, but you can still introduce very good or very bad abstractions to solve those either.
Making software is a creative process, not something immediately everyone can do. Even if two developers have the same amount of experience (in terms of years), there can be huge differences how they solve the same problem.
IMHO this applies to any craft. It's a level of skill and thinking put into building something that makes it "a piece of art", whether it's well written code or a well crafted piece of furniture - And appreciating a job well done brings joy to other people who know how to see it, just as much as poetry or a painting to art lovers.
I think the text is missing a main point why people feel the fatigue. Problem are not tools themselves or any fetish around them, problem is making choices of which ones to use for which job. It's stressful and time consuming and requires you to constantly follow everything new that's going on - and in back of your head you still constantly feel a fear that you're missing on something important because it's impossible to try and test everything that comes your way. Imagine trying to open some machine, and every screw holding the lid is a different kind and size. You'd go crazy changing between phillips, slotted, star, torx, etc. That's how I started to feel with JS at some point. Luckily I think that some level of standardization is now happening in JS world, so there's some light at the end of the tunnel...
> The only thing that somebody cares about is how much does your software cost and how much revenue it generates.
This is such a narrow mindset – can't we take pride and enjoyment from our craft while also being productive? Look at ornate antique architecture for instance: it doesn't _need_ to be beautiful to perform its function of being a building, but it is certainly more impressive and likely to endure the test of time.
Go outside and pet a puppy or something. This is depressing.
This is such a narrow mindset – can't we take pride and enjoyment from our craft while also being productive? Look at ornate antique architecture for instance: it doesn't _need_ to be beautiful to perform its function of being a building, but it is certainly more impressive and likely to endure the test of time.
Go outside and pet a puppy or something. This is depressing.
I don't buy this completely. I've seen software that doesn't solve any _business_ problem. LaTeX solves the typesetting problem, if you make that your business, sure, but LaTeX in itself was created to solve a problem not related to business, directly. If you wanna go meta and say everything is a business then I dunno what to say, it's just a blanket argument.
Also I've seen code golfs, Perl poems and like, so no I don't buy the author's viewpoint. In fact many open source projects were created to scratch some creative developer's itch and not to make money out of it.
This article seems to take a very narrow/rigid view of the computing industry/the computing community.
Also I've seen code golfs, Perl poems and like, so no I don't buy the author's viewpoint. In fact many open source projects were created to scratch some creative developer's itch and not to make money out of it.
This article seems to take a very narrow/rigid view of the computing industry/the computing community.
> This article seems to take a very narrow/rigid view of the computing industry/the computing community.
It takes a full-blown "play the market game" approach. There's nothing meaningful in life but doing business, and doing business is how meaningful things are achieved. As a programmer your job is to be a cog in a machine and also to tune the machine, and you shouldn't even dream of having any values other than this, because what the machine produces is by definition what's good and worthy.
It takes a full-blown "play the market game" approach. There's nothing meaningful in life but doing business, and doing business is how meaningful things are achieved. As a programmer your job is to be a cog in a machine and also to tune the machine, and you shouldn't even dream of having any values other than this, because what the machine produces is by definition what's good and worthy.
He starts by addressing Patrick's article, which is specifically about the "90% of programming jobs ... creating Line of Business software". Then he turns around and quotes from the NASA Apollo project, and Donald Knuth. Are these examples of this type of software? Are they relevant? TeX took decades to write, and not only does he have no customers, no requirements, and no unit tests, but the author pays people out of pocket when they find a bug. It took him over a decade to make a stable release, and he's barely made any changes to the software since then. Oh, and it's all free. I'm struggling to think of how a person could be any worse at business!
Once you admit that there are radically different types of 'programming' in the world, you shouldn't be quoting from the opposite kind to support your cause. This reads like the McDonald's operations manual quoting Julia Child. They both work with food but words like "quality" or "efficiency" will have completely different meanings in these two contexts.
Knuth has many useful things to say about software, but his oft-quoted aphorism was not telling you how to make your business succeed. Are you also going to rewrite your software from scratch after 5 years once you've learned what the hard parts are?