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

All of us test in production all the time (2019)

increment.com

Post reply on HN
Print view View original

71–80 of 164 posts

Re: All of us test in production all the time (2019)

#71

Post by TedDoesntTalk »

binsh wrote: post #66
TedDoesntTalk wrote: post #47

Earlier quoted context omitted.

Perhaps he means that you won’t be able to attract great talent. A lot of extremely talented engineers don’t want to work on code bases and technologies that are 15 years old.

Definitely would like a source for this because I feel like I hear it a lot and I don't believe it's true. You can be talented and not care what you work on. And if all you care about is what tech is new and shiny, how talented can you be? I don't want you rewriting my product every year so you can use the next framework du jour. Maybe talent means something else when nothing is at stake, but I'd argue that a talente…

> they're the ones who will replace everything every six months while you bleed money.

Yep. I agree. Maybe talent is the wrong word, but my point is that a lot of experienced engineers want to learn new things by working on new things.

There is a difference between talent and wisdom.

My source? Decades of experience in the industry working with hundreds of different engineers. So, anecdotal.

Not everything needs a double-blind research study to be truthful.

Re: All of us test in production all the time (2019)

#72

Post by ratww »

binsh wrote: post #66
TedDoesntTalk wrote: post #47

Earlier quoted context omitted.

Perhaps he means that you won’t be able to attract great talent. A lot of extremely talented engineers don’t want to work on code bases and technologies that are 15 years old.

Definitely would like a source for this because I feel like I hear it a lot and I don't believe it's true. You can be talented and not care what you work on. And if all you care about is what tech is new and shiny, how talented can you be? I don't want you rewriting my product every year so you can use the next framework du jour. Maybe talent means something else when nothing is at stake, but I'd argue that a talente…

The issue is rarely the age of the codebase or the tech stack, but rather the maintainability and quality of the code.

Due to many factors, the age of the codebase is normally inversely proportional to its code quality. Especially codebases in fields where trends change fast, like web technology.

Therefore, if you're a talented engineer able to work in multiple technologies you'll certainly prefer to work on something that has less chances of making you want to tear your hair out.

Re: All of us test in production all the time (2019)

#73

Post by bluedino »

Most places that I've worked, that "test in prod", do so for one reason. It all comes down to laziness.

The first scenario is they have never set up a test environment in the first place. They're either too lazy to do so, or too lazy to look into how to do it. Often confused with being 'too busy to do it'.

The second scenario is that they do have a testing environment-however, for some reason, it's broken. Some change was made, usually in a hurry to meet a deadline, and it's been broken ever since. This one is usually a result of the fix being too difficult, because the test environment was haphazardly thrown together in the first place.

Re: All of us test in production all the time (2019)

#74

Post by TedDoesntTalk »

ratww wrote: post #72
binsh wrote: post #66

Earlier quoted context omitted.

Definitely would like a source for this because I feel like I hear it a lot and I don't believe it's true. You can be talented and not care what you work on. And if all you care about is what tech is new and shiny, how talented can you be? I don't want you rewriting my product every year so you can use the next framework du jour. Maybe talent means something else when nothing is at stake, but I'd argue that a talente…

The issue is rarely the age of the codebase or the tech stack, but rather the maintainability and quality of the code. Due to many factors, the age of the codebase is normally inversely proportional to its code quality. Especially codebases in fields where trends change fast, like web technology. Therefore, if you're a talented engineer able to work in multiple technologies you'll certainly prefer to work on somethin…

> the age of the codebase is normally inversely proportional to its code quality.

What??? You are saying that simply because a code base is old, it is of poor quality. There are numerous public examples contradicting this: Linux, many Apache projects such as httpd, etc.

I emphatically disagree and would like to know why you think that.

Re: All of us test in production all the time (2019)

#75

Post by ratww »

rybosworld wrote: post #65
vinceguidry wrote: post #62

Earlier quoted context omitted.

I loathe NodeJS with the passion of a thousand suns. When Rails projects churn, at least you can rely on the stability of Ruby. With Node, the number of times I had to work around inconsistencies with the framework and even language were maddening. Babel is a horrible horrible thing, and Javascript was never meant to run on a server. Maybe it's better now. But I won't ever do serious work again with the stack so I'll…

Node is getting better each year imo. I've been pretty happy with ES6. What makes you say Babel is horrible? Not disagreeing but I haven't heard anyone say that before.

