Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Choose Boring Technology (2015)

boringtechnology.club

Post reply on HN
Print view View original

281–290 of 374 posts

Re: Choose Boring Technology (2015)

#281

Post by andrewflnr »

iamacyborg wrote: post #33

Urgh, this feels familiar. Last year I left a company that was just wrapping up a new tech product, everything was microservices and mongodb. Trying to get a simple answer out of the engineering team about something as trivial as “how can I get a list of customers who have purchased product X” was almost impossible. They sure had fun building it though.

In the event you haven't already seen it, you may find this skit amusing and/or sob-inducing. https://youtu.be/y8OnoxKotPQ

Ed: I'm an idiot.

Re: Choose Boring Technology (2015)

#282

Post by postfacto »

thewarrior wrote: post #179
Nextgrid wrote: post #63

Earlier quoted context omitted.

In the case of a lot of tech companies, the entire market is broken and leads to weird incentives rarely seen in any other industry: companies that aren’t profitable, don’t have a real product people pay for, don’t have a clear, plausible path to profitability and yet somehow stay in business because investors are happy to burn money. This completely reverses the typical market dynamics. The company is more focused o…

Job hopping programmers are compensated for how rare their skill is and not how much value they add to the business. It’s another flaw in capitalism. Reward employees a direct and substantial cut of the profits and incentivize to them to stay 5-10 years and these behaviors should disappear. The loss of job security, frequent job hopping has created more incentives to optimize for the next job switch and not value add…

Why the downvotes? This comment’s dead accurate.

Re: Choose Boring Technology (2015)

#283

Post by syastrov »

Reading this sounds like dejavu.

A company I’ve worked with also had a PHP monolith which was supposed to be split up into microservices to improve maintainability. The choice of language was free, and the first ones were, kid you not, written in PHP using some alpha-quality library which was supposed to make PHP asynchronous, to improve “scalability”. Comically, this stack was used in an image-serving service which had to perform blocking image resizing using ImageMagick. Due to this misunderstanding of the technology, the only way to keep it afloat was to run 90 containers in a home-managed Kubernetes cluster just to keep requests from queuing up. Another comic misunderstanding of this paradigm was when I traced down a bug where the process seemed to hang due to the fact that the developer had intentionally added a call to sleep in a loop. Coming from a Java/.Net background, they believed it would cause the “current thread” to sleep in order to not hog resources. This was problematic since the application (like nodejs) was single-threaded.

I didn’t want to work with that stack, so when it was my turn to work on a new microservice, I chose Scala + MongoDB (same as Etsy) because I wanted to learn about functional programming. Ironically, the microservice was basically a “checkbox as a service”, but I and the tech lead on the team were too brainwashed/high on learning new things to realize the overcomplexity.

The entire thing was an expensive lesson that I and some others got to learn from. The ones who didn’t learn kept their microservices ideology and found other jobs.

Fast-forward and the entire thing was scrapped and rewritten as a Django + Postgres monolith. Not to say that it wasn’t costly to do a rewrite, but infinitely less costly than continuing down the microservices road. Long live boring technologies.

Re: Choose Boring Technology (2015)

#284

Post by dehrmann »

tluyben2 wrote: post #249
Nextgrid wrote: post #63

Earlier quoted context omitted.

In the case of a lot of tech companies, the entire market is broken and leads to weird incentives rarely seen in any other industry: companies that aren’t profitable, don’t have a real product people pay for, don’t have a clear, plausible path to profitability and yet somehow stay in business because investors are happy to burn money. This completely reverses the typical market dynamics. The company is more focused o…

I often wonder why investors love paying 5 figure aws bills; even worse, why they consider lower bills or not using 'the cloud' a sign of cto incompetence. Even if the company can run on $500 hosting instead. Must be because it is easy to do DD on: AWS, check, TS (JS is now a reason to not pass VC dd I heard from friends) check , React check, microservices, check, etc.

There's definitely a stage for startups where the AWS bill doesn't matter because sustaining user growth is more important, but there's also a stage where the company, usually B2B, is trying to improve margins because it helps a lot with valuation.

Re: Choose Boring Technology (2015)

#285

Post by elonvolo »

There’s a lot of social status and perception-shaping tied up in who gets to do what innovation.

I’ve noticed that the very same ilk of leadership/managers who would balk at the complexity of adding a linter or json schema validation and cite “someday, that would be nice, but for now we’ve got to get quick wins and ship features” would not hesitate to let a golden-boy architect who’s also a drinking buddy add a CQRS microservice written in Go communicating in some hand-rolled bespoke protocol—-just because it wins some folks cool points.

