I couldn't find the source on GitHub, but somebody has helpfully scraped them a few hours ago: https://github.com/pascalandy/dotfiles/blob/main/docs/refere...
Laws of Software Engineering
541–550 of 554 posts
Re: Laws of Software Engineering
#542Earlier quoted context omitted.
Maybe I'm wrong but I suspect this might be partly due to the rise of Docker which makes attaching a debugger/profiler harder but also partly due to the existence of products like NewRelic which are like a hands-off version of a debugger and profiler. I haven't used a debugger much at work for years because it's all Docker (I know it's possible but lots of hoops to jump through, plus my current job has everything in…
On the other hand, I had to debug a PHP app in Docker using XDebug and it was mostly painless. Or, to be more precise, no more painful than debugging it on local Wamp/Xampp.
Oh I know it's doable - I remember a two people that I used to work with individually getting it working. Most people didn't seem to want to bother though.
Re: Laws of Software Engineering
#543> Premature optimization is the root of all evil. There are few principle of software engineering that I hate more than this one, though SOLID is close. It is important to understand that it is from a 1974 paper, computing was very different back then, and so was the idea of optimization. Back then, optimizing meant writing assembly code and counting cycles. It is still done today in very specific applications, but t…
The most misunderstood statement in all of programming by a wide margin. I really encourage people to read the Donald Knuth essay that features this sentiment. Pro tip: You can skip to the very end of the article to get to this sentiment without losing context. Here ya go: https://dl.acm.org/doi/10.1145/356635.356640 Basically, don't spend unnecessary effort increasing performance in an unmeasured way before its nece…
DRY might be even more misunderstood. We all parrot it to mean don’t duplicate code, forgoing the part where domain and function need to be taken into account.
Re: Laws of Software Engineering
#544Earlier quoted context omitted.
Incidents happen in the meat world too. Engineers follow established standards to prevent them to the best of their ability. If they don't, they are prosecuted. Nobody has ever suggested putting people in jail for Russia using magic to get access to your emails. However, in the real world, there is no magic. The other party "outmatches" you by exploiting typical flaws in software and hardware, or, far more often, in…
We already have similar legal measures in software for following standards. These match very directly to engineering standards in things like construction and architecture. These are clearly understood, ex SOC 2, PCI DSS, GDPR, CCPA, NIST standards, ISO 27001, FISMA... etc... Delve is an example (LITERALLY RIGHT NOW!) of these laws being applied. What we don't do in engineering is hold the engineer responsible when R…
This is simply incorrect. Engineers can in fact be held responsible for negligence if insecure engineering results in damage from a terrorist attack that could've plausibly been prevented.
Re: Laws of Software Engineering
#545Earlier quoted context omitted.
Like everything else there's nuance and a range of appropriate behaviors. It's probably worth spending some time beforehand designing the next mars rover's software but it's real easy to get, say, the design of an ai based program editor wrong if you aren't getting user feedback.
Getting feedback from users for a product is important as well. Those are somewhat orthogonal concepts. I'm not proposing analysis paralysis or no prototyping but I am saying there are some things that if you didn't consider in advance can become huge issues down the road. There are examples (e.g. Facebook or the Google crawler) where very successful products started with something not great and then were able to fix…
I mean, sure, but this becomes kinda circular, "do some planning" "how much?" "the right amount", etc.
I don't think anyone is arguing for zero planning but in terms of very general rules we can talk about on blogs and such, I would definitely advise people to "do more and think less" to paraphrase an old prussian general.
I would say overplanning is a much more common problem but the issues it causes tend to be much less noticeable than the occasional really exciting under planned project.
Re: Laws of Software Engineering
#546[dead]
Re: Laws of Software Engineering
#547For anyone reading this. Learn software engineering from people that do software engineering. Just read textbooks which are written by people that actually do things
Any recommendations? I read designing data intensive applications(DDIA) which was really good. But it is by Martin Klepmann who as I understand is an academic. Reading PEPs is also nice as it allows one to understand the motivations and "Why should I care" about feature X.
fwiw, Kleppmann sold his start up to LinkedIn and worked there on Kafka before writing DDIA!
Marianne Bellotti's Kill It with Fire is a quick but good read
Re: Laws of Software Engineering
#548Earlier quoted context omitted.
Spent 6 months last year ripping out an abstraction layer that made every request 40ms slower. We profiled, found the hot path, couldn't fix it without a rewrite. The "optimize later" school never tells you later sometimes means never
I'd say it usually means "never". I also find it a bit annoying is that most people just make shit up about stuff that is "faster". Instead of measuring and/or looking at the compiled bytecode/assembly, people just repeat tribal knowledge about stuff that is "faster" with no justification. I find that this is common amongst senior-level people at BigCos especially. When I was working in .NET land, someone kept tellin…
You don't need proof or measurement if it's a question of time complexity. The time complexity covers that.
And if you aren't optimizing for time complexity, then it's probably an over-optimization. Even if switch was faster, how much are we gaining here? A microsecond?
But, I've had instances where I've turned reports from minutes to milliseconds because of some shit SQL or doing something crazy in a loop. That's the optimization that matters, IMO.
Re: Laws of Software Engineering
#549Earlier quoted context omitted.
In my career I've seen endless examples of hopelessly badly designed software where no amount of optimization can turn it into anything other than a piece of garbage. Slow, bloated and inefficient. Ascertain an issue is too late for bad software. The technical term is polishing a turd. Not that what you're describing doesn't happen, people trying to make something irrelevant fast, but that's not the big problem we fa…
Hurray, bad software is bad, we did it! Just don't write bad code!
[deleted]
Re: Laws of Software Engineering
#550Check this out! https://github.com/theElandor/lose_law