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

321–330 of 394 posts

Re: The Grug Brained Developer

#321

Post by collyw »

bigiain wrote: post #192
maest wrote: post #87

> sometimes probably best just not tell project manager and do it 80/20 way. easier forgive than permission, project managers mind like butterfly at times overworked and dealing with many grugs. In my experience, I have to fight to keep my devs from over engineering their solutions and just get something going. I'd love to work with a dev who's happy to think about how to most quickly deliver value and who's willing…

> Many of the devs I've had to work with were more interested in building pristine codebases with clever abstractions and ability to scale to unnecessary numbers of users or bytes. I've worked with my share of them, but I've also worked with my share orders who'll hack together the quickest possible kludge that meets enough of the requirements to seem to work on the surface. Interestingly, given the choice, I'd have…

> I really like having the "architecture astronauts" being involved in the very early stage of greenfield projects. Their desire to push the boundaries can help ensure you start off on a great foundation.

I would argue the opposite, having inherited a complete shambles. Started when Mongo was peak hype, but would be far better suited to a relational database. Lots of developer time spent to run on Kubernetes, so we can scale, even though we are in no danger of a having high volume of customers in the forseeable future (it's a very specialized domain).

Re: The Grug Brained Developer

#322

Post by collyw »

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…

Really depends on what you are coding. I have my debugger set up, it's easier then trying top spot the new print statement in amongst all the other log statements being spat out.

Re: The Grug Brained Developer

#323

Post by collyw »

49531 wrote: post #67
armatav wrote: post #24

Now this is a good post. Especially the part about the frontend Complexity Demon having a grip on the entire industry, and the Fear Of Looking Dumb. It goes hand in hand.

> frontend Complexity Demon having a grip on the entire industry Is frontend web development more complex than it needs to be? If so, how?

Incredibly so. Our frontend devs gave us a talk on React (mainly for backend devs, who know enough frontend to fix bugs). Diagrams with arrows here there and everywhere. NPM install downloads a significant chunk of the internet just to display a hello world page. Compared to what I was doing in Django with server side templates and a bit of JQuery a few days ago this is incredible. It takes twice the works, for very limited benefit in our case at least. Most web apps are just displaying some data and a bit of form validation.

Re: The Grug Brained Developer

#324

Post by Torn »

ngc248 wrote: post #304
strix_varius wrote: post #140

Earlier quoted context omitted.

I don't know if this is universal, but in my circles "microfrontends" are now all the rage. How do you bring up concerns with that in good faith? It's so obviously terrible that I've no idea where to begin.

MicroFrontEnds (MFE) solve an actual problem, but it becomes a problem if developers do it for the sake of RDD (Resume Driven Development) or just because. My Company has a Cloud platform which is kinda like a marketplace and users can install and uninstall apps/services. In our case MFEs are a perfect fit.

iframes also work pretty well for this kinda thing :D

Re: The Grug Brained Developer

#325

Post by collyw »

TheOtherHobbes wrote: post #109
MrPatan wrote: post #27

This is true and excellent, and I'd put it next to Hickey's "Simple made easy" and Metz' "The Wrong Abstraction" as something I wish every developer would grok.

In "Simple Made Easy" he's recommending XML, JSON and even SQL for data. So I'm going to have go to with "No." All that does is move somewhat messy language constructs into somewhat messy data constructs. The data is static-ish, which is nice. But the associated code has exploded in complexity and with XML particularly you can't even be sure if it's truly compliant - especially if it's coming from an outside source.…

> even SQL for data

I am lacking context, but SQL was made for data.

Re: The Grug Brained Developer

#326

Post by Tao3300 »

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…

> In some languages if I saw someone adding a log statement while debugging I would immediately classify them as a junior programmer and start teaching them how to debug properly.

Ah, the awkward "tween" stage of development. If you don't switch to the management track, you'll skin your knees enough times to learn when you need one and not the other.

Re: The Grug Brained Developer

#327

Post by Tao3300 »

nerdponx wrote: post #101
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…

Printf bad, log good. Grug already have logging in app. Grug use logging, Grug no reinvent logging with printf.

Except when the complexity demon creeps into the logger. That was a thing quite recently.

Re: The Grug Brained Developer

#328

Post by eurasiantiger »

achenet wrote: post #308
eurasiantiger wrote: post #281

Earlier quoted context omitted.

Imagine going to a master craftsperson, and telling them you want them to give you the 80% experience for 20% of the price. How to do that without being disrespectful? How come programmers accept this kind of disrespect for their craft? Aren’t they supposed to be the masters, the Hattori Hanzos of program code?

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 luthier, however, and the story is very different. All their instruments are unique, and they may work on some complex ones for a long time before they decide it is ”good enough” for their standards of quality.

In the same sense, independent masons and smiths are, of course, more aligned with software engineering than any of their corporate counterparts—if any, because these professions are rather contracting-oriented.

Maybe seeing complexity as inherently problematic is actually a coping strategy employed by software craftspersons who have struggled with corporate demands such as inhuman work allocation and deadlines, internalised those demands as ”the way business OUGHT TO be done” (as if expecting a punishment for doing otherwise), and eventually become grugs who shake their club at anyone who triggers their corporate PTSD.

I really hope the grug meme does not become reality.

Re: The Grug Brained Developer

#329

Post by residualmind »

juki wrote: post #319
residualmind wrote: post #218

Earlier quoted context omitted.

Some debuggers take longer(1-3 secs) to spin up than it takes me to add a print, compile and run and see my theory confirmed or not. If I want a debugger and see e.g. the complete variable scope at a breakpoint, I'll use a debugger. If I just want a very quick sanity check I'll use a simple print. Once you enter debugger land you're there. When I'm currently not in the debugger but rather compiling and executing "for…

> You have to step through the breakpoints, right? This seems to be a common misunderstanding, but debuggers generally also support logpoints (print statements that you can add/remove on the fly without having to close, compile and restart the application).

Point taken, I might have to look at a different debugger supporting loglines for my current setup. Still, the time it takes to execute would be a concern for me. But I am going to check out other debuggers.. hope they're snappy.

I do like to step through code with a debugger when I need it. But that's rarely the case. The usual bug-hunt is something like: Do we go down path A or path B and whats the value of C before and after. Ideally, there is already logging in place that gives me exactly the info I need. If not, to me adding 2 prints or expanding the log usually seems just way more sane than spinning up a debugger, when I'm already looking at stdout/logs and I just need a tiny bit of additional info in there. Maybe I need a faster machine, lol.

Tracing is also a great tool, imho.

Re: The Grug Brained Developer

#330

Post by lowercased »

zero_shift wrote: post #128
maest wrote: post #87

> sometimes probably best just not tell project manager and do it 80/20 way. easier forgive than permission, project managers mind like butterfly at times overworked and dealing with many grugs. In my experience, I have to fight to keep my devs from over engineering their solutions and just get something going. I'd love to work with a dev who's happy to think about how to most quickly deliver value and who's willing…

It's a question of incentives and accountability. PMs aren't usually accountable when their shortcuts come and bite the team further down the line. Developers feel the pain instead. PMs won't be honest with the business that they sold an undercooked product. Need to suddenly scale up that "pragmatically" designed database? I know in my heart that too many PMs will _never_ manage expectations with their superiors if t…

> PMs aren't usually accountable when their shortcuts come and bite the team further down the line.

Years ago, was in a situation where I was working with a PO/PM set of folks (rotated around a bit, but a small team). Multiple times I would suggest X, and get "No, that's confusing, we won't need it, that will confuse users, we will never need that, etc". Then... they're gone, and the new replacements are asking "why don't we have X?"

Similarly, "hey, I need to do XYZ on feature ABC". Reply along the lines of "hey, don't worry - we just need the minimum thing up now - we'll revisit later. I will take responsibility if there's any fallout from this decision." That phrase was used multiple times over the 12-18 months.

Guess who's not here any more to answer any of the 'cut these corners' decisions? Yep - that product person who said "I'll take responsibility". Who isn't around any longer.

Many things that were assumed to be 'done' because they'd been discussed earlier were later discovered to be severely cut down or missing altogether.

What's strange to me is I've seen this pattern play out probably 3 or 4 times over the past... 20 years or so. I learned it certainly wasn't a one-off unique-to-personX thing.

Post reply on HN