Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Grug Brained Developer (2022)

grugbrain.dev

Post reply on HN
Print view View original

141–150 of 201 posts

Re: The Grug Brained Developer (2022)

#141

Post by hitchstory »

aardvark179 wrote: post #125
nicolas_t wrote: post #81

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.

Strongly disagree. Integration tests work brilliantly until a certain size or complexity is hit and then they become really bad. Unit tests are harder to write and maintain, but they will serve you much better in the long run because when they fail it’s much easier to understand and debug. The worst sort of tests are integration tests which secretly depend on another integration test having run first, which will be t…

Unit tests have lower up front costs but higher ongoing costs. By their very nature they couple more to implementation details, so they will not give you clear confirmation when code is broken.

Integration tests can give unclear signals when they are flaky, but when they are engineered well they will give a much clearer signal that things work when they pass and that something is broken when they fail.

It's harder to engineer a good integration test - this includes making them isolated and independent e.g. of test ordering or indeed, anything else.

Re: The Grug Brained Developer (2022)

#142

Post by randomdata »

mordae wrote: post #106

I have a beef with the typing section: > grug very like type systems make programming easier. for grug, type systems most value when grug hit dot on keyboard and list of things grug can do pop up magic. this 90% of value of type system or more to grug Juniors at my job routinely ship code that breaks due to null access in production, Sentry tells me. During intensive development periods that's about 1 detected null-a…

> That's just rude and uncalled for.

But is it wrong? Based on your stated experience, not even you seem to buy into type systems that force formal proofs – instead accepting lesser type systems that make tradeoffs between catching some problems (along with, most importantly, providing popup magic!) and not bogging you down in every little detail needed to prove total correctness.

Re: The Grug Brained Developer (2022)

#143

Post by PH95VuimJjqBqy »

randomdata wrote: post #126
PH95VuimJjqBqy wrote: post #101

Earlier quoted context omitted.

Not a lack of understanding, a misalignment of values. I had a team once implement the MediatR pattern for a When I asked them to remove it, it became a political fight that went to the VP because they were convinced that sort of flexibility was a good idea. Fast forward a year and they have a new technical leader and he thought I wanted that complexity until we had a conversation and when I mentioned I didn't like i…

> they were convinced that sort of flexibility was a good idea. Believing flexibility is needed still suggests a lack of understanding.

not being absolutely perfect suggests a lack of understanding, but at that point we're engaged in a tautology.

Values are those things that help guide you in the face of imperfect information. Not having a crystal ball that can predict the future perfectly means you have imperfect information.

Re: The Grug Brained Developer (2022)

#144

Post by nicolas_t »

aardvark179 wrote: post #125
nicolas_t wrote: post #81

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.

Strongly disagree. Integration tests work brilliantly until a certain size or complexity is hit and then they become really bad. Unit tests are harder to write and maintain, but they will serve you much better in the long run because when they fail it’s much easier to understand and debug. The worst sort of tests are integration tests which secretly depend on another integration test having run first, which will be t…

> The worst sort of tests are integration tests which secretly depend on another integration test having run first

That's an example of bad integration tests. Well engineered integrations tests don't do that.

Re: The Grug Brained Developer (2022)

#145

Post by bryanrasmussen »

Trasmatta wrote: post #18
jongjong wrote: post #6

It'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…

> 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.

In my experience over-engineering also often doesn't have the result of locking in devs, although their billable hours may increase in the short term.

Re: The Grug Brained Developer (2022)

#147

Post by Reefersleep »

Defletter wrote: post #111
lawn wrote: post #96

Earlier quoted context omitted.

My hobby projects are always over-engineered despite my best efforts. There's absolutely no monetary incentives here so anecdotally I agree with you.

Yup, but it goes both ways. I end up over-eningeering as some feeble attempt to avoid technical debt, only to realise my over-eningeering /is/ the technical debt. Or I end up with relatively simplistic / specialised code that needs an entire rewrite and migration process any time something is added. Either way, it's a bunch of rewritten code mixed with paralysing anxiety about writing bad code.

Get used to, and even good at rewriting. I enjoy it, and I realize that I may never have the best idea of what's appropriate at one point in time, but rather accumulate an approximation over time as I reshape the code to the best of my knowledge. And I develop tools and practices to aid me in refactoring faster and with more confidence. Most importantly, keep throwing yourself into it.

Re: The Grug Brained Developer (2022)

#148

Post by dalore »

jongjong wrote: post #6

It'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 fight complexity by trying to be lazy. The lazy solution is often the simplest, so go for lazy.

Re: The Grug Brained Developer (2022)

#149

Post by niels_bom »

pphysch wrote: post #89
kirse wrote: post #37

Earlier 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…

HTMX is pretty much feature complete though.

Famous last words.

Re: The Grug Brained Developer (2022)

#150

Post by namtab00 »

Raidion wrote: post #28
jongjong wrote: post #6

It'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…

> The biggest factor I've found in overengineering is the lack of a long term roadmap.

Can subscribe to this, 16 years career. Even a horizon of 3 months seems unattainable.

I call it a "management problem", but maybe that's because I'm not in management..

Post reply on HN