Do programmers generally enjoy some amount of complexity?

This is the cross section of high intelligence and conscientiousness. Conscientiousness is the ability to perceive and abstract the world outside yourself and intelligence accounts of quantity of variables a person many consider simultaneously.

People who are both highly intelligent and have high conscientiousness are capable of perceiving many variables simultaneously and abstract them into refined simplified solutions. People with lower intelligence and high conscientiousness are still capable of perceiving these variables but will struggle more to put them together in a meaningful way necessary to achieve a polished result. It should be noted that conscientiousness is negatively correlated to intelligence at around -0.24 - 0.27, which is a big gap that explains why some lower intelligent people are unexpectedly more capable of high quality delivery than much higher intelligent peers.

People with low conscientiousness cannot refine complex qualities into simplified output. The cost is just too high irrespective of their intelligence. The result is sloppy output that just costs less to start over every time than to refine or extend. This will appear that these people tend to preference complexity, and in a manner of speaking that isn't completely wrong. It's not so much that they prefer complexity but that they are just incapable of expending the effort to build more meaningful systems.

I absolutely hate complexity, and will work very hard to avoid it. So hard, in fact, that it can seem that my productivity is zero for long periods of time. I will think for days or rewrite the same thing several times if the code is important enough and then—sometimes—out plops some small piece of code that does the right thing.

Most people I have worked with get very impatient with me. I tend to work best with things that actually have to work all the time. I have written code that sits forgotten doing its thing for many years, while more visible contributors get kudos for solving disasters on weekends. Not bitter, of course ;)

I think it's not so much that people like complexity itself, but it's a result of punting on decisions and failure to make tradeoffs and design decisions.

Instead of writing something that does one thing and does it well, people write something that can run in four different modes, and is configurable via a yaml file, and can load plugins to change the behavior, and isn't a finished/standalone product but a "framework" that can be configured into a product...

A lot of it just comes from punting on bulletproof designs too, like some code that works 99% of the time, but every now and then it fails due to some problem like a race condition or a deadlock. So... instead of fixing it, someone wraps that layer with something that will retry N times, and N is configurable, and then every now and then it fails N times in a row so even with the retries it fails, and then people are like "we should increase the N configuration parameter!", and then other times it just sits there retrying all day and people want to know why it's stuck, turns out its still retrying "oh no, we should decrease N, so it fails early and someone can fix it, and we should add monitoring and telemetry and alerting so we can see when its in a retry loop!"

In this scenario, there is no good value for N, so it just shouldn't exist, the right answer is to fix race condition/deadlock so it just works every time.

For me, I enjoy solving complex problems as simply as possible. Also, in my career I've worked with devs for whom the complexity of their solution is a badge of honour.

I believe complexity is nothing that can be created or destroyed, but just moved around. Sure, you can create artificial complexity by making things harder than they need to be, but that just the complexity of the side effects you added accidentally. When you reduce the solution down to what is needed to solve the actual problem at hand, the complexity required to do so will always be the same. Now, you can hide that complexity behind an abstraction; it’s still there, but hidden behind a trade-off: you placed a cover over the gears, made it look nice and clean, but if you have to change gears, you’ll need to remove that cover first, and possibly make a new one afterwards. The overall system complexity stays the same.

Now, I think what most engineers enjoy is the act of slicing the complexity in neat boxes, and shift them around, until it feels balanced. It’s a very similar task as building a cairn from pebbles, actually, just on an intellectual level. You get the joy out of a feeling of accomplishment when the stack balances out.

Solving complex problems with simple systems is really really difficult.

Most people can't do it.

Even worse, most businesses are actively preventing it with the way they want their teams to work. How many people reading this can honestly say they get time to address technical debt or rework things to fit a more coherent view of the overall pattern that has developed with time and fixes and added features? How many developers can truly say they get to choose the best technology to do their job? Do you actually use the languages and tools that fit your domain best?

Almost none of us, right?

Also some of what you cite is fairly early-stage tech. IaC is still such a new concept that it's not surprising nobody's figured out how to make something that isn't incredibly annoying yet. Terraform, Bicep, whatever, it's all pretty raw and hideous still.

It's not so much that we like complex and messy tools and solutions, it's that we don't - for various reasons - have a choice.

What we enjoy is the management of complexity. Not only is "complexity" neither good nor bad by itself, not only is the same true of "simplicity", but no two people will even agree on what these things are.

> Do programmers generally enjoy some amount of complexity?

