4 ms·

One thing I had to learn to value my sanity here was to simply not argue about certain topics, such as software architecture. It was like there was this wall of

One thing I had to learn to value my sanity here was to simply not argue about certain topics, such as software architecture. It was like there was this wall of people who emerge from the shadows anytime I argue for better architecture, because it wasn’t directly responsible for Important Enterprise Business Features. Now I realize there’s probably more than one flavor of engineer: 1. software eng: ships features, prefers to use ready-made abstractions 2. infrastructure-ish eng: ships things that enable shipping of features, prefers to invent abstractions The things they value are very different! I suspect HN tends more toward SW engineers (because statistics) with some stuff for infrastructure engineers.

nijave 4y ago
I think in any moderately large business you'll have both. 1. Is usually implementing business logic for the product 2. Is generally working on things #1 uses to work productively I'm not sure about the composition on HN, but I see a lot of #2 in "DevOps"/SRE roles. Usually these roles are skipped for small startups but at some point they get big enough they need dedicated people to take them on
- tayo42 4y ago
  That's not my experience with sre and DevOps, often it's just consuming tool written by others. It's basically being a sysadmin with a git repo
- mattgreenrocks 4y ago
  #2 is distinct from pure DevOps/SRE. Those roles have co-opted the infrastructure meaning to be more along the lines of "making sure things don't catch fire at 3am." Which is valuable, but, even farther removed from programming. Still, they value the same things that the "pure infrastructure" people I were referring to do simply because they end up being on the hook for how it behaves.
agumonkey 4y ago
It's not far from the top-down vs bottom-up too. Having a wide enough infra helps adapting at the upper layer faster and cleaner.
- mattgreenrocks 4y ago
  Very true. So few people talk about this topic is saddens me. I have had success switching mindsets when I get stuck on one.
  - agumonkey 4y ago
    It's a strong skill to know how to balance this.

nijave 4y ago

I think in any moderately large business you'll have both. 1. Is usually implementing business logic for the product 2. Is generally working on things #1 uses to work productively I'm not sure about the composition on HN, but I see a lot of #2 in "DevOps"/SRE roles. Usually these roles are skipped for small startups but at some point they get big enough they need dedicated people to take them on

tayo42 4y ago
That's not my experience with sre and DevOps, often it's just consuming tool written by others. It's basically being a sysadmin with a git repo
mattgreenrocks 4y ago
#2 is distinct from pure DevOps/SRE. Those roles have co-opted the infrastructure meaning to be more along the lines of "making sure things don't catch fire at 3am." Which is valuable, but, even farther removed from programming. Still, they value the same things that the "pure infrastructure" people I were referring to do simply because they end up being on the hook for how it behaves.

agumonkey 4y ago

It's not far from the top-down vs bottom-up too. Having a wide enough infra helps adapting at the upper layer faster and cleaner.

mattgreenrocks 4y ago
Very true. So few people talk about this topic is saddens me. I have had success switching mindsets when I get stuck on one.
- agumonkey 4y ago
  It's a strong skill to know how to balance this.