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.
I'm not saying to gush over, but telling someone, "hey, you did a really good job with this, I like <thing>" seems to go over well with practically everyone. Even senior, domain experts like to be appreciated.
If you ever advice a person on a solution: follow up! Most people don't catch all of the bucketload of information you throw at them when they ask for assistance. Having a followup provides a convenient place for them to ask questions on stuff they forgot. I usually use this as a time to say good job (see above) and also ask what their next phase is going to be. Plus, following up lets you know if your advice was useful or not and helps you understand things more too.
If you every get advice from someone else, follow up!
Most of the respect I enjoy in life, both professionally and personally, comes from being generally appreciative of the people in my life. Turns out, people generally respect those who respect them.
5 year Learn about people, learn about what is important for business. Learn to listen, people. Try to do high impact work that is needed for business to succeed long term. Learn how to say no and how to gather support for your ideas. Consider contracting/consulting for better money. Be curious!
10 year I am not their year, But I think at that point you need to have focus. Decide your career path: manager, IC, startup and pursue that relentlessly. Be curious and live without regrets.
I think the most important factor in programmer career is curiosity. Once you lose that, you will quickly regress and become unhappy.
-- 1 year --
Write code. Read code. Listen to other Devs. Start saving code snippets with a short explanation of what its doing. It will get easier, you don't suck, you are not bothering the Senior Devs as long as you show them you have done work and got stuck vs wanting to be spoon fed. Communicate clearly. For Sr Devs looking at your work, it's a lot easier to show them code that talk about code, they'll probably understand the problem and the solution better than your implementation of a solution. This is fine, as long as they are not prima donnas they won't mind.
-- 5 years --
1year + Pay attention to who the movers and shakers are. Cutting edge is good if it has a purpose, not just because it's new. Identify the best devs, look at their code, what are they doing that sets them apart? If you come across your code figure out what doesn't make sense to you anymore, what where you thinking when you wrote it.
Start paying attention to your mental biases. Sunk cost fallacy in code will be what trips you up.
Sunk Cost fallacy looks like this (fictional contrived example):
Defect: Occasionally code fails for Integer number too large
I will solve this problem with a function add(int x, int y) and it will make the code clear instead of x + y and check if the result is too big and throw an error
Oh, but they use doubles once in a while, so I guess I will overload, two methods one for ints one for doubles
Hmm, sometimes we have x + y + z, so might as well re-use my simple int add method, I'll just call it twice --- temp = add(x,y) / result = add(temp, z)
Well I might have the same with doubles just in case
Create Merge Request. MR gets rejected, problem is not actually fixed, user still gets an error. The double method is making the code harder to read, and checking for DOUBLE.MAX_VALUE is silly since practically you will never have a number that large for the scope of the application. On top of that the code is much harder to read
-- 10 years --
5year + politics now matter, you can choose to engage, disengage or ignore. All three choices have advantages and disadvantages. Personally I rather prove myself through code and with clear communication instead of trying to sugar coat everything I do. You should have already started mentoring other devs either officially or unofficially. Communicate clearly on how and when you can be disturbed. Time becomes more sparse when it comes to coding, treat it like gold. This is when you start communicating weird rules to people. Things like "only ping me via email", or "I don't respond to slack messages, I check slack once every 2 hours" become things. Others don't set clear boundaries and their code quality plummets.
What I am getting at is, you have to start making some decisions, do you want to stay a dev? Write code. Want to do other things? Start doing those.
Really want to emphasize the "read" part of this. It's an important learning tool. But also, that first year dev probably doesn't realize that it's a large part of the actual job. Maybe even the majority. You need to read other people's code because you need to be able to write code that interacts with it. You also need to read your own code from time to time, at a distance in time where you may as well be another person. Be sympathetic to the readers and be one yourself.
5y, scratch that - 2y. Too late. Consider this the two year mark - learn architectural patterns, learn DB stuff decently, learn a couple more languages/tools/frameworks.
5y get promoted to senior sometime before this, get K8S/Cloud certs.
10y director of IT, etc
Unless you're at a very small company, this is essentially giving up all the dev work and moving in to a different career entirely. Make sure that's definitely what you want to do before taking the leap across to management. Some people (eg me) really don't like it, aren't particularly good at it, and realise it was a mistake before going back to a dev role.
Genuinely interested why this comment was down-voted. If you haven't come across this phenomenon yet, I'd like to know where you work :-)
Getting a job anywhere is a challenge. Cast a wide net with an open mind. In all likelihood you will leave this job on or before year 5. Accept a lower salary in exchange for experience but don't compromise so much you're below average. Don't fall into the silicon valley trap unless you're already there and/or are willing to destroy yourself for a job. You're getting this job to get your feet wet and start to develop yourself. Grinding leetcode is a waste of time. Do enough to get the job but don't do it to diminishing returns. There's no amount of leetcode that will land you a higher position anywhere. At the end of the day to advance past junior you need more than programming skill. You need the ability to show project management, self direction, and leadership. Leetcode teaches you none of this.
Keep humble and learn from everyone. Ask a lot of questions and keep in the back of your mind eventually you're going to have to find a stack you're good at. For all the pitches about "generalists" I've never met a high level engineer good at everything. I have been a backend engineer for 10 years. I have 2 languages I'm good at and a billion I'm familiar with but would not consider myself senior level. If you asked me to write a frontend I would not be able to do it.
Importantly start saving now. This cannot be emphasized enough. You're going to be making more money than you've ever made in your life even on the low end. Live frugally and within your means. Save diligently and max out your 401k and IRA. Take advantage of any savings vehicle you can find. To put the numbers into reality, if you can save $100,000 and you fell into a coma at 7% interest you'd be worth over $700,000 dollars. You need to take advantage of compound interest as soon as possible.
Year 5:
You're likely low-level senior at this point. Jobs are far easier to get, and you're likely settled into a stack you like. Move jobs frequently until you find a place where you can grow properly.
Stay humble, you don't know everything. At this point it's critical you don't let your title get to your head. You will come across people who are junior to you that teach you a thing or two. You are not senior because of your programming talent. Remember that. You are senior because your experience allows you to deliver _despite_ your shortcomings.
Begin setting your eyes on a staff/management position. Pay attention to how they act and emulate it. Always remember to take care of your juniors.
Keep saving money. Never stop.
Despite the calls for "full-stack" understand that "full-stack" engineers are often mediocre at everything instead of good at one or two things. This is great for job hunts but bad for advancement. A good parallel, because you will wonder if you should go "full-stack" is Walmart. You don't go to Walmart for high quality engineered furniture. You go there because it gets the job done. At the 5 year mark you should be starting to become an artisan and you will see the shortcomings of engineers who stayed broad for too long.
Year 10:
You are likely coming up or already have a management or staff level IC position. All advice from Year 5 applies. At this point though, leaving jobs becomes less beneficial. The only way up is through "works of God" - meaning most of your promotions above this level will be political in nature. There are diminishing returns to moving companies as you will often been embedded in a company's culture to reach a staff position. Leaving the job becomes hard because you can't leetcode your way into a staff position somewhere else. You need enough experience to be able to convince another company you can contribute at this level there. I would aim to stay at a job for as long as possible at this point.
Know how to take advantage of people's abilities. As a "super senior" you will be expected to know a lot of things you won't know. Respect your coworkers and identify things. An example of this for me is I am not very good with social things. I've recognized this and I also have almost no interest in diverting time to develop higher EQ. Instead, I lean on people on my team who are already good at these things. For example, there are people on my team who are okay engineers but superstar people-persons. I can easily compensate for their engineer and they can compensate for my underdeveloped EQ. Work symbiotically with your team and put people, and yourself, in places where you can most effectively complete the mission.
The industry is highly ageist and it's not uncommon to "age out". You should be planning for this. What I mean by this is you should be exploring lateral moves in your field. You are likely extremely, extremely good at one or two things. Ask yourself where you will go if your stack dries up. Are you willing to start back at junior in a new stack? Probably not. So, consider what it would take to possibly laterally move into management if you're capable. By year 20 the probability of your stack disappearing (see: Ruby) is pretty high. Have a plan.
Again, save save save. The power of compound interest is incredible. Do not squander it.