People don't say it directly, but all the constant complaining about the bloat and complexity of the JS ecosystem and the size of node_modules folder boils down mostly to two tools: Babel and Webpack.

Re: All of us test in production all the time (2019)

#76

Post by somurzakov »

TedDoesntTalk wrote: post #47
tluyben2 wrote: post #35

Earlier quoted context omitted.

> Sometimes what works now won't be competitive in the near future. What do you mean by that? I can understand in terms of hiring devs, this is true, but any other reason I would be curious about. Because I work with/in many companies, I see a lot of different tech and competitive is usually just what the team knows best. So unless you are making a new team, I cannot phantom why you would switch. Java with Servlets/S…

Perhaps he means that you won’t be able to attract great talent. A lot of extremely talented engineers don’t want to work on code bases and technologies that are 15 years old.

both java and .net (core) are evolving and more mature, though

Re: All of us test in production all the time (2019)

#77

Post by jahewson »

vinceguidry wrote: post #62
tluyben2 wrote: post #36

Earlier quoted context omitted.

I had the same issue with Rails as I have with Node : the churn is detriment to long standing projects. Most projects I do run for years and even decades; you go run an update for security for Rails code that is 10 years old. It is a nightmare. I did not have issues like that with php, asp.net or spring.

I loathe NodeJS with the passion of a thousand suns. When Rails projects churn, at least you can rely on the stability of Ruby. With Node, the number of times I had to work around inconsistencies with the framework and even language were maddening. Babel is a horrible horrible thing, and Javascript was never meant to run on a server. Maybe it's better now. But I won't ever do serious work again with the stack so I'll…

Curiously enough JavaScript was in fact designed to run on the server too, Netscape LiveWire shipped it in 1995.

Re: All of us test in production all the time (2019)

#78

Post by ratww »

TedDoesntTalk wrote: post #74
ratww wrote: post #72

Earlier quoted context omitted.

The issue is rarely the age of the codebase or the tech stack, but rather the maintainability and quality of the code. Due to many factors, the age of the codebase is normally inversely proportional to its code quality. Especially codebases in fields where trends change fast, like web technology. Therefore, if you're a talented engineer able to work in multiple technologies you'll certainly prefer to work on somethin…

> the age of the codebase is normally inversely proportional to its code quality. What??? You are saying that simply because a code base is old, it is of poor quality. There are numerous public examples contradicting this: Linux, many Apache projects such as httpd, etc. I emphatically disagree and would like to know why you think that.

I said "normally". I don't think anyone considers Linux or httpd "old tech", neither they are "legacy software" that experienced developers are running away from. C might be old as a language, but there are still modern things being built with it. I also said that the issue is not the age itself or the tech stack.

Re: All of us test in production all the time (2019)

#79

Post by dang »

simonw wrote: post #16

It seems likely that some of the comments here are reacting to the headline as opposed to reading the article - which is one of my favourite pieces of writing on the subject of observability and responsible maintenance of large scale systems. Lots of great quotable bits in here. Here's just one for people who didn't make it to the bottom: "There’s a lot of daylight between just throwing your code over the wall and wa…

What would be a more accurate and neutral title?

Re: All of us test in production all the time (2019)

#80

Post by jhardy54 »

rybosworld wrote: post #65
vinceguidry wrote: post #62

Earlier quoted context omitted.

I loathe NodeJS with the passion of a thousand suns. When Rails projects churn, at least you can rely on the stability of Ruby. With Node, the number of times I had to work around inconsistencies with the framework and even language were maddening. Babel is a horrible horrible thing, and Javascript was never meant to run on a server. Maybe it's better now. But I won't ever do serious work again with the stack so I'll…

Node is getting better each year imo. I've been pretty happy with ES6. What makes you say Babel is horrible? Not disagreeing but I haven't heard anyone say that before.

I write JavaScript daily and my gripe with Babel (and transpilers in general) in the JS ecosystem is that it makes it easy to have 10 dependencies written in 10 similar-but-different languages. If you have to edit a dependency then you're stuck editing their source file (written in ES6-ES11 plus random unaccepted proposals / TypeScript / Coffeescript / Purescript / etc), installing their devDeps tree to run their build process, integrating their sourcemaps to un-break your stack traces, and writing code in a slightly different language each time you make a change. It's exhausting.

It's really neat that we have the option to transpile, and I was actively working on transpilers in the Meteor ecosystem when they were all the rage, but at this point I try to avoid them whenever I can.

Post reply on HN