7 ms·

Woo for Its Own Sake

118 points by mwcampbell 6y ago

draw_down 6y ago
Keep it simple, use boring tech, etc. We know. The whole issue is what is boring, what angle we wish to view simplicity/complexity from. These pretty much always boil down to “what I like”. What I like is simple and boring, your stuff is shiny and overengineered.
- JKCalhoun 6y ago
  He gave examples that would be more accurately described as "tried and true" not "your stuff" — the code that has been battle tested in the field for decades.
- civilized 6y ago
  It's not hard to find things that virtually everyone agrees are complicating and shouldn't be used in a project unless they have clear benefits. Metaprogramming. Macros. Multiple inheritance. Multiple languages. The silver pants unicyclists know this too, they just lack impulse control.
- strulovich 6y ago
  I think this gets to the next level of the problem. Some people (usually earlier in their career) really get attracted to weird shiny stuff. But in reality, discussions I have about arguing for simplicity have two opposing sides both basing on tried and true technologies in their opinion. I find a good solution is to have reviewers and outsiders who can give feedback, and generally trust them when they recommend avoiding something. (But I have seen the cases where this exact approach would have killed a crazy idea that became a huge success story later on) Almost everyone wants simple. But simplicity is subjective. My simple can be a touch screen and yours can be buttons and we would both be correct.
JKCalhoun 6y ago
The whole article is genius (and funny) and rings true from many years experience in the biz. > I’m imagining the archetypical unicycle-juggler buying a shop full of solid printers and weird CNC machines and forgetting to buy cutters, hacksaws, files and machinist squares. As if files and machinist squares are beneath them in current year. Of all the things I could have commented on, I have to call out this last line simply because I only just saw a YouTuber last week 3D-print a part for a project he was working on: the part was the exact size and shape of a 4-inch long piece of standard PVC pipe you could pick up from Home Despot for a few bucks and saw the length you wanted in a few seconds.
- 542458 6y ago
  In the last few months I’ve printed a few parts that could be bought OTS because I don’t want to go into a store in the era of COVID. More generally, I’ve also printed stuff you can buy OTS because it can be less labor than going to the store, and occasionally cheaper. Also, sometimes it’s just more fun.
  - netizen-9748 6y ago
    While I absolutely understand the fun factor, is it really less labor to draw something in a CAD program than make a cut or two?
    - 542458 6y ago
      Less labour than driving to the store, finding the part, buying it, driving home, and carefully making an accurate cut with a hacksaw :)
- michaelcampbell 6y ago
  > Home Despot So edgy.
ajkjk 6y ago
I suspect the author has a lot more exposure to the kinds of people who want to write their next web server basically in category theory than most people actually do, and so thinks that kind of person is much more common than they actually are. But I still like the take a lot, particularly because of the perfect truth of the line "[Go] is a boring garbage collected thing that looks like C for grownups, or Java not designed by 90s era object oriented nanotech fearing imbeciles. "
xyzelement 6y ago
There was an article here a few days ago about"incompetent altruism" or something like that. The commonality is whether you're laser focused on solving the problem, versus being obsessed with yourself as the solver. The bit about us not being smart enough for some of the technologies also rings really true. Thinking of a coworker who was "smart" enough to reach for threads right away, and then inevitably spent the next 2 years of any project dealing with thread issues in production.
- wpietri 6y ago
  Exactly. Over the years I've learned to keep my self-indulgence to my hobby projects. When I'm coding for money, I try very hard to set aside my ego and do the best thing for the users. As much as I am personally motivated by novelty and curiosity, when I'm on the clock I'm a lifetime member of the Boring Technology Club: http://boringtechnology.club/ http://boringtechnology.club/
- carapace 6y ago
  "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" https://en.wikiquote.org/wiki/Brian_Kernighan https://en.wikiquote.org/wiki/Brian_Kernighan
