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

The Grug Brained Developer (2022)

grugbrain.dev

Post reply on HN
Print view View original

411–420 of 603 posts

Re: The Grug Brained Developer (2022)

#411

Post by jihadjihad »

frollogaston wrote: post #134
jiggawatts wrote: post #56

Earlier quoted context omitted.

I keep trying to explain this to tiny dev teams (1-2 people) that will cheerfully take a trivial web app with maybe five forms and split it up into “microservices” that share a database, an API Management layer, a queue for batch jobs to process “huge” volumes (megabytes) of data, an email notification system, an observablity platform (bespoke!) and then… and then… turn the trivial web forms into a SPA app because “t…

The only useful definition of a "service" I've ever heard is that it's a database. Doesn't matter what the jobs and network calls are. One job with two DBs is two services, one DB shared by two jobs is one service. We once had 10 teams sharing one DB, and for all intents and purposes, that was one huge service (a disaster too).

Great point. I've only worked at a couple places that architected the system in this manner, where the data layer defines the service boundary. It really helps keep the management of separate services sane IMO, vs. different "services" that all share the same database.

Re: The Grug Brained Developer (2022)

#412

Post by d4v3 »

magarnicle wrote: post #99

I know, I get it, but I've realised that I'm not actually grug-brained. The way my brain works, I remember things pretty well; I like to get into the details of systems. So if more complexity in the code means the app can do more or a task is automated away I'll make the change and know I'll be able to remember how it works in the future. This doesn't mean OP is bad advice, just make a conscious decision about what t…

big brain dev say, "me add complexity. no problem."

grug whisper: “problem come later.”

grug see lone dev make clever code.

grug light torch for future archaeologist.

Re: The Grug Brained Developer (2022)

#413

Post by momocowcow »

johnfn wrote: post #208
demosthanos wrote: post #127

Earlier quoted context omitted.

There was a good discussion on this topic years ago [0]. The top comment shares this quote from Brian Kernighan and Rob Pike, neither of whom I'd call a young grug: > As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program les…

On the other hand, John Carmack loves debuggers - he talks about the importance of knowing your debugging tools and using them to step through a complex system in his interview with Lex Friedman. I think it's fair to say that there's some nuance to the conversation. My guess is that: - Debuggers are most useful when you have a very poor understanding of the problem domain. Maybe you just joined a new company or are e…

This statement explain his position very clearly. Anyone who did any serious DOS programming understands it well.

"A debugger is how you get a view into a system that's too complicated to understand. I mean, anybody that thinks just read the code and think about it, that's an insane statement, you can't even read all the code on a big system. You have to do experiments on the system. And doing that by adding log statements, recompiling and rerunning it, is an incredibly inefficient way of doing it. I mean, yes, you can always get things done, even if you're working with stone knives and bare skins."

Re: The Grug Brained Developer (2022)

#414

Post by mort96 »

pjc50 wrote: post #371
mort96 wrote: post #274

Earlier quoted context omitted.

How long are you realistically "waiting for the compiler and linker"? 3 seconds? You're not recompiling the whole project after all, just one source file typically If I wanna use a debugger though, now that means a full recompile to build the project without optimizations, which probably takes many minutes. And then I'll have to hope that I can reproduce the issue without optimizations.

> How long are you realistically "waiting for the compiler and linker"? 3 seconds? This is the "it's one banana Michael, how much could it cost, ten dollars?" of tech. I don't think I've ever worked on a nontrivial C++ project that compiled in three seconds. I've worked in plenty of embedded environments where simply the download-and-reboot cycle took over a minute. Those are the places where an interactive debugger…

> I don't think I've ever worked on a nontrivial C++ project that compiled in three seconds.

No C++ project compiles in 3 seconds, but your "change a single source file and compile+link" time is often on the order of a couple of seconds. As an example, I'm working on a project right now where a clean build takes roughly 30 seconds (thanks to recent efforts to improve header include hygiene and move stuff from headers into source files using PIMPL; it was over twice that before). However, when I changed a single source file and ran 'time ninja -C build' just now, the time to compile that one file and re-link the project took just 1.5 seconds.

I know that there are some projects which are much slower to link, I've had to deal with Chromium now and then and that takes minutes just to link. But most projects I've worked with aren't that bad.

Re: The Grug Brained Developer (2022)

