Ask HN: Have we screwed ourselves as software engineers? • Hacker News Board

Re: Ask HN: Have we screwed ourselves as software engineers?

#331

Post by xpe » Wed, May 04, 2022, 6:18 PM UTC

gfodor wrote: post #183

phkahler wrote: post #38

Earlier quoted context omitted.

>> If you believe that's all there is to those ideas, maybe you need to step away and think about them for a while. Sure, there's going to be some resume padding happening in larger orgs. But all those ideas solve real problems too. They do solve real problems. The question is whether or not they solve the problem at hand, and if they create other issues in doing so. I was re-decking a back yard bridge with a friend…

I’ve never liked this best-tool-for-the-job mental model with software engineering. A given project has multiple needs, and unlike more physical tools there is a very high marginal cost for each incremental tool you use. So there is a huge balance between many well suited tools or a few but more generalized, less fit tools. This isn’t to say there’s an obvious place where to strike the balance, but the “best tool for…

I also dislike the BTftJ (best tool for the job) cliche.

Best according to who?

Based on what priorities?

Relative to what other options?

Based on what kind of experience and expertise with the various options?

My takeaway: BTftJ must only be a starting point for dialog and discussion. Shortly therafter, it is time to get real about each of our experience and biases. Otherwise, BTftJ is a only a thin veneer.

Re: Ask HN: Have we screwed ourselves as software engineers?

#332

Post by frumper » Wed, May 04, 2022, 6:20 PM UTC

phkahler wrote: post #38

viraptor wrote: post #11

If you believe that's all there is to those ideas, maybe you need to step away and think about them for a while. Sure, there's going to be some resume padding happening in larger orgs. But all those ideas solve real problems too. I think you're just in a very negative space if you start with "Distributed systems" as something overly complicated. At some scale getting a bigger machine either doesn't make financial sen…

>> If you believe that's all there is to those ideas, maybe you need to step away and think about them for a while. Sure, there's going to be some resume padding happening in larger orgs. But all those ideas solve real problems too. They do solve real problems. The question is whether or not they solve the problem at hand, and if they create other issues in doing so. I was re-decking a back yard bridge with a friend…

I use a framing hammer to hang pictures on my wall, and I've never messed up my wall.

Re: Ask HN: Have we screwed ourselves as software engineers?

#333

Post by xpe » Wed, May 04, 2022, 6:22 PM UTC

gfodor wrote: post #183

phkahler wrote: post #38

Earlier quoted context omitted.

>> If you believe that's all there is to those ideas, maybe you need to step away and think about them for a while. Sure, there's going to be some resume padding happening in larger orgs. But all those ideas solve real problems too. They do solve real problems. The question is whether or not they solve the problem at hand, and if they create other issues in doing so. I was re-decking a back yard bridge with a friend…

I’ve never liked this best-tool-for-the-job mental model with software engineering. A given project has multiple needs, and unlike more physical tools there is a very high marginal cost for each incremental tool you use. So there is a huge balance between many well suited tools or a few but more generalized, less fit tools. This isn’t to say there’s an obvious place where to strike the balance, but the “best tool for…

Thank you for calling out BTftJ as a mental model. Recognizing the very idea of mental models is a huge step forward. Arguably, it could be used as a metric for how advanced an organization (or even society) has become.

Re: Ask HN: Have we screwed ourselves as software engineers?

#334

Post by burntoutfire » Wed, May 04, 2022, 6:24 PM UTC

AlwaysRock wrote: post #269

silisili wrote: post #245

Earlier quoted context omitted.

As someone who purposely -doesn't- work at a trendy company, it seeps in here too. People abuse us to get jobs at those trendy tech companies, basically. Understand we have a relatively small web presence with not a lot of traffic. High dollar, low volume type stuff. About 6 years ago someone decided to move all our stuff to self hosted kubernetes and microservices, because reasons. As you may imagine, he took a job…

Yeah I get it. But that is an issue with technical management making a long term decision without planning correctly. Sounds like your managers are either looking at those trendy tech jobs too (and want to have the buzz words on their resumes) or they think the trendy tech will attract candidates.

> they think the trendy tech will attract candidates.

This. Management says semi-openly that the job itself is too boring to atract solid candidates, so they at least need to make the tech stack interesting and good for CV. Working with hot stack is basically part of compensation.

Re: Ask HN: Have we screwed ourselves as software engineers?

#335

Post by javajosh » Wed, May 04, 2022, 6:25 PM UTC

md_ wrote: post #322

javajosh wrote: post #159