jka 6y ago
It's definitely true, there's a frequent temptation in software engineering to be drawn to novel technologies. That said, the idea of different data types in C could have been considered a fancy addition by BCPL developers. The key is to use critical thinking to determine what developments may be useful longer-term, and also to watch out for any (typically accidental) flaws exist in the novelties that are being proposed - sometimes it takes years, but those can come back to bite us. It may not make business sense to exert effort shifting to new technologies straight away, but encouraging people to learn the strengths, weaknesses and properties of them can be valuable nonetheless.
dkarl 6y ago
I had a few job interviews last year where it was clear the people trying to hire me had plenty of programming talent on board already. They were just looking for a technically competent adult who could look at what was going on and figure out why all the fancy work that was getting done was not doing what the rest of the company needed and expected. One company had several different teams of programmers that were great at building things, but they were all going in different directions with different tech stacks (two in Go, one in Rust, and one in Python) and completely different data models for the company's basic business domain. When a directive came down from above that two systems HAD to be integrated, because a customer paying for one product wanted the other one as well, as sales and product had been hoping and planning since before the products were built, the engineers gave them an estimate of four months to do the integration. The business knew that meant 8+ months. How many programmers did they have to get this disjointed? Less than twenty. Lots of other companies have similar stories. I disagree that it is about lack of financial compensation. These companies were paying good money, and their engineers were living comfortably and abusing the relationship, whether wittingly or unwittingly. Anybody who reads HN can whip up an impressive, Netflix-blog-worthy design for any problem their company has. If their company is unlucky, they might even have the energy and raw hacker ability to get it mostly working. Where we're failing as a profession is in educating people that this is poor engineering, that it's bush league bullshit. It isn't impressive. It doesn't show any ability except a certain amount of shallow raw intelligence, which is necessary and valuable, but which is more like raw material to build ability out of than ability itself. In other forms of engineering, the culture is very clear: simplicity is an achievement. Solving an easy problem with a big, expensive solution is not an achievement. It's unskillful. The best engineers come up with solutions that make you see the problem as an easy one. Solving easy problems with difficult solutions proves you aren't qualified to take on the problems that need those solutions. How do we establish this as a standard belief in software engineering as well?
- fractionalhare 6y ago
  A lot of what you describe is attributable to resume-driven development, in my opinion. Complex solutions are used to insinuate that the engineers who implemented them are solving complex problems. This in turn improves their marketability by insinuating they've got the razzle dazzle and trendiness under their belt that justifies $500k a year. Sometimes it's also not resume-driven development, at least not intentionally. Sometimes it's because the engineers just want to work on overcomplicated shit. For example I have my personal blog running on half a dozen AWS features - S3, Athena, Cloudfront, Cloudwatch, Lambda, SNS, SES, ... I don't need any of that for a simple blog, and I write on it like once a year. And the site is still slow as shit (relatively) even though it's static because I haven't optimized the font and script loads to be non-blocking. But it was fun to set up!
jfoutz 6y ago
this is a funny and thought provoking article. There's a bit of texture that I feel is missing, and I feel personally attacked, so I'm going to throw up a weak defense of category theory web servers. Back in the day, in perl I'd bless regexes and use AUTOLOAD to provide the class implementations at runtime, as any good unicycle rider would. Changing the Rube Goldberg machine is hard. grep won't really help. I'd resort to even dirtier tricks to change behavior. Later I worked in java. grep would work, but even better, I could make a class private, create an interface and just chase compiler errors. So much nicer than hunting down the right line of code to hijack in perl. It's pretty good, and I think go provides a similar level of support, but there's still a bunch of room for Class.forName(foo); //haha! grep will never find me! and it's cool, cause you'll only find out about it at runtime. Anyway Haskell is neat because you can throw it all in a do in IO. hack away for days. When it's time to change, just change it. the compiler will help. The compiler will tell you everything you need to know to scope down to the finest level you want. It's super easy to be way too fancy up front, but any mistakes can be fixed. Anyway, Haskell is probably never the right choice but it's the only thing I know of that lets you easily change the design whenever you feel like it. It's Saturday, and I've thought about this too much. Time to put on my silver pants and go unicycling.
SkyMarshal 6y ago
Tools should be chosen to match the use case. Haskell is a good choice when you've got: 1) a problem that requires a very high-assurance system with very low tolerance for bugs, errors, and failures, and 2) a large complex system where refactoring and other maintenance-over-time activities are made materially more manageable by Haskell's strong type system and other tools, 3) a need for large-scale parallelization that a purely functional language like Haskell facilitates, and 4) a world class team of engineers who can become productive in it relatively quickly, support new hires doing so too, and won't foreseeably be outsourced to some low cost overseas sweat shop. Rust is also worth considering under those criteria, in addition to embedded systems, hard/soft real-time or constant-time systems, etc. But obviously not all software projects have all those criteria. Other languages like Go, Python, Javascript, Java-ecosystem, .Net, etc may be ideal in other circumstances. You just have to match the tools for the job.
- paulryanrogers 6y ago
  Article seems to be implying at a big company you probably can't have #4 and may not even need #1.
