JavaScript Fatigue: Realities of our industry (2017)
lucasfcosta.com
lucasfcosta.com
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?
"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 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.
> 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.
* 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 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".
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.
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.
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 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.
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.
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.
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 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.
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.
> 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.
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.
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.
The media wiki parser is a perfect example of what can go wrong with simple solutions.
You immediately went for two examples that are precisely not the kind of thing the author is talking about. Consider leftpad.
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.
the person who has to maintain it?
——
You also probably notice if they are using roof tiles as plates, but that doesn’t make them good cutting boards in the kitchen.
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.
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.
(Yes, this is true of ADP)
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.
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
Very true. A skilled carpenter is discerning about his tools and know where it matters to spend more money.
It starts with interesting and then moves on to good later I think.
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.
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');
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.
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.
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.
"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.
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.
Wrong way to look at it. From his perspective, the developers you talk about are consumers.
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.
Update: previous discussion, https://news.ycombinator.com/item?id=14861886
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.
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?
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.
For god's sake, don't go study quantum mechanics (or semiconductors, or CPU architecture) when you are writing JavaScript.
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.
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.
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.
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.