There seems to be a tendency with technical people to want to turn every problem into a _project_. To be lean/agile, it's important to resist that urge as much as possible.
Recently did some maintenance work on #turbinesFoam, and thought it would be nice if OpenFOAM followed the open–closed principle at the library level, though I suppose they don't see their primary purpose as being a library
https://t.co/YI85caT9Mp
Dealt with some buggy IoT app for our garage door opener this morning. There is no incentive for the company to maintain the software other than for a video storage subscription. In those cases, companies should be forced to release their code open source so others can fix.
Maybe AI can help come up with ideas for solutions too, by synthesizing or translating more specific solutions according to a more general pattern extracted from the requirements. Maybe it can validate them as well through simulation (read: testing in the software world).
At its core, engineering is all about coming up with possible solutions to suit some requirements, and being able to predict which ones will meet them. Toward that end, AI can be helpful with the latter, mapping previously validated solutions to requirements.
Simplicity is nice, and typically I really like that I don't have the option of driving a car all over the place. Doesn't feel like a reduction in standard of living at all--quite the contrary.
Thinking a lot about nonessential complexity lately. When it comes to life, I don't think mandatory individual car ownership (or high levels of mobility) is essential complexity, though some people do, probably because it's the status quo.
I think it's a sign that there are so many resources out there telling people how to do OOP correctly. It's a sign that OOP is very easy to do wrong, so should be used with caution.
Avoiding the need for institutional knowledge (e.g., internal frameworks) is also important in SWE teams, because we want to be able to scale the team with the least amount of onboarding possible.
As an engineer who also manages a team of engineers, this paper has had a large impact on my thinking lately: https://t.co/1i3n2WNci5
Simplicity should be pursued as a top priority: In the product, the implementation, the organizational structure.
But when it comes to software, avoid classes when possible. If the business logic (itself ideally simple) can be achieved by primitive data types and procedures, use primitive data types and procedures.
Many smart people are not lazy enough. They're happy creating and understanding complex things on complex terms because they have the capacity for it, instead of ruthlessly simplifying.