4 ms·

Sometimes engineers have perverse incentives. If you want a FAANG job, it probably helps to have experience with FAANG tech, even if your current company doesn

Sometimes engineers have perverse incentives. If you want a FAANG job, it probably helps to have experience with FAANG tech, even if your current company doesn't need it.

ehnto 6y ago
It is a very frustrating industry to spend a long time in. A hamster wheel of constantly shifting goal posts for mastery. I wouldn't mind if they were fundamental advances in software development, but it's mostly the same stuff with small advances but massive learning curves of arbitrary, non-transferrable minutiae. The side effect of this ever shifting tooling set, is almost no one masters anything. All software is varying levels of crap written by newbies, because when the tools change every project you are always a newbie in that tool set.
- llbbdd 6y ago
  As someone at a FAANG company right now, your second paragraph neatly identifies a core frustration I have with my job that I haven't been able to articulate before now. Might be time for a change...
- kqr 6y ago
  > I wouldn't mind if they were fundamental advances in software development, but it's mostly the same stuff with small advances but massive learning curves of arbitrary, non-transferrable minutiae. I think this is pinpointing the key exploitability in the market. If you have seen enough tech come and go, you can figure out which 98% of this year's idea are the same as the year before, and 40 years ago. At that point you can start cutting through the bullshit and design things using brand new tech as if you had used it for 20 years already. At that point you're way ahead of the rest of the pack. (And you can choose not to use the brand new thing, and argue convincingly for why the almost-exactly-the-same 30 year old, more mature and stable, tech is better.)
  - krab 6y ago
    I mostly agree. Though you may still develop blind spots and miss a crucial difference in this year's iteration of the same idea.
- vinay_ys 6y ago
  Firstly software development is not one monolithic job. There are many different jobs within software development. You can be a systems engineer – understand the computers at a fundamental level – with focus on systems software – building low-level high-performance components/kernels – for storage systems, databases, in-memory systems etc (each of these have a lot of technical domain knowledge specialisation within them). You can spend 10 years in this field and continuously develop/enhance your expertise incrementally – it is quite stable and rewarding experience. A branch of this specialization is distributed systems engineering – where emphasis is on software operating in a distributed cluster over network – which has additional challenges unique to the aspect of being distributed. You can be an applications engineer – understand application software engineering methodology – with focus on user/business facing application feature development in a scalable software team setting. The key focus here is not so much about low-level computer systems but more about software engineering discipline. It is about the inter/intra-team sport that is developing and continuously evolving a very large application software code base that is alive with changing/evolving user/business features. It is about modeling the functional domain of the user/business/real world. It is about the modern consumer Internet software development techniques – experimentation, live incremental safe feature releases etc. A branch of this specialization is developing application frameworks and tooling (rather than user/business functional features) to make the life of a feature engineer more productive. You can spend 10 years in this field and become an expert at software engineering discipline of churning out quality features on time and on budget. The experience and learning in the above job families transcend any particular technology stack. The learnings are transferable from one tech-stack/functional-domain to another with relatively minimal effort. This effort is part of the work itself and doesn't turn you into a newbie for having to do it. p.s: A generalist full stack engineer is usually an applications engineer who is somewhat good at systems engineering and is able to glue together systems to achieve the application features well. These engineers can take a startup from start and through initial growth phase and up to start of hyper growth phase. But there's a scale/performance threshold – where the scale of application deployment grows, performance starts to hurt your users, you need strong systems engineering specialists to fix those deeper systems/distributed-systems problems. Public cloud systems have been continuously raising that threshold since the beginning.
- theshadowknows 6y ago
  I just learned last week that we're bringing Pega on for some projects. Never even heard of Pega before then lol. Time to sit down with a free account and learn something else that we'll throw away in five years.
  - treeman79 6y ago
    5 years is sadly decent run. Was in a big Javascript project, where any article over 3 months old was useless or wrong. The internals of the app constantly being rewritten to flavor of the month.
- jrochkind1 6y ago
  This rings so true to me. I really like mastering things, so I've tried to stick with a technology stack (that I have kind of mastered), but I don't think it's been good for my career.
tjpnz 6y ago
It's not just engineers either. I've seen new EMs copy and paste ill fitting FAANG development practices into organizations and then bounce off to which ever company championed it not long after.
whatsmyusername 6y ago
Yeah we've run into this. Before my time they gave a full application to one developer, who proceeded to build it in a language we barely use on tech no one else in the company understands (and, while not bad, isn't even close to something we'd choose to use in any other circumstance). Once it was done...ish, he ducked out to be a consultant, leaving others to clean up the mess (we ended up just selling it for not what we put into it).

