Live data from Hacker News

Ask HN: Have we screwed ourselves as software engineers?

news.ycombinator.com

291–300 of 430 posts

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

#291
post #168

My advice is : work with more senior people. It seems to me that people with 10/15+ years of experience will judge this hype train more severely than younger ones. The dangerous spot is engineers with 5-10 years of xp who have become good enough at writing huge piles of unecessary code and have them work.

This is what I was going to say. I think that the great problem of our time might be unforced errors.

I've said it before, but I take issue with just about everything that's happened in tech in the last 20 years. I've been programming since I was 12, so have about 32 years of experience. I feel that things really were the very best from about 1995-1999, but since then we've mostly had uninspired and brute-force solutions endlessly doubling down on the status quo, because that's where the money is apparently.

I just see such quick embrace of things like async, which I view as an anti-pattern. We're paying people $150/hr to build out complex solutions that nontechnical people were putting together in FileMaker and Microsoft Access in the 80s and 90s. Even our hardware has endlessly pursued DSP vector processing on GPUs, forcing us to manually convert our software to shaders or something proprietary, when scalable transputers and 1000+ core systems on a chip with local memories appearing as a single context (what we might call.. desktop computing) would have been so much simpler and better. I could go on about this stuff literally forever.

What's the solution? It's so simple that it's right under our noses: make the opposite decisions from the ones we have been making. Old school. Practice radical inclusion and hire people immediately based on their credentials and experience, rather than putting them through endless interview rounds. Bootstrap, and when you make it, pay it forward and help others make it. Get away from all this insubstantial profit-oriented disruption stuff and solve the actual problems in people's lives like how to reduce their dependency on handouts from the rich under trickle-down economics. We need automated food/clothing/shelter that's too cheap to meter, and we need it yesterday.

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

#292

The way I look at it is: there are more tools in the toolbox than ever before. Which makes our judgement (the thing they really pay us for) even more important. Kubernetes, for example, is a specific solution to a specific problem. The solution is complex but so is the problem. If k8s give you the right trade-offs for your situation, then it’s not busy work. Of course, there are plenty of project where judgement Is t…

I call it Resume Driven Development

I worked with someone who did this. I'm glad he has moved on. He would not do basic tasks correctly. Had an attention span of a toddler. He was DBA and couldn't google simple problems. I asked him to do something he would say give me 20 minutes. 2 weeks later he would say "IT CANT BE DONE". Then, I would do it myself in a few minutes after googling the error.

Instead of applying knowledge, he would bring up all these buzzwords to meetings and not really understand what he was talking about. I get angry just thinking about it.

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

#294

Still, part of the industry is moving towards simple solutions. A refreshing experience was a mobile app Apple device, with Swift and Swift UI. It was a real joy, works as expected, produces concise code, small files, live preview and reasonably fast build time. Sure, it's closed environment, but last time I felt so productive doing UI dates back to Visual Basic. Counter-example: a simple web app, nothing fancy, and…

> Sure, it's closed environment, but last time I felt so productive doing UI dates back to Visual Basic.

The "closed" nature seems to have made such IDE's better integrated such that you didn't need "layer specialists" for each layer: you just "did it".

