Live data from Hacker News

The Grug Brained Developer

grugbrain.dev

331–340 of 394 posts

Re: The Grug Brained Developer

#331
post #306

> grug brain developer try collect learns into small, easily digestible and funny page, not only for you, the young grug, but also for him because as grug brain developer get older he forget important things, like what had for breakfast or if put pants on grug relate. other day grug forget Angular have pipes even though grug use async pipe in same PR. This is particularly concerning for me because not being too stron…

grug brain like pokemon brain: have to forget thing to learn new thing. sometimes old thing useless, sometime old thing very important like bank password

Re: The Grug Brained Developer

#332
post #253

Earlier quoted context omitted.

I've been the guy who gets called at 4am when postgres takes a dump. I've also been the guy doing the calling (well, not really as a PM, since again, we don't generally have the ability to tell anyone what to do at 4AM , but I digress.) > Communicating with them goes nowhere since they don't empathize with your point of view. Can't speak for everyone, but again, I've been on both sides of the table, and I've never se…

I think the grandparent meant that the PM is motivated by the threat of having to leave due to a failing project.

That's how I read it.

Re: The Grug Brained Developer

#333

> good debugger worth weight in shiney rocks, in fact also more: when faced with bug grug would often trade all shiney rock and perhaps few children for good debugger and anyway debugger no weigh anything far as grug can tell grug know debugger good but grug often realize grug no need debugger on smaller cases and only run it when grug need it, grug try simple code like print and log first, if grug sad and no underst…

Relying on log and print statements is like giving up. I would claim that's not simplicity, that's inexperience, but I have no idea what language you're referring to. Sometimes I do it with JavaScript when I didn't setup the project, it's using a framework I don't know and I'm not willing to spend the time figuring out how to get real debugging working so there are caveats. But you definitely should not be doing that…

[deleted]

Re: The Grug Brained Developer

#334
post #72

complexity isn't bad, redundant complexity is

Yes, people often confuse inherent problem complexity (maybe domain complexity) with unneeded complexity introduced by code architecture. You can reduce the latter, but often you can't reduce the former. That's why it is best to keep abstraction for code architecture at bay.

You can reduce inherent problem complexity by picking a simpler subset of the task to solve (for example only support a single backend rather than plugins and interfaces, or exclude complex problems like text ligatures and glyph shaping). The resulting program will be shorter, have less indirections (making it easier to trace statically, and require less scrolling between functions and jumping between files), easier to make correct and fix bugs, and easier for outsiders to read and learn the fundamentals of a problem domain from. And once you've learned a conceptual understanding from simple programs (JACK2), you'll be better-prepared to learn big complex programs (PipeWire), which are harder to learn not only because they deal with more complex problem domains (latency compensation, multi-device synchronization, video), but also because they suffer from dynamic dispatch (requiring runtime debugging to identify which type implements an interface) and are too big to learn the architecture by merely looking at individual files (though I hope projects get better at teaching architecture: https://matklad.github.io/2021/02/06/ARCHITECTURE.md.html).

Unfortunately, in some cases complex programs adopt fundamentally different architectures (dynamic dispatch and plugins, different data structures, extra modules like Harfbuzz and Pango, etc.) from simpler programs. Perhaps they have reasons for doing so, but in practice I find myself still confused even if I understand the simplified concepts and can write useful code using them.

Re: The Grug Brained Developer

#335
post #87

> sometimes probably best just not tell project manager and do it 80/20 way. easier forgive than permission, project managers mind like butterfly at times overworked and dealing with many grugs. In my experience, I have to fight to keep my devs from over engineering their solutions and just get something going. I'd love to work with a dev who's happy to think about how to most quickly deliver value and who's willing…

It's a question of incentives and accountability. PMs aren't usually accountable when their shortcuts come and bite the team further down the line. Developers feel the pain instead. PMs won't be honest with the business that they sold an undercooked product. Need to suddenly scale up that "pragmatically" designed database? I know in my heart that too many PMs will _never_ manage expectations with their superiors if t…

> PMs aren't usually accountable when their shortcuts come and bite the team further down the line. Developers feel the pain instead.

Developers (and people in general) are bad at prediction the future. I've seen many times that a developer are solving a problems in more generic and extensible form than required, creating a complex solution in hope that future changes will be easy. But then future comes not as it was expected and refactoring is required anyway.

80/20 for me includes not solving problems you don't have but think you may have in the future. If you need to solve X and X looks like a special case if Y class it doesn't necessary mean solving more generic but bigger and harder problem Y is a good idea.

Re: The Grug Brained Developer

#336

Earlier quoted context omitted.

This. Premature and excessive fragmenting into unmaintainable and operationally microse5rvices is the bane of my existence. It's often done by zealots, who see microservice architecture as a matter of religious faith, not operability convenience. Sure, some monoliths are harder to debug if there are multiple distinct packages that need to operate together if they are all in the same container. But fragmenting a simpl…

i can't tell you how many teams I've seen spend months and months engineering some vast microservice system only to end up serving maybe 500 DAU. It could have been a single executable on a $5 VPS

Up above there’s a great thread about the perverse incentives in project management roles. This is a great example of perverse incentives in development roles - resume driven development practices.

Re: The Grug Brained Developer

#337

Earlier quoted context omitted.

It's a question of incentives and accountability. PMs aren't usually accountable when their shortcuts come and bite the team further down the line. Developers feel the pain instead. PMs won't be honest with the business that they sold an undercooked product. Need to suddenly scale up that "pragmatically" designed database? I know in my heart that too many PMs will _never_ manage expectations with their superiors if t…

> PMs aren't usually accountable when their shortcuts come and bite the team further down the line. Developers feel the pain instead. Developers (and people in general) are bad at prediction the future. I've seen many times that a developer are solving a problems in more generic and extensible form than required, creating a complex solution in hope that future changes will be easy. But then future comes not as it was…

> Developers (and people in general) are bad at prediction the future.

Right now I can safely say that 80% of the times I foresee changes they actually happen. I won’t stop pre-empting stuff for the 20% I get wrong.

Re: The Grug Brained Developer

#338
post #169

Earlier quoted context omitted.

Inheriting someone else's mess can really hurt. Especially when you are not given the time to improve things. Worse when you're told they've negotiated 20% extra time to clean up, but every estimate gets shortened by more than 20% to please the customer. Then you're in the firing line when new features don't ship in time and bugs keep popping up everywhere. It makes you question your ability as a developer. Sapping y…

Agreed. And I've found that agile doesn't really help here either. Sometimes I wonder how we got to be highly paid, but sometimes, completely lacking the authority to do our own jobs.

Because it's a hard job that not a lot of people can actually do, but most companies still operate under the, now outmoded, model of industrial production. Under this model, every employee's role can be modeled as a fungible cog in an assembly line. This lets management, and organizations as a whole, abstract over their production process and not deal with the particularities of any given worker.

I've got a kind of fuzzy idea that this is a similar mental bias/logical fallacy to the black swan events that Taleb talks about. People assume normal distributions, but the underlying is a Pareto or Power Law distribution. They do this because it's easy and has lots of nice and practical properties. In the case of markets/finance, it makes the math really easy to work with on a day to day basis in the 99.9% case. But in the black swan event, the .1% case, it totally falls apart and your model cannot account for it.

Much like the financier assuming normal instead of Power Law, the production of software assumes the industrial model of production. This works for some high % of cases to get some amount of productivity out of most writers of software. But at the high end of software professionals, or in a situation in which something actually new is being built to solve an unsolved problem, this breaks down.

Anyway, this is not a wholly thought out thesis and mostly rambling, but it is poking at my mind and I figured I'd write it down somewhere.

Re: The Grug Brained Developer

#339
post #284

Earlier quoted context omitted.

In such a component-oriented circumstance, what is the motivation for choosing a “microfrontend” approach instead of, say, a component?

The longer you are a developer, the more you see fads a cylic just like anything else in this world. rebranding happens every 5 to 10 years for most things.

2008: Website with jQuery

2022: Server side rendering using island-based architecture for client-side rehydration of interactive components

Post reply on HN