41–50 of 407 posts
This is taking a shot at Java, and a pretty old "joke" but I've heard of this actually being a thing out in the wild: https://stevenheidel.medium.com/a-factoryfactoryfactory-in-p...
Another fun shot: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
The worst part of this kind of thing is that young carpenters honestly, really, truly, just need to learn to use a hammer. They can't even conceive of the problems that are being solved by the hammer factory, let alone the factory factory. But in the world of the factory factory factory, the apprentice carpenter (who really just wanted to drive a few nails) is now faced with trying to understand the gargantuan comple…
Everyone needs to learn to do calculus by hand before advancing to the calculator. People picking up frameworks without fundamental understanding is a shockingly common fallacy.
Earlier quoted context omitted.
> Quite possible I’m still the junior in terms of skill though. This is a very "senior" mindset.
IMO senior understands that simplicity is possible, but economically not viable for most projects. So complexity is inevitable evil. And true mastery is delivering products, keeping complexity at bay. Not spending time to pursue ideals and at the same time keeping project from felling down to unmaintainable mess.
This must be a Java joke I'm too C++ to understand. But I was actually hoping for a factory automation online game because I feel like I need to sink the next 2 - 14 days of my life into a shapez.io or mindustry or something like that...
- Everything's an object -> Let's define lots of nouns!
- Classes cannot be declared to implement interfaces after the fact -> Let's write some adapter classes!
- People get tired of writing adapter classes and notice that JVM has reflection capabilities -> Let's make a framework that generates adapter classes as needed!
- Everything's heap-allocated -> Let's avoid excess allocations by re-using objects! Which means you've got a big web of interlinked mutable thingamabobs floating around, made possible by Java's pretty-good GC.
- 'const'ness ('final'ness in Java-ese) is defined on the type, not on where it's used -> Most classes are written assuming mutability, and if you want immutability, you need to create an entirely separate type hierarchy.
I could go on.
When I want to write a Java program but keep it simple, I usually end up writing something that looks more like a C++ program. Minimal, domain-specific classes with as much setup in the constructor and as much `final` as I can get away with. But it's not as ergonomic a language for writing programs in that style as C++ is. And once a coworker brings in some library written in the conventional combinatoric-explosion-of-classes-and-pointers-to-mutable-objects-everywhere style, you're pretty much stuck with it.
Simplicity is easy to mandate: "just use simple tools!". It's not always obvious when the finished product looks wonky and slanted and has to be retrofitted several times that the complexity was always there, in the world. The complexity in our tools is hopefully there to help with some complexity in the world. In my experience, it's always the junior who shouts "This could all be so much simpler!".
> In my experience, it's always the junior who shouts "This could all be so much simpler!". Or the actual senior engineer, as opposed to the mid-level engineer with a senior title. It's the ones in the middle that really love adding in the complexity - you have to relearn how to prune it back out.
Music was my first career, and there was something that really stuck with me while studying music theory- learn as much as you can, and then don’t think about any of it when you go to compose.
I remember somebody commenting here on HN about a developer conference, where the speakers were bragging about their software being complex.
This is an awful trend with software, and is related to John Carmack's "layers of crap", Wirth's Law and developers who want to keep their job by writing code only themselves understand.
The quality of any engineering work is highly correlated to how simple and approachable it is. Unfortunately sofware developers have the unfortunate tendency to have a taste for complexity, because they feel complexity is a form of art since they view computers are complex things.
It doesn't have to be like that.
But if you were building spice racks at scale, of course you would build them in a factory! And you'd use machinery made in other factories. And those factories would have tools and machines made in yet other factories.
That's why you can go to Amazon or Wayfair or the Container Store and find 100 different spice racks for less than $30, and why nobody builds a spice rack by hand, except for fun.
Earlier quoted context omitted.
It's not a hammer subscription, it's hammering-as-a-service. You ship them the nails and wood, they ship you back the nails hammered into the wood. You don't have to worry about the complexity of storing or using a hammer anymore, let alone the difficulty of selecting the right hammer, it all just works. They charge extra to sell you the nails and wood, to avoid the complexity of packing and shipping your nails and w…
Maybe you don’t want to be a carpenter after all…
If you need to build stuff out of wood, you have three options: buy something pre-made, hire someone to build it for you, or hire a team of carpenters to build it in house. Arguably, the third option should be your last choice.
Stretching the metaphor a bit, sometimes it makes sense to hire a team of carpenters, but contract out or buy pre-built a few particular parts that are particularly difficult or complicated.
That's essentially what these SaaS products are supposed to offer. The problem is not that they exist, the problem is that it can be difficult to know when you need or don't need any particular product.