[deleted]
The Grug Brained Developer
261–270 of 394 posts
Re: The Grug Brained Developer
#262This is wonderful. I feel myself thoroughly agreeing (but also somehow intensely disagreeing at the same time) with things that are written, especially when it comes to type systems. At some sort of deep level, I seem to like the idea that stuff is proven to work, regardless of how complex the type system overhead is. Maybe it's just two sides of the same coin. Some sort of primitive hatred of complexity and a primitive desire for safety and control will forever be at war inside me.
Re: The Grug Brained Developer
#263This might be the best text on programming I've read since Why's Poignant Guide
this might be the highest complement ever received in the history of hacker news, thank you
Re: The Grug Brained Developer
#264Earlier quoted context omitted.
I don't know if this is universal, but in my circles "microfrontends" are now all the rage. How do you bring up concerns with that in good faith? It's so obviously terrible that I've no idea where to begin.
Oh lawd, at our client people recently pushed that idea, too. Unfortunately, managers were all on board ("Every team will be able to release autonomously and much faster!!!11") and it became politically impossible to argue for alternatives that won't result in dependency and infrastructure hell. So here we are now, splitting off every single page of a god damn legacy web shop into a separate micro frontend, each of w…
Oh no... you know what, maybe we don't deserve to cross the great firewall as a species.
Re: The Grug Brained Developer
#265Earlier quoted context omitted.
> Anyway, it might be good to talk to your PMs and not assume they're evil villains. I've always thought PM's to be more or less aliens with a ray gun tapping at their watch. Communicating with them goes nowhere since they don't empathize with your point of view. The only thing they're concerned with is when something's going to get done. The only form of motivation is threat of existence in the company. > While I've…
A good PM is worth their weight in gold, but the problem is that the qualifications for a good PM are very hard to make objective. This leads to the role becoming magnet for power-hungry MBAs with a bean counter mentality who will tend to outcompete anyone with real knowledge of UX or engineering unless the company understands the danger of money/power-driven PMs and actively counteracts it by focusing on actual prod…
I’ve found that only hiring technical PMs can be really helpful in this regard. YMMV depending on the product, but when it fits it’s great.
Re: The Grug Brained Developer
#266Earlier quoted context omitted.
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…
In real-time systems (games, specifically) logging can be very useful for figuring out what happened on the frame _before_ the bug happened, which in a lot of cases is not immediately obvious where the bug manifests (and you'd hit a breakpoint). The alternative is setting (sometimes many) breakpoints in different places and remembering what happened at each of them. Personally, I prefer reading a log.
Time travel debugging addresses this, but maybe would be too slow or memory intensive for games.
Re: The Grug Brained Developer
#267Earlier quoted context omitted.
Unfortunately, you don't have to work with bad PMs very often, to occasionally experience a year or more of misery due to their ineptitude. Good PMs are a bit of a paradox. They are immensely impactful and bring value to every project they touch. Yet they are also far overqualified for what is often a thankless job. I also have come to the view that even good PMs will rarely allocate the work that is truly impactful.…
What are the downsides to "going rogue" too often? Where do politics come into play here?
If your "going rogue" project fails, then you can be seen as not having done any work for X weeks. If your manager was against you working on that project--especially if they needed you to work on something else--then you will be seen poorly, and that can be rough for your career.
Re: The Grug Brained Developer
#268Earlier quoted context omitted.
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…
> Either you are using a shitty language with a crap debugger or you need to learn how to use your IDE. or you are working in a domain where debug builds are intolerably slow.
For games you often use pragmas to selectively disable optimization. It depends if you will be debugging in a few key places or not whether that is useful, but if you are manually placing logs I assume so.
Re: The Grug Brained Developer
#269Good stuff, reminds me of PLT Hulk [0], although obviously Grug isn't a fan of powerful type systems.
Re: The Grug Brained Developer
#270Ah, 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…
Whoa now, I was with you until you seemed to imply that "simple" software means shitty code. Simple in this context means a solution with as little complexity as possible. Hopefully written elegantly and carefully, with lots of thought for future maintenance and readability. Maybe you use a 10-year-old, constantly maintained and thoroughly tested library to do 90% of the work instead of writing everything yourself. W…
> Hopefully written elegantly and carefully, with lots of thought for future maintenance and readability.
Those are fine things to value even if they are highly subjective.
You might think it’s easier to read a while loop with a handful of mutating variables and a few branches. I might disagree.
I think it’s easier to read an accumulating function that uses traverse.
It’s wishful thinking that we should both hold the same values or that only one of us is right.
> big brain type system shaman often say type correctness main point type system, but grug note big brain type system shaman not often ship code. grug suppose code never shipped is correct, in some sense, but not really what grug mean when say correct!
This big brain ships code every day.
Also streams big brain work in big brain language once a week to show people that it’s not the work of big brain shamans.
Big brain is happy to answer questions and help people learn.