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!"
Don't have time now to find links of Jonathan Blow, George Hotz, Casey Muratori, and many other decidedly non-junior programmers complaining about the absurd, unnecessary complexity of modern software development.
The people who complain are the people who know how much simpler it can be.
Now, there is a separate phenomenon of green devs who think they can rebuild X only because they can't fathom the bulk beneath the iceberg's tip. That is real too. But it takes nothing away from the very real fact that the vast majority of software written today is much, much more complex than it needs to be.
I just listened to George speak to Lex. He talked about the engineering time they spend in tinygrad to make it simpler. A lot of hours goes in to refactoring to make it as simple as it is. Writing simple software for complex problems takes a lot of work.
The path of least resistance at every step is definitely more complexity, so that’s what happens. Fighting complexity has to be actively prioritized.
Try to discuss this with people and it’s endless hand waving about resume driven development or not enough time or devs aren’t good enough or nobody really writes good software.
> 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.
> An architect’s first work is apt to be spare and clean. He knows he doesn’t know what he’s doing, so he does it carefully and with great restraint. As he designs the first work, frill after frill and embellishment after embellishment occur to him. These get stored away to be used “next time.”
> Sooner or later the first system is finished, and the architect, with firm confidence and a demonstrated mastery of that class of systems, is ready to build a second system. This second is the most dangerous system a man ever designs. When he does his third and later ones, his prior experiences will confirm each other as to the general characteristics of such systems, and their differences will identify those parts of his experience that are particular and not generalizable. The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one. The result, as Ovid says, is a "big pile."
Yes. My “worst” code was when I was mid-level. Too clever, showing off what I learned.
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.
> My “worst” code was when I was mid-level. Too clever, showing off what I learned.
This was my experience as well, for pretty much the same reason. At some point, I gained enough experience that I no longer cared about impressing anyone or showing off, and my code became substantially better.
In my experience, it's always the junior who shouts "This could all be so much simpler!".
Vis-a-vis the conversation that has ensued from this statement, I'll offer the suggestion that the real seniors are the ones who don't make blanket statements one way or the other, and appreciate the distinction between incidental complexity and intrinsic complexity. Some times, the problem itself is simply complex and requires a complex solution. One should not rush to eschew complexity in those cases. Other times, the complexity is incidental and is brought in by the choices of the developers. In (many|most|all|??) of those cases, we should try hard to avoid that complexity.
In my experience, juniors almost never shout that. They are still living within the managed "website in 0 lines of code!" world the framework purports to provide.
And mids just think that's what the job is and nothing to do about it. It's not 1985 any more and 1985s tools aren't enough to write a cloud db backed ios app.
It's the seniors, and the good ones at all levels even if they aren't good at it yet, who object to complexity on a pure lack of elegance basis. They value elegant solutions and complexity is usually the ugly brute force solution that's merely complex when it's claiming to be sophisticated.
Even if they don't have any idea what to do differently, they just know that something surely can't be sensible just on the face of it. I would hope everyone at least gets the ancient "hello world by different levels of programmer" joke, and can see when it starts happening for real around them.
> It's the seniors, and the good ones at all levels even if they aren't good at it yet, who object to complexity on a pure lack of elegance basis.
I actually think the opposite of that. Experienced programmers, from my observations, have learned that complexity is an inevitability that requires management (all nontrivial programming is really an exercise in complexity management, after all). They resist adding complexity unnecessarily, but also recognize where it can't be avoided and opt for managing it instead.
In the real world, "elegance" is an unattainable ideal that is to be admired and desired, but experienced devs recognize that pushing too hard for it will result in the exact opposite of it.
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.
> In my experience, it's always the junior who shouts "This could all be so much simpler!".
Yeah, this is true. But I often wonder how much of this is because the seniors have given up on simplicity and since they have internalized the complexity it doesn't bother them anymore.
> Yeah, this is true. But I often wonder how much of this is because the seniors have given up on simplicity and since they have internalized the complexity it doesn't bother them anymore.
I've seen this first-hand. It makes for a bad experience and a demoralized, ineffective team.
As a senior my goal is to write that really complex stuff and then hide it behind a simple interface that always works the way you expect so you never have to look under the hood.
Essential complexity is exactly that. The entire game is to separate it from the accidental complexity. My career/life was revolutionized by a paper that is 100% focused on this very topic:
The solution to eliminating accidental complexity is ultimately presented as a flavor of relational model, which I simply read as "please just use SQL for most things". This perspective has served me exceptionally well over the last ~4 years now.
A quote I like from Chapter 8:
> The relational model [Cod70] has — despite its origins — nothing intrinsically to
do with databases. Rather it is an elegant approach to structuring data, a means for manipulating such data, and a mechanism for maintaining integrity and consistency of state. These features are applicable to state and data in any context.
Chapter 9 offers an actual proposed solution - Functional Relational Programming.
At the end of the day, suffering in a cesspit of complexity is a choice. The relational model is the answer for untangling highly-complex (aka high-dimensional) problem domains, especially ones that require arbitrary downstream views of the data. The central piece of magic with the relational model (as applied to the real world) is the query planner. You should start thinking of this as an actual code-writing super AI that can answer optimization questions 1000x faster than your best developers. All you have to do is give it a tiny pile of hints to work with, and almost any arbitrary request will be satisfied in a nearly-ideal amount of time.
For others: this is the classic Out of the Tar Pit paper, which I also adore so so much. It promotes very explicit state management and functional programming to reduce accidental complexity.
our friend ChatGPT summarizes the paper thus:
"In summary, "Out of the Tar Pit" argues for a shift in software design principles, advocating for the reduction of accidental complexity through functional programming and dataflow concepts, proper state management, and the use of formal methods. By focusing on these principles, the authors believe that software systems can be made simpler, more robust, and easier to understand and maintain."
In my experience, it's always the junior who shouts "This could all be so much simpler!".