#415

Post by 0xbadcafebee »

Me no like grug perpetuate complexity myth. Little grugs no understand complexity is not monolith. Me want fix that.

Complexity not bad. Complexity just mean "thing have many consideration". Some thing always have many consideration. Not bad if useful and necessary.

Complexity still difficult and raise problem. So try avoid complexity when unnecessary and no add value. But shun complexity bad when it detract value or raise new problem.

Little grug benefit from not over-simplify. Not everything just good or bad, most thing both, it depend.

Re: The Grug Brained Developer (2022)

#416

Post by DangitBobby »

titanomachy wrote: post #115

“Good debugger worth weight in shiny rocks, in fact also more” I’ve spent time at small startups and on “elite” big tech teams, and I’m usually the only one on my team using a debugger. Almost everyone in the real world (at least in web tech) seems to do print statement debugging. I have tried and failed to get others interested in using my workflow. I generally agree that it’s the best way to start understanding a s…

Sometimes I need a debugger because there's a ton of variables or I just have no idea what's wrong and that's the easiest way to see everything that's going on. It's really frustrating to feel like I need a debugger and don't have a good way to add the IDEs visual debugger (because I'm using a CLI on a remote session or something). It's also really frustrating to be inside a debugging session and wish you knew what the previous value for something was but you can't because you can't go backwards in time. That happens so often to me, in fact, that print debugging is actually more effective for me in the vast majority of cases.

Re: The Grug Brained Developer (2022)

#417

Post by shadowgovt »

norir wrote: post #233
shadowgovt wrote: post #42

Earlier quoted context omitted.

Being at a firm where the decision to use C++ was made, the thought process went something like this: "We're going to need to fit parts of this into very constrained architectures." "Right, so we need a language that compiles directly to machine code with no runtime interpretation." "Which one should we use?" "What about Rust?" "I know zero Rust developers." "What about C++?" "I know twenty C++ developers and am conf…

The correct answer was almost surely lua + native modules for hotspots. I'm not surprised they couldn't see that though.

There's a layer that you could turn your head and squint and call Lua, but it's far more constrained than Lua is.

They never wanted to be in a situation in the embedded architecture where performance was dependent upon GC pauses (even incremental GC pauses). Their higher-level abstraction has tightly constrained lifecycles and is amenable to static analysis of maximum memory consumption in a way Lua is not.

Re: The Grug Brained Developer (2022)

#418

Post by ttoinou »

prmph wrote: post #405

> complexity very bad Oh boy, this is so true. In all my years of software engineering this is one of those ideas that has proved consistently true in every single situation. Some problems are inherently complex, yes, but even then you'd be much, much better off spending time to think things through to arrive at the simplest way to solve it. Again and again my most effective work has been after I questioned my prior…

Your two first examples, you just hide the complexity by using another tool, no ?

And I don’t see how number 3 is simpler. In my maths head I can easily create bijective spaces. Emulating backward migration through others means might be harder (depending on details of course thats not a general rule)

Re: The Grug Brained Developer (2022)

#419

Post by Nezteb »

octo888 wrote: post #234
titanomachy wrote: post #115

“Good debugger worth weight in shiny rocks, in fact also more” I’ve spent time at small startups and on “elite” big tech teams, and I’m usually the only one on my team using a debugger. Almost everyone in the real world (at least in web tech) seems to do print statement debugging. I have tried and failed to get others interested in using my workflow. I generally agree that it’s the best way to start understanding a s…

My hypothesis is that because we generally don't/can't use debuggers in production but rather rely on logging and tracing, that extends to local dev.

Agreed!

If you usually aren't able/allowed to use a debugger in production and must rely on observability tools, it's helpful to know how to utilize those tools locally as effectively as possible when debugging.

Re: The Grug Brained Developer (2022)

#420

Post by closeparen »

rcxdude wrote: post #285
closeparen wrote: post #258

Earlier quoted context omitted.

The service I'm working on right now has about 25 packages. From the language's perspective, each package is a "module" with a "public" API. But from the microservices architecture's perspective, the whole thing is one module with only a few methods.

But why would users of the module care about the dependency packages? You could still have a module with only a few methods and that's the interface.

If “everyone would just” restrict themselves to import only the package you meant to public API, sure, it would work. But everyone will not just.
Post reply on HN