JavaScript Fatigue: Realities of our industry (2017)

https://lucasfcosta.com/2017/07/17/The-Ultimate-Guide-to-JavaScript-Fatigue.html

by wheresvic1 • 7 years ago

83 68 7 years ago

lucasfcosta.com

growtofill• 7 years ago

(2017), please.

Update: previous discussion, https://news.ycombinator.com/item?id=14861886

austincheney2• 7 years ago

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.

s3m4j• 7 years ago

It's also the same logic you can observe everywhere in business : pushing down responsabilities, outsource resources, leave a paper trail etc.

karanlyons3• 7 years ago

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.

ownagefool2• 7 years ago

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.

antt3• 7 years ago

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.

seanwilson• 7 years ago

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.

justatdotin• 7 years ago

nobody cares about how good is your code

the person who has to maintain it?

sbhn3• 7 years ago

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.

afarrell4• 7 years ago

Or the business owner who is frustrated that their product still lists Czechoslovakia as a country.

(Yes, this is true of ADP)

afarrell4• 7 years ago

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.

austincheney2• 7 years ago

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.

perfunctory2• 7 years ago

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');

Seriously? If this is not a major reason of js fatigue I don't know what is.

aaaaaaaaaaab2• 7 years ago

Lol, are these assert libs mimicking badly written English still a thing? I thought we grew out of this a few years ago.

Gigablah• 7 years ago

Really? All it takes for language fatigue is syntax? I’d hate to hear what you think of English.

namelosw• 7 years ago

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.

antonkm2• 7 years ago

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.

perfunctory2• 7 years ago

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.

chiefalchemist• 7 years ago

"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.

tyingq• 7 years ago

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.

shabbyrobe• 7 years ago

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.

Can_Not• 7 years ago

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.

shaan72• 7 years ago

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.

rat9988• 7 years ago

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.

Wrong way to look at it. From his perspective, the developers you talk about are consumers.

shaan72• 7 years ago

Ah yes, my bad -.-

sbhn3• 7 years ago

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.

sanxiyn2• 7 years ago

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.

xorcist• 7 years ago

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.

sanxiyn2• 7 years ago

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.

TeMPOraL3• 7 years ago

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.

commandlinefan2• 7 years ago

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”.

sbhn3• 7 years ago

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,

divan• 7 years ago

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.

commandlinefan2• 7 years ago

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.

rnd332• 7 years ago

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?

aaaaaaaaaaab2• 7 years ago

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!"

roenxi• 7 years ago

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.

tiuPapa• 7 years ago

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.

ehnto• 7 years ago

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".

mobjack• 7 years ago

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.

rinchik• 7 years ago

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.

Viliam12343• 7 years ago

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.

Viliam12343• 7 years ago

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.

rnd332• 7 years ago

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.

kissgyorgy• 7 years ago

    "software is not poetry"

Yes it is. You did not saw yet how you can write the same piece of code like hundreds of different ways, some of them which are "more beautiful", some of them are "really bad code".

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.

ivanhoe2• 7 years ago

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.

ivanhoe2• 7 years ago

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...

asow92• 7 years ago

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.

legends2k• 7 years ago

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.

TeMPOraL3• 7 years ago

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.

ken• 7 years ago

I'm sensing a bait-and-switch here.

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?

JavaScript Fatigue: Realities of our industry (2017)

Related Stories