Hi readers, this is the ninth (actually 9b) chapter of “my story“. Please take a look at the other chapters for some context.
In previous chapter I’ve documented my timeline at Hooli, the tech giant I’ve been working for 7.5 years between November 2012 and March 2020. I’ve documented my feelings, my team changes, some of my issues, and all of my earnings and wealth growth during my time there.
This chapter is about why working in tech is not as amazing as you might think. It’s not just about Hooli, even though it’s centered around Hooli. I guess similar issues can be found in other tech companies, especially those “extra-large”.
Anyway, Hooli is still a company worth working for. I’d recommend anyone who’s in IT to give it a try. Even the young Millennials/Zoomers among you, the hustle-porn/startup/entrepreneur/GaryVee addicted, take a very good and financially rewarding 9to5 job first, then do your stuff. You’ll thank me 😉
You’ll be surrounded by brilliant people, and get to touch some cutting edge technology. You’ll learn how to communicate, how to think at scale, and – more importantly – how to continuously learn new stuff. Go for it!
Having said that, let’s move to what I – and the internet – didn’t like about working at Hooli.
During my 7.5 years there I’ve collected so many journal entries about my Hooli adventure… There are of course some positive journal entries, but I find myself more incline to write when I’m sad, or when I have something I want to write down to not forget about it. And it’s usually something negative. The more time passed, the more negative my entries are.
For example:
2014, November 27th: Nice Friday at work! amazing discussion with X (he wants to come to Switzerland), nice rum drink with X, Y, and Z. Btw, Z cooked some green tea biscuits and brought them to the office. I love these guys! I want to continue being part of this team!
Same day, 5 years later:
2019, November 27th: Wednesday, another boring day at work. Morning session on Networking not that bad – Lunch with W, a colleague who is also a RIP reader – afternoon session reverse whiteboard, boring like death. T pushed me to be the one driving the reverse whiteboarding session, but I declined. I think I’m perceived as lazy, but I really can’t sustain this shit. I’m counting the days.
I do see some differences…
Mind that I started this journey late in life, at age 35. Your mileage may vary. During my 7.5 years at Hooli I’ve been thru many life changes like: marriage, daughter, burnout, midlife crisis. Perspectives change over time, life goals change over time, passion for “the job” changes over time – usually in the “wrong” direction.
My complaints journal is very long. Re-reading it (something like 29 pages long, but it’s not omnicomprehensive) I can see that many of the issues were fleeting, time and project bounded. But an equal amount were endemic. No matter in which team you are, in which role, how cool your colleagues are… those problems are always there and always will be. Maybe they get worse over time! Surely they did while I was there.
This post is mostly about those immutable (or mutable for the worse) characteristics that made my 7.5 years of working at Hooli not the dream experience I expected it to be.
maybe I’ll also write a post about my personal issues, and Hooli-specific dark sides. Maybe, let’s see.
While doing my research for this post, I looked up on the internet for some extra inspiration and found few amazing articles worth posting here. This one is a millions times clicked thread on Quora that I find very relevant to the content of this post. This Business Insider article extracts some of the hottest issues in the same Quora thread in a nice to read way. It’s a 2016 article though. Things have changed. Anyway, I’ve read the top ~50 answers on the Quora thread, and I think my own issues are mostly all covered there, plus some.
Maybe in a future post of this series I’m going to do a survey of the issues exposed in that thread, and add my own commentary.
Let’s start!
Mr. V
A couple of months ago I was approached by a reader of my blog who was looking for someone to fill a very interesting job position at his company. Let’s call him Mr. V. A challenging and completely different kind of job compared to my past experience! I was honored by his interest in me. We had several chats, a couple of video calls during Covid lockdown, and I also went to their office for a tour once the dust settled. I was close to take that job, but at the same time I got the offer that I then signed with the Academic Institute (I will start working there in September), and I decided to give my Software Engineer career one last chance.
Anyway, in one of our email exchanges Mr. V asked me:
“I know how sensible you are to corporate bullshit, and how easy it is for you to quit a job you don’t like… so can you tell me honestly and openly what are the aspects of a job that you dread, and what are those that excite you?”
It’s not an easy answer, and I encourage you to do the same thought exercise. It will help clarify what’s out of sync between you and your professional life.
Anyway, I sent him the following answer:
It’s not easy to write down “what I don’t like of a job”, because, well, everything is kind of negotiable. There’s nothing I hate in absolute terms, I guess.
Take “stand-up meetings” for example. I hate them, I think. But maybe if I’m super engaged with what I’m doing I would look forward to having a stand-up meeting, and check what others are doing to reach a shared goal. we all believe in.
Anyway, I realized I already wrote such lists in the past so I dug in my old notes and found a “what I hate / what I like” doc I wrote last summer (during my burnout).
I cut&paste here its content, maybe you can take a look and form an opinion about what could make me run away screaming 🙂
Mind that It’s a bit exaggerated: I was at the bottom of my burnout condition, and I was trying to convince myself I had to quit Hooli.
Enjoy!
Hate
- Feeling useless, and not helping anyone with my job (I need to see the impact of my actions).
- Feeling unskilled and not mastering my tasks (I need to feel mastery).
- Feeling empty and burnt out by meaningless tasks (I hate bureaucracy).
- Not liking my company anymore for its mission, the products we work on, the attention economy we want to own, the too personalized ads targeting, and the smartphone addiction we’re helping spreading (I need purpose).
- I hate working in a company all around the globe, with slow communication with people not sitting next to me (fast iteration, clean communication).
- I hate to maintain shitty old code (unnecessary complexity).
- I hate unit tests when they’re useless, and they are most of the time in data heavy processes with simple logic (unnecessary complexity).
- I hate slow progresses (I like fast iteration).
- I hate not debugging code running on my machine and having to use printf instead (I like fast iteration).
- I hate not writing challenging algorithms, like those we ask during interviews (I like mental challenges).
- I don’t like web development in general: backend, frontend, everything. I fell in love with coding when it was single thread, single machine, mostly algorithms and data structures.
- I don’t like cloud computing, and distributed systems (same as above).
- I hate cut&paste code, moving and copying config files around (meaninglessness, a sign of lack of mastery).
- I hate having to change project as soon as I feel good at it (impossibility of developing mastery, a structural problem).
- I hate corporate politics and reorgs at any level (corporate bullshit).
- I hate meetings, in particular standup meetings (corporate bullshit).
- I hate open spaces (corporate bullshit).
- I hate performance evaluation and promotions (corporate bullshit).
- I hate fixed working hours (corporate bullshit).
- I hate Objective, Key Results, and personal professional fake goals setting (corporate bullshit).
- I hate working 40 hours weeks (work-life balance).
- I hate the sad faces I meet everyday at work, seeing no sparks in anybody’s eyes (lack of purpose, lack of energy at work).
- I hate being bored at work, I have a lot of things I like doing more than sitting here and do nothing (lack of purpose, corporate bullshit).
- I don’t like political correctness brought to the exasperation (corporate bullshit).
- I don’t like the “we are a family not a company” litany (corporate bullshit, work-life balance).
- I hate commutes and “must show up in the office” (work-life balance, corporate bullshit).
- I hate paper and bureaucracy (bureaucracy and corporate bullshit).
Like
- High compensation (salary, bonus, stocks, benefits and perks… even though reaching FI would make making more money unnecessary).
- Interesting colleagues (even though I realized I don’t miss them if I don’t interact with them for a while, and I didn’t make many long lasting relationship at Hooli excluding the close Italian ones and maybe few others like SuperBoss, X, Y, Joe).
- Kind managers (even though if I don’t have a job I don’t need a manager).
- Flexibility with working time, sick days, working from home (even though if I don’t have a job I have even greater flexibility).
- Openness and culture (TGIF, Memegen… even though I don’t think I’ll miss it – July 2020 confirmed: I don’t miss any of them).
- Amazing tools (for code reviews, code editors, distributed systems… even though they contribute to some of the problems above, and if I want to code for myself I can use amazing tools freely available, more than good enough for my personal ambitions).
- Respectful environment, I learned a lot about biases, harassment, discrimination and respect (even though I’ve learned everything I need already, and at Hooli we’re going to extreme directions of exaggerated political correctness. Like banning words like black-list, black-box and so on).
Now guys, don’t try this at home 🙂
That’s not how you normally talk to a recruiter or to a potential boss.
But that’s also where honesty and openness could bring you. Thanks to my blog I had nothing to hide to my potential new boss. I was able to have an honest conversation and to build trust on top of that. It felt great. If the other offer weren’t around, I’ll probably be working at Mr.V company now – and nothing prevents this from happening in case my new Academic Job won’t work.
As you can see, the negatives revolve around few key concepts: mastery, purpose, corporate bullshit, impact, bureaucracy, autonomy…
It’s nothing new. It’s the Ikigai thing:
Now, the entire “hate” content of my email to Mr. V was inspired my first hand experience at Hooli (and the “love” aspects have a “even though” clause).
Let’s dig deeper into some of them.
Note: I clustered issues differently in the following paragraphs compared to the original email.
Perf Driven Development – Stress
So one of the main questions I keep getting after having quit is “is working at Hooli stressful?“, to which I have hard time finding an answer. According to Joe Udo (RetireBy40), the answer is simple: every Engineer should aim to FI because your career isn’t going to last. And one of the main reasons is high stress.
I don’t know. Based on my personal experience at Hooli, the job of a software engineer in a tech company is not much stressful on a daily basis, but it’s a lot stressful on a bi-quarterly basis.
What happens on a bi-quarterly basis? Performance Evaluations!
Perf, for friends.
Every six months there’s this huge signaling game that occupies a full month of brain time for each employee (writing their own package, finding peer reviewers, writing peer reviews, write manager feedback, stack rank colleagues), and another extra month for managers (calibration meetings, promotion committees, compensations adjustments, difficult conversations and so on).
This entire game is what’s at the center of everything at Hooli. It’s called perf-driven development.
You don’t perceive much pressure on a daily basis, most of the time. It actually seems the environment is kind of laid down. Relax, slow down, go to the gym, take a nap. But every 6 months you have to be on stage, show off, and outshine others.
Now, I hate perf like almost anyone who’s not going for promotion next cycle. I think it’s fair to measure performances, but something has to change. This process is not even good at measuring that. It’s a celebration of self promotion. And it drives development in the wrong direction.
And I’m not the only one complaining about that:
https://fs.blog/2019/11/performance-reviews-kill-culture/
At Hooli, individual perf outcome is measured on a 5 potential outcomes scale:
- Turbo Giga Awesome!!!
- Giga Awesome!!
- Awesome!
- Ok.
- Not Ok…
As you can see these outcomes are not centered around “Ok”. Ok is quite down the list. In fact, Ok is not really Ok. You can’t just be Ok. You can’t just meet the expectations Hooli set for you. You’re expected to exceed your expectations. I know, it doesn’t make sense. But that’s how it works.
I’ve been there. As I said in the previous chapter, after the first confusing year I enjoyed a 1.5 years (3 perf cycles) of “Awesome!”, “Giga Awesome!!”, and “Turbo Giga Awesome!!!” score, and got promoted. Then things drifted a bit, literally everyone I liked working with quit my team at Hooli Maps, Superboss quit Hooli, Hooli Maps CEO quit Hooli, Hooli Maps slowly descended into irrelevance within Hooli – sadly, because it was probably the product I loved the most before joining Hooli. While this happened I did what a wise Engineer at Hooli should never do: remain in the same team after a promotion.
Promotion… during the perf process one can self elect as a “promotion candidate”. If you want to get promoted you need to prepare an awesome “Promo Packet” that consists of your self assessment (what have you done? how complex was it? what was your impact? how did you lead the project? Can you show evidences, a lot of them?), a manager review, and several peer feedback, i.e. you need to ask your colleagues to write a peer review on your projects. Better if you bring to the table peers on your ladder, slightly higher leveled than you, with whom you’ve interacted in a significant and demonstrable way.
Then your promo application goes thru a series of calibration meetings (to get the ranking), promo meetings, appeals, counter-appeals, until a yes/no decision is finalized, and your manager will let you know when “perf gets released”.
The process comes with its inevitable injustices, unfairness, biases, luck, resentments but I think it’s not bad “per se”. I can’t think of a better way to enforce a meritocratic environment (even though…). You set rules, people play the rules, inefficiency happens. Maybe it’s endemic of working for a large organization. I don’t blame Hooli for this.
If you want to know who’s not performing well enough, there’s not much more you can do. The alternative is the traditional model of “managers decide everything”: managers promote, hire, fire. But that leads to other worse inefficiencies like “everyone will try to please the manager”. Technically, at Hooli, you can be promoted even if your manager hates you. That’s on paper though. I’ve never seen anyone even attempting promotion without full manager support.
Anyway, is this process efficient enough to detect underperformers? In my experience, getting fired for bad performances is a very rare event. I’ve only seen it happening once maybe, and there were rumors that the guy actually wanted to be fired.
<Sarcasm>
It’s much much easier to get fired for code of conducts violation!
Just show up in your next meeting saying:
“Hey guys, I blacklisted the hacker’s IP address from our services. Let’s make hard for him to attack us!”
“WTF RIP! You used the word guys, which is not inclusive… and blacklist, which is racist! You should have used deny-list, which is the new standard. People are getting promoted to port all our codebase to a respectful naming convention! And you also used him as a third person pronoun instead of picking one among the 5 gender neutral ones! You’re fired! Btw, does the IP of the hacker come from the dark web?”
“Which kind of web?”
“Dark… oh shit… 🙁 ”
“Gooodbye 😀 ”
</Sarcasm>
So.. is Hooli really finding the bad apples via calibration scores and perf reviews? I don’t have enough data, but I suspect the benefits of finding that 1-2% of underperformers pale in comparison with the inefficiency of a perf-driven development culture.
Maybe it would be much more productive to “let people go wild“, like Sarah Constantin proposes here (emphasis mine):
Why can people be so much better at doing a thing for fun, or to help their friends and family, than they are at doing the exact same thing as a job? […]
Maybe it’s something around coercion? But it happens to people even when they choose their work and have no direct supervisor, as when a prolific hobbyist writer suddenly gets writer’s block as soon as he goes pro. […]
The costs of reliability are often invisible, but they can be very important. The cost (in time and in office supplies and software tools) of tracking and documenting your work so that you can deliver it on time. The cost (in labor and equipment) of quality assurance testing. The opportunity cost of creating simpler and less ambitious things so that you can deliver them on time and free of defects. Reliability becomes more important with scale.
Large organizations have more rules and procedures than small ones […] Large institutions, even when doing everything right, acquire inefficiencies they didn’t have when small, because they have higher reliability requirements. […]
People given an open-ended mandate to do what they like can be far more efficient than people working to spec…at the cost of unpredictable output with no guarantees of getting what you need when you need it. (See: academic research.) […]
In general, you can get greater efficiency for things you don’t absolutely need than for things you do […] This suggests that “toys” are a good place to look for innovation.
Ok, maybe performance evaluation’s main goal is not to get rid of bad apples, but it’s to find the stellar performers and promote them. Fair. I don’t have a concrete alternative for that. But at least in my experience I’ve suffered the Heisenberg-RIP Principle of performance: if you measure it, you alter it (for the worse). When I had a “free mandate to do good” I was performing extremely well, and felt engaged most of the time, and a master of my trade. When I had to do things for measurement sake, I performed barely ok. Which for my ego is a sign of underperformance.
So… I don’t have many solutions, just – as always – more questions 🙂
Ok, fair, I didn’t do my homework. I didn’t study modern theories on organizations, like the one proposed in the study called Reinventing Organization.
Maybe Hooli is stuck at Orange level, and maybe Teal Organizations figured the performance evaluation and expectations management out. I don’t know.
Food for thought.
Anyway, perf is not only for promo. When you go thru perf without going for promo, you follow a simpler path – but you still have to write a self assessment, find peer reviewers, get a good manager review, and finally get your performances graded in the 5 steps scale mentioned above.
Essentially, if you’re performing well but not yet at the next level, doing non-promo perf means you’re training yourself for when you’re going for promo. If you’re performing just ok or a bit above or below, perf is a torture. An anxiety-filled hell that in the best case will result in you clapping at your colleagues being promoted, and in the worst cases in a difficult conversation with your manager (or a PIP). During the ~15 perf cycles I’ve been around, Hooli alternated between public promotion celebrations, to total silence, back to sending congratulatory emails within the team and so on. It’s not clear if it helps or not to let others know who’s stellar and who’s mediocre.
Apart from the perf process itself, the most damaging aspect of the perf-driven development is the attitude it incentives: just do what’s going to be good on your promo packet.
- Interviewing potential hires? Nah, it doesn’t count.
- Fixing bugs? Not much.
- Maintaining old code? Are you crazy??
- Refactor code? Well, it depends… can we measure and prove the impact? Can we? Ok, let’s do it. Wait… it’s just for the sake of easing future development? Holy shit, what am I going to put in my promo packet then? Nope!
- Pair Programming? Are you joking??
- Helping other colleagues? Mmm it depends: does my ladder for level N+1 requires some leadership skills? Can I take over a sizeable chunk of my colleague’s project so that it can be a line item in my promo packet? Ok, let’s do it…
I’m not saying that everyone thinks like this, of course! I’m just saying that the incentives are in that direction. I’ve had amazing colleagues that helped out and refactored crappy code all the time, and those were the best to hang out with. Sadly, the perf process discourages this behavior. As anecdotal evidence, most of the amazing colleagues that didn’t care much about promotions quit Hooli to either join smaller companies, or to fund one.
Perf/Promo driven development requires that you only take on shiny new projects, make a pre-alpha prototype, launch anyway even if the code is full of bugs, show some positive (for you) short term metrics at perf time, and then leave the boat unattended and watch it while it sinks.
I come from a different mindset of responsibility, support, maintenance. Quality.
Code Quality – Unnecessary Complexity – Innovation
Working on a codebase with a large Engineer turnover is a hell of a life. There’s almost nobody you can ask for help, except nice colleagues who – like you – know nothing. You can guess together. And the knowledge you build up this way is always based on anecdotal experience, and empirical evidence. Not scientific. It’s alchemy, not chemistry.
And this is not a Hooli exclusive problem, this is how Software Development works almost everywhere. The time a software company has available before dying a death by thousands cuts is based on how the company manages growing complexity.
I bet Hooli did a great job for its first 15 years or so. Reaching huge scale while still being manageable. During last 5 years (at least) things went south and perf driven development took over.
There’s an annual self celebration routine at Hooli. Let’s call it Hooligeist. Every employee fills out a huge and detailed form where essentially they evaluate their bosses, their directors, the company, work life balance, the technology being used and so on. It’s a series of sentences that you should mark as “strongly agree”, “agree”, “disagree”… things like “I would recommend my manager to other employees”, or “I think Hooli is still focused toward its mission”, and so on.
Well, the sentiment around sentences like “My work has not been slowed down by unnecessary technical complexity” dropped double digits per year, until somewhere around 70% disagreed or strongly disagreed with the sentence in 2020 (or 2019, don’t remember exactly).
And of course, one day (maybe it already happened?) Hooli will stop measuring the metric if it doesn’t help morale.
But that’s what happens when a company grows, and I think this is inevitable.
Not Hooli fault.
It’s called tech company doom loop:
Per driven development, and huge technical debt lead to individual opportunism and collective shortermism, i.e. a continuous low-hanging-fruits driven goal setting. No room for risks, despite all the amazing words from executives about innovation and courage.
Incentives don’t always align with intentions.
And at the same time no much room for improving code robustness, coding quality, refactoring. It’s never a priority, even though nobody will stop you if you want to work on those issues. Just mind that you won’t be rewarded for them. Unless something surfaces and becomes critical. Like a huge shift toward reliability (and a lot of Reliability Engineering opening positions) after a couple of very bad incidents back in 2018 / 2019. Still, it’s production reliability that gets resources. Not development.
These things accumulate over time, even inside your brain. When I was working in research and then Videogames (and then as a Freelance) I used to know my tools deeply. I’ve mostly been working in C++ before Hooli. I’ve read everything ever published about C++. Books by Meyers, Sutter, Alexandrescu, Koenig, Josuttis, Stroustrup… plus classical Software Development and Design books like Design Patterns, Test Driven Development, Refactoring, Clean Code… I used to feel a master of my trade.
Not anymore 🙁
At Hooli priorities change pretty quickly. Frameworks, languages, tools… you become good at adopting something new very quickly. You learn how to learn. Seems cool right? Wrong. You don’t actually “learn how to learn”. You only learn how to superficially use a gargantuan tool for the small task you have at hand, and then forget about it – because you have a lot of small tasks to handle. What you’re building is irrelevant. If you raise your head you can see its insignificance, and you know the project will probably be shut down within a year or two. The project I was promoted for has been deprecated a year after the launch, and shut down another year later. And as soon as it was 10% ready it was launched. I felt embarrassed for it. “wait, it’s missing this and that and that”. “no, let’s launch and iterate 😉 “. We only iterated once. There are still dozens of TODOs in the code. But a new quarter came, new low hanging fruits must be grabbed.
So there’s no time to get really good at anything. Your brain has no capacity to get good at the 1000 tools you constantly need to perform well. Better to keep it empty, and be ready to attack the “1001th-tool for dummies” guide (or just cut&paste from other code), use the tool once, then forget about it.
Mastery: the lack of
One of the side effects of this approach is that you don’t invest in learning individual tools. Someone calls it “maturity”, or “seniority”. I call it self obsolescence as a technical worker. Jack of all trades, master of none. It doesn’t bring you far in tech. Unless you take the leap into management, and then the dance can continue. Your breadth, not your depth, becomes an asset if you can keep impostor syndrome at bay.
I’m not wired in this way.
I’m (was?) a Software Engineer because I felt passionate about creating things. Creativity requires mastery. I can’t let “the sky be the limit” if I don’t know how to use my tools. During my C++ years, I felt a master of the language and the go-to person in every engineer circle for language questions. I could focus on high level stuff, on just creating something new, because I knew how to implement what I wanted to create. Zero technical friction. This feedback loop made me even more passionate! I devoured more books, I could expand my knowledge, slowly in adjacent fields.
At Hooli, I stopped being interested in learning technical stuff. At first I got a book on Javascript. Let’s learn the good parts! I know nothing about this language and I have this cool frontend project! Let’s look how… wait what? It’s no more a priority? But our users love it! Ok, fine… Python. Ok, let’s study the languag… what? Yes, I know I can cut&paste from our codebase, but I feel much more comfortable knowing the principles, the paradigms, the idiomatic way to do X in language Y, using the framework Z… what? I should learn Go as well? And use these 100 libraries… you know what? let’s cut&paste and make the compiler don’t complain 😉
Quality? Not today. Some unit tests will be more than enough.
That’s how my passion drained. No more focusing on the creative art of code design, algorithms, data structures… just quickly implementing something that is usually irrelevant, soon to be deprecated, using a gazillion tools in a shallow way.
It took a lot of time for me to acknowledge this.
It wasn’t a lucky series of few bad events. It wasn’t a shitty boss that would have forced me to ragequit and look for something else. It’s been a nice, kind, comfortable descent into darkness.
Facing perf stress every six months, continuously fighting with impostor syndrome, knowing I was a good software engineer in the past, and acknowledging that I’m no more.
And I know many, most perhaps, are experiencing what I am at Hooli or in similar companies. But there is a surprisingly high fraction of colleagues who seem to thrive in such environment. Based on my anecdotal stats:
- Roughly 20% of engineers quickly become unsufferable and express their complains and inevitably quit or get escorted to the door.
- Another 60% seems to live just ok, but half of them are dying inside and sooner or later will confess and slid in the bottom quintile. Maybe I appeared to be in this bucket for a while.
- The remaining 20% seem to enjoy and take advantage of this set of rules. They get promoted fast, climb the ladder, and are genuinely happy with the system. I would love to know their secret!
Burnout
Well, I’ve talked a lot about this issue in the past, and I don’t have much to add from my personal experience.
I can only add a couple of resources here to show that maybe it’s not necessary your fault if you’re burnt out. Maybe the system has some responsibility.
First, burnout – and mental health – is a real thing. It used to be stigmatized a lot. Things are slowly going in the right direction.
Second, burnout is not your fault. But you can do a lot to prevent it. The corporate way to address it is via McMindfulness – which is essentially a way to discharge responsibility on you. Yep, you probably didn’t think about this:
Third, if you want a forty year career, take your time and slow down TODAY.
Fourth, coding is hard, coding is suffering. Especially in modern workplaces. Let’s just stop telling people “you should go and pick a shovel in a coal mine, you spoiled kid!”
Even “lucky” YouTube creators experience Burnout, which has very similar roots of what I described in my “unhappiness at Hooli” series so far: lack of (perceived) mastery, lack of cause-effect relationships, lack of a semi-predictable environment and rules to play with.
Ok, enough for today.
I’ve so much more to say… Remaining issues will be addressed in future posts. I bet at least another 2-3 posts this length are coming. I hope you enjoy the series 🙂
I’m going on vacation for ~2 weeks, so I won’t be posting until mid August. But I’ll read and reply to comments and emails. Feel free to join the conversation 🙂
Have a nice day!
P.S.
Okay, having said all of that… get that job at Hooli anyway! It will boost your career even if you don’t plan to stay there for long. You’re going to earn a lot of money, learn a lot of things – some of which will be useful anyway. You won’t get exceptionally good at anything, except maybe at “getting shallowly good at random things in a short amount of time”, but that’s a skill worth cultivating for a couple of years at least.
And maybe if you happen to be in the top quintile, those 20% who thrive is such an environment… bingo! You get an amazing salary, unlimited career and salary growth, and a job that you love! Those who can do that are way better than FIREd people! And maybe that’s also a skill you can learn. Maybe you can learn how to thrive in such an environment. You need to give it a shot.
Don’t come go to Hooli (or any other FAANG company) to just wait until you reach FI, or you’ll die trying. Go to Hooli to try to join the exclusive club of “those who love it”. At the end of my Hooli career I was in the bottom quintile, those who suffer a lot, and I had to give up. I’ve been in the central 60% pack for many years, and maybe I’m guilty that I let myself slide down to the bottom. In a parallel universe there’s a RIP telling you a very different story, had a single event gone differently.
I know, by speaking with people in their early 20s, that working at Hooli looks to them like “working for a bank” looked to me when I was their age. It was weird to realize this, like it was probably weird for a boomer to accept that their children didn’t dream about working for a bank as well… but I double down: before you go out and try your stuff, take this still amazing 9to5 job and rock!
Have a great day!
Previous chapter:
Next chapter: