Quitting your dream job twice
t3.gg
t3.gg
I got a different take on the topic. I work as a ML Engineer and many people I talk to (particularly students) say that they'd love to work in ML. When I ask why, few people can give an articulate answer other than "ML is cool".
What I try to convey is that work in ML can be as dull and unfulfilling as any other domain, and conversely other jobs can be thrilling and fulfilling. People let great opportunities go by chasing their "dream job", just to realised when they get there that it wasn't as brilliant as promised.
As a parting thought, some of the happiest people I know work a 9-5 job that gives them a reasonable living standard, and have rich and vibrant personal and social lives outside work.
I love this statement.
A while back, when I was trying to figure out what I liked, was good at and should do with my career, I realised that I can't select things based on how much I liked the good parts (because I like so many things) but rather, how annoying I found the dull parts.
It's like, if you find a profession or hobby, where even the annoying and dull parts you can say "meh, it's not great but like I'm not too bothered by this", then you'll probably manage to survive a 20 year tenure with it. Since that's where most people would tap out.
It's easy to like the fun parts. Like when you are coding and everything is working fine. But are you also fine with the nitty gritty of debugging, refactoring and all the in-between bits that round up the profession? I see this in many professionals across the board.
Those who understand the significance of the mundane, the small and boring tasks as a integral component of the wider vision of the profession, develop a special bond with that, that is longer lasting and truer.
Not too much unlike relationships I would say. The good times can be great. But if the small day-to-day stuff is slightly annoying, it starts to get under your skin, and grows over time, like chipping away at a tree trunk, eventually felling the tree. Lasting bonds happen when each person understands and isn't too bothered by the mundane and annoying, human side of their partner.
All this being said, please excuse the philosophy. I'm in Europe, it's 11am, I've had my 3rd coffee and ironically I'm supposed to be refactoring code right now.
One thing I've noticed about myself is that I'm never really sure what makes me happy, but I definitely know what makes me unhappy, so I try to do the opposite of that.
Take mountain climbing. When looked from outside you imagine the mountain, the green, skies and what-not, but the actual task view is 90% gray rocks, 5% your calloused hands and 5% sky.
This is the secret. Don’t work in your passion; find a specialization that you don’t hate but also don’t love and set reasonable boundaries on work. If it’s not something you’re passionate about, you will respect those boundaries and the drudgery becomes bearable.
I absolutely love tech and tinkering on code. So much so that I had to stop doing it and actually lean into the managerial battles described in the article. Turns out I’m pretty good at that job, and I like working with people all day, but it’s a career rather than a calling. I also don’t feel compelled to keep pushing to finish a problem and come up for air to see it’s 9pm.
Kudos on the community activism; talk about building something of meaning.
It's about product sale forecasts, by the way.
I hear this pretty often, typically from very talented developers who have never shipped traditional commercial software as a product (which is definitely a dying breed). I don't care how good you are, you shipped a PoC in a week, not a product. It's great that your self reflection has identified what you're both good at and want to do, but a lot happens outside of writing code to create a product and this can take a long time. I've built a few in my career where I had involvement in the entire process, and typically the difference between when we're "done coding" to when the product is completed is 4x. I'm slow so maybe you can get this down to 3x, but I'm not convinced.
If I had one dream for software development the field and craft it's that we would build less, better.
While you are busy building slowly entire companies are being built quickly. Perfectly? No. But your product probably isnt either.
Now. If it turns out that the product isn't reasonably safe to use and it hurts people, then the manufacturer has a moral and ethical obligation to cover the damage.
"reasonably safe" is often decided by the court system after a manufacturer hurts people with their products.
Besides, the only difference between the two is whether it has customers, it’s not engineering milestone that makes a POC a product.
My first reaction to this statement was, "no that's wrong." But then on reflection, I think that it might be accurate. HOWEVER,
> Besides, the only difference between the two is whether it has customers
This is wrong.
The difference between a proof of concept and a product, is that a product is assumed to be reasonably safe. A proof of concept can be barely held together by string and tape. Because it's just trying to gage the reactions of the stakeholders. Or even exploring the feasibility of the idea itself.
A product had better get the edge cases cleaned up. If you write an email client that sends the user's password to some random URL, then that's okay because it's just a proof of concept. Nobody should be using it yet. On the other hand, if Microsoft's Outlook sends your password off to some random URL, then that's a serious problem. Because Outlook is a product.
Proof of concept has a "use at your own risk" or "for demos only" attached to it.
Product has a moral and ethical obligation of the manufacturer attached to it. It had better be reasonably safe to use for the intended (or reasonably accidental) usages.
Sure, maybe there are some really polished proofs of concept, and maybe there are absolutely horrendous products. Using your example of Outlook sending passwords, that doesn't suddenly mean it isn't a product and was reverted back to merely a POC. It's just a shit product.
Fortunately, it doesn't really matter. I just think folks shouldn't be so quick to shoot down one's accomplishments. Imagine seeing someone pursue their dreams and work on stuff they love, and the audiences reaction is "well, it's actually not a _real_ product." That's just lame.
Really appreciate the support man. I've built enough "real product" to be confident that this method of building is just as real as the rest.
And why might that be? Isn't it because people realized they make way more money charging for PoCs shipped in a week than "products" polished over several years?
Nobody cares what your engineering methodology is like if it doesn't print money.
The fact that shitty software companies are raising massive valuations now should signal that the actual, real useful software companies are massively undervalued.
I'm afraid the OP is going to find that starting a business will NOT let you be a full-time developer. You're going to spend a lot of time learning aspects of doing business that didn't even know were happening. This can also be fulfilling if you look at growing the business as a development process but if you're really looking to code for 40 hours a week I'm afraid you'll be disappointed again.
I think part of your problem is the idea of a "dream job". Jobs are contracts that lead to you getting paid in exchange for hours. It sounds like management was wasting some of those hours but that's their perogative. My advice is that your identity is NOT your job and that if you feel the need for the zen of 8 straight hours of writing code then you should have a side-project.
This didn't sink in until my 30's, it's true though.
Seems like a founder can definitely do that, but then _also_ spend 40 hours a week on the business side. (Only kind of a joke)
The speed at which he puts things out just seems like a different planet to me. I've always been valued by my employers in concrete ways, so I'm pretty sure that I'm not a 0.1x developer, but both my skills and ambitions appear to be quite a bit more modest. That said, I was the only one keeping two teammates (one quite like the OP) from strangling each other, despite not being in a formal leadership role, so that's worth something. Anyway, it's fascinating to read something by someone with such a different brain.
It was the most exciting job I have ever had. I did work with real world impacts. People literally lived and died based on the things we accomplished in there.
Returning to the 'real world' outside of that realm, and I have never been as excited about work as I was then. Sure, I have gotten help and my mental state isnt in crisis anymore. But its not quite the same being on the 'outside' as it is when youre in the middle of above top secret projects that stretch every part of your capabilities.
It is through the help I received I know I can never return to that world; it was what literally caused the issues I was having. I do regret quitting my dream job quite a lot.
What's an SCIF? I tried acronymfinder.com but that didn't help me to understand.
IMO thinking that "having an impact will make me happy" is a fallacy, one of which bored corporate office drones often fell prey to.
As a counterexample, I present a biography of Jozef Czapski - an artist by calling, who became involved in setting up the administration for helping Polish citizens released from Gulags after 1941 (that's when Stalin became part of the anti-Germany alliance, and thus had to release Poles he put into Gulags earlier). It's interesting that his work never had greater impact (he was literally saving lives of thousands of people, who came to him starving, ill, without any money or a place to stay), but it was also the only time when he was seriously depressed. The work just didn't agree with him, he much preferred doing paintings, even if they had zero real-world impact.
Given that even fast connections between SF and Tokyo average around 110ms (1), is < 100ms an arbitrary goal that has been pulled out of thin air, or are you deploying new technology that's faster than a typical fiber connection?
1) https://hello.agora.io/rs/096-LBH-766/images/Agora_WP_SD-RTN...
In fiber, with light traveling at about (2/3) * c, the minimum latency from SF to Tokyo would be about 42 ms.
The physical fiber optic floor from SF to Tokyo is about 50ms, point-to-point, with no sub-fiber last miles, wifi access points, or delay from routers and switches.
Actual user-to-user latency is much higher than that. Agora, for example, cites:
> Low latency, 400ms average globally
I mean... sometimes it's better to beg forgiveness than ask permission. If there's such a big win sitting so close within reach, sometimes you should stop asking and just do it.
I forget the source but there's a good quote about how in the beginning you're learning the rules, as an intermediate you know the rules and how to work within them, but a true senior knows when and how to break the rules.
My take on why it's hard is that I want to be a team player and I generally want to do good for the company and especially the team. If I go and do something else, which I believe in, but which is not what we agreed upon with my team, it feels awkward and I either have to do it in my spare time (this strategy wears thin with time) it "sabotage" something else that I'm doing.
So I definitely see a structural issue at hand here. If anybody has a suggestion of how these situations could be addressed - I'm all ears. How can we tackle situations where the time to write code is much much less than the amount of time to discuss if we have to write this code? How to skip to writing the code quicker?
Lesson learned for sure - spend a few hours hacking at it before trusting someone else's claims of inherent complexity
If you push your code and ask forgiveness in this environment you're risking your company's SOC2 compliance. The auditors are not going to care about the business impact. Their priority is to make sure you're following the process you wrote.
At best you'll get an exception for that control. At worst you'll get a Qualified Opinion. I would not want to be the developer who violated controls and caused the auditors to render a Qualified Opinion. In that case the management response will likely indicate you've been sacked.
Peer review is a good thing. Mature organizations have been doing it forever. It was already endemic at my first real job in '98. We're finally seeing that discipline forced on the industry from the outside. By and large we haven't done a good enough job ourselves so now the AICPA is involved. Get used to it.
Just don’t forget all mammals before being rational are emotional animals.
This fucks me up really bad too. I made significant progress in very expressive KPIs and my answer after a promotion was “I quit”. It’s very little rewarding to pick up low hanging fruits, specially if they’re there as result of bad decision making early on by other people, even though it’s so rewarding career-wise.
Good luck, OP. No matter the end result, enjoy the journey.
Unless you work alone, you will always have these interactions. You will always need to persuade and collaborate and yes, compromise.
Honing these soft skills is the other part of advancing your career and becoming a great engineer. The next time it happens, see it as an opportunity to grow, learn patience, compromise, and to practice your persuasion techniques.
What would you have become if you stayed at twitch another 4 years? Maybe director of engineering. Or CTO. You’ll never know. And maybe those aren’t your goals right now since those roles don’t build. That’s ok.
Thanks for the post. Enjoyed reading it. Good luck with the new endeavor.
The issues come when the red tape is so absurdly placed that obvious wins are being missed. I'm not leaving due to my inability to communicate what is right, I'm leaving _in spite of_ my communication and leadership being effective.
Always happy to be challenged and find compromise, but this post isn't about that. It's about drawing the line.
I hope you have your line drawn somewhere reasonable too. "CTO" or not, I promise it will make you much happier :)
I convinced myself that if we got institutional funding as they hoped, the cavalry would come in and tighten everything up. But then I asked around and found out that institutional investors don't do that. I started just collecting a paycheck instead of trying to build something, got discouraged and left.
It’s definitely never fun when increasing front-end engineering complexity becomes the band-aid for back-end shortcomings. Especially when things are still small enough where everybody should reasonably be able to contribute to anything if they can make improvements.
Sometimes you just want to be able to make choices based on instinct, forgoing deep analysis when you need to move fast and fully accepting that the wrong direction could be the end of the road for the project. But maybe the right choice would have been too; that’s the adrenaline rush of starting things and seeing what you can build. Good luck on this next step.
If you plan ahead, risk can be contained to small enough spaces to make big experiments much safer. Had surprisingly good luck with this over the last year. Round is practically a ship of Theseus with how many parts I've gutted
Love seeing you here man, let's catch up soon
I've come to believe that this is why a lot of people are attracted to starting something of their own. While "bureaucracy" and "red tape" is indeed excessive and detrimental in many organizations, some amount of it is inevitable when an organization gets large and successful enough.
I think a lot of engineers never fully appreciate this. Listening to stakeholders and getting buy-in can make the process feel too slow, but the human components of product management and software development are important. Success usually isn't just about pushing code; it often depends on having listened to stakeholders, obtained buy-in, etc.
Of course, every entrepreneur is forced to understand this if their baby takes off because there are very, very few organizations that don't become slower and more bureaucratic when they achieve a certain level of success.
“Predictable Success” is one of the few business books I recommend, not because it’s necessarily revelatory but rather because it verbalizes these concepts so well.
That's interesting, I always thought that those feelings were a normal thing when you join a organization, and disappeared with time when you "get used to things". I would love to hear what other people think about this.
"It took a while, but they listened. We replaced our monstrous 7,000 LOC socket server with a minimal, maintainable implementation under 350 LOC. This was a huge win, but I had become disillusioned by the process."
How can I replace my current 48,395 LOC of Javascript + dependencies with something more maintainable? Can it be similarly be replaced with 350 LOC ?
This particular rewrite happened to drop about 14 unnecessary deps in favor of vanilla Node.js, Typescript and Socket.io
edit: looks like OP wasn't the author, oops! good luck theo!