barnacled 6y ago
One thing I've noticed in my career is that those who possess a certain kind of 'wow' factor are the ones who are categorised as the 'stars' and thus progress quickly through the technical ranks. I've tended to find that these people don't write particularly good code (not usually bad, just mediocre) and tend to lack ability in software engineering - writing deeply unrobust code that falls far short of their perceived 'rockstar' qualities. I can't tell you the number of conversations I've had with managers or even colleagues where their untouchable genius is extolled to the heavens. Combine this with the fact that those who raise issues and foresee problems are often viewed poorly (possibly even MORE so if those problems actually end up happening). Ultimately you end up with a situation where those who advocate for solid engineering are, while respected, never really raised above the low levels of the career ladder and those who embrace woo rise up.
throwanem 6y ago
> I’m imagining the archetypical unicycle-juggler buying a shop full of solid printers and weird CNC machines and forgetting to buy cutters, hacksaws, files and machinist squares. In 2020 we call this a "makerspace".
pnathan 6y ago
It depends. What are you doing? What are the constraints? What is the problem? Do you need innovation? Do you need plumbing? Can you lift your eyes and see the value in a radically new way? Does it look like what you are already doing, or does a beginner's mind really suggest a new approach? The author sounds like a crabby old guy who doesn't want to change. Probably an artifact of the topic. But it *is* a real problem- people get locked into fancy-chasing. This introduces risk into the project delivery: team based (knowledge) and tech (not adequately debugged). I've worked at length in "fancy" languages and some of the fancy tech. My conclusion is you have a limited amount of investment you can do. Some of this is team based (language learning, keeping the employees happy), some is in product, some is in tech stack (FlashyFancypants DB and SparklePants.JS). Good tech leadership includes picking out what to take risks on, judging appropriate ROI. Note this holds true for open source, not just business projects! I work in a Clojure shop, so I interact with the rewards and risks of this strategy right now. My last team/company, we chose Go for the team language. It wasn't as unilaterally good as some might hope. Nor was it as unilaterally as bad! It was just another language.
closeparen 6y ago
The “just solve the problem” attitude also gets used as an excuse to ship the worst code that can get through user acceptance testing. The worst bridge that can stand up to the load is good, cost efficient engineering. The worst code is not. One, because bad code hides bugs that you probably don’t have rigorous enough testing to find. Two, because there will be new demands on that code in the future, and bad code is harder and riskier to change. You might look like a responsible adult when you ship it today, but three years later the new maintainers will know you were a child making a mess. And probably end up doing a rewrite, or at least needing to. All this “woo” with languages and frameworks and services and whatever else, is the search for higher quality code. There is a certain myopia about new things vs. getting better at design with old things. There is a certain blindness to iterative improvement, e.g. Rust is much sexier than modern C++ as a solution to the problems of C++98. But rather than condescending to this you can channel the energy into more responsible directions. I work in a team where many people have zero aesthetic sensibility about code. Not like “I know this is ugly but we have to get it done today” or “I know this is ugly but it’s the best we could come up with,” just zero sense that it’s ugly. Grass is not greener.
- peterkos 6y ago
  Trying to explain that code is more than "well, it works!" is especially hard. Maybe its just the part of programming that's more an art than a science?
  - beaconstudios 6y ago
    programming is a systems science - it is qualitative and constraint-based, not metric-based. It's an optimisation problem where you have to optimise for multiple concerns - maintainability, extensibility, scope, testability, and so on. Overengineering in a way that doesn't help any of these is falling at the first hurdle.