Re: Choose Boring Technology (2015)

#286

Post by acemarke »

wwww4all wrote: post #248
acemarke wrote: post #216

Earlier quoted context omitted.

Not sure what you mean by the "pretends" statement. Both the Redux core and Redux Toolkit _are_ completely UI-agnostic, and can be used with _any_ UI layer or even standalone. Yes, most Redux usage is with React, and we do orient our docs around the assumption that you're probably using Redux and React together, but there's many people who are using Redux separately.

The “pretends” comment is light hearted joke (or is it?) about keeping Redux UI library agnostic. When we all know React is the 8000 pound gorilla pulling on Redux. The default assumption for any production React application is that it will need Redux at some point. It’s much more efficient to start the React project with Redux, than trying to bolt on Redux after React project is underway after a while. Redux Toolkit…

Fair enough :)

Yeah, as I've been redoing our docs, I've really tried to emphasize the "take some time to decide if you _really_ need Redux" aspect:

https://redux.js.org/tutorials/essentials/part-1-overview-co...

FWIW, we do take the "UI-agnostic" part seriously. We've got an upcoming new API for Redux Toolkit that we've dubbed "RTK Query", currently available as a preview release. We've got an example of it working with Svelte, and I know I saw someone else trying it out with Vue:

https://rtk-query-docs.netlify.app/examples/svelte

Re: Choose Boring Technology (2015)

#287

Post by asphaltycode »

ChrisMarshallNY wrote: post #140
_qulr wrote: post #134

Earlier quoted context omitted.

> I don’t do “boring,” as much as I do “mature and robust.” > I’ve been writing in Swift since the day it was announced May I ask how you consider these to be compatible?

> May I ask how you consider these to be compatible? It was a calculated risk. Since the company I was working for, at the time, was never going to use Swift, my "bread and butter" was at no risk, whatsoever. We were a C++ shop. I just started working with it on nights and weekends. Being a C++ shop, however, we were quite familiar with Lattner and LLVM, so we were aware of his propensity for WIN. That gave me some c…

I appreciate these posts quite a bit. Can you give another example of “playing the long game”?

Re: Choose Boring Technology (2015)

#288

Post by Aeolun »

reader_mode wrote: post #71

> My friend Andrew wears the same brand of black shirt every day. He thinks that if he conserves the brainpower it would take to pick something to wear, he’ll bank it and be able to use it later for something else. >I don’t know if this makes sense for fashion or what have you, but I really think there is something to this. Johny Bravo was conserving his brainpower all along ! I kind of like this idea, will probably…

This works just as well with a slightly more diverse outfit. I have 3 pants, and 5 shirts, any combination between these is fine, so I just wear what isn’t being washed at the time.

Re: Choose Boring Technology (2015)

#289

Post by oblio »

andrewflnr wrote: post #281
iamacyborg wrote: post #33

Urgh, this feels familiar. Last year I left a company that was just wrapping up a new tech product, everything was microservices and mongodb. Trying to get a simple answer out of the engineering team about something as trivial as “how can I get a list of customers who have purchased product X” was almost impossible. They sure had fun building it though.

In the event you haven't already seen it, you may find this skit amusing and/or sob-inducing. https://youtu.be/y8OnoxKotPQ Ed: I'm an idiot.

Link?

Re: Choose Boring Technology (2015)

#290

Post by Aeolun »

BigJono wrote: post #176
criddell wrote: post #130

Earlier quoted context omitted.

And what about the front end? What's the best, most boring choice there? I was on a project for a bit using React and although it felt like an obvious way to write things, I can't help but feel you can't create something that will last for a decade with it.

You absolutely can. React is the gold standard right now. It's already been king for 6 years and it's not going anywhere. The hype for angular died down. The hype for vue has started to die down. This little bit of hype svelte has at the moment will die down. React does have a ton of problems but they all come from the next level of dependencies down. Shit like Gatsby and Nextjs won't pass the test of time. Neither w…

> Neither will redux (it's already pointless) and all the convoluted bullshit like redux-saga.

I can’t speak to your own use case, but redux and saga absolutely save our bacon when working on a huge enterprise app.

I don’t even want to think about the crazy kinds of stuff we’d have to do without them.

Maybe someone will come up with a better abstraction, but I really think these are fairly good ones.

Post reply on HN