[dumpster_fire]

I don't know about this.

What I deem smart or dumb changes over the years. When I was a junior dev, I saw someone totally new to coding create a single static class method that did tens of thousands of lines of if else checks for a state machine. The group of us junior devs shared the code snippet with each other and laughed at how ridiculous it was. The code could've been so much cleaner with proper extraction and abstraction. The bootcamp fresh minted dev was what I had considered as someone who's dumb but gets things done.

Over the years as I worked with more teams, I've seen people do "smart" things like a one liner quadruple nested ternary return. Everyone marveled at how clean it looked. I've also seen smart devs who experimented with Haskell or OCaml in their spare time start using closures in closures in closures. Lambdas everywhere when remotely possible. Anyone who didn't understand what they were doing were too inexperienced and dumb. They were always heralded as the geniuses of the company.

Nowadays, I very much rather debug a ten thousand line static method with if else clauses. It's quick to navigate, and incredibly easy to debug. Stupidly simple is my new smart.

The only thing I've really concluded after so long is that, the only dumb person in the room is always me. I've been told I'm a pretty kick-ass teacher so that pretty much seals my dumbass status.

[silvestrov]

This is the main reason I dislike java Spring Boot: too much magick going on at runtime which is difficult to figure out if you are not an expert in Spring.

Much better to have (pre)generated code which is then compiled like any other java code. In this case you can see the code, you can navigate it, you can single-step thru it when running.

Spring Boot is too much like monkey patching in Ruby. Please let me see the code that runs.

[steve_adams_86]

Early in my career I remember being really bothered by a guy who insisted we use a finite state machine for handling some stuff I’d already written and was pretty happy with. In my mind it was such overkill and he was being academically ostentatious or something.

I now love having opportunities to lean on finite state machines because I’m more aware of how dumb my primate brain is and how helpful it is to have guard rails. So, multiple layers of dumb: I couldn’t figure out that this guy was smart enough to see how dumb we were in the context of the problem we were solving, and he was ultimately trying to save me from myself.

This was around ten years ago.

I’ve also been told I’m a great teacher, haha. Sealed.

[majormajor]

This is a fun example because I've seen exactly the reverse situation. (Not to say state machines are bad, just to say sometimes they don't fit as much as it seems on first glance.)

A bunch of mid-level devs on the team wanted to model our new thing as a state machine. But it dealt with a LOT of edge cases. Including real fun things like "that actually CAN be a valid state transition if Customer Service does it to manually resolve an issue caused by a previous bug or something, or just to make a customer happy, even."

I was the guy who eventually convinced them not to by illustrating just how many states and transitions this machine would actually have to have to do everything it needed to. A lot fewer people want to write thousand-node state machine descriptions than who want to write 20-node ones.

(How did I know that would happen? Because I'd previously been a mid-level engineer who jumped straight to "state machine!" for something and it added countless complexity and pain to the project. :D )

[steve_adams_86]

Absolutely, that's a legitimate concern. A real benefit of approaching state machines model-first is that you get to see those nodes on paper before trying to write the code, and you can quickly recognize a tire-fire of an idea vs a situation where you can sanely box in logic and avoid state-explosions.

I've had a few tasks with state machines turn into messes, but thankfully they were only at the cost of my personal time rather than my team's. I definitely prefer them for cases where a model juuust fits into your head, or nearly so — it seems fairly intuitive, and not totally monolithic in scale or inversely tiny in proportion. There's this sweet spot where it's just complex enough that you want to box it in, but not so complex that a formal description using a rigid convention would endanger you from your coworkers.

[majormajor]

Yeah the attempting-to-model first approach is great too for trying to avoid walking into "we thought this would take three weeks but it's gonna take 6 month" situations because the initial requirements were not all the way thought through around edge cases and such, and looping stakeholders in to just how nasty it may or may not be early-on.

[steve_adams_86]

That dovetails really well into our other thread about putting an emphasis on listening and understanding rather than trying to lead conversations. Putting attention to properly understanding a problem is very empowering, and often leads to more decisive data points than discussions can.

[Too]

Ooof, saw a team get hung up on modeling the application as a state machine once. No existing solution could support all the edge cases so they had to write a templated state machine engine first.. Yeah.. No surprise what happened to that later.

[steve_adams_86]

I think going state machines all the way down is almost always a mistake. I can maybe see using state machines to undergird some logic in an application, like… I don’t know, maybe you’ve got some authentication stuff you’d like to reliably model as states, and that’ll be fairly foundational. But if you then model authenticated and unauthenticated states as substates, then have further nested states representing the sort of scaffolding or actual features of the application… That’s a nightmare.

I’ve noticed some people are hesitant to compose state machines too, like using dumb states to execute smarter state machines such that you can localize complexity and isolate things better. Almost like people think it needs to be a monolithic machine in order to truly maintain safety?

In any case, like any pattern there’s plenty of room for abuse, haha. I am a pattern abuser myself, usually learning things the hard way.

[joseda-hg]

I was recently discussing something similar, and we came to the conclusion that the difference lies in Intention

Doing an overly complex method because that's the only way you know vs doing it because it has benefits

We came to it in a discussion about manners (My interlocutor usually does something considered rude, but does it in an over the top way that always get a chuckle) You need to know plenty about rules, before you know how to break them with good results