Who wrote that? I want to know! I need to know! I need to follow him/her on Twitter, LinkedIn, GitHub, Whatever, ... I need to work with him/her, it's my doppelganger!
The Grug Brained Developer (2022)
21–30 of 201 posts
Re: The Grug Brained Developer (2022)
#22OK I reckon everyone is going to get on the HTMX wagon over the course of the next few months, and it's going to blow a ton of young minds and save a huge amount of global energy and make a lot of people very happy. And then these same inquisitive young people are going to click enough links on htmx.org that they stumble across hyperscript and it's gonna be like that moment in Dusk till Dawn where the vampires come out
Re: The Grug Brained Developer (2022)
#23Who wrote that? I want to know! I need to know! I need to follow him/her on Twitter, LinkedIn, GitHub, Whatever, ... I need to work with him/her, it's my doppelganger!
It's the author of htmx - very smart guy. :)
Re: The Grug Brained Developer (2022)
#24I love this site, always get a laugh out of it. My absolute favorite:
Microservices
grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too
seem very confusing to grug
Re: The Grug Brained Developer (2022)
#25Re: The Grug Brained Developer (2022)
#26It's weird how smart people are naturally attracted to complexity like moth to a flame. It takes years to learn to fight the urge to over-engineer. Once you learn to see it though, it's hard to ignore. Now I can tell instantly if code is over-engineered. Unfortunately It seems like maybe 99% of code is over-engineered. The developer's incentive to maximize their own lock-in factor and billable hours are powerful forc…
> It's weird how smart people are naturally attracted to complexity like moth to a flame.
Hah, I just experienced this when I asked my brother for a simple comparison of about 7 criteria in a 3 column table, to include in a report.
He gave me 12 criteria not entirely from the data source I was looking for, and a cost calculator to boot.
On the other hand, over the course of a few weekends he coded up a beautiful baroque bastard of an excel macro that saved us thousands of man-hours over 5 years.
Re: The Grug Brained Developer (2022)
#27It's weird how smart people are naturally attracted to complexity like moth to a flame. It takes years to learn to fight the urge to over-engineer. Once you learn to see it though, it's hard to ignore. Now I can tell instantly if code is over-engineered. Unfortunately It seems like maybe 99% of code is over-engineered. The developer's incentive to maximize their own lock-in factor and billable hours are powerful forc…
> Few are ever able to escape the mindset because they are not fully conscious.
No one can, and no one is. All lines of code are over-engineered, just some more so. No amount of thought will get you to the perfect solution; it's an unapproachable asymptote. We're all creatures of time and there's a limit to how many cycles we can afford to spend iterating in design space to try and hit the right note. (Not to say we can't get better with practice, though.)
Re: The Grug Brained Developer (2022)
#28It's weird how smart people are naturally attracted to complexity like moth to a flame. It takes years to learn to fight the urge to over-engineer. Once you learn to see it though, it's hard to ignore. Now I can tell instantly if code is over-engineered. Unfortunately It seems like maybe 99% of code is over-engineered. The developer's incentive to maximize their own lock-in factor and billable hours are powerful forc…
Overengineering is part ego, sure, part new technologies and boredom, sure.
The biggest factor I've found in overengineering is the lack of a long term roadmap. If you need to build a feature X, and you engineer the bare minimum and need to put in the same amount of hours to do X+1, your management is going to be upset that you're taking too long to ship. You already had it 80% (in terms of feature complete) of the way there, why is that extra 20% as hard as the first 80%? So the engineers build up scar tissue. If you have to handle a ton of cases that you don't understand, why not build a CaseHandlerFactory so you can add the next feature faster?
A clear roadmap of "this is what we want in 1 year" will help solve over engineering. Otherwise engineers are incentivized to make their code as configurable, modifiable, and extendable, as possible, regardless of cost or business need. Not to mention all the additional time trying to figure out "canonical" data models that will "future-proof" the applications interfaces. If you have to iterate quickly (which is not as common as agile folks wish), you need to build up a raport with leadership to help them understand that speed comes with trade offs: faster might mean 'more work to change later', while slower to market today might mean faster iteration down the line. These discussions ARE valuable for leadership, as sometimes they need a quick win because of a Q3 earnings hole or contract, and sometimes they are willing to make longer term investments.
You move too quickly, they call your solutions hacky, you move too slowly, they call it overengineered. Everyone needs to be on the same page of what the change is trying to do: win short term, win long term, or somewhere in the middle.
Re: The Grug Brained Developer (2022)
#29It's weird how smart people are naturally attracted to complexity like moth to a flame. It takes years to learn to fight the urge to over-engineer. Once you learn to see it though, it's hard to ignore. Now I can tell instantly if code is over-engineered. Unfortunately It seems like maybe 99% of code is over-engineered. The developer's incentive to maximize their own lock-in factor and billable hours are powerful forc…
I struggle with this constantly. I think there are two problems: 1. I like interesting puzzles. A lot of code - especially commercial code - is pretty boring if you do it right. I find myself subconsciously pushing for features that will be fun to implement. And by "fun", I mean, features that will overcomplicate everything. 2. While I'm in the middle of programming something, all the choices that I make seem straigh…
> "Oh, we're slowly building up a custom, buggy, binary framing protocol. Lets just use protobuf/msgpack"
By using protobuf/msgpack you lose the ability to precisely control the layout and encoding of your data on the wire. Most applications don't care, but this results in your wire representation being defined by "whatever protobuf says".
Say I want to transmit an unsigned 16 bit integer with protobuf. How do I do that? The documentation doesn't include 16 bit integers as a datatype, so I'd probably have to wrap it in 32 bits and/or use some varint stuff. It would be simpler to just write a big endian 16 bit int though.
I wish there was a simpler alternative to protobuf that gives more control to end users and doesn't try to be smart. Until then, making your own binary protocol is not over-engineering.
Re: The Grug Brained Developer (2022)
#30OK I reckon everyone is going to get on the HTMX wagon over the course of the next few months, and it's going to blow a ton of young minds and save a huge amount of global energy and make a lot of people very happy. And then these same inquisitive young people are going to click enough links on htmx.org that they stumble across hyperscript and it's gonna be like that moment in Dusk till Dawn where the vampires come o…
Spoiler very much alert.