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

271–280 of 374 posts

Re: Choose Boring Technology (2015)

#271

Post by aeternum »

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.

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 explosive growth.

Re: Choose Boring Technology (2015)

#272

Post by lumost »

phendrenad2 wrote: post #2

I always found it funny that companies will go to extreme Herculean lengths to hire the best programmers, and are incredibly fearful and paranoid that they could be making a "bad hire", and yet once hired they don't spend a second making sure engineers aren't completely running the software product off the rails and killing the company internally. The author mentions trying to rewrite Etsy's backend in Scala and Mong…

It's a mixed bag, if you hire engineers who exclusively want to refine the existing toolchain - you may find that solving new product problems becomes more difficult. You may get stuck with an ancient oracle stack drawing down your entire companies profit margin. Or the team responsible for some technology has ossified so heavily that your launch date is moved to twenty never.

You can immediately spot a misaligned engineering culture when every team has its own tech stack and its own ops as it means that none of the teams trusted each other for anything and had to resort to federation. On the flip side you can se bad engineering cultures where decisions are made based on pure conformity with what was previously built regardless of the problem being solved.

There's a happy middle-ground, a company like etsy with 200-400 engineers can happily afford a small team of 2 engineers trying out scala/mongo for something, it might work out, and nuking it from orbit won't cost that much in the grand scale of things.

Re: Choose Boring Technology (2015)

#273

Post by vyrotek »

cutler wrote: post #122
tpetry wrote: post #5

The problem with the non-boring technology club is that programmers see what problem FAANG companies are solving and wanting to be on the edge on new technology too. But they don‘t have the same problems. Another problem is they want to show what they can do. If they tell in an interview they are working with rails/django and a postgresql database they fear they look incompetent using those old technologies. So they…

Yes, Hotwire is another game-changer from that genius DHH. So much so that Django and Laravel already have their own implementations. I just love the passion that guy has for what he does and his commitment to Ruby. I think Rails is an even better choice since it became boring.

He's a smart guy but this feels more like a pendulum swing. ASP.NET had a similar implementation called AJAX UpdatePanels back in the mid 2000's.

Re: Choose Boring Technology (2015)

#274

Post by mikesabbagh »

I think that technology used needs to be chosen based on today's needs and not tomorrow's. Startups that decide to deploy 5 containers on kubernetes make me cry. The time and cost to operate and maintain this beast is beyond any estimate compared to even hosting each container on a seperate vm. This read was very satisfying, thank you

Re: Choose Boring Technology (2015)

#275

Post by jboy55 »

phendrenad2 wrote: post #2

I always found it funny that companies will go to extreme Herculean lengths to hire the best programmers, and are incredibly fearful and paranoid that they could be making a "bad hire", and yet once hired they don't spend a second making sure engineers aren't completely running the software product off the rails and killing the company internally. The author mentions trying to rewrite Etsy's backend in Scala and Mong…

"the engineers are bored and they're rewriting perfectly-good codebases in Common Lisp and OCAML for funsies"

Had this literally happen to me, but I was a low level manager and this was happening in another team. One thing I've taken from it, at the time the feeling around Sr Management was that we needed to allow this or we would lose the engineers. They allowed it, and after the conversion, those engineers left to start their own company. The remaining engineers had to deal with undocumented OCaml code and keep it running and were resentful.

I have seen this with React vs Vue, where an engineer not liking React, just did his code in Vue. 'We have to let him do this or he'll leave', but he left on his own accord.

Lesson, stick up for your codebase, and if engineers don't like it, let them leave or make them leave. The other engineers on your team will like it, and some of them will become your new Sr Engineers.

Re: Choose Boring Technology (2015)

#276

Post by _qulr »

meheleventyone wrote: post #269
ZephyrBlu wrote: post #262

Earlier quoted context omitted.

I was genuinely curious what you classed as basic programming. I would definitely consider pointers pretty fundamental if you're a C++ dev. It is pretty hard to believe that 50% of candidates don't know what a pointer is. I've barely touched C/C++ and still know what pointers are and how they work.

