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

361–370 of 394 posts

Re: The Grug Brained Developer

#361

Post by dgroshev »

lowercased wrote: post #330
zero_shift wrote: post #128

Earlier quoted context omitted.

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…

Do you know what corners can't be cut in advance though? Sure, you can have a tiny post-seed team bogged down for a month rolling out Hashicorp Vault for everything because "that's how it should be done", or play forever with microservices, or roll out Bazel in a two person team writing Python, don't ship enough, and get out of business. Alternatively, they can be passing an .env file with secrets around, build a monolith, and deploy it with bash/make. It might be tedious or even dangerous at some scale, but which way would leave more time to create real-world value, hopefully somewhat captured and used to pay salaries?

The question of responsibility is a funny one. For every PM jumping ship and leaving developers with tech debt, there are tens of developers bogging businesses down with unnecessary complexity [1] and jumping ship with newly padded CVs. Do you think it's any better? In fact, what do you think is worse for the world?

[1] Too much complexity can kill a business much faster than failing to scale. Loads of unicorns were unstable and failing under load (failwhale!), but that's a problem that comes with customers, which means money, which means it's much easier to resolve than having no money and a beautiful scalable stack.

Re: The Grug Brained Developer

#363

Post by collyw »

strikelaserclaw wrote: post #195
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.

microfront ends work well for self contained components that need to be used in multiple pages, they don't even need to have a "separate" backend, as long as there is an area or code file for the backend code that deals with whatever data the microfront end needs.

What kind of component are you talking about? Could you give an example, because as a backend dev, I have no idea what sort of thing would require that level of separation.

Re: The Grug Brained Developer

#364

Post by collyw »

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

I disparage them, because most companies including my own don't need them. My team are keen, but I can only see it adding complexity. If your company genuinely operates at that scale go for it. But remember that Stack overflow runs on a pretty classical architecture.

https://stackexchange.com/performance

Re: The Grug Brained Developer

#365

Post by wizofaus »

necovek wrote: post #313
dangerface wrote: post #302

Earlier quoted context omitted.

> Former engineer turned PM here. I think you'r experience as an engineer has biased your view. For example number 3 with your engineering experience you might think that but ultimately it's the engineering team that has to deal with the scaling not you. Your incentives are to scale everything back to meet dead lines while the engineers incentive is to make every thing work so that when it goes live they don't get ca…

As mostly an engineer (though I've spent time as a tech/team lead and engineering manager in the past), I think you've missed the point. Most of the things will not need to be "scaled" at all. Ever. As an engineer, I mostly struggle to come up with a simple solution while accommodating all the crappy, leaky abstractions in the rest of the code: that's the hard part of the job. And 20 years in, I still wonder why peop…

Indeed, concern about how well your product might scale to handle high load and use of umpteen layers of abstraction sounds somewhat contradictory to me! (I'd also say most scaling problems aren't necessarily all that hard to solve, but having some idea of what limits might be hit fairly quickly if there was an anticipated need to grow the userbase is a pretty key part of building SaaS platforms. Even single user apps can suffer from scaling issues if suddenly they're expected to deal with far more data than anyone had bothered testing with. Allowing the engineering team, including QA, time to assess potential scaling issues is surely the first step.)

Re: The Grug Brained Developer

#366

Post by collyw »

nisegami wrote: post #341
jstanley wrote: post #18

> grug no able see complexity demon, but grug sense its presence in code base This is the key problem with complexity. Complexity is fine if you understand it! It's when you're aware that something is complex, but you start to get these mental force-fields pushing you aware from the scary parts, that it becomes a problem. > demon complexity spirit mocking him make change here break unrelated thing there what!?! That'…

>but then 3 years later you realise something you somewhat care about has been silently broken for a very long time The trick is to never stay somewhere long enough to feel the consequences of your bad decisions

Your reply made me smile, but it's the opposite that has given me my biggest learning experiences. Greenfield projects that you stay on a while. You only have yourself to blame when there are problems a few years in.

Re: The Grug Brained Developer

#367

Post by collyw »

Tade0 wrote: post #351
collyw wrote: post #323

Earlier quoted context omitted.

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…

That's just React, which both has the highest market share and a culture of following the latest fad combined with piecing together applications from multiple tiny modules(because "it's a library not a framework"). Also jQuery becomes slow and unmaintainable very fast, especially considering that modern frameworks do a lot of tricks to increase performance, like detecting a row swap in a list. Next gen frameworks lik…

Angular is at least as bad. The whole thing is a mess. I miss the days of server side rendering and JQuery.

Re: The Grug Brained Developer

#368

Post by recursive »

koonsolo wrote: post #291
recursive wrote: post #209

Earlier quoted context omitted.

Vanilla js can do all that. Just `import` and done. No build steps.

IE users are now complaining that your site doesn't work. Like I said, stability.

I wouldn't call that stability. You might. I have the luxury of never caring about problems like that. Most people can probably achieve it now that IE is officially super-dead or whatever.

Re: The Grug Brained Developer

#369

Post by recursive »

koonsolo wrote: post #290
recursive wrote: post #199

Earlier quoted context omitted.

Speed maybe. But stability? Hard to imagine how that stack of build tools is going to provide more stability.

The obvious ones: Typescript + eslint + jest + Selenium. More complexity, high return on investment. The non obvious ones: Without babel you are either writing legacy JavaScript (which is arguably not as clean and easy to read), or users will complain your site is not working on their older browser.

How old is legacy? I seem to do ok using most ES6 features. I still am not a fan of javascript, but the newer features don't do much. It's not really a readability thing, but the one JS feature I'm holding my breath for is native decimals. I could really use that.

Re: The Grug Brained Developer

#370

Post by razzimatazz »

raphlinus wrote: post #229
raphlinus wrote: post #86

Earlier quoted context omitted.

I might be willing to give this a shot. I appreciated the charm and humor in the original, but especially for readers who don't have English as a first language it probably gets in the way of the message.

Here are the first few sections: https://gist.github.com/raphlinus/f6b34f85d63c4b73a0242481ed... I'll keep going if there's positive feedback, delete it if the author doesn't appreciate it.

I like it. It still carries a little bit of whimsy and puts a smile on my face (while nodding).
Post reply on HN