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

491–500 of 603 posts

Re: The Grug Brained Developer (2022)

#491

Post by 1-more »

9rx wrote: post #490
1-more wrote: post #485

Earlier quoted context omitted.

In a world where I am writing a language with null and have half-implemented a grown up type system by checking for null everywhere and writing tests that try to call functions with null (EDIT: and I remembered to do all of that), I guess we could say that I'm at the same place I am right now. But right now I don't have to write defensive tests that include null. You're asking about a circumstance that's just very ve…

> But right now I don't have to write defensive tests that include null. You seem to misunderstand. The question was centred around the fact that unexpected null cases end up being tested by virtue of you covering normal test cases due to the constraints on execution. Explicitly testing for null is something else. Something else I suggest unnecessary — at least where null is not actually part of the contract, which f…

Oh the errant nulls only ever came up when I was writing dynamically typed languages. Is that what you're asking about?

Re: The Grug Brained Developer (2022)

#492

Post by 0xbadcafebee »

GMoromisato wrote: post #98

One of the many ironies of modern software development is that we sometimes introduce complexity because we think it will "save time in the end". Sometimes we're right and it does save time--but not always and maybe not often. Three examples: DRY (Don't Repeat Yourself) sometimes leads to premature abstraction. We think, "hey, I bet this pattern will get used elsewhere, so we need to abstract out the common parts of…

sometime grug spend 100 hours building machine to complete work, but manual work takes 1 hour. or spend 1 hour to make machine, lead to 100 hours fixing stupid machine.

dont matter if complex or simple, if result not add value. focus on add more value than detract, worry complexity after

Re: The Grug Brained Developer (2022)

#493

Post by joshvm »

nyarlathotep_ wrote: post #138
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…

> 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. One of the first things I do in a codebase is get some working IDE/editor up where I can quickly run the program under a debugger, even if I'm not immediately troubleshooting something. It's never long before I need to use it. I was baffled when I too encountered…

For desktop GUI development I can't imagine not using breakpoints and stepping. Especially when you have several ways that some callback might be triggered. It's super helpful to break on a UI element signal (or slot) and then follow along to see why things aren't working.

I don't use debuggers as often in Python, probably because it's eaiser to throw code in a notebook and run line by line to inspect variables, change/inject state and re-run. That's possible but a lot harder to do in C++.

Also for embedded work, using a debugger and memory viewer is pretty powerful. It's not something people think about for Arduino but almost every commodity micro supports some sort of debugwire-like interface (which is usually simpler than JTAG).

Re: The Grug Brained Developer (2022)

#494

Post by toastercat »

osigurdson wrote: post #396

While I agree that complexity is bad the fact that we don't really have a shared understanding of what complexity is doesn't help. At worst, it can be just another synonym for "bad" that passes through the mental firewall without detection. For instance is having multiple files in a project "complex"? If I am unfamiliar with a codebase is it "complex" and I therefore have to re-write it?

I think you hit the nail on the head. This article is definitely biased against modern front-end development for example and recommends HTMX as less "complex", but from what I've seen, using HTMX just trades one form of complexity for another.

This part:

> back end better more boring because all bad ideas have tried at this point maybe (still retry some!)

I entered a Spring Boot codebase recently, and it was anything but boring or "simple" -- everything is wrapped by convention in classes/abstract classes/extending layers deep of interfaces, static classes for single methods. Classic OO design that I thankfully moved away from after college.

I think the author makes good points, but I don't think the author is any different than your average developer who accuses the thing they are not familiar with to be "complex".

Re: The Grug Brained Developer (2022)

#495

Post by manmal »

dkarl wrote: post #103
default-kramer wrote: post #95

Earlier quoted context omitted.

I'm convinced that some people don't know any other way to break down a system into smaller parts. 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.

That's what I've observed empirically over my last half-dozen jobs. Many developers treat decomposition and contract design between services seriously, and work until they get it right. I've seen very few developers who put the same effort into decomposing the modules of a monolith and designing the interfaces between them, and never enough in the same team to stop a monolith from turning into a highly coupled amorph…

Put the modules in different git repos and interfaces will get super clean eventually.

Re: The Grug Brained Developer (2022)

#496

Post by soseng »

roncesvalles wrote: post #123
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'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…

Curious to learn more about why it is difficult to debug. I'm not familiar with service mesh. I also work at a large corp, but we use gateways and most things are event driven with kafka across domain boundaries. I spend most of my time debugging each service locally by injecting mock messages or objects. I do this one at a time if the problem is upstream. Usually, our logging helps us pinpoint the exact service at to target for debugging. It's really easy. Our devops infrastructure has built out patterns and libraries when teams need to mint a new service. Everything is standardized with terraform. Everything has the same standard swagger pages, everything is using okta, etc.. Seems a bit boring (which is good)

Re: The Grug Brained Developer (2022)

#497

Post by jesse__ »

kakuri wrote: post #475
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 loved Chrome's debugger for years, then build tools and React ruined debugging for me. Built code largely works with source maps, but it fails often enough, and in bizarre ways, that my workflow has simply gone back to console logs. React's frequent re-renders have also made breakpoints very unpleasant - I'd rather just look at the results of console logs. Are there ways I can learn to continue enjoying the debugge…

Agreed, debugging tools for the browser are almost comically incapable, to the point of not even useful in most cases.

Re: The Grug Brained Developer (2022)

#498

Post by sesm »

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…

Many talk complexity. Few say what mean complexity. Big brain Rich say complect is tie together. Me agree. Big brain Rich say complexity bad. Me disagree. Tie things necessary. If things not connected things not solve problem.

Re: The Grug Brained Developer (2022)

#499

Post by theshrike79 »

soseng wrote: post #496
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…

Curious to learn more about why it is difficult to debug. I'm not familiar with service mesh. I also work at a large corp, but we use gateways and most things are event driven with kafka across domain boundaries. I spend most of my time debugging each service locally by injecting mock messages or objects. I do this one at a time if the problem is upstream. Usually, our logging helps us pinpoint the exact service at t…

It's easy if Someone(tm) has already set up a system where you can whip up the relevant bits with something like localstack.

But if there is no support from anyone and you'll be starting from scratch, you've print-debugged and fixed the issue before you get the debugger attached to anything relevant.

Re: The Grug Brained Developer (2022)

#500

Post by recursivedoubts »

0xbadcafebee wrote: post #488
recursivedoubts wrote: post #450

Earlier quoted context omitted.

that's a good point, but complexity bad

if complexity bad, then houses bad, air conditioning bad, roads bad, clothing bad, farming bad, computers bad, .... simpler to live naked in wood, use big rock hunt food. but grug really like pizza. use computer order pizza, leave tip on app. grug no have to social interact, make grug happy. manage complexity well and it make good result, worth occasional pain. soon complexity become normal.

it's a good point, well worth considering, but also complexity bad
Post reply on HN