> I've barely touched C/C++ and still know what pointers are and how they work. Congratulations you’ve successfully triggered the pedantic interviewer. You will now face six questions on pointers in C++ they just looked up each more trivia based than the last.

Who would pass the technical screen must answer me these questions three, ere the onsite he see.

Re: Choose Boring Technology (2015)

#277

Post by zmmmmm »

twic wrote: post #64
phendrenad2 wrote: post #2

I always found it funny that companies will go to extreme Herculean lengths to hire the best programmers, and are incredibly fearful and paranoid that they could be making a "bad hire", and yet once hired they don't spend a second making sure engineers aren't completely running the software product off the rails and killing the company internally. The author mentions trying to rewrite Etsy's backend in Scala and Mong…

> How many engineering managers can spot the common situation "the engineers are bored and they're rewriting perfectly-good codebases in Common Lisp and OCAML for funsies"? And how many know what to do about it when they see it? I think there is a tension between this kind of actively guiding anti-complexity management and hiring "top talent". The very best developers are capable, and avoid complexity. The next best…

> So, if you want to hire developers who are at least capable, you have to give them some leeway to make things overcomplicated

This is always a challenge in general - how do people learn the lessons of complexity without creating it and then seeing the effects? I wish there was a better word for it as every person who reads "complexity" says well "duh of course I don't want that" before they then go and manufacture another bucket full of it. Complexity masquerades as simplicity - in the first instance it nearly always solves the immediate problem better than anything else. Recognising the latent complexity of choices is one of the hardest but most important skills to learn.

Re: Choose Boring Technology (2015)

#278

Post by ksec »

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.

1. They are already an investor in Amazon. They have an interest, both in the actual spending and the trend setting of current and future companies to use AWS.

2. It is actually increasingly hard to get an industry wide reputable hosting provider ( Cloud, VPS , Metal or not ) that many investors could agree upon. Just like you said which makes DD harder.

3. Amazon actually offer heavy discount and even lots free credit to startup by accredited VC. Meaning the difference in the first few years is actually tiny. And in your example, if it can be run on $500 budget elsewhere you can bet it will literally be free on AWS from those startup.

Re: Choose Boring Technology (2015)

#279

Post by zmmmmm »

vp8989 wrote: post #160
twic wrote: post #64

Earlier quoted context omitted.

> How many engineering managers can spot the common situation "the engineers are bored and they're rewriting perfectly-good codebases in Common Lisp and OCAML for funsies"? And how many know what to do about it when they see it? I think there is a tension between this kind of actively guiding anti-complexity management and hiring "top talent". The very best developers are capable, and avoid complexity. The next best…

"The very best developers are capable, and avoid complexity. The next best developers are capable, and love complexity. The worst developers are not capable." It's not always in one's control to avoid complexity. The simplest solution to a problem in a lot of cases may be 2-3x the lift (simplicity tends to require more work, complexity is easy) and thus blocked by the business. A holistically simpler solution may be…

> The simplest solution to a problem in a lot of cases may be 2-3x

This is such an important point. For whatever reason it has become ingrained in people's heads that the simplest solution must by reductionist logic be the easiest one. And therefore the easiest solution is the simplest one and it is good to be lazy and just introduce complexity everywhere.

Re: Choose Boring Technology (2015)

#280

Post by Yeroc »

chrisco255 wrote: post #255
gravypod wrote: post #170

Earlier quoted context omitted.

Making efficient use if mongodb is very difficult but if you build your app and expectations correctly you can get something very performant. For example pre-4.x listing huge collections was unexpectedly extremely slow.

Yeah Mongo is 10 years old or so at this point. This article was written in 2015 about decisions made years earlier. It's now reached maturity and stability. It's now "boring tech".

Um, even if it's mature technology that doesn't negate the costs of operating two different databases which is a large part of what the original presentation is about.
Post reply on HN