Live data from Hacker News

Choose Boring Technology (2015)

boringtechnology.club

361–370 of 374 posts

Re: Choose Boring Technology (2015)

#361

Earlier quoted context omitted.

Not using the cloud has many hidden risks. You need multiple physical locations for reliability, those now need to be staffed. If you instead use cheaper 3rd party hosting companies, you may have hurdles to growth and future migration cost since those companies do not have many of the certifications required. From an investor POV, paying a little extra now is often worth it to reduce risk and remove barriers to explo…

Is that a real problem with a reputable bare-metal hosting provider? I agree that a fly-by-night VPS provider would be a major risk, but OVH for example is a major host in Europe (that successfully hosted websites long before the "cloud" was a thing). They have all the major certifications and have been in the business for two decades now and their uptime is solid. The only risk I can see is the lack of managed servi…

I just call our OVH services "the could" to placate people.

Re: Choose Boring Technology (2015)

#362

Earlier quoted context omitted.

I have been writing it full time about 13 years. I love writing in this language, and TypeScript even more. I am just frustrated by what appears to be some combination of insecurity, false expertise, and a vehement lack of passion in the work force. If I want to be happy I should move on to a different technology stack, but I really enjoy making products in this language.

It's funny, I have about 13 years experience, have been senior in both enterprise, start-ups and everything in-between, and have basically the exact same view about front end dev as your original post. Except I fucking hate using Typescript, and totally wasn't expecting to see you mention you like it, given all the other stuff. IME all the same people that overengineer everything with god awful dependencies are the s…

How did you get into the startup world? I’d like to work with people like you.

Re: Choose Boring Technology (2015)

#363

Earlier quoted context omitted.

Basecamp is a simple app though. Ridiculously simple. That app could have been written in the mid-1990s using WebObjects in just a few months. Technologies like MongoDB, React, GraphQL, Microservices etc exist because modern, real-world apps are generally far more advanced than just a glorified CRUD app. Consumers simply have higher expectations and more demands for what web apps should be able to do.

> modern, real-world apps are generally far more advanced than just a glorified CRUD app. ... are they?

...yes

Re: Choose Boring Technology (2015)

#364

The way I see it is that one should master their stack. If you work over and over again with the same stack you will know it well. You will be able to move mountains with it. But it takes years to arrive to that. It takes implementing multiple projects the same way over and over again. You need the wherewithal to stick with your stack and not get lured away. Maybe this is what boring means. Maybe boring is different…

This is a great comment and is spot on. Mastery has exponential returns over proficiency. The best thing is that mastery feels really good once you have it. I've been bouncing around the past several years not finding what I want, but I've realized the past year that I want to have the mastery with a stack that I haven't since my C/C++ OpenGL computer graphics years.

Good luck on your journey to mastery. When someone needs an expert on your mastered stack, they'll be dumb not to hire you.

Re: Choose Boring Technology (2015)

#365

Earlier quoted context omitted.

It's funny, I have about 13 years experience, have been senior in both enterprise, start-ups and everything in-between, and have basically the exact same view about front end dev as your original post. Except I fucking hate using Typescript, and totally wasn't expecting to see you mention you like it, given all the other stuff. IME all the same people that overengineer everything with god awful dependencies are the s…

How did you get into the startup world? I’d like to work with people like you.

Wish I had a better answer, but it was pretty much just luck. A bit of accidental networking and good timing.

When I finished uni I had a few interviews for large enterprise-y companies to get into their graduate programs. None of those panned out. Then while I was looking for more things like that, one of my classmates asked if I wanted to interview to be employee #1 at the startup him and a non-technical friend had created.

They didn't have much funding, so it was ~45k (minimum wage or close to it in Australia) to start, as opposed to the grad programs that I think would have been around 55k-60k. But the job was basically building an entire fairly large and complex web app (as well as a bit of desktop and hardware related stuff) between the two of us, who had close to zero real world experience, my friend on the back-end and me on the front-end. So we basically just had all the responsibility, with no experience, and nobody to guide us.

