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

The Grug Brained Developer

grugbrain.dev

Post reply on HN
Print view View original

381–390 of 394 posts

Re: The Grug Brained Developer

#381

Post by whiskyagogo »

recursive wrote: post #209
whiskyagogo wrote: post #205

Earlier quoted context omitted.

Modularization, encapsulation, coordination, safely scaling contributors/features.

Vanilla js can do all that. Just `import` and done. No build steps.

“Can do” doesn’t always (or even often) mean “can do well” or “can do well according to our needs” or “works for all our use cases” or “works for all our users” or…

If vanilla JS checks off all those boxes for you, that’s genuinely fantastic and I’m happy for you. And a lil envious tbh. But there are a myriad reasons I/we currently can’t justify ditching the build toolchain, and most of them relate to scaling in a way that fulfills our requirements. I can’t imagine I’m alone in that.

Re: The Grug Brained Developer

#382

Post by deterministic »

mattmanser wrote: post #98
nullptr_deref wrote: post #61

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

30+ years professional developer here. Tell me how you would debug a customer issue that happened yesterday on their system without logging and without being able to connect to their system? Manually using a debugger is a red flag for me. It tells me that the developer doesn’t understand how to automate debugging by automatically detecting invalid application states and logging the problem. The best developers I have ever worked with never use debuggers. The worst developers I have ever worked with used debuggers all the time. Because they had so little understanding of the code that they needed to manually step through the code to get it.

Re: The Grug Brained Developer

#383

Post by mbrodersen »

koonsolo wrote: post #120
recursive wrote: post #90

Earlier quoted context omitted.

npm, babel, webpack, module compatibility, et al

You are free to develop everything in vanilla JavaScript and run your coded scripts straight in the browser. Very non-complex. But the team that uses npm, babel, webpack etc will crush you both on development speed and stability.

Hahahaha that’s a good one. The quality of the end product depends 99.99% on the quality of the developers. Not the tools they use.

Re: The Grug Brained Developer

#384

Post by Majestic121 »

bb88 wrote: post #349
timr wrote: 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…

> if your PM is motivating you via threats, something is very wrong. Seriously? This is how 80% of companies work. In many of those companies, stack ranking is a very effective tool for running people out the door. It's often _baked_ into corporate culture.

If that's your experience, you either have been extremely unlucky, or you should look back on your own behavior.

I've had some problems with PM before, but never about threats, and that would go very poorly with most people I know.

Re: The Grug Brained Developer

#385

Post by Too »

deterministic wrote: post #382
mattmanser wrote: post #98

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

30+ years professional developer here. Tell me how you would debug a customer issue that happened yesterday on their system without logging and without being able to connect to their system? Manually using a debugger is a red flag for me. It tells me that the developer doesn’t understand how to automate debugging by automatically detecting invalid application states and logging the problem. The best developers I have…

I think in a way you are both right. This argument goes both ways. I’ve seen developers have so little understanding of the code that they needed to add logs on every second line of it. I’m talking about stateless pure functions with clear inputs and outputs, here you should only have to log the input, possibly also the output, the rest is reproducible. Some would call this tracing, not logging.

The best systems are the ones that log just enough, but no more, whatever that means can be difficult to quantify. I find logs that are informative or actionable to an operator are the most useful, if a log entry appears more than once a minute and this entry is only useful for a developer of a particular submodule, it’s too chatty and likely an indication this module is not understood enough. If a system is doing its job it should for most of the time not say much. Getting to this state of log nirvana does however, as you say, require the best of developers.

Re: The Grug Brained Developer

#386

Post by Too »

agentultra wrote: post #16

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…

As the idiom goes: Can’t see the forest for all the trees.

Sadly it’s often difficult to argue with someone using the complex=bad-club, because everybody knows complexity must be avoided - at all cost!!

What one should understand is the essential complexity of the problem, then design your solution around that, to control where the complexity goes and to not introduce accidental complexity. Blindly going complexity=bad will result in it popping up elsewhere later.

Many people as you say don’t even know what it means and use complex=bad for all kind of things they disagree with, including choice of tools or libraries. Using a library you don’t know is not complex, it is difficult, also something that should be avoided but that doesn’t make it the same thing. (Adding libraries and mixing competences can of course add complexity also, but let’s not get pedantic…)