ilovefood 6y ago
This was a fascinating and funny read. What a great writing style and strong opinion. I had to agree with most of it!
jodrellblank 6y ago
20% content, 80% sneering and self-pleasuring about inferior other people. It's not that solid trustable systems don't exist, or are a bad idea, or chasing the new-shiny doesn't happen, but they're not really what the post is about. > underpaid compensated in self esteem [..] manager saying “dude yer so fookin smart” [...] brainlet payment system. [..] benefit to boring languages is people concentrate on the problem not interesting complexities of tool Missing the point raised earlier: "the problem" being solved is that work is boring; Woo isn't added "for its own sake", it's added because being an interchangable cog in a relentless productivity optimization machine isn't what humans exist for, no matter how much employers and the author would like that to be so. > people who feel like every line of code has to be innovative Employees don't get paid or promoted for saying "this is good enough, let's take 18 months off", but they do for adding a new widget or showing off to the boss. Broken incentives lead to people following them. > like bike-shedding, but more perverse It's pleasure! Spit! Disgusting, sinful and shameful, and the people who enjoy it are inferior. Get back to the grindstone! > you are presumably solving real world problems which someone pays for "Impress my manager", "buy some food", "survive this stupid doomed project nobody wants that doesn't have the political backing or funding to get to its impossible goals" are problems people solve for money. Jobs where people solve real world problems seem a small subset of jobs. > about as necessary and in demand as riding to work in silver pants on a unicycle The way someone commutes to work has so little to do with anything that it's a big reinforcement this is about image, not engineering. > developers [..] are often child-like in their enthusiasm for new and shiny things Everyone knows that companies are at their best when petrified, stagnant, resistant to change and unwilling to entertain new ideas, right? > Engineers are different: they’re trying to solve a problem No-true-Scotsman so that "Engineer" now means person who tries to solve a problem (only using existing tools and techniques), and people titled or qualified as "engineer" who aren't trying to solve problems, or anyone who is trying use a new approach to solve a problem or doesn't have the same constraints and goals are "not real engineers". > Engineers understand it’s OK to solve the problem with ephemeral, trashy, but fast-to-market solutions Nothing the world loves more than falling bridges, burning skyscrapers. A moment ago the important thing was to build stable, long-term, easily maintained systems with boring technologies (a classic description of "engineering"). Now Engineers are building ephemeral trashy minimal viable products? Is trashy and ephemeral "engineering" now? (No, the point is who to mock and shame, and who is superior). > if the product manager is going to change it all next week Could be related to why the idiot in the clown shoes is enjoying building it in Haskell, knowing that it won't need to be long-term maintainable because it doesn't matter anyway. No, it must be because they're inferior to the blog post author, who is all about solving real world problems like making sure software engineers know their status is beneath him. > Engineers also plan for the future [..] critical infrastructure that lives [..] depend on Engineers do the right thing in the right circumstances, and you can tell they are engineers post-hoc when it worked? Handwave away any critical infrastructure which failed as "not built by engineers", e.g. Boeing must have put no engineers on the Maxxx, you can tell because it killed people. > Consider a previous era; motors for small fishing boats. [...] So the motors of the early days were extremely reliable. Consider survivorship bias, the unknown number of fishing boats with more complex motors that worked just fine, the unknown number with simple engines that were unreliable and unfixable out on the water. Pointing out that some simple reliable engines exist does not show that "motors of the early days were reliable". > Such engines are useful enough they remain in use to this day Maybe simpler engines are simply cheaper and the lack of emissions regulations or any performance or luxury equivalent of a Ferrari commercial fishing boat hasn't caused much engine change over time? Complex systems can be useful enough that they remain in use to this day, too. > this design still sold by the Sabb company in Norway [..] they’re definitely more reliable where it counts More reliable than what, exactly? Are there competitors making complex and unreliable fishing boat motors that leave people stranded and dying, have been making them for 70 years and nobody notices and they still have customers? No, the alternative is a strawman sneer comparison, a solar powered Sterling engine. Point to a commercial fishing company run by a unicycling strawman using solar powered Sterling engines and then going bankrupt? Anyone? > in the engine room, you are filled with confidence[..] If you find some jackass on a unicycle, maybe not so much. And you should judge by how they appear, and not by their track record or by talking to them, since this whole blog post is entirely about who is high status and respectable and who is inferior by image and not really about whether you get home from your fishing trip. [cont]
deleted 6y ago
[deleted]
1vuio0pswjnm7 6y ago
He kinda rags on Haskell. I am wondering what people on HN think of pandoc, a Haskell project by someone outside the software industry for converting to/from .docx and other formats. I like it because it can be used as a single binary. Is there some other preferred way amongst so-called "software engineers" to do the sort of conversions pandoc does. Python libraries, maybe?
- earthboundkid 6y ago
  Pandoc is fine, but it is literally the most popular OSS Haskell project, and it’s a super obscure document converter. The most popular OSS projects in Go are Docker and Kubernetes (maybe a strike against Go? Lol) and Rust has this thing called “Firefox”. Haskell has been around for twenty years and by any objective measure has made almost no direct impact on OSS. It’s a thing programmers do for fun on the weekend instead of Sudoku. It had some influence on Rust and Swift, but all of the software written in Haskell could disappear tomorrow and no one would notice.
  - illegalsmile 6y ago
    any modern functional programming feature was inspired by haskell, if it didn't invent it it sure proved its usefulness.
  - nineteen999 6y ago
    > Rust has this thing called “Firefox” Less than 10% of it: https://4e6.github.io/firefox-lang-stats/ https://4e6.github.io/firefox-lang-stats/ Also there were several Rust developers laid off from Mozilla a few months back, including the Servo team: https://www.reddit.com/r/rust/comments/i7stjy/how_do_mozilla_layoffs_affect_ https://www.reddit.com/r/rust/comments/i7stjy/how_do_mozilla...
    - earthboundkid 6y ago
      Yes, and? The point is that Firefox substantially depends on Rust and is the most prominent OSS Rust project. People would notice if FF went away one day. No one would notice if pandoc disappeared until they got some weird files they needed to convert.
zumu 6y ago
This article would make a lot more sense if it was criticizing something more prevalent (e.g. JavaScript library churn, etc.) Point taken, but I see no reason to straw man Haskell and Rust. They have their uses and new successful features they explore get ported back into the boring languages. This is how technological development works. For a non-programming example, anti-lock brakes were used in Concorde jets before they were used in automobiles. Also, one must consider that Java was a 'shiny' language once. Honestly, if OP knows of many companies that are picking Haskell or Rust over the likes Java or Golang, please post links. I'll happily apply.
- ncmncm 6y ago
  I was there. Java was never a shiny language. It was many things. It was, most particularly, a ticket out of the world of the Microsoft sharecropper, needing to learn a whole new Microsoft Framework every second year, and discovering over again each time all the shit that didn't work, that couldn't be made to do what it was for, and cobbled-together ways to get around it instead. I managed to never need to code on Microsoft until a bit around 2010, so missed the appeal. I was amazed to discover that, even in 2010, nobody who had coded for MS their whole lives knew any better than I did how to get an MS OS to do any sensible thing. I would ask, and they would start rooting, trying random things until something seemed to work. The idea of a documented, stable, standard library component that actually did what it said without crashing was an absolute revelation, but the opposite of every shiny thing imposed on them before.
demifiend 6y ago
This reads like a paraphrase of David Graeber's "On the Phenomenon of Bullshit Jobs" but with chan-speak loan words like 'brainlet' mixed in for flavor. Is the author trying to suggest that software development is a skilled trade but that most jobs in the trade are bullshit jobs best outsourced to Elbonia?
hrishi 6y ago
"really cool lisp macros for ad servers" hits hard, in a place I didn't know I could be hit.

