[HN Gopher] Woo for Its Own Sake
___________________________________________________________________
Woo for Its Own Sake
Author : mwcampbell
Score : 81 points
Date : 2021-01-09 15:50 UTC (7 hours ago)
(HTM) web link (scottlocklin.wordpress.com)
(TXT) w3m dump (scottlocklin.wordpress.com)
| ajkjk wrote:
| 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 wrote:
| 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 wrote:
| 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/
| carapace wrote:
| "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
| jka wrote:
| 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.
| pnathan wrote:
| 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 wrote:
| 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 wrote:
| 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?
| ilovefood wrote:
| This was a fascinating and funny read. What a great writing style
| and strong opinion. I had to agree with most of it!
| throwanem wrote:
| > 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".
| jfoutz wrote:
| 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.
| barnacled wrote:
| 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.
| dkarl wrote:
| 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?
| rdiddly wrote:
| I almost hate to say it, but the answer to your last question
| might lie in instituting the kind of standards, credentialing,
| mentorship and licensing that exist in the "real" engineering
| fields. Stuff that will correctly be called out as
| unfortunately really "hampering individual freedom" (including
| the freedom to be a jackass) and being "unnecessary" and
| "bureaucratic" and (quite intentionally and without quotation
| marks) gatekeeping.
|
| Civil engineering is sort of the oldest and ultimate example,
| where a bad design puts people's lives at risk. In deference to
| said lives, senior engineers in that field review every drawing
| or calculation that goes out the door, and they also mentor the
| junior engineers, who have to be graduates of accredited
| schools, and also can't get certified until they've spent a
| certain amount of time being mentored and passed the exams,
| etc.
|
| The mindset you're talking about is basically all about
| craftsmanship or elegance of a solution. Formal mentorship or
| apprenticeship programs do a great job of maintaining and
| transmitting that. School isn't really enough, and certain
| fields have recognized that fact.
|
| In software however, and I'm not sure whether this is the
| problem or the symptom, the number of developers apparently (I
| was told recently) doubles approximately every 5 years. Which
| means the field is always overwhelmed with new people, full of
| energy but not experience, who want to do something cool and
| exciting, but haven't been, for example, burned by their own
| past decisions to try to do something cool and exciting. They
| see only upside. Which is valuable in itself, but they need
| more direction than they're getting, from the older engineers
| who have the war stories and who aren't especially concerned
| with being cool (which c'mon let's face it, is essentially a
| mating display) and who are _boring_.
| fractionalhare wrote:
| 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!
| dkarl wrote:
| I agree about the resume-driven development aspect, and I
| think it's great to use a personal project as an outlet for
| experimentation! Too many people do stuff like that at the
| expense of unnecessary complexity in production systems.
|
| I'll grant that collectively an engineering team might decide
| to overengineer a simple, noncritical service to get
| production experience with a technology or two that they are
| targeting for future adoption. Nothing wrong with that, and
| there's nothing wrong with making room in the schedule for
| engineering experiments to test out new technologies.
|
| Managers and the rest of the business, for their part, need
| to understand the need for experimentation so it can be done
| honestly and not under the guise of other work.
| m463 wrote:
| Folks with the outside perspective often attribute some
| intent to a situation, but if they went through it, it would
| be obvious and simple.
|
| I think engineers try to do the best they can. It's just old
| guys might do it the mainframe way, slightly younger unix,
| then windows, then linux.
|
| Or folks who've been with the culture do it that way, and new
| folks from outside the company bring new college grad or
| last-company-i-worked-for culture along with them.
|
| And folks who try something new suffer from the 'fog of war'
| and your "the docker solution" that got everything started so
| well makes you a real expert in nested docker configurations
| and firewall issues. :)
| tomsmeding wrote:
| What you describe you did with your blog is, in some sense,
| resume-driven development: you probably learned stuff in the
| process, which might be useful in a future job situation.
|
| The difference is that nobody paid you for doing all that
| unnecessary stuff. Doing unnecessary things for learning is
| good, but not what a company is paying you for, usually.
| sseagull wrote:
| There is also an element of each project optimizing to its
| own minimum. If each project selects the best language, tech
| stack, hosting stack, etc, for itself, it creates an
| overarching complexity across projects.
|
| Fixing this requires lots of communication and leadership.
| Each project may need to select sub-optimal components (like
| language) for itself, but in doing so it can remove overall
| complexity.
| ChrisSD wrote:
| As you ask for simplicity, I think this can be succinctly
| summed up as a lack of engineering leadership.
|
| I know having completely independent teams is the in thing but
| there needs to be some high level design and coordination. I'm
| not even against different teams using different tools but the
| integration story has to be there from day zero if it's a
| business requirement.
|
| Ultimately there needs to be an engineer who has both the power
| and knowledge to coordinate design decisions.
| dkarl wrote:
| I agree with this 100%, and I think the people providing this
| leadership should be in management. Software engineers need
| to be managed by someone who can understand and evaluate
| their work, because of what you said and also because other
| aspects of management benefit from the ability to cast a
| critical eye over the work being done as well.
|
| EDIT: Going further, I think the people trying to hire me as
| an engineer to fix their problems should have replaced their
| front-line management with managers who understood code, so
| they had some clue what their engineers were doing wrong and
| how to fix it. The idea that engineers should be able self-
| manage is a rare best case scenario, not a best practice that
| can be replicated across the industry.
| userbinator wrote:
| _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?_
|
| My experience with things like foreign automotive components
| suggsts this is not exactly true in general... but it's true
| that monsterously complex solutions seem to be far more common
| in the software world.
| brundolf wrote:
| I think part of the difference in mentality comes from the
| difference in material constraints.
|
| If a mechanical engineer designs something that needs a ton of
| fancy moving parts, those moving parts significantly and
| directly impact their budget (I assume), because they're going
| to have to be purchased or made for each widget that gets
| manufactured. They also unavoidably impact physical properties
| of the object, like weight and dimensions.
|
| Whereas a programmer can spin out as much code as they want,
| basically without material consequence. There is no constant
| gravitational force keeping them in check, requiring them to
| justify each piece of complexity as they go. It's ethereal,
| weightless, and its disadvantages usually only surface years
| down the line.
| dkarl wrote:
| In my experience, the costs are felt immediately, because
| there is more code and more complexity. Virtually every cost
| in software development goes up when there is more code and
| more complexity. There are more bugs. It takes longer to
| diagnose and fix bugs. It takes longer to add new
| functionality. Performance is less predictable, and
| performance problems are harder to diagnose. Onboarding new
| programmers is slower. Fewer members of the team can do
| critical work on the code. Routine library upgrades are more
| likely to impact the code and take longer when they do.
|
| Code is a liability, in other words. It may not be tangible,
| but you can think of it as weight that the team has to carry
| everywhere it goes.
| brundolf wrote:
| You're totally missing my point, which is that all of those
| costs are abstract and protracted. They aren't felt as
| you're literally typing the characters; they can't be
| listed as concrete numbers in a budget. If an engineer is
| using a CAD tool and they add a part, they can see the
| space that's no longer available for other parts. Or they
| can see that the product would have to be made physically
| larger to accommodate it. There is concrete feedback to
| contend with _during_ the development process, not just a
| vague notion of future reliability.
| SkyMarshal wrote:
| 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 wrote:
| Article seems to be implying at a big company you probably
| can't have #4 and may not even need #1.
| draw_down wrote:
| 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 wrote:
| 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.
| JKCalhoun wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Less labour than driving to the store, finding the part,
| buying it, driving home, and carefully making an accurate
| cut with a hacksaw :)
| michaelcampbell wrote:
| > Home Despot
|
| So edgy.
___________________________________________________________________
(page generated 2021-01-09 23:01 UTC)