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

271–280 of 394 posts

Re: The Grug Brained Developer

#271

Post by razzimatazz »

arthurcolle wrote: post #250
arthurcolle wrote: post #239

Earlier quoted context omitted.

These literally just get better and better. > big brain type system shaman often say type correctness main point type system, but grug note big brain type system shaman not often ship code. grug suppose code never shipped is correct, in some sense, but not really what grug mean when say correct! grug need start shiney rock deposit ritual for grug similar program shaman so grug has more club. maybe some club have spik…

More > grug warn closures like salt, type systems and generics: small amount go long way, but easy spoil things too much use give heart attack

Definitely saving that, translating it to interview-compatible speak, and springing it on future employers.

Actually I need to translate a good 75% of grug's teachings to interview compatible language...

Re: The Grug Brained Developer

#272

Post by hrayn3 »

greatpostman wrote: post #175
twhitmore wrote: post #107

Microservices grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too That made me laugh. The microservices madness of the past decade is now starting to settle down to more mature understandings, but there are still a lot people biting off large testing, operational, and data transactionality/ reporting costs. People often don't recognise beforehand the magnitude of…

I actually disagree. I think people disparaging micro services are working at companies or on problems that are too small for that solution

Agreed. My company has a (relatively) mature MFE platform, and it rocks. The MFE team handles builds, deployment, and can build features like experimentation into the platform, so the teams can focus on the MFEs. The MFEs are not arbitrarily small - they are related to specific experiences. A single MFE might be a collection of pages in a flow, for example. It means less work for devs, more consistency across a big company, and much safer deployments - the worst thing that can happen if you ship a bug is to tank your MFE because they're all isolated. At a big company, being able to change something small on your MFE and push to prod without worrying about every other page in the site is awesome.

Re: The Grug Brained Developer

#274

Post by eurasiantiger »

3np wrote: post #227
residualmind wrote: post #211

Earlier quoted context omitted.

Sorry to hijack without being asked. I totally agree with the original piece and this comment. For me the most important part is: no matter how complex your requirements are, how you deal with complexity and abstraction in your codebase and architecture, will make or break it. Abstractions should match what's actually happening (with just the minimal right amount of future telling). Useless abstractions and missing a…

grug think two is company but three is crowd. no refactoring new abstraction until same code in three places. sometimes crowd is fine too, if divided nicely. grug never saw point of new class with only fetchAndParseMany function. also why grog keep putting state in mutable instance properties on acting class when can just be parameter arguments? save so little typing but will for get curse. grug remembers making big…

Also known as the Rule of Three: https://en.wikipedia.org/wiki/Rule_of_three_(computer_progra...

Re: The Grug Brained Developer

#275

Post by dusted »

girvo wrote: post #73
dusted wrote: post #47

Earlier quoted context omitted.

> And if you wanted to do anything that wasn't a "solved problem" already, you had to write your own library. For which language is that statement not true ?

Their point is that the language they’re discussing requires you to write that library far more often than other languages, as a second order effect of few using it. But you know that already, you just want to make a semi-snarky reply instead, I guess.

No, I just sincerely don't believe that library availability indicates anything except library availability. It tells nothing about a language other than how man libraries are available.

Re: The Grug Brained Developer

#276

Post by eurasiantiger »

timr wrote: post #253
bb88 wrote: post #240

Earlier quoted context omitted.

> Anyway, it might be good to talk to your PMs and not assume they're evil villains. I've always thought PM's to be more or less aliens with a ray gun tapping at their watch. Communicating with them goes nowhere since they don't empathize with your point of view. The only thing they're concerned with is when something's going to get done. The only form of motivation is threat of existence in the company. > While I've…

I've been the guy who gets called at 4am when postgres takes a dump. I've also been the guy doing the calling (well, not really as a PM, since again, we don't generally have the ability to tell anyone what to do at 4AM , but I digress.) > Communicating with them goes nowhere since they don't empathize with your point of view. Can't speak for everyone, but again, I've been on both sides of the table, and I've never se…

I think the grandparent meant that the PM is motivated by the threat of having to leave due to a failing project.

Re: The Grug Brained Developer

#277

Post by bigDinosaur »

koonsolo wrote: post #120
recursive wrote: post #90

Earlier quoted context omitted.

npm, babel, webpack, module compatibility, et al

You are free to develop everything in vanilla JavaScript and run your coded scripts straight in the browser. Very non-complex. But the team that uses npm, babel, webpack etc will crush you both on development speed and stability.

Webpack is by far the worst tool I've ever used in my development career so far. I never want to see it again, yet using it has allowed me to do things that otherwise would have been a major problem. Something can be useful, but still hideous beyond belief in terms of complexity.

Re: The Grug Brained Developer

#278

Post by eurasiantiger »

galaxyLogic wrote: post #124
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…

You have the right insight I think. The thing about putting lots of effort into "refactoring" is that the code you refactor may actually not end up in the product at all. I think "prototyping" is better than "refactoring". Prototyping basically means that you write your app more than once. On the 2nd round you know what needs to be there and what not. You may have come up with a much better much simpler design for th…

Refactoring is probably a sign of problems, unless by refactoring one means ”giving abstract structure to yet unstructured code”, i.e. factoring for the first time.

That needs to happen after feature-completeness, but before a project goes into maintenance.

Re: The Grug Brained Developer

#279

Post by eurasiantiger »

NateEag wrote: post #252
mecha_ghidorah wrote: post #247

Earlier quoted context omitted.

I definitely think prototyping should be more common but the problem is I've been burned before. "Just build a version of this thing as quickly as you can. Don't worry about performance or anything so much, the goal is to get an idea of what these features might actually feel like to use so this is just a proof-of-concept project" Then "Oh hey we are going to give that proof-of-concept project to a client to try out…

The key to having prototypes and PoCs work out okay is to leave some important piece of UX out entirely. Such an approach gets you the benefits of being able to explore a problem space with code in a quick, sloppy manner, without any risk of anyone actually deploying what you wrote.

Never make prototypes easy on the eyes. Use Comic Sans liberally. That way nobody will assume it is the final application which just needs a few touches.
Post reply on HN