I like the point that your dream job of today might become your professional prison of tomorrow. But at the end this was the entrepreneurship porn that HN loves.
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.
"work in ML can be as dull and unfulfilling as any other domain"
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.
> 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.
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.
Of course. It's the "zoom" effect, not sure how else to call it.
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.
> 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.
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.
Do you find that you then have more time and energy to code on the side on your own things as a hobby? Or do you get enough of a “hit” from being code-adjacent and spend that mindspace elsewhere?
It’s close enough to my day job that I don’t really do much coding anymore. I burned out pretty hard on it a decade ago so it just feels like work. I scratch that itch with other things now (music, competition shooting, community activism). There are plenty other ways to exercise an analytical mind.
Thanks for the reply, and what you say makes sense and is a familiar tale. Weirdly a lot of people describe their coding past with a burnout, reassessment, and subsequent pullback, almost like a drug relationship.
Kudos on the community activism; talk about building something of meaning.
I really do think grinding code is a young person’s game. It takes the kind of mental stamina you can only sustain for so long before life gets in the way.
I can echo this sentiment, I work as Senior SRE at a FAANG, I always though I wanted to work at a FAANG because it would be exciting, high pace, and use lots new technologies. Well most of the time it's incredibly boring. The only difference between where working at a FAANG and a regular old fortune 500 is that people who don't work at a FAANG think my job must be amazing.
I got asked to help on an ML project and right now it seems dull as dishwater. Having a hard time being productive because I can't get interested in it at all. That might change in time, it's still really early, but I'm starting to think I'm glad I didn't chase this particular rabbit hole.
Well said. Since work takes such an out-sized amount of our lives, we often assume that this is where our purpose is. At parties, people ask what we "do" and we almost universally reply with our vocation. We assume this is our definition. If that works for you, great! But sometimes, a job is just a means to sustain life. Find a cause, find a hobby, find a purpose that truly fills your soul. The search for such a thing is another joy in life. And when you find it, you can experience it without the business concerns and unrealistic deadlines. I've read countless stories about people who had a dream and once their dream was attached to making rent and having food, it was no longer their dream. Make your job the thing you dread so your passion remains for your dream.
I think the "x is cool" part is necessary. Even if the actual steps to do something are mundane or tedious, it's usually the concept of "doing the cool thing" that gives motivation to persevere.
Part of the “appeal” of some of these tech areas is the supposed status of working on something that is perceived to be hard. But then people get into them and realize that, unless you’re the ones doing the actual research (which itself is frequently a slog in a different way), for most part the day-to-day is the same as anywhere else: occasionally solving small challenges amidst a lot of “boring” work and maintenance. Some “cool” tech alone is not what makes a job fulfilling over any appreciable timespan.
>> I spent a week putting too much time into a web game about Dogecoin. ... I can go from concept to product pretty damn quick.
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.
The majority of the article is about how the author spent significant time working on mature products, not just doing little green field apps. It sounds like they definitely know the difference between a proof of concept and an actual product.
Besides, the only difference between the two is whether it has customers, it’s not engineering milestone that makes a POC a product.
> 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.
I see what you're saying, I just don't view it like that. There isn't any definitive way to say something is or isn't a product versus a proof of concept, my criterion included (it having customers).
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.
> never shipped traditional commercial software as a product (which is definitely a dying breed).
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.
It is a good thing. Even shitty software was underpriced back then. Developers and tech companies deserve massive ROI for the work they do. In an alternative world the Linux Foundation would have become the first trillion dollar company.
The fact that shitty software companies are raising massive valuations now should signal that the actual, real useful software companies are massively undervalued.
Sounds like classic gatekeeping to me. Do you get to decide what is a POC and a product? What qualifies something to be one over the other? Tests? Some other technical aspect that feels "producty"?
While you are busy building slowly entire companies are being built quickly. Perfectly? No. But your product probably isnt either.
A proof of concept becomes a product when the manufacturer sells it to clients with the expectation that it is reasonably safe to use.
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.
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.
Thinking back to the 10x developer discussions from a few days ago, the OP seems like an exemplar of one of the stereotypes (not necessarily bad or wrong): Very fast, very quickly frustrated, potentially not great at communication/politics.
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 is good that the author is in a good space. I quit my dream job last October due to failing mental health arising from being forced to work inside a SCIF for a year.
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.
> People literally lived and died based on the things we accomplished in there.
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.
Your "Round" product claims "<100ms latency from San Francisco to Tokyo."
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?
We're built on top of Agora at the moment. We saw some super promising numbers in the sub-100 range but I didn't thoroughly test. Their SD-RTN whitepaper(1) makes claims nowhere near that bold, so I will update accordingly
Those are point-to-point pings between data centers.
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:
> I had spent almost half a year justifying code that took under 10 hours to write.
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.
You can not beg for forgiveness if you don't have a formal approval to allow your changes into the product. In multi-team environment it's impossible to push your code into production if you aren't aligned with the rest of organization. There are all types of gatekeeping and quality checks that prevent from any cowboy action. Most of the time that's for good, and sometimes it hurts, because of different views, mindsets and experience of people who are taking those decisions.
This. Even if you work in a small shop, SOC 2 Type II Security is starting to become table stakes for any kind of formal business arrangement. This means you have a formal Change Management process which includes peer review and peer testing.
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.
If the specific change is a 10-hour rewrite that's self-evidently better than the old code, you absolutely can beg for forgiveness once you've written it, since you don't have to merge or deploy it anywhere. You're going to quit anyway, so who cares whether your boss tells you off for spending a day or two attempting to solve a legitimate business problem?
If you're going to quit, why spend 10 hours of your own life solving a legitimate business problem that won't benefit you in any seemingly measurable way?
Because most human beings are intrinsically motivated to help people and all things being equal you might as well? I don't really understand what point you're making here.
While I completely agree with you that asking for forgiveness in these situations is probably a better strategy, I definitely know the feeling that OP had.
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?
Honestly I expected it to take at least a week or two. The team that owned the backend made it seem like there was a lot of "super tough magic going on here", which was a lie on its face.
Lesson learned for sure - spend a few hours hacking at it before trusting someone else's claims of inherent complexity
By experience, the social aspect of working in a team and being right and proving it by breaking the rules, is a risky business as it may cause the eternal hate of some peers, who in other aspects are themselves as technically strong as yourself and will stay around forever.
Just don’t forget all mammals before being rational are emotional animals.
> This was a huge win, but I had become disillusioned by the process.
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.
The reason for your twitch and TTFN departure, red tape as you called it, are everywhere. It’s not red tape. It’s persuasion, collaboration, compromise, and leadership. You clearly have all of these skills. But still, It’s easy to get frustrated by these things when all you want to do is build.
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.
I've taken plenty of these opportunities. I describe one in detail in the post. The majority of the teams I've been on were structured well enough for easy wins to be taken and good solutions to be built.
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 :)
It seems really niche but I like that, it allows you to really perfect the product for a singular use-case. Do you already know if/how you're planning to expand after this?
We have a lot of ideas but I don't want to share too much as we haven't committed to any one thing yet. Definitely eyeing the IRL/mobile streaming market though, feels like there's a growing need for some innovation in that realm
We had a similar problem my last startup job. The back end was a complete house of cards. I spent months trying to convince leadership we needed to shore it up. I could have done it myself in a week if they let me. But they kept pivoting from one concept to another on the front end and weren't interested in fixing the back-end.
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.
> 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.
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.
I don’t disagree at all, it’s just about difference phases of a business’ arc. Early on you take big risks and move quickly, optimizing for completely different things than when you’re further along and more established. And sometimes you’re happy to do the slower soft work of trying to turn a giant ship (case in point, this is my current position) but other times you just want to ride the ocean on a raft that you’re cobbling together from passing driftwood. Both approaches are terrible fits when attempted at the wrong phase of a company’s lifecycle, but that doesn’t mean a person can’t appreciate the different modes while understanding why the grass looks greener. (I also know that being total yolo to start something is a myth, but so is the idea that everything at a large established business should involve slow consensus-building).
“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.
I really need to do a follow up post on this: "building safety nets"
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
> Realizing that I had outgrown my role was a long, painful process. My last year was particularly rough. I saw so many points that hurt both creators and users. I wanted to destroy, rebuild, and improve everywhere I could.
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.
Sometimes a dream job becomes just that, a job. Slowly and slowly it eats you up and you either grind it out for that paycheck or go find something else.
"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 ?
as a skate/music nerd, this was cool to read. i'll be fresh out of uni soon, and hoping i can stumble upwards as well. good luck to OP, round looks rad!
edit: looks like OP wasn't the author, oops! good luck theo!
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.