118 points by mwcampbell 6y ago

Keep it simple, use boring tech, etc. We know. The whole issue is what is boring, what angle we wish to view simplicity/complexity from. These pretty much always boil down to “what I like”. What I like is simple and boring, your stuff is shiny and overengineered.

JKCalhoun 6y ago
He gave examples that would be more accurately described as "tried and true" not "your stuff" — the code that has been battle tested in the field for decades.
civilized 6y ago
It's not hard to find things that virtually everyone agrees are complicating and shouldn't be used in a project unless they have clear benefits. Metaprogramming. Macros. Multiple inheritance. Multiple languages. The silver pants unicyclists know this too, they just lack impulse control.
strulovich 6y ago
I think this gets to the next level of the problem. Some people (usually earlier in their career) really get attracted to weird shiny stuff. But in reality, discussions I have about arguing for simplicity have two opposing sides both basing on tried and true technologies in their opinion. I find a good solution is to have reviewers and outsiders who can give feedback, and generally trust them when they recommend avoiding something. (But I have seen the cases where this exact approach would have killed a crazy idea that became a huge success story later on) Almost everyone wants simple. But simplicity is subjective. My simple can be a touch screen and yours can be buttons and we would both be correct.

JKCalhoun 6y ago

The whole article is genius (and funny) and rings true from many years experience in the biz. > I’m imagining the archetypical unicycle-juggler buying a shop full of solid printers and weird CNC machines and forgetting to buy cutters, hacksaws, files and machinist squares. As if files and machinist squares are beneath them in current year. Of all the things I could have commented on, I have to call out this last line simply because I only just saw a YouTuber last week 3D-print a part for a project he was working on: the part was the exact size and shape of a 4-inch long piece of standard PVC pipe you could pick up from Home Despot for a few bucks and saw the length you wanted in a few seconds.

542458 6y ago
In the last few months I’ve printed a few parts that could be bought OTS because I don’t want to go into a store in the era of COVID. More generally, I’ve also printed stuff you can buy OTS because it can be less labor than going to the store, and occasionally cheaper. Also, sometimes it’s just more fun.
- netizen-9748 6y ago
  While I absolutely understand the fun factor, is it really less labor to draw something in a CAD program than make a cut or two?
  - 542458 6y ago
    Less labour than driving to the store, finding the part, buying it, driving home, and carefully making an accurate cut with a hacksaw :)
michaelcampbell 6y ago
> Home Despot So edgy.

ajkjk 6y ago

I suspect the author has a lot more exposure to the kinds of people who want to write their next web server basically in category theory than most people actually do, and so thinks that kind of person is much more common than they actually are. But I still like the take a lot, particularly because of the perfect truth of the line "[Go] is a boring garbage collected thing that looks like C for grownups, or Java not designed by 90s era object oriented nanotech fearing imbeciles. "

xyzelement 6y ago

There was an article here a few days ago about"incompetent altruism" or something like that. The commonality is whether you're laser focused on solving the problem, versus being obsessed with yourself as the solver. The bit about us not being smart enough for some of the technologies also rings really true. Thinking of a coworker who was "smart" enough to reach for threads right away, and then inevitably spent the next 2 years of any project dealing with thread issues in production.

wpietri 6y ago
Exactly. Over the years I've learned to keep my self-indulgence to my hobby projects. When I'm coding for money, I try very hard to set aside my ego and do the best thing for the users. As much as I am personally motivated by novelty and curiosity, when I'm on the clock I'm a lifetime member of the Boring Technology Club: http://boringtechnology.club/ http://boringtechnology.club/
carapace 6y ago
"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" https://en.wikiquote.org/wiki/Brian_Kernighan https://en.wikiquote.org/wiki/Brian_Kernighan

jka 6y ago

It's definitely true, there's a frequent temptation in software engineering to be drawn to novel technologies. That said, the idea of different data types in C could have been considered a fancy addition by BCPL developers. The key is to use critical thinking to determine what developments may be useful longer-term, and also to watch out for any (typically accidental) flaws exist in the novelties that are being proposed - sometimes it takes years, but those can come back to bite us. It may not make business sense to exert effort shifting to new technologies straight away, but encouraging people to learn the strengths, weaknesses and properties of them can be valuable nonetheless.

dkarl 6y ago

