> 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…
The Grug Brained Developer
331–340 of 394 posts
Re: The Grug Brained Developer
#332Earlier 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.
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…
Re: The Grug Brained Developer
#334complexity 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.
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> 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…
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
#336Earlier 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
Re: The Grug Brained Developer
#337Earlier 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…
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
#338Earlier 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.
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
#339Earlier 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.
2022: Server side rendering using island-based architecture for client-side rehydration of interactive components
Re: The Grug Brained Developer
#340think hard about think soft ==> no need think hard all time