> So, while it’s clearly possible to have a career in a lucrative field you dislike, it’s (a) going to be harder for you than for people who like it and (b) maybe you should consider a field that you do like?
> You gotta want it. Do you want it enough to go through the tremendous amount of effort it takes to learn it? Maybe you hate programming, but you want the money enough. Maybe you don’t care about the money, but you want to program every second of the day.
> Just make sure you have the drive to make it happen.
There's also a huge difference between liking to program and liking to work as a programmer. I despise the latter as business programming takes the joy out of everything. Trying to educate management about the current boundaries of the product or having to work extra hard because a product manager promised features that dont yet exist is exhausting. Not being allowed to work on fixing tech debt while having to build on top of it is pain. Doesn't help being a solo dev in a start up either so maybe that's the issue.
I think this is just the nature of paid work, though. Academics are generally in love with their topic, and very much not in love with the kind of admin busywork that they have to spend much of their working hours doing.
I meant it as a shorthand for the standard gripe of "love my job, hate the paper work.". Many surgeons will also admit that they hate clinic work too, it's so much nicer once the patient is sedated and they can drop their bedside manner.
However there are jobs close to "recreational surgery".
One is surgical assisting. The pay is poor compared to being the primary surgeon, but has none of the patient or bureaucratic responsibility. Retired surgeons often do this, and not because they need the money.
Another is volunteering in the third world. Little bureaucracy and no long term patient contact.
As a solo dev in a start up, man is this true. I have a lot of control over the product, but nobody else understands or cares how features are achieved. I feel your pain.
I like pushing the boundaries and making seemingly hard visions come to life. Sadly, I'm often working on CRUD applications where most things are possible and boring. At home I work on obscure side projects to see what is possible with either existing open-source projects, or non-existing projects (things I want that I can't find).
> I'm often working on CRUD applications where most things are possible and boring.
Gotta disagree, a lot of things aren't possible as soon as you have a data scheme set which was running in prod for a while. Introduces a lot of complexity when data structures suddenly have to change.
There's a lot you can legitimately blame PMs for, but promising features that don't yet exist is essentially their job definition. A good PM will allow for uncertainty and flexibility, but at the end of the day, to have some sort of product roadmap, even in the most agile of environments, they have to say things like "at that stage we'll have functionality x, so our product will enable users to y, so that we'll better compete across z"
>> promising features that don't yet exist is essentially their job definition
Agree. I think he meant (at least my reality) they promise features that does not exist (ok) AND are impossible to implement in the promised time (or at all).
I think there's also an element here of... when you work a long time on something, you tend to become emotionally attached to it, and you want it to be good and work well. Time to fix technical debt and work on making the product good is often implicitly waved as a carrot ahead of people who care about that sort of thing. "We can prioritize that after we ship $FEATURE."
This then feels like a betrayal on an emotional level when instead of a nice block of time to fix technical debt, instead the priority becomes $NEXT_FEATURE (the "features that don't exist yet.")
Management that can successfully keep the treadmill running ships features faster, so it keeps happening, and can contribute to burnout as (what felt like) implicit promises are repeatedly broken for the good of the business at the expense of the product.
PMs are an invention of PHBs that sat in too many introductions to agile from management consulting firms.
Actual agile gets rid of them along with all the other cruft. PM as a title is fundamentally a jobs program for people who couldn’t hack it as programmers, or are nepo hires. You could argue a North Star like a product manager performs useful business alignment. But in 12 years across several companies I haven’t met a single project manager that is more than a professional problem manufacturer with selective hearing that miraculously ignores expert engineering opinion.
Of course. Obviously a PM who isn't talking to the devs isn't doing their job.
But having said that, a PM is the person who owns the roadmap, and after talking to the devs, they may at times choose a course of action that goes against the devs' preferences (assuming the devs even have a consensus), because the PM has a lot of additional considerations. There are for example situations when the choice is either to crunch, take on massive technical debt, and still arrive at a feature with a somewhat lower quality than we'd like, or to lose a big business opportunity and possibly to have to let people go.
Most PMs that I've worked with are actually not that good at their job, and some were definitely detrimental to the org, but the good ones, who have an extensive understanding of the business domain and the technical situation, and have a clear vision (and strong opinions held loosely), are worth their weight in gold. And seeing how I did a short stint in a product role and don't want to go back to that sort of responsibility, I am grateful for the ones who are willing to take this on, and to take ownership when things don't go according to plan (and they usually don't, even in the best orgs).
(1) The technical staff understand the business constraints AND (2) management understands the technical constraints AND (3) both constraints "match" you are in heaven. I've seen that. Is possible. Is nice.
More often than not, one of the 3 conditions is not met. In case of 1 and 2, if they are good professionals, talk can (and typically will) help. In case of 3, you business case sucks, that is a big problem, change company. Run.
I am the worst example to ask this. I regularly go rogue or work on private shit during work. As long as there isn't any pressing work to do I force the balance I need. Perks of working alone I guess.
> it’s (a) going to be harder for you than for people who like it and (b) maybe you should consider a field that you do like?
This shit is so infantile. It's like people have never heard of grinding. Do you think big law attorneys "love" their jobs? How about public accountants? How about dentists (famously known for having high suicide rates).
> Maybe you hate programming, but you want the money enough.
Yes welcome to the grand epiphany that drives 99% of people. There's nothing special about programmers.
Interestingly, the three careers you listed are protected by strict professional credentialing systems that do not exists for programmers, and professionals in law and medicine enjoy a social prestige that is certainly attractive to a group of people who might not innately enjoy the work itself.
I can’t speak for others, but I’ve never met anyone really successful in the industry that hate their job, or were purely driven by the grind.
Every single one have been deeply passionate about their craft.
Not saying that you can’t grind your way to success - earning enough to retire at FAANG firms is possible, just by grinding. But the vast majority, even those with a grind mindset, will not be able to do that.
respectfully, you probably do not know the inner motivations of every successful person you know. what may look like passion to you may be grind to them
> You gotta want it. Do you want it enough to go through the tremendous amount of effort it takes to learn it? Maybe you hate programming, but you want the money enough. Maybe you don’t care about the money, but you want to program every second of the day.
> Just make sure you have the drive to make it happen.
Man this is so true