I had a few job interviews last year where it was clear the people trying to hire me had plenty of programming talent on board already. They were just looking for a technically competent adult who could look at what was going on and figure out why all the fancy work that was getting done was not doing what the rest of the company needed and expected. One company had several different teams of programmers that were great at building things, but they were all going in different directions with different tech stacks (two in Go, one in Rust, and one in Python) and completely different data models for the company's basic business domain. When a directive came down from above that two systems HAD to be integrated, because a customer paying for one product wanted the other one as well, as sales and product had been hoping and planning since before the products were built, the engineers gave them an estimate of four months to do the integration. The business knew that meant 8+ months. How many programmers did they have to get this disjointed? Less than twenty. Lots of other companies have similar stories. I disagree that it is about lack of financial compensation. These companies were paying good money, and their engineers were living comfortably and abusing the relationship, whether wittingly or unwittingly. Anybody who reads HN can whip up an impressive, Netflix-blog-worthy design for any problem their company has. If their company is unlucky, they might even have the energy and raw hacker ability to get it mostly working. Where we're failing as a profession is in educating people that this is poor engineering, that it's bush league bullshit. It isn't impressive. It doesn't show any ability except a certain amount of shallow raw intelligence, which is necessary and valuable, but which is more like raw material to build ability out of than ability itself. In other forms of engineering, the culture is very clear: simplicity is an achievement. Solving an easy problem with a big, expensive solution is not an achievement. It's unskillful. The best engineers come up with solutions that make you see the problem as an easy one. Solving easy problems with difficult solutions proves you aren't qualified to take on the problems that need those solutions. How do we establish this as a standard belief in software engineering as well?

fractionalhare 6y ago
A lot of what you describe is attributable to resume-driven development, in my opinion. Complex solutions are used to insinuate that the engineers who implemented them are solving complex problems. This in turn improves their marketability by insinuating they've got the razzle dazzle and trendiness under their belt that justifies $500k a year. Sometimes it's also not resume-driven development, at least not intentionally. Sometimes it's because the engineers just want to work on overcomplicated shit. For example I have my personal blog running on half a dozen AWS features - S3, Athena, Cloudfront, Cloudwatch, Lambda, SNS, SES, ... I don't need any of that for a simple blog, and I write on it like once a year. And the site is still slow as shit (relatively) even though it's static because I haven't optimized the font and script loads to be non-blocking. But it was fun to set up!

jfoutz 6y ago

this is a funny and thought provoking article. There's a bit of texture that I feel is missing, and I feel personally attacked, so I'm going to throw up a weak defense of category theory web servers. Back in the day, in perl I'd bless regexes and use AUTOLOAD to provide the class implementations at runtime, as any good unicycle rider would. Changing the Rube Goldberg machine is hard. grep won't really help. I'd resort to even dirtier tricks to change behavior. Later I worked in java. grep would work, but even better, I could make a class private, create an interface and just chase compiler errors. So much nicer than hunting down the right line of code to hijack in perl. It's pretty good, and I think go provides a similar level of support, but there's still a bunch of room for Class.forName(foo); //haha! grep will never find me! and it's cool, cause you'll only find out about it at runtime. Anyway Haskell is neat because you can throw it all in a do in IO. hack away for days. When it's time to change, just change it. the compiler will help. The compiler will tell you everything you need to know to scope down to the finest level you want. It's super easy to be way too fancy up front, but any mistakes can be fixed. Anyway, Haskell is probably never the right choice but it's the only thing I know of that lets you easily change the design whenever you feel like it. It's Saturday, and I've thought about this too much. Time to put on my silver pants and go unicycling.

SkyMarshal 6y ago

Tools should be chosen to match the use case. Haskell is a good choice when you've got: 1) a problem that requires a very high-assurance system with very low tolerance for bugs, errors, and failures, and 2) a large complex system where refactoring and other maintenance-over-time activities are made materially more manageable by Haskell's strong type system and other tools, 3) a need for large-scale parallelization that a purely functional language like Haskell facilitates, and 4) a world class team of engineers who can become productive in it relatively quickly, support new hires doing so too, and won't foreseeably be outsourced to some low cost overseas sweat shop. Rust is also worth considering under those criteria, in addition to embedded systems, hard/soft real-time or constant-time systems, etc. But obviously not all software projects have all those criteria. Other languages like Go, Python, Javascript, Java-ecosystem, .Net, etc may be ideal in other circumstances. You just have to match the tools for the job.

paulryanrogers 6y ago
Article seems to be implying at a big company you probably can't have #4 and may not even need #1.

barnacled 6y ago

One thing I've noticed in my career is that those who possess a certain kind of 'wow' factor are the ones who are categorised as the 'stars' and thus progress quickly through the technical ranks. I've tended to find that these people don't write particularly good code (not usually bad, just mediocre) and tend to lack ability in software engineering - writing deeply unrobust code that falls far short of their perceived 'rockstar' qualities. I can't tell you the number of conversations I've had with managers or even colleagues where their untouchable genius is extolled to the heavens. Combine this with the fact that those who raise issues and foresee problems are often viewed poorly (possibly even MORE so if those problems actually end up happening). Ultimately you end up with a situation where those who advocate for solid engineering are, while respected, never really raised above the low levels of the career ladder and those who embrace woo rise up.

throwanem 6y ago

> I’m imagining the archetypical unicycle-juggler buying a shop full of solid printers and weird CNC machines and forgetting to buy cutters, hacksaws, files and machinist squares. In 2020 we call this a "makerspace".

pnathan 6y ago