You are experiencing what I call "The Bisquick Problem". Bisquick is basically flour with some other stuff, like salt, premixed into it, and sold in a box in the USA. So instead of just buying flour and salt, you buy them together, which makes some things easier (like making pancakes), but it complicates literally everything else. You can't use it as flour, or as salt. With software, the problem is even greater. You…

I like the analogy, but it strikes me as missing the upside (and other potential causes of problems the author may be seeing). Bisquick is a great solution if you have only one problem. I want more solutions like Bisquick: easy to map to the problem (pancakes -> Bisquick; not pancakes -> not Bisquick), hard to fuck up, low marginal cost above the inputs. It's great! In the converse, we have lots of custom software so…

I think you're speaking to a different (but still legit) problem. The OP is asking about the nature of confusing complexity, as it might appear to a new programmer. The capital implications of making real, profitable software from interlocking systems of alchemy is indeed not a solved problem - but I would say that it's interesting point of alignment between capitalists and beginner software programmers! Everyone wants lower maintenance costs, in terms of both time and brainpower. The $500k+ FAANG superstar programmer is a byproduct of the fact that alchemy is much harder to master than chemistry.

Re: Ask HN: Have we screwed ourselves as software engineers?

#336

Post by drewcoo » Wed, May 04, 2022, 6:34 PM UTC

dec0dedab0de wrote: post #52

I generally agree, but two things I'd like to point out. If you're using python for the web you're already part of the complexity problem, atleast from the perspective of someone deploying php 15 years ago. I use python for web development, and I love it, but deploying webpages used to be copy an apache config and ftp/scp your files to some location. Now we need app servers and reverse proxies, and static files are s…

Monorepos solve the problem of cross-project "externalities" (sarcasti-quotes) like cross-project testing and CI/CD commonalities.

Re: Ask HN: Have we screwed ourselves as software engineers?

#337

Post by pydry » Wed, May 04, 2022, 6:38 PM UTC

It's true but I'd be careful what you wish for. When the industry finally does coalesce around sets of simple, solid, dependenable tools compensation takes a dive.

Re: Ask HN: Have we screwed ourselves as software engineers?

#338

Post by mdmglr » Wed, May 04, 2022, 6:49 PM UTC

> moving away from python (because its too "slow"); someone recently gave a talk in my company, how to make a 500 line python script (which heavily involves in-efficient handling of IO) go faster with Rust.

I'm pretty good about shutting those types of talks down in my own org. Usually when "slow" is mentioned you have to take the presenters word for it. Rarely do they include metrics. And if they do once we delve into the code it usually becomes obvious why something is slow. Usually "slow" comes from using bad abstractions.

Re: Ask HN: Have we screwed ourselves as software engineers?

#339

Post by phkahler » Wed, May 04, 2022, 6:49 PM UTC

frumper wrote: post #332

phkahler wrote: post #38

Earlier quoted context omitted.

>> If you believe that's all there is to those ideas, maybe you need to step away and think about them for a while. Sure, there's going to be some resume padding happening in larger orgs. But all those ideas solve real problems too. They do solve real problems. The question is whether or not they solve the problem at hand, and if they create other issues in doing so. I was re-decking a back yard bridge with a friend…

I use a framing hammer to hang pictures on my wall, and I've never messed up my wall.

Well that's because you don't drive the nail in all the way to hang a picture. Would not recommend it for molding for example - any time you want to drive the nail flush without scuffing the material around it. My bridge had plenty of cross-hatch marks around the nails when done ;-)

Re: Ask HN: Have we screwed ourselves as software engineers?

#340

Post by phkahler » Wed, May 04, 2022, 6:54 PM UTC

gfodor wrote: post #183

phkahler wrote: post #38

Earlier quoted context omitted.

>> If you believe that's all there is to those ideas, maybe you need to step away and think about them for a while. Sure, there's going to be some resume padding happening in larger orgs. But all those ideas solve real problems too. They do solve real problems. The question is whether or not they solve the problem at hand, and if they create other issues in doing so. I was re-decking a back yard bridge with a friend…

I’ve never liked this best-tool-for-the-job mental model with software engineering. A given project has multiple needs, and unlike more physical tools there is a very high marginal cost for each incremental tool you use. So there is a huge balance between many well suited tools or a few but more generalized, less fit tools. This isn’t to say there’s an obvious place where to strike the balance, but the “best tool for…

>> I’ve never liked this best-tool-for-the-job mental model with software engineering.

I don't either. As photographers say, the best camera is the one you have with you. Same thing, the best tool for the software job is the one you already have and everyone knows how to use. Why anyone would want to introduce these high-end fads to an organization without proper reasoning is beyond me.