Debt is not something to "overcome". Debt is generally a tool to trade time for value. If you're accruing career debt, it should hopefully pay dividends. This is what people call "career capital".
Hard work does not automatically generate career capital. You have to be hard-working and/or smart and/or charismatic and/or lucky.
The only honest way to make money is to convince others to give you money. My personal advice is to (1) learn what people want and (2) hone your ability to create useful goods and services.
Having experience in some tech stack or industry that is no longer relevant but makes up a large part of your CV.
Having some role (eg support or QA) on your CV that unfairly makes it seem like you are not as technical as other people.
Being stuck in the same role for a long time with no progression - limiting then seniority of roles you can apply for.
Being in an industry and getting pigeon holed - eg crypto, finance, insurance. Hard to get into a different industry as people will perceive you to be a certain type of developer.
Not sure what it would be called - I guess “career limiting choices”.
re: "Having experience in some tech stack or industry that is no longer relevant but makes up a large part of your CV"
I "solved" this for myself (switched from PS on a particular product line to an entirely different realm of PS about 6y ago) by formatting my [currently 4-page] resume thusly
First page:
- Summary
- Recent Experience (show experience since my switch)
- Featured Articles
- Proficiencies
- Certifications/Accreditations Held
Second page:
- Featured Speaking Experience
- Education
- Previous Career History (with less detail going back through my career history)
In recent years I have definitely found my career history as technical tester to be a bit of a wart on my CV. Having originally come from scrappy fast-moving companies where the line between Dev/QA and even Ops to some degree get blurry, it's been a little bit of culture shock find that in many companies such roles are expected to operate in less-technical silos, and where even trying to have important technical discussions outside of the silo are often met with skepticism at best or outright dismissal at worst. I have also seen a strong trend towards outsourcing this kind of work, often further intensifying the silos. My awareness of this whole implicit sort of caste system has made me want to give up on my career in testing altogether and just try to climb the hill of selling myself as a traditional software engineer instead, even if testing/testability/test infra are still my passion and area of expertise.
It's a tough call to make because I'm opinionated enough about how testing should be done that I also don't want to end up working as a software engineer in a company that treats QA like drones either.
A tester with opinions on development goes against a mostly unidirectional SDLC flow. A developer with a penchant for testability is a multi-skilled asset as they help the org to shift left on quality. The sooner you switch roles, the sooner you will align with the more powerful part in the value chain.
Developers’ jobs, on average, are more difficult and more valuable. It’s easier to take a median developer and turn them into a good tester than it is to take a median tester and turn them into a good developer. Similarly, if we consider a bright college graduate, it would take them less time to become competitive as a tester than as a developer. Secondly, the difference in business impact of a “good enough” tester versus a “world class” tester is negligible (rarely more than 1-5 FTE), while the difference between a “good enough” developer and a “world class” developer is uncapped. The economic treatment of these two groups, and therefore their relative power in the workplace, merely reflects the expected replaceability and value of these professionals.
I recently had an interesting experience where a recruiter told me I should re-brand my title for a role based on my description. I had a lot of "big data" experience, though my title was "Software Engineer". He told me at the end of the day, it only matters if I can actually do the skills that people would mentally associate with the title—which I very much could do.
So I've begun to recently think about how I could "brand" my skillset regardless of my ACTUAL title. Since employers almost never give a shit what your exact title was.
Happy to hear counterpoints, but my experience is that you could definitely re-frame your experience with different / compound titles in order to get better looks from other companies.
A decent example from my own career (if we're going with the "debt as short-term gain, long-term loss" metaphor): I spent 3 years at a DoD consulting firm for my second job.
The pros:
- Boost in pay ($40k -> $85k a year)
- Boost in my credibility and resume (I had no STEM degree)
- More professional development resources (I was able to do a master's while working and got to witness a lot of engineering in-the-large)
The cons (at least in my mind, since I can't be sure what I would have done elsewhere):
- A lot of the stuff I did there is unmarketable. No one is writing new code in Perl. And static analysis, while technically very interesting, is not a ginormous market.
- I feel "behind" in the world of cloud computing since I didn't do much of it while I was there. Most of my next steps look like places that demand a lot of skill building big systems in the cloud. I'm doing it a lot right now but I feel like my team and I are learning a lot of lessons the hard way.
- If I had succeeded in moonshotting my way into a top tier tech company earlier, I would have earned enough capital to take advantage of a couple critical periods (cheaper housing, various opportunities in the stock market, etc)
I've heard this called "10 years of work doing the same year 10 times", but I don't know a catchy word or phrase. Maybe the Germans among us have a word?
> How do you overcome it?
How do you overcome technical debt in a project?
* identify it
* prioritize the issues; you can't tackle them all at once
Stagnating? For me the problem is just to stay at the same height (or repeat that year over) as a software engineer, you need to have quite a decent angle of attack, because of all the new technologies and concepts being pushed on us. And then there is tsunami of business-specific knowledge. Almost certainly whatever way you choose through your career, you close a door of some sort at each step, which is kind of a career debt. So the game is predicting what you will regret least in 10 years time :-)
The "Technical debt" in my career was going to a small university no one has heard of for my CS degree, then trying to get my start in a very competitive city with a much larger university feeding into a lot of the Junior positions, where the housing was expensive and the salaries were low.
I mostly fixed it by moving to a much different city, applying to jobs outside my comfort zone there, landing a good position at a recognizable company name, and building from there.
I changed jobs 3 times in 5 years and doubled my salary.
My ongoing "technical debt" is that I am extremely abrasive towards authority, so I don't get along with executive types. I also tend to think they aren't as valuable as their salaries would suggest. It's something I will have to get over or it will place a permanent ceiling over how much I can grow in my career.
So I have similar perspective on authority in my career. Something that has helped me is to stop expecting them to be infallible, to always have the answer, to always be exceptional. This helps to lessen the animosity I feel towards the “incorrect” decisions they make. I agree on the salaries though.
I don't tend to think of them as infallible, though. I tend to think of them as morons, who mostly have their positions through nepotism or because they are really good at bullshitting.
I mostly don't really care much, except when they start getting in the way of my success.
A recent example is my CTO demanded everyone in the engineering department watch like 5 hours of keynote speeches from the executive team during a recent convention out company held.
Because their metrics showed that most of the engineers skipped it.
It was a huge waste of time and only served to stroke the egos of a bunch of execs so they could feel important because everyone watched their speeches.
But I'm still going to be held accountable to hit my deadlines and the team did get a talking to for missing our sprint goal despite being asked to do this.
A talking to from who? Tell them to reduce the sprint items to match the new schedule leadership requires. Next sprint add in 5 hours buffer to avoid unnecessary surprises. Use the missed deadline as reason. Start taking more control of the sprint goals. Reference this moment as justification.
At the end of the day none of the stuff you are saying would make a tiny bit of difference because we still have deadlines and we still have to do our best to get everything we are expected to deliver done by those deadlines.
You think the CTO is a moron because he wants everyone to hear about what the companies priorities are and how they measure and celebrate success? And they are going to pay you $700 dollars to do it? And you are afraid this will get in the way of your success?
They literally are telling you how they value success. You are getting in your own way when it comes to success if you ignore the message.
> what the companies priorities are and how they measure and celebrate success?
These sorts of things are better communicated through other channels. There's no need to have everyone attend a speech for this. Nevermind 5 hours of speeches.
You're also assuming a lot about the actual content of these keynotes. They were basically just content-free, "rally the troops" style corporate sludge.
You're right that I'm getting in my own way in terms of success, but it's not because I don't understand the company's mission.
It's because I struggle to fall in line with MBA brainrot.
There was a time I avoided the cloud, certifications, meetings, having to be a team player.
Then I was told it's possible to have fun, the purpose of certifications, make good money, and do those things while at the same time enjoying them.
Now I absolutely love running meetings, working on a team, as an individual contributor, and haven't touched physical hardware in 4 years.
Nothing really changed except putting in the work and changing my attitude. Since that time I have doubled my pay, work under the conditions that I enjoy.
Like paying debt, you have to work twice as hard to get half the result. Ultimately, eventually, there is a net positive.
Sometimes, junior developers look down on me because I don't know the keywords of the newest hyped-up framework from memory. You could call it technical debt that I keep using mostly old and boring technology.
Or you could call it "mind-blowing cost savings by reducing technical risks" and let management send you a bonus payment ;) Despite what the React docs suggest, an SPA is usually not the best architecture.
Ignore what junior developers think or say. They almost always have zero clue and simply parrot whatever is fashionable at the moment. While happily creating maintenance nightmares that depends on 1000+ libraries with hundreds of bugs and security issues.
Wait until their code is so bad that they are spending 100% of their time just fixing bugs, while you are maintaining critical code in production with zero bugs, working 100% on new features. And then politely ask them if they still believe what they claimed back then or whether they have learned something from their choices :)
Unfortunately they usually leave before their code hits 100% crappiness, leaving a mess for people to take over. I have seen this so many times that it stopped being funny a long time ago. Which is why I only hire experienced developers.
This is so one sided take it's just bad. Do you think there's no junior dev who's passionate? And that you can build a valuable relationship with him? Did you become senior dev without being a junior first?
1. Every year do a bit of research and figure out what the most sought after technologies are in job ads from companies you would potentially like to work for.
2. Pick one or more technology from the list and learn it well enough to pass a job interview by implementing small but realistic examples of biz applications using it.
Not being amazing at maths compared to my peers. I'm still pretty good (bahcelors in physics and doing a Doctorate in AI) but wish that my maths was better..
After I've seen the same things happen over and over, I've learned to recognize the patterns and stop giving a shit about most of it.
I've been in my current job long enough that I have a good idea what matters and what will be completely lost and forgotten in the black hole of bureaucracy in a week.
Most of it doesn't matter, so I just go through the motions and go home less frustrated. I've optimized what I can and eliminated the rest.
39 comments
[ 0.20 ms ] story [ 81.4 ms ] threadWhat an interesting way to frame it.
Debt is not something to "overcome". Debt is generally a tool to trade time for value. If you're accruing career debt, it should hopefully pay dividends. This is what people call "career capital".
Hard work does not automatically generate career capital. You have to be hard-working and/or smart and/or charismatic and/or lucky.
The only honest way to make money is to convince others to give you money. My personal advice is to (1) learn what people want and (2) hone your ability to create useful goods and services.
[1] https://taylor.town/make-money
I highly recommend reading So Good They Can't Ignore You for more perspectives on building career capital.
[2] https://www.amazon.com/Good-They-Cant-Ignore-You/dp/03494158...
Also consider reading How to Win Friends and Influence People for guidance on how to create charisma.
[3] https://www.amazon.com/How-Win-Friends-Influence-People/dp/0...
Having experience in some tech stack or industry that is no longer relevant but makes up a large part of your CV.
Having some role (eg support or QA) on your CV that unfairly makes it seem like you are not as technical as other people.
Being stuck in the same role for a long time with no progression - limiting then seniority of roles you can apply for.
Being in an industry and getting pigeon holed - eg crypto, finance, insurance. Hard to get into a different industry as people will perceive you to be a certain type of developer.
Not sure what it would be called - I guess “career limiting choices”.
I "solved" this for myself (switched from PS on a particular product line to an entirely different realm of PS about 6y ago) by formatting my [currently 4-page] resume thusly
First page:
- Summary
- Recent Experience (show experience since my switch)
- Featured Articles
- Proficiencies
- Certifications/Accreditations Held
Second page:
- Featured Speaking Experience
- Education
- Previous Career History (with less detail going back through my career history)
It's a tough call to make because I'm opinionated enough about how testing should be done that I also don't want to end up working as a software engineer in a company that treats QA like drones either.
Developers’ jobs, on average, are more difficult and more valuable. It’s easier to take a median developer and turn them into a good tester than it is to take a median tester and turn them into a good developer. Similarly, if we consider a bright college graduate, it would take them less time to become competitive as a tester than as a developer. Secondly, the difference in business impact of a “good enough” tester versus a “world class” tester is negligible (rarely more than 1-5 FTE), while the difference between a “good enough” developer and a “world class” developer is uncapped. The economic treatment of these two groups, and therefore their relative power in the workplace, merely reflects the expected replaceability and value of these professionals.
So I've begun to recently think about how I could "brand" my skillset regardless of my ACTUAL title. Since employers almost never give a shit what your exact title was.
Happy to hear counterpoints, but my experience is that you could definitely re-frame your experience with different / compound titles in order to get better looks from other companies.
The pros:
- Boost in pay ($40k -> $85k a year)
- Boost in my credibility and resume (I had no STEM degree)
- More professional development resources (I was able to do a master's while working and got to witness a lot of engineering in-the-large)
The cons (at least in my mind, since I can't be sure what I would have done elsewhere):
- A lot of the stuff I did there is unmarketable. No one is writing new code in Perl. And static analysis, while technically very interesting, is not a ginormous market.
- I feel "behind" in the world of cloud computing since I didn't do much of it while I was there. Most of my next steps look like places that demand a lot of skill building big systems in the cloud. I'm doing it a lot right now but I feel like my team and I are learning a lot of lessons the hard way.
- If I had succeeded in moonshotting my way into a top tier tech company earlier, I would have earned enough capital to take advantage of a couple critical periods (cheaper housing, various opportunities in the stock market, etc)
> How do you overcome it?
How do you overcome technical debt in a project?
* identify it
* prioritize the issues; you can't tackle them all at once
* work on one issue at a time over time
this is just something that is said to devalue the skill of workers
Factory line worker, why aren't you a manager yet? It's your fault we think less of you, see?
I mostly fixed it by moving to a much different city, applying to jobs outside my comfort zone there, landing a good position at a recognizable company name, and building from there.
I changed jobs 3 times in 5 years and doubled my salary.
My ongoing "technical debt" is that I am extremely abrasive towards authority, so I don't get along with executive types. I also tend to think they aren't as valuable as their salaries would suggest. It's something I will have to get over or it will place a permanent ceiling over how much I can grow in my career.
I don't tend to think of them as infallible, though. I tend to think of them as morons, who mostly have their positions through nepotism or because they are really good at bullshitting.
I mostly don't really care much, except when they start getting in the way of my success.
A recent example is my CTO demanded everyone in the engineering department watch like 5 hours of keynote speeches from the executive team during a recent convention out company held.
Because their metrics showed that most of the engineers skipped it.
It was a huge waste of time and only served to stroke the egos of a bunch of execs so they could feel important because everyone watched their speeches.
But I'm still going to be held accountable to hit my deadlines and the team did get a talking to for missing our sprint goal despite being asked to do this.
So...
Yeah, it's Not Real Agile. I know.
They literally are telling you how they value success. You are getting in your own way when it comes to success if you ignore the message.
These sorts of things are better communicated through other channels. There's no need to have everyone attend a speech for this. Nevermind 5 hours of speeches.
You're also assuming a lot about the actual content of these keynotes. They were basically just content-free, "rally the troops" style corporate sludge.
You're right that I'm getting in my own way in terms of success, but it's not because I don't understand the company's mission.
It's because I struggle to fall in line with MBA brainrot.
* "wisdom" you've acquired from a lot of n=1 experiences that aren't actually generalizable
* Technical skills that you hold onto dearly instead of growing, that once were more valuable than they are today.
Then I was told it's possible to have fun, the purpose of certifications, make good money, and do those things while at the same time enjoying them.
Now I absolutely love running meetings, working on a team, as an individual contributor, and haven't touched physical hardware in 4 years.
Nothing really changed except putting in the work and changing my attitude. Since that time I have doubled my pay, work under the conditions that I enjoy.
Like paying debt, you have to work twice as hard to get half the result. Ultimately, eventually, there is a net positive.
Sometimes, junior developers look down on me because I don't know the keywords of the newest hyped-up framework from memory. You could call it technical debt that I keep using mostly old and boring technology.
Or you could call it "mind-blowing cost savings by reducing technical risks" and let management send you a bonus payment ;) Despite what the React docs suggest, an SPA is usually not the best architecture.
Wait until their code is so bad that they are spending 100% of their time just fixing bugs, while you are maintaining critical code in production with zero bugs, working 100% on new features. And then politely ask them if they still believe what they claimed back then or whether they have learned something from their choices :)
Unfortunately they usually leave before their code hits 100% crappiness, leaving a mess for people to take over. I have seen this so many times that it stopped being funny a long time ago. Which is why I only hire experienced developers.
1. Every year do a bit of research and figure out what the most sought after technologies are in job ads from companies you would potentially like to work for.
2. Pick one or more technology from the list and learn it well enough to pass a job interview by implementing small but realistic examples of biz applications using it.
That’s it.
The blues, if you've never had em, I hope you never do.
I've been in my current job long enough that I have a good idea what matters and what will be completely lost and forgotten in the black hole of bureaucracy in a week.
Most of it doesn't matter, so I just go through the motions and go home less frustrated. I've optimized what I can and eliminated the rest.
No, it's not fulfilling. It pays the bills.