4 ms·

I tend to use 'boring' technology if that serves the purpose, and I try to not experiment with new tech in projects that I need to deliver. For experimentation

by beeman 6y ago

I tend to use 'boring' technology if that serves the purpose, and I try to not experiment with new tech in projects that I need to deliver. For experimentation and prototyping I tend to check out new things, those might end up in the 'boring' stack once I'm familiar with them. For me it's a personal stack of tools that work for me, and I try not to be too influenced by what's the next new thing on sites like StackOverflow or Hackernews, I use what works for me and what makes my clients happy.

non-entity 6y ago
Whats considered "boring technology"? Typically, I assume it refers mostly to more time test and mature tech, but is it popular mature tech, or just any mature tech in general?
- ravenstine 6y ago
  I'd consider it a combination of being time-tested and lacking hype. Ruby on Rails is a good example of something which seems to get next to no hype compared to its heyday(even 7 years ago when I started with it), but still powers thousands of businesses and has lots of job postings.
  - nicoburns 6y ago
    I think it's mainly about being reliable. For instance, I'd consider Hasura "boring" in the good sense. It's fancy in that it allows you to do realtime queries on top of postgres. That's new and exciting. But it's also boring in that it took about half an hour to set it up. I've zero problems with it since, and the pnly maintenance is that it occasionally propmts me to update to thw latest version. Which takes about 5 minutes and has yet to cause an breakage.
