No post body was provided.
A career ending mistake
271–280 of 332 posts
Re: A career ending mistake
#272I changed careers at 40+ years old. I'm very happy that I did it. People have all sorts of constructs / ideas about how careers work (based on experience) or how they think it works, or how they want it to work. I talk to some college graduates who tell me what they're planning for and have ZERO clue what industry they're talking about, their description is unrecognizable to me ... even tho I know it is the one I wor…
It is interesting to me how much variation there is within a single career, a single company, a single department, etc.
Re: A career ending mistake
#273It's completely unsurprising to me that HN likes to take career advice from someone who doesn't know the difference between 'careen' and 'career'.
I thought this too, but google backs him up as being correct.
I don't know where Google got that definition, but I don't see it in a dictionary so far...
https://en.wiktionary.org/wiki/career
Re: A career ending mistake
#274Feels like the "senior IC" role described in this article corresponds mainly to today's "3-5 years of experience 'senior' engineer" roles. The reality that I've seen and experienced is that advancing beyond that on an IC track means a lot more people/political work, rather than constant "hands on keyboard" coding as described in the article. It's not the same as management, but it's inevitably more meetings and evang…
This is something people seem hesitant to realize: that after a certain point you can only grow your career by "managing" other people. This is true in a lot of (most?) fields. At some point you cannot become more productive as an individual and you need to start coordinating the work of many people if you want to increase your productivity. This can of course take many forms, but the essence is inescapable.
This is really not how most companies think about it. Unless you take an extremely broad view of what “management” is.
As a term of art, used by people writing the JDs for “manager” jobs (source: have wrote those JDs), it specifically means having people reporting to you, being responsible for their productivity, growth, and development.
The senior IC track does not (have to) involve management. It does involve a lot of communication, collaboration, and coordination, which may look like management if you squint. And there is overlap; in small companies, particularly startups, sometimes tech lead and manager hats are worn by the same person. But they are different roles.
And particularly, to the point of the article, they are different career tracks. You might wear both hats for a bit, but most careers will end up specializing on one or other track.
See https://lethain.com/ for lots of material on what it means to be a staff-plus IC, as well as engineering manager.
Re: A career ending mistake
#275The author makes it sound as if career paths were under our control, while they often are not. Any of these events can change your choice of possible roles completely:
- Being at the wrong place at the wrong time
- Industry changes or gets disrupted
- Falling out with a boss
- Having burnout
- Having children
- Spouse gets sick
- Accidents
- Stock bubble bursts
- War
Trying to plan your (job) life up front can be a nice thought experiment, but, in my opinion, not much else. Like a car driving in the dark, we can’t really plan way ahead. There’s no knowing what’s further down the road.
Accepting this is, I believe, crucial for leading a good (job) life.
Re: A career ending mistake
#276The author makes it sound as if career paths were under our control, while they often are not. Any of these events can change your choice of possible roles completely: - Being at the wrong place at the wrong time - Industry changes or gets disrupted - Falling out with a boss - Having burnout - Having children - Spouse gets sick - Accidents - Stock bubble bursts - War Trying to plan your (job) life up front can be a n…
Thats a bleak (if maybe correct) outlook on life!
I think the old maxim “success if where preparation meats opportunity” is very true. You cannot usually control for the “opportunity” side but without preparation you’ll definitely miss a lot of opportunities.
Sure you can’t predict war, but its hardly ever something that happens overnight - like the brewing conflict in Ukraine has been brewing for decades and you can always try to move somewhere more stable.
We can’t predict us or our spouse having accidents but we can strive to be healthy.
Most of the “things outside our control” we can attempt to mitigate or plan to avoid. And sure sometimes shit happens and you have to deal with it, but thats not a healthy outlook I think, you should plan for the future, what if nothing earth shattering happens?
And you can do things to mitigate the risk and the amounts of bad outcomes - thats also planing, we’re not just animals after all - running away from pain and towards pleasure, we can think about the future, and I in my estimate this article just encourages us to do so.
Re: A career ending mistake
#277Feels like the "senior IC" role described in this article corresponds mainly to today's "3-5 years of experience 'senior' engineer" roles. The reality that I've seen and experienced is that advancing beyond that on an IC track means a lot more people/political work, rather than constant "hands on keyboard" coding as described in the article. It's not the same as management, but it's inevitably more meetings and evang…
This is something people seem hesitant to realize: that after a certain point you can only grow your career by "managing" other people. This is true in a lot of (most?) fields. At some point you cannot become more productive as an individual and you need to start coordinating the work of many people if you want to increase your productivity. This can of course take many forms, but the essence is inescapable.
The great thing about software is that “more” can not just be people, it can be “more software”.
The way I hope to end my career is in IC, building tools that make other devs/the org more productive.
Building software that multiplies other developers output will also increase your output in a sense. You are vastly more productive because you “work through the people using your software”. Which I believe can be a position of very high status in and of itself. Imagine Guido, or the teams behind go, react, etc…
Most big organizations need people to work on their infra full time, and thats what I hope to end up doing someday, no need to mange people, you can still manage computers, only a lot more of them.
Its what Paul Graham said in one if his essays - as a factory worker you can’t increase your output much by working more, but as a software dev - you can, and with enough planning / luck that can be exponential.
Re: A career ending mistake
#278Earlier quoted context omitted.
Or you get "old" and experienced enough to realize it's all the same things every day, everywhere :-) And I can almost guarantee startups are much more learning-conducive than FAANG in that regard.
You learn different things at startups vs FAANG. A startup probably won't be able to afford the standard of engineering that you can find at places like Google. There are good practices you can learn there that you probably won't see at a startup. As a company scales up, coordinating effort across teams becomes more important for getting stuff done, even as a senior IC. You no longer know the whole stack (assuming yo…
> A startup probably won't be able to afford the standard of engineering that you can find at places like Google.
A "standard of engineering at Google"? You must be joking.
Best examples of engineering I have ever seen were done at 5-15 people startups. I'm proud of participating in some of those. FAANG on the other hand is a mire of bullshit.
Re: A career ending mistake
#279Earlier quoted context omitted.
Sure... I guess nothing is provable. I know COBOL devs. They say its harder and harder to find gigs but they just tend to stay in their jobs longer now. I have a relative that will probably retire in his current COBOL gig.
Not a bad thing. One becomes an expert in one niche domain (I wouldn't say COBOL is niche but you know) and comfortable sit on top of it. One can just work maybe 15, 20 years and retire early.
You also need to be aware that there will be massive pressure on businesses to remove your job though. Every single app written in a lanuage that has a diminishing number of people able to work on is a huge risk. The only reason COBOL devs are still able to fine work is because businesses like banks didn't have the foresight to remove that dependency early enough - they've been running their legacy code for far too long and now it's hard to replace. Its unlikely that they'll be keen make the same mistake again.
Re: A career ending mistake
#280I once took a job that I regretted taking on the very first day. I contemplated quitting that same day but stuck it out for many years thereafter. Turns out staying in that job WAS the career ending mistake. It killed my career, family life and even health. It takes a lot of effort to recover from these career mistakes even if you have spectacular resume and background. Number one rule in avoiding this is to never ta…
Oh wow, what was that you saw directly at day 1 that was a dead giveaway „well this is going to suck“?