And the rocket science needed to get "responsive" UI's right is crazy. If only 3% use an app on a mobile device, you bloated your UI by a complexity factor of about 10x to get that extra 3%. The labor math doesn't support it. Vulcan accountants are puking. (And mobile friendly apps tend to waste screen real-estate, increasing scrolling and back-and-forth navigating. GUI multi-panels are a productivity miracle, use 'em!)

WYSIWYG is cheap, easy, and consistent; you can save a lot by telling responsive to go to Bloat Hell. (Maybe someday a responsive UI framework will make it easy, but that will probably arrive with flying cars, hover-boards and Mr. Fusion.)

Being obsessed with "web scale" when most biz apps have only a few thousand users is also a resource drain. Stop putting phallic symbols into your stack, people! A dinky winky is sufficient for 95% of apps.

Choice of sub-parts by itself is good, but if it has a psychological side-effect of creating a layered mess, then perhaps a KISS Bouncer of some kind is needed to trim and factor the options. Otherwise, "cool" ends up trumping boring-but-productive. (I have more to say about his elsewhere around here.)

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

#296

Earlier quoted context omitted.

> 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. The problem with deploying PHP is that it immediately gives you something for very little effort, but the effort scales incredibly disproportionately once you outgrow your need for the bare functioning minimum. I personally prefer the "modern" approach of dropping a s…

Oh I agree, I still get chills when I think about troubleshooting PHP. I was really just making the point that the effort to deploy python as a webapp these days would have been considered overly complex to the average developer 15 years ago. Just how some of the current stuff seems to the OP, so maybe not all seemingly complex stuff is bad.

This is why you shouldn't run Python in your downloads directory:

    python3 -m http.server 8000
Concepts of "app" have changed and superstitious ritual has built up around the sacrament of deployment.

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

#297

The new data tools I've seen are complex under the hood, but offer elegant user experiences, giving the best of both worlds. You referenced a 500 line Python script being refactored with Rust and make me think of the Polars project: https://github.com/pola-rs/polars Polars uses Rust to make DataFrame operations lightning fast. But you don't need to use Rust to use Polars. Just use the Polars Python API and you have a…

Or you just replace Python with Nim and get the performance of Rust.

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

#298
post #168

My advice is : work with more senior people. It seems to me that people with 10/15+ years of experience will judge this hype train more severely than younger ones. The dangerous spot is engineers with 5-10 years of xp who have become good enough at writing huge piles of unecessary code and have them work.

> judge this hype train more severely than younger ones.

Meanwhile the EM's are afraid to hire us because we're "tired" and not "team players" (ie have a back bone when we've seen this pattern 20x across our career with 0 successful outcomes)

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

#299
post #296

Earlier quoted context omitted.

Oh I agree, I still get chills when I think about troubleshooting PHP. I was really just making the point that the effort to deploy python as a webapp these days would have been considered overly complex to the average developer 15 years ago. Just how some of the current stuff seems to the OP, so maybe not all seemingly complex stuff is bad.

This is why you shouldn't run Python in your downloads directory: python3 -m http.server 8000 Concepts of "app" have changed and superstitious ritual has built up around the sacrament of deployment.

If you're running malicious code it doesn't matter which directory you're running it from.

And I hope noone is using http.server to deploy their python webapps. the documentation even has a warning right at the top

https://docs.python.org/3/library/http.server.html

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

#300

Earlier quoted context omitted.

God I am sick of these apologetics every time someone expresses skepticism. > Get it wrong another way and you end up overwhelmed by traffic, unable to scale in response and forever fighting fires. To nitpick this specifically, over my 12-year career toiling over this stuff there has never been a scenario where this has required a radical rework to solve. Boring-ass B2B shit rarely requires that level of engineering…

> God I am sick of these apologetics every time someone expresses skepticism That's a highly obnoxious response to a measured and reasonable comment.

Because it is repeating theme on these boards: someone expresses a nonconventional or old-school way of doing things, and someone else always jumps on with why overcomplicated cloud shit should be the solution to everything.

Most businesses are never going to be a Netflix or a TikTok or whatever. Yet their businesspeople are absolutely infected with this mindset. And don't get me wrong, it is a disease and its primary symptoms are exactly what OP is complaining about.

So instead of building practical, easy-to-maintain systems we cater to the dreams of excessively optimistic (can you even be anything else as management?) nontechnicals who think every idea is going to require the kind of scale and tooling that someone like Facebook has at their disposal. And they're backed up magpie engineers more fascinated with interesting than functional infrastructure.

Ironically, that very tooling and scale ends up demanding even more resources which demands even more tooling to manage. What a virtuously (hah!) profitable phenomenon for the vendors of these tools.

Good grief.

Post reply on HN