Hacker News Reader

I read a great article a while ago (can't remember where) when they tasked some embedded guys with building a somewhat complex front end app.

When it was done, there were no bugs. Not a single issue. They asked the embedded guys how they had accomplished it. They said "we didn't know bugs were allowed".

Many people have never authored or even been involved with a high quality piece of software, so they just don't know what it looks like, or why you'd want it.

You'd think that someone in the exec team would have some personal pride and ownership in the code and would want to flush out bugs and improve quality. But nah.

This nails so much of my frustration with software development at the moment.

The requests to my team are:

build what product says

close out 90% of the defects you find by priority order

deliver in the priority of feature > security > accessibility

once delivered move on to something else we only have time to work for 3 months on an initiative before we move on

These requirements don't end up with a well working product. They end up with gaps in product, defects that are obvious, non-accessible site. Things take time to polish and be made right, but that's not what is requested. Wanting to iterate and measure isn't important because its not more features.

One would think that machines and automation would be the perfect thing to catch bugs.

We already do that on many levels -- compilers, linters, pre-commit hooks etc. Well, AI can just red-team and create new tests. The great thing about red-teaming vs blue teaming is that false positive and hallucinations don't hurt the final product. So you can let it go wild.

I mean they don't care about bugs because it doesn't affect sales or bottom line..

Everyone is used to terribly software with awful security holes and performance so why rock the boat?

It's not like average normies will complain.. after all, they are probably used to swimming in an ocean of ads, telemetry and junk. Investors will cut the execs a check regardless, the only thing that matters is piling on more features and growing.

There are _zero_ consequences for writing bad software.

Honestly, firmware is usually where we find the worse kind of bugs.

The trick is to automate for your own benefit and keep quiet. Automate your 8hr/day job down to as low as possible, and use the free time for entertainment or another job (where you ideally do the same).

The reward for good work is more work. If they company wanted to pay you more, they would've already done so. If the company wanted automation, they would put that as a job description and pay accordingly (or more likely outsource it and get a shitty result for 10x the price - despite never willing to pay you anywhere close to that even if you were to give them the fully working solution).

This is just the reality of scaling. Largely but not necessarily automation. Think of customer service now compared to early 2000s. Thats not really a story of automation. Instead, it's a story of 1) outsourcing 2) a bit of legitimate self service options (automation) and 3) abandonment - they simply stopped supporting at a good level. Quality is much worse but throughput is much higher - a necessary evil to scale.

AI actually has some ability to improve things. At least when I think about manufacturing and farming. When you produced at such a massive scale you could never individually inspect every potato, widget, or target every weed etc. You could produce WAAAY more but more bad products went out the door. But now you can inspect every individual thing. May not extend to every industry though.

I have a friend who automated his entire days work down to the click of a single button. He did not tell management because they were pretty scummy. He got written up for not "looking busy" despite his output being higher than his coworkers.

Business is stupid. They value busy-ness over productivity.

> He got written up for not "looking busy" despite his output being higher than his coworkers.

Also my experience with that first job. I would get the work done quicker than others, and leave around 5pm (most stayed beyond 6pm).

The message was clear: "There's always work to do. If you're getting work done early, you need to do more!"

I got worse ratings than people who achieved less. It also explains why coworkers refused to learn how to automate things.

Again: I automate to make my life easier. If it isn't working, I shouldn't do it.

> Business is stupid. They value busy-ness over productivity.

Not stupid, just entitled to all of your innovation and productivity while you're on the clock (if waged) and off the clock (if you're salaried). If you've shown yourself to be an outlier - that's great for the business - and congratulations, you've aet yourself a new baseline. Isn't class economics just delightful[1]?

The only employees who have a more direct linkage between productivity and income are sales folk, and it's boom or bust there. If you're an engineer that somehow doubles your employers profits, don't dream they'll double your salary, a once-off bonus is the best you can hope for, at the next evaluation cycle.

1. From each, according to his ability. To each, according to "market" rates, and his negotiation skills.

But that is stupid. If they incentive innovation and productivity gains they could do more business. They don't have to give you the full value of your improvements to incentivise you.

I guess it is right there in the name, isn't it?