What advice do you have for people with the aforementioned years of experience.
Can be about programming, engineering in general, life, whatever you want
At 1 year: Be kind. You don't know everything; accept that the devs around you might know things you don't. Focus on making things better. Try to add value.
At 5 years: Be kind. You don't know everything; accept that the devs around you might know things you don't. Focus on making things better. Try to add value.
At 10 years: Be kind. You don't know everything; accept that the devs around you might know things you don't. Focus on making things better. Try to add value.
I have 23 years experience now and the advice hasn't changed yet. Maybe it will next year.
Well said. I would also add that if you start somewhere new, don't judge too quickly that everything is garbage there and you could fix it all. There are many layers of reasons/issues on why certain things have been done certain way and even though you may have better solutions, listen/learn first. Don't be a Know it all even if you are that good.
I would add context is key to some forms of code. Yea some things may be sloppy, but they also may have been added at 3 am during an incident. While hopefully these gets cleaned up, sometimes they get forgotten or de-prioritized. Even the best devs can write bad code, so always remember what could of been. It helps, I’ve found, in having empathy for other people’s code
Good point. I’ll add that it’s important to remember you’re part of a larger team with a mission that is (most likely) not to just build software. From my experience, the most valuable software engineers are the ones who excel at both programming AND at interfacing with the other teams in the company (design, biz dev, etc).
Becoming a really good engineer is about hoarding experience and tools. Every project you work on, no matter how simple, is an opportunity to add new tricks and tools to your belt.
The real magic happens when you get to say "OK, I can solve this problem by combining technique X (which I learned on that project 5 years ago) with tool Y (which I picked up last week).
This doesn't mean you should try and introduce the latest hot framework on everything you do, but it does mean you should always take an opportunity to learn a new trick - even something as simple as writing a Bash script to automate a process that usually takes three steps on the command-line.
So take a lot of notes. A few years ago I started trying to learn in public as much as possible - making notes for myself on GitHub Issues and publishing TILs ( https://til.simonwillison.net/ ) - and it's really paid off for me - I feel like I learn faster and waste less time revisiting old things. But you may be more comfortable keeping private notes, and that's fine too. Just make sure they're well backed up!
At 1 year: Hang in there, only 39 more years to go until retirement.
At 5 years: Hang in there, only 35 more years to go until retirement.
At 10 years: Hang in there, only 30 more years to go until retirement.
All jokes aside, the best advice I got that covers all the years is, "When they give you your first assignment, bust your ass like you've never busted your ass before. Do it fast and perfect as you can. That will set the stage for the rest of your time there." I got into the habit and do it always. Once you show people you can "get stuff done," they will bring you with them when they move jobs. You'll always have work and you'll never have to talk to a recruiter again.
You should learn how to build systems. Build stuff in your spare time, full applications so you understand what it takes to build them. Ideally you would want to build a product that people use so you understand what it takes to actually build and ship a product. Setup the server that hosts your applications. Setup the DNS records and register a domain name so you know how all that works. Also, pick an industry like healthcare or banking or even tech, that way you're not a programmer you're a "financial industry programmer." Each industry has it's own nuances and regulations it has to deal with. Knowing these things adds value.
Mind the burnout. If you are in the US and get almost no vacation time, mind it carefully. Burnout will make you hate your job and lead to more burnout. It can last months, sometimes years.
Be mindful of politics. You'll most likely encounter situations that make no sense from a technical or commercial point of view - they happen because someone high up (or their friends) will be benefiting at the expense of the company. At that stage of your career, you're probably better off keeping quiet and playing the game rather than try to make things right (unless the problem is serious like the company breaking the law or regulations). I have been in this situation before, pushing back against a "solution" based on (correct) technical reasons, completely missing the big picture - ended up being fired on a totally unrelated technicality because I've made enemies with someone high up. It worked out very well for me regardless, but this all depends on your own situation, so keeping this in mind is important.
5 years:
I would recommend branching out beyond programming and exploring related fields such as networking and security. From an engineer with 5 years' experience I would expect good knowledge of the UNIX shell and OSes in general (you should know your way around a Unix box), basic networking knowledge (DHCP, DNS, etc - if I gave you a Unix box with 2 interfaces to act as a router I'd expect you to be able to set that up via the command-line, at least with static IPs everywhere) and security (managing TLS certificates, HTTPS and how it works at a general level, common security vulnerabilities for web applications, etc).
10 years: not there yet, but so far my observation would be that at that point people and relationships become more important than engineering. As an individual contributor you can get away with no people skills if your technical skills are good, but if you want to go beyond that and into management, people skills become paramount. I'm not saying that after 10 years you should go into management, but having the skills to do so is useful; even if your desire is to stay as an individual contributor you might face just the right opportunity (either in terms of work, as in a healthy mix of management and code, or money where the financial upside more than makes up for the downside of having to do management vs programming) and having the option to take it is good.
> Be mindful of politics. You'll most likely encounter situations that make no sense from a technical or commercial point of view - they happen because someone high up (or their friends) will be benefiting at the expense of the company.
This never changes. The names change, but the characters don't.
In the age of Info Overload - Never ask vague questions.
You are asking for irreparable brain damage.
It always good to remember we have 6 inch chimp brains. And its getting very easy to fill it up with useless bullshit totally unrelated to your reality.
There are too many chimps jabbering away online all very different. There is a big spectrum of personality types in the chimp troupe, thrown into all manner of situations no one has prepared those 6 inch brains to handle. So the vaguer the question gets, the larger the corpus of answers you will receive that will have no connection to your personality type or situations you land up in.
Learn to make the question as specific as possible to your reality. If you are an apple tree it doesn't matter what advice a redwood tree or cactus is busy broadcasting into the ether.
1 year advice: It's very hard to get a software engineering job but stick with it, get work experience any way you can, even if you have to work pro bono. Get as much programming experience as you can. Don't over reach on your resume qualifications, but do go into great detail. Instead of saying: "Skills: Javascript". Go into details, for example: "Skills: Javascript, Front end dev experience: Tabs, pagination, leaderboards, infinite scrolling, post loading, pre-loading, page load optimization, etc" the more details you can give the better. this gives interviewers an idea of what experience you have.
10 Year: It's much easier to get a job, but it's also much harder to keep your job, especially if you just got hired by a new company. an engineer who spends 4 years at one company will be more qualified to work there than a brand new engineer at that company with 10 years of experience. So, at this level, when you join a new company, you'll have to work extremely hard.
If you want the very highest salaries, you'll need to jump ship. it's hard work but the more often you change jobs, the higher the salary.
personally, i think, once you get past the middle of the bell curve, any additional raises are of diminishing returns. you'll work harder and harder for less and less money.
don't let mean companies with bad cultures take advantage of you. there still exist companies with good work cultures where you don't have to be a full time slave.
Your job performance is determined by the following:
1/3 - your own hard work
1/3 - how well you do politically (play nicely with others)
1/3 - factors beyond your control (just one example: working in a rapidly expanding industry will be greatly in your favor)
Can I ask what country you're in? I'm in the US and my experience suggests the exact opposite of nearly every point in your first paragraph
Programming jobs here are plentiful, you should never work for free, your very first job might be a little harder to get than later ones but it won't be hard. And listing things like "tabs" and "pagination" on your resume feels really desperate, like you're scraping the bottom of the barrel to pad out the list as much as possible. The closest thing I would suggest is to maybe list some specific frameworks like React or Redux (or the equivalent for your area); though even then it's not really for the technical recruiters, it's for the imprecise algorithms that sift through the pile
Well, I started my career in the US durring the dot com bubble bust when absolutely no software engineer could get a job no matter what they did. this no doubt informed my views on the subject.
But, even now, I thought it would be harder to get a job as a junior role than senior. As a hiring lead, 5 years back, i remember, we could have our pick of just about any overqualified intern we wanted. we got one guy who already had 1 to 2 years of work experience, just so he could be hired as an intern and he was awesome.
As for being detailed. mentioning implemtations isn't just about padding out. It's about providing an accurate picture of what your experience is. It's not enough to simply say "i am intermediate JS experience". that doesn't tell the interviewer much. furthermore, most people aren't very accurate at rating themselves. overconfident people think they're experts and experts with no confidence under-rate themselves. by mentioning implementations and specific experiences, it allows the interviewer to more accurately guage your level of expertise.
An engineer's value has a direct, exponential relation to the size and complexity of the problems they can solve.
Wanna work on the most interesting things?
With the most interesting people?
wanna make sure you're compensated accordingly?
make sure you are involved in analysing and solving the hardest problems, in the hardest of conditions.
Sometimes the term 'hard' can be deceiving.
When thinking about hard technological tasks, many engineers think about scale, or cracking product/market fit or whatever - all true.
But consolidating a legacy permission systems into a single system in a 30+ years old big corporate is very hard, and bringing a windows, asp.net based legacy (20 years old) to the cloud and integrating all the modern tools is very hard - both are not sexy and might not involve scale and amazing start-up-like mentality. They are both very interesting, very hard to achieve, and are very well compensated.
There's a chance this kind of person won't be promoted, or get to do fun things simply because they're so competent at doing hard things.
I think it's better to look like you're the type of person who can do that, but also look marketable and make friends with powerful people in the company.
Yep, I've spent a lot of my career working on systems and taking stories that others don't want. I'm 9 years in at the same company, have a masters, and I'm just a midlevel dev making under $100k.
If you want to move into a more senior position, it's faster to change employers than to stay where you are. Yes, you can advance with the same employer, if you're willing to change projects, skill domains, or sites.
But statistically it's faster to advance by applying to the many more numerous senior openings arising elsewhere than within your own company. You probably have the same chance of promotion in-house that you do for acceptance to a job out-of-house, but you'll get many more shots-on-goal by applying out-of-house.
So in brief, to advance quicker, change employers.
Readit News
At 5 years: Be kind. You don't know everything; accept that the devs around you might know things you don't. Focus on making things better. Try to add value.
At 10 years: Be kind. You don't know everything; accept that the devs around you might know things you don't. Focus on making things better. Try to add value.
I have 23 years experience now and the advice hasn't changed yet. Maybe it will next year.
The real magic happens when you get to say "OK, I can solve this problem by combining technique X (which I learned on that project 5 years ago) with tool Y (which I picked up last week).
This doesn't mean you should try and introduce the latest hot framework on everything you do, but it does mean you should always take an opportunity to learn a new trick - even something as simple as writing a Bash script to automate a process that usually takes three steps on the command-line.
So take a lot of notes. A few years ago I started trying to learn in public as much as possible - making notes for myself on GitHub Issues and publishing TILs ( https://til.simonwillison.net/ ) - and it's really paid off for me - I feel like I learn faster and waste less time revisiting old things. But you may be more comfortable keeping private notes, and that's fine too. Just make sure they're well backed up!
At 5 years: Hang in there, only 35 more years to go until retirement.
At 10 years: Hang in there, only 30 more years to go until retirement.
All jokes aside, the best advice I got that covers all the years is, "When they give you your first assignment, bust your ass like you've never busted your ass before. Do it fast and perfect as you can. That will set the stage for the rest of your time there." I got into the habit and do it always. Once you show people you can "get stuff done," they will bring you with them when they move jobs. You'll always have work and you'll never have to talk to a recruiter again.
You should learn how to build systems. Build stuff in your spare time, full applications so you understand what it takes to build them. Ideally you would want to build a product that people use so you understand what it takes to actually build and ship a product. Setup the server that hosts your applications. Setup the DNS records and register a domain name so you know how all that works. Also, pick an industry like healthcare or banking or even tech, that way you're not a programmer you're a "financial industry programmer." Each industry has it's own nuances and regulations it has to deal with. Knowing these things adds value.
Mind the burnout. If you are in the US and get almost no vacation time, mind it carefully. Burnout will make you hate your job and lead to more burnout. It can last months, sometimes years.
Be mindful of politics. You'll most likely encounter situations that make no sense from a technical or commercial point of view - they happen because someone high up (or their friends) will be benefiting at the expense of the company. At that stage of your career, you're probably better off keeping quiet and playing the game rather than try to make things right (unless the problem is serious like the company breaking the law or regulations). I have been in this situation before, pushing back against a "solution" based on (correct) technical reasons, completely missing the big picture - ended up being fired on a totally unrelated technicality because I've made enemies with someone high up. It worked out very well for me regardless, but this all depends on your own situation, so keeping this in mind is important.
5 years:
I would recommend branching out beyond programming and exploring related fields such as networking and security. From an engineer with 5 years' experience I would expect good knowledge of the UNIX shell and OSes in general (you should know your way around a Unix box), basic networking knowledge (DHCP, DNS, etc - if I gave you a Unix box with 2 interfaces to act as a router I'd expect you to be able to set that up via the command-line, at least with static IPs everywhere) and security (managing TLS certificates, HTTPS and how it works at a general level, common security vulnerabilities for web applications, etc).
10 years: not there yet, but so far my observation would be that at that point people and relationships become more important than engineering. As an individual contributor you can get away with no people skills if your technical skills are good, but if you want to go beyond that and into management, people skills become paramount. I'm not saying that after 10 years you should go into management, but having the skills to do so is useful; even if your desire is to stay as an individual contributor you might face just the right opportunity (either in terms of work, as in a healthy mix of management and code, or money where the financial upside more than makes up for the downside of having to do management vs programming) and having the option to take it is good.
This never changes. The names change, but the characters don't.
It always good to remember we have 6 inch chimp brains. And its getting very easy to fill it up with useless bullshit totally unrelated to your reality.
There are too many chimps jabbering away online all very different. There is a big spectrum of personality types in the chimp troupe, thrown into all manner of situations no one has prepared those 6 inch brains to handle. So the vaguer the question gets, the larger the corpus of answers you will receive that will have no connection to your personality type or situations you land up in.
Learn to make the question as specific as possible to your reality. If you are an apple tree it doesn't matter what advice a redwood tree or cactus is busy broadcasting into the ether.
10 Year: It's much easier to get a job, but it's also much harder to keep your job, especially if you just got hired by a new company. an engineer who spends 4 years at one company will be more qualified to work there than a brand new engineer at that company with 10 years of experience. So, at this level, when you join a new company, you'll have to work extremely hard.
If you want the very highest salaries, you'll need to jump ship. it's hard work but the more often you change jobs, the higher the salary.
personally, i think, once you get past the middle of the bell curve, any additional raises are of diminishing returns. you'll work harder and harder for less and less money.
don't let mean companies with bad cultures take advantage of you. there still exist companies with good work cultures where you don't have to be a full time slave.
Your job performance is determined by the following: 1/3 - your own hard work 1/3 - how well you do politically (play nicely with others) 1/3 - factors beyond your control (just one example: working in a rapidly expanding industry will be greatly in your favor)
Programming jobs here are plentiful, you should never work for free, your very first job might be a little harder to get than later ones but it won't be hard. And listing things like "tabs" and "pagination" on your resume feels really desperate, like you're scraping the bottom of the barrel to pad out the list as much as possible. The closest thing I would suggest is to maybe list some specific frameworks like React or Redux (or the equivalent for your area); though even then it's not really for the technical recruiters, it's for the imprecise algorithms that sift through the pile
But, even now, I thought it would be harder to get a job as a junior role than senior. As a hiring lead, 5 years back, i remember, we could have our pick of just about any overqualified intern we wanted. we got one guy who already had 1 to 2 years of work experience, just so he could be hired as an intern and he was awesome.
As for being detailed. mentioning implemtations isn't just about padding out. It's about providing an accurate picture of what your experience is. It's not enough to simply say "i am intermediate JS experience". that doesn't tell the interviewer much. furthermore, most people aren't very accurate at rating themselves. overconfident people think they're experts and experts with no confidence under-rate themselves. by mentioning implementations and specific experiences, it allows the interviewer to more accurately guage your level of expertise.
Wanna work on the most interesting things? With the most interesting people? wanna make sure you're compensated accordingly?
make sure you are involved in analysing and solving the hardest problems, in the hardest of conditions.
Sometimes the term 'hard' can be deceiving. When thinking about hard technological tasks, many engineers think about scale, or cracking product/market fit or whatever - all true.
But consolidating a legacy permission systems into a single system in a 30+ years old big corporate is very hard, and bringing a windows, asp.net based legacy (20 years old) to the cloud and integrating all the modern tools is very hard - both are not sexy and might not involve scale and amazing start-up-like mentality. They are both very interesting, very hard to achieve, and are very well compensated.
I think it's better to look like you're the type of person who can do that, but also look marketable and make friends with powerful people in the company.
But statistically it's faster to advance by applying to the many more numerous senior openings arising elsewhere than within your own company. You probably have the same chance of promotion in-house that you do for acceptance to a job out-of-house, but you'll get many more shots-on-goal by applying out-of-house.
So in brief, to advance quicker, change employers.