It depends. What are you doing? What are the constraints? What is the problem? Do you need innovation? Do you need plumbing? Can you lift your eyes and see the value in a radically new way? Does it look like what you are already doing, or does a beginner's mind really suggest a new approach? The author sounds like a crabby old guy who doesn't want to change. Probably an artifact of the topic. But it *is* a real problem- people get locked into fancy-chasing. This introduces risk into the project delivery: team based (knowledge) and tech (not adequately debugged). I've worked at length in "fancy" languages and some of the fancy tech. My conclusion is you have a limited amount of investment you can do. Some of this is team based (language learning, keeping the employees happy), some is in product, some is in tech stack (FlashyFancypants DB and SparklePants.JS). Good tech leadership includes picking out what to take risks on, judging appropriate ROI. Note this holds true for open source, not just business projects! I work in a Clojure shop, so I interact with the rewards and risks of this strategy right now. My last team/company, we chose Go for the team language. It wasn't as unilaterally good as some might hope. Nor was it as unilaterally as bad! It was just another language.

closeparen 6y ago

The “just solve the problem” attitude also gets used as an excuse to ship the worst code that can get through user acceptance testing. The worst bridge that can stand up to the load is good, cost efficient engineering. The worst code is not. One, because bad code hides bugs that you probably don’t have rigorous enough testing to find. Two, because there will be new demands on that code in the future, and bad code is harder and riskier to change. You might look like a responsible adult when you ship it today, but three years later the new maintainers will know you were a child making a mess. And probably end up doing a rewrite, or at least needing to. All this “woo” with languages and frameworks and services and whatever else, is the search for higher quality code. There is a certain myopia about new things vs. getting better at design with old things. There is a certain blindness to iterative improvement, e.g. Rust is much sexier than modern C++ as a solution to the problems of C++98. But rather than condescending to this you can channel the energy into more responsible directions. I work in a team where many people have zero aesthetic sensibility about code. Not like “I know this is ugly but we have to get it done today” or “I know this is ugly but it’s the best we could come up with,” just zero sense that it’s ugly. Grass is not greener.

peterkos 6y ago
Trying to explain that code is more than "well, it works!" is especially hard. Maybe its just the part of programming that's more an art than a science?
- beaconstudios 6y ago
  programming is a systems science - it is qualitative and constraint-based, not metric-based. It's an optimisation problem where you have to optimise for multiple concerns - maintainability, extensibility, scope, testability, and so on. Overengineering in a way that doesn't help any of these is falling at the first hurdle.

ilovefood 6y ago

This was a fascinating and funny read. What a great writing style and strong opinion. I had to agree with most of it!

jodrellblank 6y ago

20% content, 80% sneering and self-pleasuring about inferior other people. It's not that solid trustable systems don't exist, or are a bad idea, or chasing the new-shiny doesn't happen, but they're not really what the post is about. > underpaid compensated in self esteem [..] manager saying “dude yer so fookin smart” [...] brainlet payment system. [..] benefit to boring languages is people concentrate on the problem not interesting complexities of tool Missing the point raised earlier: "the problem" being solved is that work is boring; Woo isn't added "for its own sake", it's added because being an interchangable cog in a relentless productivity optimization machine isn't what humans exist for, no matter how much employers and the author would like that to be so. > people who feel like every line of code has to be innovative Employees don't get paid or promoted for saying "this is good enough, let's take 18 months off", but they do for adding a new widget or showing off to the boss. Broken incentives lead to people following them. > like bike-shedding, but more perverse It's pleasure! Spit! Disgusting, sinful and shameful, and the people who enjoy it are inferior. Get back to the grindstone! > you are presumably solving real world problems which someone pays for "Impress my manager", "buy some food", "survive this stupid doomed project nobody wants that doesn't have the political backing or funding to get to its impossible goals" are problems people solve for money. Jobs where people solve real world problems seem a small subset of jobs. > about as necessary and in demand as riding to work in silver pants on a unicycle The way someone commutes to work has so little to do with anything that it's a big reinforcement this is about image, not engineering. > developers [..] are often child-like in their enthusiasm for new and shiny things Everyone knows that companies are at their best when petrified, stagnant, resistant to change and unwilling to entertain new ideas, right? > Engineers are different: they’re trying to solve a problem No-true-Scotsman so that "Engineer" now means person who tries to solve a problem (only using existing tools and techniques), and people titled or qualified as "engineer" who aren't trying to solve problems, or anyone who is trying use a new approach to solve a problem or doesn't have the same constraints and goals are "not real engineers". > Engineers understand it’s OK to solve the problem with ephemeral, trashy, but fast-to-market solutions Nothing the world loves more than falling bridges, burning skyscrapers. A moment ago the important thing was to build stable, long-term, easily maintained systems with boring technologies (a classic description of "engineering"). Now Engineers are building ephemeral trashy minimal viable products? Is trashy and ephemeral "engineering" now? (No, the point is who to mock and shame, and who is superior). > if the product manager is going to change it all next week Could be related to why the idiot in the clown shoes is enjoying building it in Haskell, knowing that it won't need to be long-term maintainable because it doesn't matter anyway. No, it must be because they're inferior to the blog post author, who is all about solving real world problems like making sure software engineers know their status is beneath him. > Engineers also plan for the future [..] critical infrastructure that lives [..] depend on Engineers do the right thing in the right circumstances, and you can tell they are engineers post-hoc when it worked? Handwave away any critical infrastructure which failed as "not built by engineers", e.g. Boeing must have put no engineers on the Maxxx, you can tell because it killed people. > Consider a previous era; motors for small fishing boats. [...] So the motors of the early days were extremely reliable. Consider survivorship bias, the unknown number of fishing boats with more complex motors that worked just fine, the unknown number with simple engines that were unreliable and unfixable out on the water. Pointing out that some simple reliable engines exist does not show that "motors of the early days were reliable". > Such engines are useful enough they remain in use to this day Maybe simpler engines are simply cheaper and the lack of emissions regulations or any performance or luxury equivalent of a Ferrari commercial fishing boat hasn't caused much engine change over time? Complex systems can be useful enough that they remain in use to this day, too. > this design still sold by the Sabb company in Norway [..] they’re definitely more reliable where it counts More reliable than what, exactly? Are there competitors making complex and unreliable fishing boat motors that leave people stranded and dying, have been making them for 70 years and nobody notices and they still have customers? No, the alternative is a strawman sneer comparison, a solar powered Sterling engine. Point to a commercial fishing company run by a unicycling strawman using solar powered Sterling engines and then going bankrupt? Anyone? > in the engine room, you are filled with confidence[..] If you find some jackass on a unicycle, maybe not so much. And you should judge by how they appear, and not by their track record or by talking to them, since this whole blog post is entirely about who is high status and respectable and who is inferior by image and not really about whether you get home from your fishing trip. [cont]

