121–130 of 394 posts
> 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…
Earlier quoted context omitted.
Undoing someone's copy-pasted for-loops and while-loops is called "factoring" and undoing someone's bad abstractions is called "re-factoring" and is about 10x as slow. At this point in my career I have seen way more crappy abstractions and needlessly abstracted code than grug-brain code. And, to be brutally honest, as much as I love those functional combinators, first-class functions, streams, etc, they suck to reaso…
> And, to be brutally honest, as much as I love those functional combinators, first-class functions, streams, etc, they suck to reason about. > Sometimes loops are better! That I think is backwards. A loop could be doing literally anything - it probably is futzing with global variables - so there's no way to reason about it except by executing the whole thing in your head. A map (or mapA) or a fold (or foldM) or a fi…
> 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…
> 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…
I think "prototyping" is better than "refactoring". Prototyping basically means that you write your app more than once. On the 2nd round you know what needs to be there and what not. You may have come up with a much better much simpler design for the whole system when you know what needs to be there and what it needs to do.
Code-quality is important no doubt, but it is not important for code that doesn't end up in the final product.
> 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…
As for your point about logging being a fail condition, I was working on a distributed system where I had no control over which instance my code was running on. I would attach a debugger and make the same request a dozen times before the instance I had attached the debugger to processed the request. This wasn't a system I could setup a local instance of. I also couldn't reduce the instances to a single one because there were other devs, testers, data engineers working on it and the system did raster processing that regulary took 1-5 minutes. I resorted to log debugging.
> 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…
Ah, the ample club of wishful thinking. There are two general ways of approaching software design (and I'm paraphrasing Tony Hoare here): 1. You can write software so simple there are obviously no errors 2. You can write software so complex there are no obvious errors One thing that escapes "grug" is that achieving 1. often requires more sophistication than their magical club allows. Most well-intentioned "grug" deve…
I very much prefer to work in a codebase of poorly written loops and variable assignments rather than one with poor abstractions.
Poor abstractions can harm way, way more than spaghetti code. Their harm usually spreads out through system.
Imagine this:
* 1 single poorly written function which takes a number of inputs and has an output, but internally it's long and messy.
* A bunch of abstracted entities, which interact throughout the system, but are poorly designed.
The complexity of 1 is isolated to the implementation. There's a nice encapsulation. Removing/Rewriting is easy.
But 2 becomes a complete mess which is not isolated. You'd have to skin it layer by layer. Thats way more scary to me.
> 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…
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 they can harangue developers into overtime, out-of-hours alerts or death marches. It’s asymmetric risk.
Don't take that personally. I’m sure you, individually, do the right thing. But my experience is that PMs / POs / team leads as a group can be bad actors. It's just the way incentives are structured for middle managers. By the time the problems of your "pragmatic" architecture have emerged, your typical PM / EM / team lead will either be working on another team, doing another job, or talking about "tech debt" as "just one of these things", a mysterious natural force, visiting your team stochastically like a freak summer snowstorm or an outbreak of measles.
_That_ is why developers are cautious. Do you _seriously_ think that you are the only person in your team who understands "commercials" or "cost benefit analyses"?
Experienced developers do, which is why we've learned the best strategy in the long run is to avoid offering too many concessions to people without skin in the game.
Also, grug not know if big brained or grug. Grug think grug but not see big brained. Big brained think big brained stop big brain and become grug. When stop think grug big brain, big brain grug return. Hard, and bore. Life such.
Now sleep, soon shiny rocks collect.
Ah, the ample club of wishful thinking. There are two general ways of approaching software design (and I'm paraphrasing Tony Hoare here): 1. You can write software so simple there are obviously no errors 2. You can write software so complex there are no obvious errors One thing that escapes "grug" is that achieving 1. often requires more sophistication than their magical club allows. Most well-intentioned "grug" deve…
Woah woah. This is literally the kind of complexity grug wants to avoid. Simple doesn't mean using the fewest language features or keywords, it means simple to read, follow along, reason about, and debug. Abstractions can aid in that (like using a third party library!), until they are imported/implemented aspirationally and thus often unnecessarily, and sometimes resulting in abstractions for abstractions, selective application of the abstractions vs fresh implementation, etc (...and thus AWS)
At no point does grug argue that you should stick to what you know, he just says you should trap your complexity in crystals ie literally suggesting to use the Good Abstractions, When They Make Sense.