I’ve always strived to “live in a position of f%%% you” (https://m.youtube.com/watch?v=xdfeXqHFmPI). Why would I let a company “burn me out”?
When the pay/bullshit ratio gets too low, I send my always updated resume out, review my “career document” to prepare for behavioral/informal interviews (I don’t do whiteboard coding interviews), talk to people in my network and I get another job.
Before my current job, I was a dev lead and then the de facto “cloud architect” at smaller companies. My current job is much less stressful.
[1] currently my official title is not “software developer”. But for all intents and purposes, I still develop user facing software along with a crap ton of yaml, HCL, diagrams and PowerPoint slides.
Like, you refuse them or the positions you apply for don't require them?
I stayed at one company too long from the time I was 25 until I was 34. By the time I left, I was very much an “expert beginner” - I was doing old school VB6 in 2008 (discontinued in 2001) and C++/MFC/COM programming (ask your kids). But at 34, I had developed soft skills and knew how to talk to business people.
From 2008 - 2018, I both modernized my enterprise dev skills and learned how to solve business problems. I also got lucky and always seemed to get connected to managers, directors and CTOs who were new to their company and needed to solve business problems. Most of my “interviews” were casual semi-technical but mostly about process/development improvements even as I stayed hands on.
By 2016, I belatedly discovered “the cloud” when the company I worked for as dev lead wanted to “move to the cloud” and they hired “consultants” who were really just a bunch of old school Net ops folks who knew how to do “lift and shifts” duplicating and on prem architecture to AWS and of course costing more. As I learned more about AWS, I knew I could bring a unique set of talents as someone who knew both the infrastructure side and the development.
I found a job at another company where the then new CTO wanted to pivot the company to being “cloud native” and sell access to micro services to large health care companies.
I talked through my proposals after listening to him and I led the effort over the next two years.
Then at 46 a recruiter from Amazon Retail reached out to me about an SDE position. I was not interested in being a software engineer at any large company, not interested in relocating “after Covid was over”, nor was I interested in doing the leetCode/DS&A monkey dance.
She suggested I apply for a role in cloud consulting “application modernization” (really just software development + devops using cloud services) in Professional Services that was fully remote. I had the tech skills, the project leadership experience and the customer facing experience from working at small companies. My interview was all behavioral besides a little AWS techno trivia as part of the initial screening.
So in reality, I just fell into a specialty where companies are more interested in my ability to solve business problems than reversing a binary tree on the whiteboard.
That show is incredibly good. I'm not quite done with the first season (two more episodes, will likely be watching them both tonight), but it's very interesting.
I think a lot of people at first think that if they could have an operation done that makes them essentially skip their work day, they'd jump at the chance. This show really shows how there could be serious problems with that.
Capital-P-Policies get followed. But there are a lot of lower-case-p-policies, more what you might call guidelines, that are not. Sometimes, for good reasons! There are examples of things Amazon does that try to encourage individual judgement, trusting the people in place. But there are also examples where we think we know what the right process is, but for whatever reason (prioritization, we haven't figured out the right way to enforce it, scaling challenges) it's not as strictly followed as outsiders might assume.
That has been exactly my experience, after 5.5 years. My team spends 4 hours in sprint planning every week (there are 9 of us). It is way more important to try to plan out work than it is to actually do the work.
> The bigger problem I have with the company is the types of managers that environment creates. The primary function of a manager at Amazon as far as I can tell is to enforce process and the secondary function is to maximize output of the people reporting to them.
I did burn myself out trying to reduce operational load. I wasn't arguing for it the right way, so I ended up doing it myself. I was able to measure my results, but it didn't even count towards a promo because I didn't "harmonize discordant views"... instead I just did what needed to be done.
Many many folks inside Amazon say it has a startup culture. That is false. Try to find out how many of those folks have actually worked outside Amazon before taking their advice.
That seems excessive, but I don't know what area you work in. Does your team need to spend that long? I have heard of that happening within Amazon, but then people vote with their feet and move to a team that doesn't spend four hours in sprint planning.
> Many many folks inside Amazon say it has a startup culture.
I've spent roughly as much of my career at startups as I have at Amazon. It's a bit of a mix bag. Having worked at start-ups that had to spend time doing undifferentiated work (just getting automated deployments, for example), it's in some ways nice not to deal with that, and yes, you have to follow The Process for that to be easy. I sometimes see people taking chances and acting quickly on new opportunities. But yes, I also see people not taking chances when the cost of doing so would have been small. Then again, I once worked for a start-up where you had to use a particular template for a design document, and you had to produce a project plan that 6-month long projects that was accurate to the hour. So... I think it's hard to make generalizations.
In this case I'm talking about the tasks in each sprint. I think 1 day of planning per sprint is a lot. We are supposed to be agile. If we missed a task, swap it with another. If something isn't actually important, bring in something new. We end up doing this anyway... so why all the upfront planning each sprint?
Related back to the above comment, (my opinion) people really love to establish rules and processes and are not able to handle ambiguity. I spend a lot of time (remember the 4 hours a week) arguing whether a story is a mouse or a hedgehog.
IMHO it's splitting hairs, let's just do the work and we estimated a little wrong it just isn't that important.
My implementations are for a specific customer and I don’t have to worry about that type of scale where a mistake or miscommunication in requirements can be costly and affect hundreds of customers.
I have made mistakes as a contributor to a popular company sponsored open source project. Even that caused headaches beyond the scale I was use to dealing with.
When I started in AWS, I watched customers implement hack solutions for themselves because it would take our team too long to deliver a proper solution (so hard to give specifics on HN :) ). That was the hardest thing for me to handle. The mindset is what works best over the next N years, not what works best for a set of customers right now.
Honestly that is the right mindset. Early adopters know they are early adopters and will have to work around problems.
I think the take away from this conversation, for anyone still following, is that a lot of developers (like myself) want to move really really fast. AWS has processes in place to prevent this movement from breaking customers. While it is so annoying for me, it really is a win for customers.
Highly motivated people who always go the extra mile get exploited and burnt out. Kind people get their kindness taken advantage of and it sours their view of the world. At least that's what I've seen from the outside.
The bigger problem I have with the company is the types of managers that environment creates. The primary function of a manager at Amazon as far as I can tell is to enforce process and the secondary function is to maximize output of the people reporting to them.
Empathy is actually a disadvantage in this type of role and it selects for all sorts of what I would consider adverse behaviors among managers. The "leadership" principals relate to actual leadership as a jellyfish relates to Smucker's. Look up Google's project oxygen findings if you want a comparison.
I personally doubt I'll ever hire someone who learned engineering management at Amazon unless they've been sufficiently detoxified in a different company.