Hacker News Reader

Spot on about reading a random blog or article. I think many engineers at work are under pressure to deliver, and are looking for quick solutions. They do a search and see a Medium post related to their problem written by someone who says they are an “<platform> developer at <company>”, and for some reason most readers see these authors as an authority in their domain (because why else would they be writing about it? /s), and just accept the blog post’s practices or conclusions. Once read an article a long time ago about Android’s async task , and some blog post claimed it should only be used for operations less than one second. I looked at the official documentation and while it did mention that it should be used for short operations, no where did it mention it should be less than one second specifically (unless I missed it). I saw the same advice mentioned by many other devs who referenced that same article.

To add on to this, the current most preached about "best practices" comes largely from a de-risking, never-ever fail point of view, ie. 'safety'. Unfortunately with such standards also comes a concept known as 'acccountability', ie. 'ass-covering' practices that provide little practical value.

This results in programmers no longer being able to iterate fast and having to rely on some third-party whose tradeoffs they don't understand, resulting in slow, bloated software and dissatisfied programmers.

I am not sure if I read you right here (correct me if I am wrong), but do you say that safety and stability concerns lead to bloated software because devs cannot blindly trust third party dependecies?

Because if so, yeah. You are responsible for the software you write and the dependecies you use. Software engineering is one of the least responsible engineering diciplines anyways. I am e.g. also a certified electrical engineer and of course I am responsible if my wrong decisions kill someone. If I would use a cheap chinese knockoff circuit breaker (because we can iterate faster if the stuff isn't expensive and certified) and someone gets killed, I go to jail. If someone gets killed and I can proof that I followed the currently agreed on state of technology my ass is covered. Of course you can get a lightbulb to light up without following any rule (and maybe this would be more efficient), but in EE the existing rules came as a consequence of deaths and rhe prevention of those is worth it.

In software engineering the worst that can usually happen (unless you work in IOT or industrial applications) is that you loose your user data. Many software devs don't care about whether they loose their users data and there are no tangible consequences. "Oh it was a software error" is still a good excuse, as if there was nothing which could have prevented that software error. I program software myself but I am al for stricter consequences in our profession because it would straighten out some heads who think this is all just fun and games for their personal joy.

IMO, much of the low engineering standards in software is from a (potentially false) awareness in the industry that most products we work on simply aren't that valuable. If a bug deletes my Twitter account, that sucks to me be for a day but no real harm was done. The people who work in banking or healthcare IT tend to know better and have correspondingly higher (though still shockingly low) standards.

Haha. The banks ought to know better, but in fact due to software being hard to prove correct, we still get major disasters like the TSB migration failure. It caused real world problems like peoples house purchase deals falling through and money getting lost:

https://www.theguardian.com/business/2018/jun/06/timeline-of...

The thing, is there is seemingly no appetite to try to prove correctness of even single machines systems. Let alone distributed systems. I wonder if ever there will be a time where this kind of proof is cheap enough to be acceptable to business.

Do you have any concrete examples of that? I think I kind of see what you mean, and I have a feeling that this is mostly right, but I'm not sure.

Managers excited about a new tech idea are probably the most destructive thing in the industry.

As are managers that conform to archaic tech when better options exist.

Especially when maintaining and adding to a legacy system takes more effort and risks than simply rebuilding it.

Nah, just rewrite the code base.

> I saw too many junior developers read a rando blog article, then get a non-technical / semi-technical manager excited about something that made their life easier, even though it was by no means a good practice for the context at hand.

I’ve seen the other way around too - senior developers rejecting or pushing changes that they find convenient. IME it’s not to do with experience, rather stubbornness.