Sometimes engineers have perverse incentives. If you want a FAANG job, it probably helps to have experience with FAANG tech, even if your current company doesn't need it.

ehnto 6y ago

It is a very frustrating industry to spend a long time in. A hamster wheel of constantly shifting goal posts for mastery. I wouldn't mind if they were fundamental advances in software development, but it's mostly the same stuff with small advances but massive learning curves of arbitrary, non-transferrable minutiae. The side effect of this ever shifting tooling set, is almost no one masters anything. All software is varying levels of crap written by newbies, because when the tools change every project you are always a newbie in that tool set.

llbbdd 6y ago
As someone at a FAANG company right now, your second paragraph neatly identifies a core frustration I have with my job that I haven't been able to articulate before now. Might be time for a change...
kqr 6y ago
> I wouldn't mind if they were fundamental advances in software development, but it's mostly the same stuff with small advances but massive learning curves of arbitrary, non-transferrable minutiae. I think this is pinpointing the key exploitability in the market. If you have seen enough tech come and go, you can figure out which 98% of this year's idea are the same as the year before, and 40 years ago. At that point you can start cutting through the bullshit and design things using brand new tech as if you had used it for 20 years already. At that point you're way ahead of the rest of the pack. (And you can choose not to use the brand new thing, and argue convincingly for why the almost-exactly-the-same 30 year old, more mature and stable, tech is better.)
- krab 6y ago
  I mostly agree. Though you may still develop blind spots and miss a crucial difference in this year's iteration of the same idea.
vinay_ys 6y ago
Firstly software development is not one monolithic job. There are many different jobs within software development. You can be a systems engineer – understand the computers at a fundamental level – with focus on systems software – building low-level high-performance components/kernels – for storage systems, databases, in-memory systems etc (each of these have a lot of technical domain knowledge specialisation within them). You can spend 10 years in this field and continuously develop/enhance your expertise incrementally – it is quite stable and rewarding experience. A branch of this specialization is distributed systems engineering – where emphasis is on software operating in a distributed cluster over network – which has additional challenges unique to the aspect of being distributed. You can be an applications engineer – understand application software engineering methodology – with focus on user/business facing application feature development in a scalable software team setting. The key focus here is not so much about low-level computer systems but more about software engineering discipline. It is about the inter/intra-team sport that is developing and continuously evolving a very large application software code base that is alive with changing/evolving user/business features. It is about modeling the functional domain of the user/business/real world. It is about the modern consumer Internet software development techniques – experimentation, live incremental safe feature releases etc. A branch of this specialization is developing application frameworks and tooling (rather than user/business functional features) to make the life of a feature engineer more productive. You can spend 10 years in this field and become an expert at software engineering discipline of churning out quality features on time and on budget. The experience and learning in the above job families transcend any particular technology stack. The learnings are transferable from one tech-stack/functional-domain to another with relatively minimal effort. This effort is part of the work itself and doesn't turn you into a newbie for having to do it. p.s: A generalist full stack engineer is usually an applications engineer who is somewhat good at systems engineering and is able to glue together systems to achieve the application features well. These engineers can take a startup from start and through initial growth phase and up to start of hyper growth phase. But there's a scale/performance threshold – where the scale of application deployment grows, performance starts to hurt your users, you need strong systems engineering specialists to fix those deeper systems/distributed-systems problems. Public cloud systems have been continuously raising that threshold since the beginning.
theshadowknows 6y ago
I just learned last week that we're bringing Pega on for some projects. Never even heard of Pega before then lol. Time to sit down with a free account and learn something else that we'll throw away in five years.
- treeman79 6y ago
  5 years is sadly decent run. Was in a big Javascript project, where any article over 3 months old was useless or wrong. The internals of the app constantly being rewritten to flavor of the month.
jrochkind1 6y ago
This rings so true to me. I really like mastering things, so I've tried to stick with a technology stack (that I have kind of mastered), but I don't think it's been good for my career.

tjpnz 6y ago

It's not just engineers either. I've seen new EMs copy and paste ill fitting FAANG development practices into organizations and then bounce off to which ever company championed it not long after.

whatsmyusername 6y ago

Yeah we've run into this. Before my time they gave a full application to one developer, who proceeded to build it in a language we barely use on tech no one else in the company understands (and, while not bad, isn't even close to something we'd choose to use in any other circumstance). Once it was done...ish, he ducked out to be a consultant, leaving others to clean up the mess (we ended up just selling it for not what we put into it).