8 ms·

JavaScript Fatigue: Realities of our industry (2017)

83 points by wheresvic1 8y ago

growtofill 8y ago
(2017), please. Update: previous discussion, https://news.ycombinator.com/item?id=14861886 https://news.ycombinator.com/item?id=14861886
austincheney 8y 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 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 8y ago
  It's also the same logic you can observe everywhere in business : pushing down responsabilities, outsource resources, leave a paper trail etc.
- karanlyons 8y 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.
  - ownagefool 8y 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/ https://www.php-fig.org/ defining how this should fit together.
perfunctory 8y 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.
- aaaaaaaaaaab 8y ago
  Lol, are these assert libs mimicking badly written English still a thing? I thought we grew out of this a few years ago.
  - deleted 8y ago
    [deleted]
- deleted 8y ago
  [deleted]
- deleted 8y ago
  [deleted]
- deleted 8y ago
  [deleted]
- Gigablah 8y ago
  Really? All it takes for language fatigue is syntax? I’d hate to hear what you think of English.
- namelosw 8y 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.
chiefalchemist 8y 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 8y 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 8y 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 8y 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.
shaan7 8y 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 8y 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.
  - shaan7 8y ago
    Ah yes, my bad -.-
sbhn 8y 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.
sanxiyn 8y 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 8y 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.
  - sanxiyn 8y 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.
- TeMPOraL 8y 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.
- commandlinefan 8y ago
sbhn 8y 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-Redux-Boilerplate 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,
kimjongman 8y ago
A client messaged me yesterday Client: We want to use React for our website Me: What do you plan to build? Why do you want to use React? Client: Because it's cool and we like facebook duh
deleted 8y ago
[deleted]
divan 8y 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.
- commandlinefan 8y 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.
rnd33 8y 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?
- aaaaaaaaaaab 8y 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 8y 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.
kissgyorgy 8y 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.
- ivanhoe 8y 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.
ivanhoe 8y 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 8y 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 8y 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.
- TeMPOraL 8y 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 8y 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?

83 points by wheresvic1 8y ago

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

austincheney 8y 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 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 8y ago
It's also the same logic you can observe everywhere in business : pushing down responsabilities, outsource resources, leave a paper trail etc.
karanlyons 8y 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.
- ownagefool 8y 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/ https://www.php-fig.org/ defining how this should fit together.

perfunctory 8y 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.

aaaaaaaaaaab 8y ago
Lol, are these assert libs mimicking badly written English still a thing? I thought we grew out of this a few years ago.
- deleted 8y ago
  [deleted]
deleted 8y ago
[deleted]
deleted 8y ago
[deleted]
deleted 8y ago
[deleted]
Gigablah 8y ago
Really? All it takes for language fatigue is syntax? I’d hate to hear what you think of English.
namelosw 8y 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.

chiefalchemist 8y 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 8y 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 8y 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 8y 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.

shaan7 8y 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 8y 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.
- shaan7 8y ago
  Ah yes, my bad -.-

sbhn 8y 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.

sanxiyn 8y 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 8y 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.
- sanxiyn 8y 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.
TeMPOraL 8y 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.
commandlinefan 8y ago

sbhn 8y 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-Redux-Boilerplate 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,

kimjongman 8y ago

A client messaged me yesterday Client: We want to use React for our website Me: What do you plan to build? Why do you want to use React? Client: Because it's cool and we like facebook duh

deleted 8y ago

[deleted]

divan 8y 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.

commandlinefan 8y 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.

rnd33 8y 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?

aaaaaaaaaaab 8y 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 8y 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.

kissgyorgy 8y 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.

ivanhoe 8y 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.

ivanhoe 8y 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 8y 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 8y 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.

TeMPOraL 8y 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 8y 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?