deleted 6y ago

[deleted]

1vuio0pswjnm7 6y ago

He kinda rags on Haskell. I am wondering what people on HN think of pandoc, a Haskell project by someone outside the software industry for converting to/from .docx and other formats. I like it because it can be used as a single binary. Is there some other preferred way amongst so-called "software engineers" to do the sort of conversions pandoc does. Python libraries, maybe?

earthboundkid 6y ago
Pandoc is fine, but it is literally the most popular OSS Haskell project, and it’s a super obscure document converter. The most popular OSS projects in Go are Docker and Kubernetes (maybe a strike against Go? Lol) and Rust has this thing called “Firefox”. Haskell has been around for twenty years and by any objective measure has made almost no direct impact on OSS. It’s a thing programmers do for fun on the weekend instead of Sudoku. It had some influence on Rust and Swift, but all of the software written in Haskell could disappear tomorrow and no one would notice.
- illegalsmile 6y ago
  any modern functional programming feature was inspired by haskell, if it didn't invent it it sure proved its usefulness.
- nineteen999 6y ago
  > Rust has this thing called “Firefox” Less than 10% of it: https://4e6.github.io/firefox-lang-stats/ https://4e6.github.io/firefox-lang-stats/ Also there were several Rust developers laid off from Mozilla a few months back, including the Servo team: https://www.reddit.com/r/rust/comments/i7stjy/how_do_mozilla_layoffs_affect_ https://www.reddit.com/r/rust/comments/i7stjy/how_do_mozilla...
  - earthboundkid 6y ago
    Yes, and? The point is that Firefox substantially depends on Rust and is the most prominent OSS Rust project. People would notice if FF went away one day. No one would notice if pandoc disappeared until they got some weird files they needed to convert.

zumu 6y ago

This article would make a lot more sense if it was criticizing something more prevalent (e.g. JavaScript library churn, etc.) Point taken, but I see no reason to straw man Haskell and Rust. They have their uses and new successful features they explore get ported back into the boring languages. This is how technological development works. For a non-programming example, anti-lock brakes were used in Concorde jets before they were used in automobiles. Also, one must consider that Java was a 'shiny' language once. Honestly, if OP knows of many companies that are picking Haskell or Rust over the likes Java or Golang, please post links. I'll happily apply.

ncmncm 6y ago
I was there. Java was never a shiny language. It was many things. It was, most particularly, a ticket out of the world of the Microsoft sharecropper, needing to learn a whole new Microsoft Framework every second year, and discovering over again each time all the shit that didn't work, that couldn't be made to do what it was for, and cobbled-together ways to get around it instead. I managed to never need to code on Microsoft until a bit around 2010, so missed the appeal. I was amazed to discover that, even in 2010, nobody who had coded for MS their whole lives knew any better than I did how to get an MS OS to do any sensible thing. I would ask, and they would start rooting, trying random things until something seemed to work. The idea of a documented, stable, standard library component that actually did what it said without crashing was an absolute revelation, but the opposite of every shiny thing imposed on them before.

demifiend 6y ago

This reads like a paraphrase of David Graeber's "On the Phenomenon of Bullshit Jobs" but with chan-speak loan words like 'brainlet' mixed in for flavor. Is the author trying to suggest that software development is a skilled trade but that most jobs in the trade are bullshit jobs best outsourced to Elbonia?

hrishi 6y ago

"really cool lisp macros for ad servers" hits hard, in a place I didn't know I could be hit.