From there I just hopped around a few jobs, looking for small places where I was the senior or second most senior person on the team. I learnt from the first job that the easiest way to learn is to be in a position where you have as much responsibility as possible so failure isn't really an option.

Re: Choose Boring Technology (2015)

#366
post #355

Earlier quoted context omitted.

Is that a real problem with a reputable bare-metal hosting provider? I agree that a fly-by-night VPS provider would be a major risk, but OVH for example is a major host in Europe (that successfully hosted websites long before the "cloud" was a thing). They have all the major certifications and have been in the business for two decades now and their uptime is solid. The only risk I can see is the lack of managed servi…

Sure cherrypicking postgres since it has more experience as "on-prem". Try and replicate s3 type of service for me or something like sns - even without fancy stuff.

You can still use S3 even without being on AWS, though for more reasonable (For SNS, what does it offer that RabbitMQ doesn't? I've always found RMQ to be rock-solid and wouldn't use SNS anyway.

Re: Choose Boring Technology (2015)

#367

Earlier quoted context omitted.

I was very disappointed when I joined Amazon to learn we were using plain old Java with servlets (this was 2015, I think kotlin is more common now). Since leaving I’m in awe of how sensible the technical decision making that led to that was.

I interviewed with Stripe and one of the engineers mentioned they’re transitioning many services to a exciting new technology called... Java. That was in 2021

I will confess that I'd struggle to go back to java now. Kotlin has all the sensibility with just enough power to make me happy. I get to live in the JVM eco-system without the song-and-dance of something like scala.

Re: Choose Boring Technology (2015)

#368
post #306

Earlier quoted context omitted.

I’ve found kotlin to be wonderfully boring. There are definitely some sharp knives that get abused though. I’ve met a few people who want to throw OO in the bin and treat kotlin as pure FP to their detriment.

Isn't that a real option with Arrow?

Kind of. I don't think arrow - however good it becomes - can really compete with a language where those primitives (like do notation) come with the compiler.

Re: Choose Boring Technology (2015)

#369
post #49

Earlier quoted context omitted.

How about “leaves the industry rather than have to use terrible things at dumb companies”, thus giving a survival bias that selects for shiny. I know I feel that way about a lot of stuff now.

One of the most relatable posts I've ever seen on HN. Same reason I'm working towards getting out.

It´s kind of sad. I am the same. I want to do something different but I don´t know much else and the pay is reasonable (reasonable, not great, I am in Spain).

Re: Choose Boring Technology (2015)

#370

Earlier quoted context omitted.

Great point. I’m working with a client right now where 90% of the operational pain and low impact dev could be resolved by admitting that the project does not need to resemble a FAANG system.

One company I worked for went to great lengths to emulate FAANG. But they were a medium sized company. They were absolutely crushed under the weight of FAANG "best practices" and technology. They lost time rewriting perfectly fine code. They chased the microservice fad. And they lost market share. It's in the interest of FAANG to maintain this idea of needing k8s, this massive CI pipeline, certain processes, etc. etc…

> It's in the interest of FAANG to maintain this idea of needing k8s, this massive CI pipeline, certain processes, etc. etc. Because it slows down competition. It halts startups. It slows progress. They want to throw as much overhead as possible at smaller companies.

I'm not sure I agree that this is the underlying motivation. To get promoted at a FAANG you need to be demonstrating technical prowess. What says technical prowess like rewriting the app in a new framework that you open source to great acclaim? The business gets a feed of new talent, technical kudos from the community and maybe even a genuine benefit tht had some marginal gain at the scale that a FAANG operates at.

As an example, I don't think Amazon is recommending SOA to sabotage other companies. I think they're recommending the way of work required at Amazon scale.

> The thing people need to realize is that FAANG are entrenched. They are as risk-adverse as can be. They will happily write unit tests and maintain 100% test coverage and do all of this crap because they are more scared of losing market share than innovation.

I found the rate of feature delivery and innovation at Amazon to be way higher than the companies I've worked with since. 100% test coverage wasn't incentivized at all. Increasing revenue was.

Post reply on HN