I love the section on tests. It really is exactly what I've come to learn over the years. Integration tests are the sweet spot for finding bugs. Mocks tend to over complicate things (I still use them sometimes but I avoid using them systematically) and unit tests are too brittle in face of refactoring whereas integration tests help with refactoring.
The Grug Brained Developer (2022)
81–90 of 201 posts
Re: The Grug Brained Developer (2022)
#82It'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 w…
> 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.
I've never understood this, maybe I'm just a bad engineer. I mean, it sucks having to pivot, but all those configurable and extendable pieces take hours trying to get the design right. And you only end up using ~1% of them, and then something you didn't foresee happens as well. I always end up spending months of my life saving days doing the change-overs.
And that's before we get into the problems with onboarding a new engineer (or being the one onboarded) into the kind of hellscape that the overly configurable application turns into.
Re: The Grug Brained Developer (2022)
#83Earlier quoted context omitted.
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…
> 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. That's what factorio is for!
Or Project Euler! :)
Re: The Grug Brained Developer (2022)
#84ok. so grug make good, good point. many good point. now say others no listen and do opposite of what grug say for month after month. code complex. code very complex what grug do now
ok. some need feel fire under ass to see house burning.
grog only relax and wait. complexity spirit demon do the rest
Re: The Grug Brained Developer (2022)
#85Earlier quoted context omitted.
> The developer's incentive to maximize their own lock-in factor and billable hours are powerful forces. In my experience these are rarely, if ever, the reasons for over engineering.
I never though so either, but then I worked at a place that had a stale product, product teams powerless and developers rejecting most features/writing random code all the time. It took me a month to realise that the staff developers very much revelled in and protected their bad code and bizarre domain choices. It was so far gone that there was no way to get rid of them and the product was just slowly dying and burni…
>It took me a month to realize that the staff developers very much reveled in and protected their bad code and bizarre domain choices.
I think personality can account for this without any reference to incentives, which come in to explain how this personality problem can be so common among successful engineers.
Re: The Grug Brained Developer (2022)
#86ok. so grug make good, good point. many good point. now say others no listen and do opposite of what grug say for month after month. code complex. code very complex what grug do now
grug say now ok reach for club
Re: The Grug Brained Developer (2022)
#87It'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…
> smart people are naturally attracted to complexity like moth to a flame I think the general inclination here towards static typing is due to this, rather than any evidence that statically typed languages lead to higher quality software. Engineers just love puzzles. I'm also looking at you, Rustaceans... runs for his life
I’ve seen some variation of this accusation being thrown around for years- and frequently by people who I regard as smart, capable developers. On the other hand, having worked with languages all over the spectrum of static typing- I’ve also seen first how how high the bar really is for benefiting from static types before you hit diminishing returns.
The best answer I can come up with is that people just seem to have differently wired brains. For me, static typing- even fairly sophisticated static typing, is simple. It makes the code simpler, easier to reason about, easier to refactor, and with a sufficiently expressive type system it lets you build things in a much more intuitive way than you could otherwise. It’s not about solving puzzles for the sake of them- types remove a big part of the puzzle by letting me explicitly write things down- and letting the compiler keep track of the details.
Certainly plenty of people don’t see it that way, and I’ve heard a lot of people make similar arguments about dynamic typing being simpler and more expressive. I don’t think they are lying but I see a big pile of inscrutable pain when I work in large dynamically types codebases.
I know I’m right about my experience, and I trust other people are right about theirs, so there must be some significant divide in how we conceptualize code that makes one persons elegant simplicity another’s intolerable complexity.
Re: The Grug Brained Developer (2022)
#88It'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 wouldn't call those "smart people". They're not much beyond mediocre, but see overcomplicating things (which in many cases they will dogmatically explain away as being a "best practice") as a way to make it appear like they're smart. The smartest are those who can make complex problems look simple, with simple solutions.
And they're never really appreciated, since those problems end up looking so simple in hindsight
Re: The Grug Brained Developer (2022)
#89OK 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…
everyone is going to get on the HTMX wagon This is an infinite cycle with JS though. Someone tired of JS complexity writes a simple JS lib (SJSLib), SJSLib attracts people for simplicity, SJSLib grows complex because it has to support all the web things, someone tired of SJSLib complexity writes a simple JS lib... I say this as someone who started with raw JS and fought IE5/6 for years, jQuery then saved us all, skip…
HTMX is pretty much feature complete though.
Re: The Grug Brained Developer (2022)
#90Earlier quoted context omitted.
everyone is going to get on the HTMX wagon This is an infinite cycle with JS though. Someone tired of JS complexity writes a simple JS lib (SJSLib), SJSLib attracts people for simplicity, SJSLib grows complex because it has to support all the web things, someone tired of SJSLib complexity writes a simple JS lib... I say this as someone who started with raw JS and fought IE5/6 for years, jQuery then saved us all, skip…
Obligatory Vanilla JS link: http://vanilla-js.com
Plain JS and HTMX are like Duct Tape and Spackle. I feel like I can fix/build anything I need with them.