Yes, to their own (and the team's) detriment.

I really hate complex/clever/dense code. Just about as much as I hate "Look I found a want to look through this and write it once instead of mapping every property 1-by-1"!

Every, single, time I've seen that "shortcut code" it's turned from:

    foreach($item as $key => $value) {
        $newItem->$key = $value
    }

Into

    foreach($item as $key => $value) {
        if(/*special case 1*/) {
            // Special Logic
        } else if(/*special case 2*/) {
            // Special Logic
        } else if(/*special case 3*/) {
            // Special Logic
        } else if(/*special case 4*/) {
            // Special Logic
        } else {
            $newItem->$key = $value
        }
    }

In record time.

Just doing:

    $newItem->keyOne = $item->keyOne;
    $newItem->keyTwo = $item->keyTwo;
    $newItem->keyThree = $item->keythree;

Is much more maintainable and gives you unlimited "hooks" if you need special logic for a given key.

Note: this is a contrived example as the keys are the same, most cases I've seen this in dealing with mapping DTOs (maybe going from snake_case to camelCase) in/out of a system, a use-case where I 100% do not want "magic".

I've moved from code-golfing and being as clever as I can to loving boilerplate and verbose code.

> Or is this shower-type thought safe to chuck in the receptacle of non-sensical but good sounding ideas

Regardless of veracity, having an answer is reductive beyond the point of utility.

Like, yeah, it's reasonable to infer that someone who has chosen a career in programming might enjoy a nice game of Factorio. But beyond that, what is actionable or predictive about knowing?

It's worse than that. People will start making the hidden little assumption that the complexity of a deliverable is strongly correlated with the practitioner's propensity for complexity.

It's just blaming developers for bad software with extra steps. Instead of considering the dozen bigger factors that lead to shipping imperfection, we just have another reason to pull out the tired old excuse of blaming the programmers and their broken nerd brains that focused too hard on nerding instead of delivering business value.

Odd if nobody has mentioned yet how dominant frameworks such as React are usually hand-me-downs from market incumbents. I view them primarily as elaborate false abstractions; heavily astroturfed, intentionally suboptimal solutions for the sake of disempowering workers and creating jerbs, thus precluding emergent competition.

A junior would get a nice sense of mastery from figuring what the hell the framework authors must've been thinking when they designed it ass-backwards, but in the long run would burn out and become unwilling to learn the (usually simpler) layer underneath the abstraction. While a senior who's become wise to the racket would have to contend with the next crop of junes normalizing an even more nonsensical tool for accomplishing even less with even more because that's what the influencers influenced them to think.

Yes, I think there are software producers (there's a new title to throw in there :D ) that over-complicate solutions maybe naturally because of how they are wired or intentionally because of some need to be better than others or they see complicated things in the industry and feel like using them.

A lot of complexity is defensive, that comes from limited information on how the code will run.

For example if you’re asked to write a server with a public handler with an access to an important db, you may think of rate limiting it immediately.

Or if you have to compare two slices of a numeric stream to find out which numbers are “new”, you’ll spend half a day adapting and testing a complex dynamic programming routine, cause you don’t know if O(n^3)-ing it is fine cause n never exceeds 10 irl.

Programmers receive understated tasks all the time. Simplest solutions tend to fail and create Friday night recovery, so they learn to foresee the obvious and forecomplicate things to turn Friday nights into Friday evenings.

You don’t know what to take away. You may not even be sure how you will use your own system yourself.

I think that two things are happening here. First, we need to acknowledge that simplicity is hard. Requirements change, and making things as simple as they can be (but not simpler) requires a lot of effort.

Second, programmers love spotting things that can be optimized for some definition of what that means - whether it’s faster, more flexible, more secure, more future-proof, more reliable, etc. We don’t like leaving low hanging fruit. The only natural limit to these optimizations is the complexity they add, and the idea that some improvements are not “worth it”. As a direct consequence, we end up with the most complex solutions we can still reason about.

I actually love delving into legacy systems, trying to understand Design decisions, figuring out the incongruencies etc.

It gets considerably less fun if you are under time pressure or have any kind of expectation to make effective changes.

For me, no. My motto is "as simple as it can be, as complex as it needs to be". I don't want to build overly complex systems for the sake of building it.

What I enjoy more is seeing things work. Without any luck or non-determinism in my code. "I press button, I get coffee" type of predictability. Boring is good. Boring is reliable.

I also enjoy when my code works fast. Without a mountain of hidden dependencies, absurd amount of resource usage, and "please get a coffee, and come back when it finishes" length of waiting.

Things should be snappy, light, and simple. And preferably GPLv3 licensed.

> Occured to me that sometimes, simple enough is not good enough for us programmers

There's a beautiful article recently linked about naming conventions, there's also another about "The worst developer". Incredible reads.

Simple is good, but it depends on context, it's an absolute certainty we like reducing problems to solvable gradients. This is a good thing.

We all love problems, solving them is 1 challenge, solving them beautifully is another #2 thing.. Never making those problems is an architect thing. We all grow to evolve but learn from eachother.

As a classic, or "physics based" engineer, I'd argue that software engineering is pure complexity extract. Take away all the environmental variables, make everything a perfect binary 1 or 0, and then do engineering in that space. The only thing that can really give value in that space is complexity.

I've worked on some pretty complex electronics, but even the most insanely engineered projects don't even begin the scratch the surface of the complexity in an average commercial grade software program.

Speaking for myself, I am impressed by something that is necessarily complex in order to accomplish some difficult task, and dislike needless complexity that could be simpler. A good example of necessary complexity would be this post from yesterday https://news.ycombinator.com/item?id=43448457. Another example would be how the A-10 had to be fueled right before takeoff because it would leak fuel until at top speed.

I kind of like my software as I like my cars: Simple, and easy to troubleshoot.

The more predictable behavior, the better...so choose your tools and methodology wisely. The older I've become, the more I appreciate doing something that might be hard and challenging / lots of up-front costs during development, if it yields a robust system which is easier to fix, should something happen. So I will go for battle tested solutions, over the novel ones.

Few things rival the satisfaction of solving an extremely complex problem with numerous constraints by producing an elegant, simple solution. When your best thinking, experience, knowledge—and often collaboration—lead to such clarity, the feeling must be similar to what mathematicians like Euler experienced when discovering their most beautiful proofs.

Simplicity is the ultimate sophistication.

It's about finding a simple (enough) way through a (seemingly) complicated system.

Generally, no. Some folks do, some don’t. It’s uncommon to find anything subjective that generalizes to an entire population of folks with knowledge of a specific widespread skill.

There are two kinds of problem solver: The ones that think that a complex problem requires a complex solution and those who try to solve complex problems with elegant solutions.

The first group transfers all the complexity directly to the solution, the latter tries to eradicate complexity by trying to simplify the problem first.

I found that engineers tend to be usually in the first group. Designers (especially UX's) tend to form the second group.

Example:

This is (popular) software made by the first group: https://www.bulkrenameutility.co.uk/assets/img-bru/mainscr.p...

This is essentially the solution at the same problem, made by the second group: https://cdn.osxdaily.com/wp-content/uploads/2015/05/choose-b...

See also: https://xkcd.com/538/

there are some problems that are just inherently complex by their nature.

Some challenges are definitely fine. But any complexity introduced by human interaction is absolutely disgusting for me. For example, recurrent ambiguous requirements.

    > It seems that sometimes we might actually enjoy grappling with complex, even byzantine systems. Can anyone relate?

This is the worst part about young, smart engineers: they revel in complexity -- often unnecessary -- as a way to "flex" (often ego driven). It often manifests in such a waste of time and effort, reinventing the wheel, or making poor technical design decisions.

I'm in my 40's now and have seen it all. My conclusion is:

    - The simpler the better, 
    - Monoliths > microservices, 
    - Proven platforms > novel ones, 
    - Proven vendors > startups, 
    - Sensible defaults > illusion of choice,
    - Enduring patterns > flavor of the month,
    - OOP isn't as bad as it is made out to be and functional isn't the silver bullet people hype it up to be,
    - Productivity is often sacrificed at the alter of ego

It can be frustrating watching teams and engineers learn some of these for the first time. Sometimes it's worse: I see the mistake, but I don't see the learning and the ego's can make it hard to direct them to the right place. I can see the friction and the source of friction, but I don 't have the energy in me to fight that fight -- I just want to ship code and create value, not flex my engineering chops.

A team has recently been having discussions on scaling and I pointed to Figma's excellent series on how they scaled their backend[0]. While non-trivial, it is a proven route built on proven scaling techniques -- all documented with plenty of real-world feedback. A team has been working on RBAC, but exploring exotic solutions instead of trying Postgres RLS and looking at guidance and success from Supabase[1].

I see the appeal to the ego of inventing something novel and learning your own lessons, but to me it seems a waste of effort when the team's value doesn't lie in blazing new paths in proven system design.

There's a great post by @pizlonator in another thread[2] on Hyman Rickover:

    > [H]e succinctly summarizes the phenomenon where a technology that is substantially complete to the point that it has known issues is looked down upon while a technology that is purely "on paper" (the "paper reactor" as he calls it) is treated as a good alternative, since the paper technology isn't far enough along for the problems to even be known.

[0] https://www.google.com/search?client=firefox-b-1-d&q=figma+s...

[1] https://supabase.com/docs/guides/database/postgres/row-level...

[2] https://news.ycombinator.com/item?id=43450884

Do programmers generally enjoy some amount of complexity?

There are probably too many factors that vary by individual to create a generalized answer.

I want the real genius to pick or create a solution meaning it will be so simple it would take a supreme being to make it any simpler. Anyone at any technical level should be able to read the docs and hit the ground running. People need to get work done and not spend 80+% of their work time screwing around with some complex disaster that will only turn into an even greater time-sink as it (d)evolves.

“The definition of genius is taking the complex and making it simple.” --Albert Einstein

"An idiot admires complexity, a genius admires simplicity." --Terry A. Davis, Creator of Temple OS