- gen220 6y ago
  "The stuff they used in the good old days" :) In seriousness, the phrase "boring technology" is, to me, a reference to the talk "Choose Boring Technology" [0], which has been discussed on HN numerous times [1] (deservedly, because it's great). The author doesn't explicitly say what boring technology is, but uses examples you'd generally expect: postgres, php, python, memcached, mysql, apache web server. Basically, products that have been doing relatively complicated things (interpreted code, rdbms, key-value stores) for a very long time. Explicitly, he says that "boring technology" is technology that's defined by its very low maintenance cost. He claims that maintenance costs are mostly driven by uncertainties around failure conditions and design. These kinds of uncertainties are especially present in newer stacks, where the opportunities for footguns and unspecified failure conditions abound, because people are still working them out. He implicitly references Redis as a fancy new technology, but a lot of people today would probably consider Redis "boring" (unless you're trying to use it as your RDBMS). [0]: http://boringtechnology.club/ http://boringtechnology.club/ [1]: recently, here: https://news.ycombinator.com/item?id=20323246 https://news.ycombinator.com/item?id=20323246
ravenstine 6y ago
I'm kind of a broken record in this sense, but I'll say again that one can pay too much attention to HN and, if they do, they might come to believe that PHP and Ruby are far too slow for most cases and that only serious developers write their backend in Elixir, Python, or Rust, use NoSQL, integrate Kafka for a data pipeline, build frontends in TypeScript or Elm with Svelte, WebPack or GTFO, and containerize everything and scale out with K8s. 99% of the developers here aren't even close to needing to think in terms of that scale, beyond simply not doing dumb things in your code that can happen no matter what tools you use. Hell, there are whole companies that don't need to do these things. A few companies I've worked for or contracted with were bogged down, IMO, because someone couldn't settle for "adequate", making the company suffer because their architecture is so hard to figure out. I like using "boring" tech(in particular Ember.js, Node.js, Ruby, CouchDB and PostgresSQL/SQLite) because if something gets the job done in a reasonable amount of time, most of which I think comes down to having a competency with a set of tools, then I really don't care very much for drinking from the firehose of frameworks and libraries. Letting go of ego is tough but, when you do, you're freed from the need to be "like Twitter" or "like Uber" and instead just build things using tools you are genuinely interested in or work for you. It's one thing if you really have the desire to be the kind of wizard to work at Google(and not be relegated to writing shell scripts all day), but if that isn't for you that's fine because the vast majority of jobs out there don't need an archmage. What most companies need is someone who is going to KISS and not eff things up. If you can do that, you'll have a hard time getting fired even if you sometimes slack off.
- mattlondon 6y ago
  Valid comments but there really is no reason not to use Typescript these days if you are considering JavaScript. Even for small/single-person projects there is no reason not to use it given its benefits and the fact that it takes 10 minutes to learn if you are a JavaScript developer already.
  - brendanmc6 6y ago
    I’ll die on that hill— back when I was interviewing for my next frontend position I told all my prospects I wasn’t interested in working for them if they aren’t using TypeScript or at least open to migrating. There really is no reason to use plain JS for anything!

by beeman 6y ago

non-entity 6y ago

Whats considered "boring technology"? Typically, I assume it refers mostly to more time test and mature tech, but is it popular mature tech, or just any mature tech in general?

ravenstine 6y ago
I'd consider it a combination of being time-tested and lacking hype. Ruby on Rails is a good example of something which seems to get next to no hype compared to its heyday(even 7 years ago when I started with it), but still powers thousands of businesses and has lots of job postings.
- nicoburns 6y ago
  I think it's mainly about being reliable. For instance, I'd consider Hasura "boring" in the good sense. It's fancy in that it allows you to do realtime queries on top of postgres. That's new and exciting. But it's also boring in that it took about half an hour to set it up. I've zero problems with it since, and the pnly maintenance is that it occasionally propmts me to update to thw latest version. Which takes about 5 minutes and has yet to cause an breakage.
gen220 6y ago
"The stuff they used in the good old days" :) In seriousness, the phrase "boring technology" is, to me, a reference to the talk "Choose Boring Technology" [0], which has been discussed on HN numerous times [1] (deservedly, because it's great). The author doesn't explicitly say what boring technology is, but uses examples you'd generally expect: postgres, php, python, memcached, mysql, apache web server. Basically, products that have been doing relatively complicated things (interpreted code, rdbms, key-value stores) for a very long time. Explicitly, he says that "boring technology" is technology that's defined by its very low maintenance cost. He claims that maintenance costs are mostly driven by uncertainties around failure conditions and design. These kinds of uncertainties are especially present in newer stacks, where the opportunities for footguns and unspecified failure conditions abound, because people are still working them out. He implicitly references Redis as a fancy new technology, but a lot of people today would probably consider Redis "boring" (unless you're trying to use it as your RDBMS). [0]: http://boringtechnology.club/ http://boringtechnology.club/ [1]: recently, here: https://news.ycombinator.com/item?id=20323246 https://news.ycombinator.com/item?id=20323246

ravenstine 6y ago

I'm kind of a broken record in this sense, but I'll say again that one can pay too much attention to HN and, if they do, they might come to believe that PHP and Ruby are far too slow for most cases and that only serious developers write their backend in Elixir, Python, or Rust, use NoSQL, integrate Kafka for a data pipeline, build frontends in TypeScript or Elm with Svelte, WebPack or GTFO, and containerize everything and scale out with K8s. 99% of the developers here aren't even close to needing to think in terms of that scale, beyond simply not doing dumb things in your code that can happen no matter what tools you use. Hell, there are whole companies that don't need to do these things. A few companies I've worked for or contracted with were bogged down, IMO, because someone couldn't settle for "adequate", making the company suffer because their architecture is so hard to figure out. I like using "boring" tech(in particular Ember.js, Node.js, Ruby, CouchDB and PostgresSQL/SQLite) because if something gets the job done in a reasonable amount of time, most of which I think comes down to having a competency with a set of tools, then I really don't care very much for drinking from the firehose of frameworks and libraries. Letting go of ego is tough but, when you do, you're freed from the need to be "like Twitter" or "like Uber" and instead just build things using tools you are genuinely interested in or work for you. It's one thing if you really have the desire to be the kind of wizard to work at Google(and not be relegated to writing shell scripts all day), but if that isn't for you that's fine because the vast majority of jobs out there don't need an archmage. What most companies need is someone who is going to KISS and not eff things up. If you can do that, you'll have a hard time getting fired even if you sometimes slack off.

mattlondon 6y ago
Valid comments but there really is no reason not to use Typescript these days if you are considering JavaScript. Even for small/single-person projects there is no reason not to use it given its benefits and the fact that it takes 10 minutes to learn if you are a JavaScript developer already.
- brendanmc6 6y ago
  I’ll die on that hill— back when I was interviewing for my next frontend position I told all my prospects I wasn’t interested in working for them if they aren’t using TypeScript or at least open to migrating. There really is no reason to use plain JS for anything!