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

421–430 of 603 posts

Re: The Grug Brained Developer (2022)

#421

Post by patrickmay »

giantrobot wrote: post #125
demosthanos wrote: post #107

Earlier quoted context omitted.

> To these people, if it's not exposed as a API call it's just some opaque blob of code that cannot be understood or reused. I think this is correct as an explanation for the phenomenon, but it's not just a false perception on their part: for a lot of organizations it is actually true that the only way to preserve boundaries between systems over the course of years is to stick the network in between. Without a networ…

3. Company structure poorly supports cross-team or department code ownership Many companies don't seem to do a good job coordinating between teams. Different teams have different incentives and priorities. If group A needs fixes/work from group B and B has been given some other priority, group A is stuck. By putting a network between modules different groups can limit blast damage from other teams' modules and more c…

[O]rganizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.

— Melvin E. Conway, How Do Committees Invent?

Re: The Grug Brained Developer (2022)

#422

Post by phito »

thunspa wrote: post #362
phito wrote: post #282

Earlier quoted context omitted.

Yes, it's perfectly doable even if you're doing microservices. Not being able to debug your application is an engineering failure.

can you say more? how do you do it?

We mostly have dotnet services in k8s, using Rider (IDE) and Telepresence for remote debugging. Having observability (OpenTelemetry) is also really useful.

Re: The Grug Brained Developer (2022)

#423

Post by patrickmay »

jiggawatts wrote: post #76
djeastm wrote: post #65

Earlier quoted context omitted.

>I keep trying to explain this to tiny dev teams I'm curious what role you have where you're doing this repeatedly

The customer is a government department formed by the merger of a bunch of only vaguely related agencies. They have “inherited” dozens of developers from these mergers, maybe over a hundred if you count the random foreign outsourcers. As you can imagine there’s no consistency or organisational structure because it wasn’t built up as a cohesive team from the beginning. The agencies are similarly uncoordinated and will…

> some backwards part of the world like Paris.

This alone earns my upvote.

Re: The Grug Brained Developer (2022)

#424

Post by kossae »

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…

I still don't understand how, with a properly configured debugger, manually typing print statements is better than clicking a breakpoint at the spot you were going to print. Context overload might be an issue, but just add a 'watch' to the things you care about and focus there.

Re: The Grug Brained Developer (2022)

#425

Post by monkeyelite »

frollogaston wrote: post #131
roncesvalles wrote: post #123

Earlier quoted context omitted.

I'd love to use a real debugger but as someone who has only ever worked at large companies, this was just never an option. In a microservices mesh architecture, you can't really run anything locally at all, and the test environment is often not configured to allow hooking up a stepping debugger. Print debugging is all you have. If there's a problem with the logging system itself or something that crashes the program…

Same, this isn't my choice, debuggers don't work here. And we don't even have microservices.

> debuggers don't work here

It’s impossible? Or would take engineering work to enable

Re: The Grug Brained Developer (2022)

#426

Post by connicpu »

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…

I love debuggers, but unfortunately at my current job I've found that certain things we do to make our application more performant (mainly using giant structs full of fixed size arrays allocated at the start of the application) cause LLDB to slow to a crawl when `this` points to them. It really really doesn't like trying to read the state of a nearly 1GB struct...

Re: The Grug Brained Developer (2022)

#428

Post by prmph »

ttoinou wrote: post #418
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)

I'm not sure where the complexity is hiding in my examples.

For the code generation, note that some types are almost impossible to express properly, but code can be generated using simpler types that capture all the same constraints that you wanted. And, of course I only use this approach for cases where it is not that complicated to generate the code, and so I can be sure that each time I need to (re)generate it, it will be done correctly (ie., the abstraction is not leaky). Also, I don't use this approach for generating large amounts of code, which would hide the inherent structure of the code when reading it.

For the eslint example, I simply made do without depending on linting as a hard dependency that is always active. That is one of my points: sometimes simply some "niceties" would simplify thing a lot. As another example in this vein, I avoid too much complex configuration and modding of my dev environment; that allows me to focus on what matters.

In the migration example, the complexity with backward migration is that you then need to write a reverse migration script for every forward migration script. Keeping this up and managing and applying them properly can become complex. If you have a better way of doing it I'd like to hear it.

Re: The Grug Brained Developer (2022)

#429

Post by Xenoamorphous »

pbohun wrote: post #403
isoprophlex wrote: post #330

Earlier quoted context omitted.

I swear I'm not making this up; a guy at my current client needed to join two CSV files. A one off thing for some business request. He wrote a REST api in Java, where you get the merged csv after POSTing your inputs. I must scream but I'm in a vacuum. Everyone is fine with this. (Also it takes a few seconds to process a 500 line test file and runs for ten minutes on the real 20k line input.)

Was it joining on some columns or just concatenating the files? I'm going to laugh pretty hard if it could just be done with: cat file1.csv file2.csv > combined.csv

You need to account for the headers, which many (most?) csv files I've encountered have.

So I guess something like this to skip the headers in the second file (this also assumes that headers don't have line breaks):

  cp file1.csv combined.csv && tail -n+2 file2.csv >> combined.csv

Re: The Grug Brained Developer (2022)

#430

Post by zeta0134 »

kossae wrote: post #424
johnfn wrote: post #208

Earlier quoted context omitted.

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…

I still don't understand how, with a properly configured debugger, manually typing print statements is better than clicking a breakpoint at the spot you were going to print. Context overload might be an issue, but just add a 'watch' to the things you care about and focus there.

Two situations immediately come to mind, though the second is admittedly domain specific:

1. If I actually pause execution, the thing I'm trying to debug will time out some network service, at which point trying to step forward is only going to hit sad paths

2. The device I'm debugging doesn't *have* a real debugger. (Common on embedded, really common for video games. Ever triggered a breakpoint in a graphics shader?) Here I might substitute "print" for "display anything at all" but it's the same idea really.

Post reply on HN