I’ve been on GCP since Google App Engine was their first major product (2008ish I want to say? Maybe 2009) and that would only give me 14 years experience on GCP. Plus Go wasn’t originally supported on App Engine until much later.
Perhaps HR was complaining about not being able to hire those people for the $50k/yr + unlimited PTO budget that they have?
because I can bet that if HR was willing to pay $500k+/yr + sensible PTO, a few of those GCP engineers right out of Google who literally wrote the first few lines of code for GAE might consider joining.
This kind of person isn't easy to find, because:
- she has to have extensive knowledge about these frameworks
- feel very confident configuring servers
- follow the latest exploits
- perform security reviews
- audit dependencies
and:
- still be able to address vulnerabilities writing elegant code.
I guess it's a lot to ask for, but we had a team mate in the past who did exactly this.
Did they die or move on to a better paying opportunity?
Far too many employers are used to high job competition allowing them to pay only pennies on the dollar for that work. The moment people ask for rational and reasonable wages, it’s suddenly “No OnE WaNtS tO wOrK” because they’re wanting champagne work output on a horse piss beer salary.
Permission to steal this line?
OK, so did they die or move on to a better paying opportunity?
I personally see a minimum of three jobs, done well, at 30 hours a week.
1. Backend Engineer = Rails
2. Front End Engineer = Vue
3. Infra Engineer/Devops = AWS
...and with a security background.
...and all 3 at an expert level.
I've worked with a lot of bright and capable people over the years but I can't think of anyone matching this level of expertise.
If I had to guess; did the project grow organically for a few years where the original developer learned all of the skills as they went and now this person left?
Well, sort of. He was experienced before he joined, but staying with us many years definitely helped him to structure everything correctly and automatize a lot of tasks. What's interesting, he actually worked only 3 days a week. It's doable if you clearly define the responsibilities.
Concur!
It isn't that enough people arn't wildly smart enough/don't have the mental capacity to be a full-stack developer AND a penetration tester simultaneously.
It's that it just don't make sense to enough of these wildly smart people to take on what's essentially three jobs, that when done well, individually consume 30+ hours a week each.
Businesses that hire these frankenstien's monster as employees instead of contractors just don't have a clue.
It's also extremely likely these frankenstien's monsters will burn themselves out as employees essentially juggling three jobs as a salaried flat rate employee.
The only scenario in which being this frankenstien's monster make sense is to bootstrap a consultancy as a founder or a contractor, sign up enough clients and scale out by hiring specialist employees.
The only reason why these frankenstien's monsters happen (outside being a founder or a contractor and I am talking exclusively about employees here) is that employee started off as one type (full-stack developer OR a penetration tester), failed to find employment and cross trained into the other, where they found employment.
For example, without knowing any details, it's likely the full-stack developer AND a penetration tester started off as a penetration tester, failed to find employment and cross trained into full-stack developer. Of course, devil lies in the details, so if the full-stack developer failed to find employment as one but noticed significant demand for penetration testing, they could very well have become a penetration tester.
Empirically a penetration tester doesn't have either time or energy to be an effective full-stack developer or vice versa, especially outside a founder or a contractor role in a bootstrap stage.
Wouldn't it make sense to decouple some of the requirements? For instance, there's pretty good separation between front and back end. The person only needs a conceptual understanding of the other side and detailed understanding of the protocol to be used. I use both Vue and many backend tech, but my understanding is that I use Vue with a REST api and reactive rendering. The api design could be iterated by members from both groups.
I don't think you're drawing the right conclusion.
It isn't that enough people arn't wildy smart enough/don't have the mental capacity to be a full-stack developer AND a penetration tester simultaneously.
It's that it just don't make sense to enough of these wildy smart people to take on what's essentially three jobs, that when done well, individually consume 30+ hours a week each.
Businesses that hire these frankenstien's monster as employees instead of contractors just don't have a clue.
It's also extremely likely these frankenstien's monsters will burn themselves out as employees essentially juggling three jobs as a salaried flat rate employee.
The only scenario in which being this frankenstien's monster make sense is to bootstrap a consultancy as a founder or a contractor, sign up enough clients and scale out by hiring specialist employees.
The only reason why these frankenstien's monsters happen (outside being a founder or a contractor and I am talking exclusively about employees here) is that employee started off as one type (full-stack developer OR a penetration tester), failed to find employment and cross trained into the other, where they found employment.
For example, without knowing any details, it's likely the full-stack developer AND a penetration tester started off as a penetration tester, failed to find employment and cross trained into full-stack developer. Of course, devil lies in the details, so if the full-stack developer failed to find employment as one but noticed significant demand for penetration testing, they could very well have become a penetration tester.
Empirically a penetration tester doesn't have either time or energy to be an effective full-stack developer or vice versa, especially outside a founder or a contractor role in a bootstrap stage.