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

401–410 of 603 posts

Re: The Grug Brained Developer (2022)

#401

Post by fredrikholm »

isoprophlex wrote: post #330
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.

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.)

The worst part of stories like this is how much potential there is in gaslighting you, the negative person, on just how professional and wonderful this solution is:

  * Information hiding by exposing a closed interface via the API
  * Isolated, scalable, fault tolerant service
  * Iterable, understandable and super agile
You should be a team player isophrophlex, but its ok, I didn't understand these things either at some point. Here, you can borrow my copy of Clean Code, I suggest you give it a read, I'm sure you'll find it helpful.

Re: The Grug Brained Developer (2022)

#402

Post by avhception »

ronjakoi wrote: post #161
avhception wrote: post #122

Earlier quoted context omitted.

Using a debugger on my own code is easy and I love it. The second the debugger steps deep into one of the libs or frameworks I'm using, I'm lost and I hate it. That framework / lib easily has many ten thousands of person-hours under it's belly, and I'm way out of my league.

But you can just use the "step out" feature to get back out when you realise you've gone into a library function. Or "step over" when you can see you're about to go into one.

While that's true, it doesn't necessarily help me understand why my parameters for said lib or whatever lead to things blowing up.

Re: The Grug Brained Developer (2022)

#403

Post by pbohun »

isoprophlex wrote: post #330
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.

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

Re: The Grug Brained Developer (2022)

#404

Post by eptcyka »

tcoff91 wrote: post #255
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…

Adding print statements sucks when you are working on native apps and you have to wait for the compiler and linker every time you add one. Debuggers hands down if you are working on something like C++ or Rust. You can add tracepoints in your debugger if you want to do print debugging in native code. In scripting languages print debugging makes sense especially when debugging a distributed system. Also logging works b…

Intoruding logging can actually hide concurrency bugs.

Re: The Grug Brained Developer (2022)

#405

Post by prmph »

> 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 approaches and radically simplified things. You might lose some potential flexibility, but in most case you don't even need all that you think you need.

Some examples:

- Now that reasonably good (and agentic) LLMs are a thing, I started avoiding overly complex TypeScript types that are brittle and hard to debug, in favor of writing spec-like code and asking the LLM to statically generate other code based on it.

- The ESLint dependency in my projects kept breaking after version updates, many rules were not sophisticated enough to avoid false positives, and keeping it working properly with TypeScript and VSCode was getting complicated. I switched to Biome.js, and it was simpler and just as effective. However, I'm recently having bugs with it (not sure if Biome itself or the VSCode extension is to blame). But whatever, I realized that linting is a nice-to-have, not something I should be spending inordinate amount of times babying. So I removed it from the build tool-chain, and neither do I even need have it enabled all the time in VSCode. I run Biome every now and then to check the code style and formatting , and that's it, simple.

- Working on custom data migration tooling for my projects, I realized forward migrations are necessary to implement, but backwards migrations are not worth the time and complexity to implement. In case a database with data needs to be rolled back, just restore the backup. If there was no data, or it is not a production database, just run the versioned initialization script(s) to start from a clean state. Simple.

Re: The Grug Brained Developer (2022)

#406

Post by recursivedoubts »

tannhaeuser wrote: post #262
factorialboy wrote: post #4

From the creator of HTMX.

grug guy THINK big brain and make up hypermedia api and so complicated words like revealed religion but only in his imagination. more important app is like how programmer intended. web only for docs like unix files anyway no good to think too much.

i've seen things you wouldn't believe...

Re: The Grug Brained Developer (2022)

#408

Post by recursivedoubts »

Jean-Papoulos wrote: post #307

I argue that complexity is good. Complicated things though, those are bad. The world is complex, and we must deal with it. But as long as we organize our work and don't let it spiral into being complicated , we'll be fine.

very hard for most developers (maybe even you) to tell the difference

"be organized" is, of course, good advice

Re: The Grug Brained Developer (2022)

#410

Post by recursivedoubts »

r-bryan wrote: post #252

Oh FFS why is print-vs-debug being debated as either/or? Both can be valuable, depending on the circumstances. It's clearly both/and.

it's not presented as either-or in the article: i talk about how debuggers AND logging are both important tools
Post reply on HN