Re: The Grug Brained Developer

#387

Post by karategeek6 »

necovek wrote: post #313
dangerface wrote: post #302

Earlier quoted context omitted.

> Former engineer turned PM here. I think you'r experience as an engineer has biased your view. For example number 3 with your engineering experience you might think that but ultimately it's the engineering team that has to deal with the scaling not you. Your incentives are to scale everything back to meet dead lines while the engineers incentive is to make every thing work so that when it goes live they don't get ca…

As mostly an engineer (though I've spent time as a tech/team lead and engineering manager in the past), I think you've missed the point. Most of the things will not need to be "scaled" at all. Ever. As an engineer, I mostly struggle to come up with a simple solution while accommodating all the crappy, leaky abstractions in the rest of the code: that's the hard part of the job. And 20 years in, I still wonder why peop…

> I still wonder why people think it's smarter to introduce seventeen layers of abstractions for things that have one or at most two implementations

Tell me you are a Java dev without telling me you are a Java dev. :)

(While I know it's not just Java with this problem, my personal experience is that Java is the worst.)

Re: The Grug Brained Developer

#388

Post by jeffparsons »

eurasiantiger wrote: post #328
achenet wrote: post #308

Earlier quoted context omitted.

Martin Guitars has a range of guitars ranging from ~$1500 to $10,000 in price. The sound and play-ability on all of them is superb, what differentiates them is the materials and the aesthetic aspects - i.e. fancy inlays and stuff. Similarly, I imagine you could go see a stone mason and ask for a simple brick wall for 20% the price of an ornate bas-relief facade, which would still be well constructed. Or ask a blacksm…

Does the corporate luthier fancy working on the simple stuff, or the complex stuff? Neither, because they likely work a single phase of an assembly line instead of finishing an instrument all by themselves. This is where the Martin Guitars analogy breaks down: the guitars are not bespoke products. Pieces of computer software obviously are, otherwise we wouldn’t be having this discussion. Look at any entrepreneur luth…

I like the analogy of the entrepreneur luthier and more generally the master craftsman. I've had the experience of building software "on the assembly line" and, and also been lucky enough to be paid by the same employer to work in a way that is much closer to the "master craftsman" end of the spectrum. I much prefer the latter.

But it's only in side projects that I really feel I'm able to work as a master craftsman, without the ever-present burden to just ship a pragmatic compromise that delivers value to the business so that I can move on to the next pragmatic compromise. I wonder if this is another reason why, say, doctors working in hospitals will often also have their own private practice — sure, the extra money is nice, but the autonomy and mastery that comes with a side business might be even more important.

Re: The Grug Brained Developer

#389

Post by mbrodersen »

Too wrote: post #385
deterministic wrote: post #382

Earlier quoted context omitted.

30+ years professional developer here. Tell me how you would debug a customer issue that happened yesterday on their system without logging and without being able to connect to their system? Manually using a debugger is a red flag for me. It tells me that the developer doesn’t understand how to automate debugging by automatically detecting invalid application states and logging the problem. The best developers I have…

I think in a way you are both right. This argument goes both ways. I’ve seen developers have so little understanding of the code that they needed to add logs on every second line of it. I’m talking about stateless pure functions with clear inputs and outputs, here you should only have to log the input, possibly also the output, the rest is reproducible. Some would call this tracing, not logging. The best systems are…

Agree. It is how and why you use a tool that matters. Not the tool itself. So judging people based on the tool they use is probably wrong. The fact that I have only seen bad developers use debuggers might just be a coincident.

Re: The Grug Brained Developer

#390

Post by bb88 »

Majestic121 wrote: post #384
bb88 wrote: post #349

Earlier quoted context omitted.

> if your PM is motivating you via threats, something is very wrong. Seriously? This is how 80% of companies work. In many of those companies, stack ranking is a very effective tool for running people out the door. It's often _baked_ into corporate culture.

If that's your experience, you either have been extremely unlucky, or you should look back on your own behavior. I've had some problems with PM before, but never about threats, and that would go very poorly with most people I know.

In 2022 what's the leading cause of people leaving a company?

Toxic Management / Toxic work culture.

https://www.cnbc.com/2022/01/14/the-biggest-reason-people-qu...

Modern management have had what? 100 years to fix this now?

Post reply on HN