43 ms·

To chime in with my own anecdotal opinion that is likely to anger some people... in my experience most developers do their best work after about 6-8 months of s

by Kranar 5y ago

To chime in with my own anecdotal opinion that is likely to anger some people... in my experience most developers do their best work after about 6-8 months of starting a job at a new company, and that comes to an end after about 24-36 months of working at the same company. After that the vast majority of people just stagnate, get complacent, the job stops being interesting to them and they move on. After observing this I don't really mind hiring people to work for 2-3 years and then have them move on to another role, and most people I hire I do so with the expectation that I'll get a good two years of work and not much more. A very small percentage of people continue to improve over the long term, and those people I am happy to continue increasing their pay, but I don't really go out of my way to retain employees and I don't think it's particularly worth it to do so. This blog post mentions a kind of impact based compensation structure, and while I can respect the idea behind it, I am skeptical that they've managed to find a deterministic and impartial way of measuring "impact". I don't presume to have such a system so I pay based on what I observe in the market and let the market decide what the value is of software developers. For example, I genuinely don't know if software developers have more of an impact than the product designers, or the legal department even though I pay software developers much much more. What I do know is that it's much easier for me to hire a competent lawyer or UX designer than it is to hire a competent software developer and there are many more competent lawyers and designers out there... so I pay them less, regardless of whatever objective measure of impact may exist.

535188B17C93743 5y ago
While I think it's an organizational failure, even if folks aren't "growing" after 36 months, I definitely think there's institutional knowledge they have that helps them be more effective... the more time that elapses, the more of that institutional knowledge is lost and not documented. Obviously it's not great to have companies hanging on by the thread of a single person's knowledge over 10 years, but I feel like at a lot of companies (especially smaller companies), this is the reality.
- sparker72678 5y ago
  > but I feel like at a lot of companies (especially smaller companies), this is the reality. Exactly. There are many small companies that will be far more impacted be one of their 2 developers leaving than they would be by the owner being hit by a bus, but they'll still balk at raising salaries.
  - MichaelZuo 5y ago
    Well market dynamics over the long term should take care of companies that short sighted. They will be outcompeted by others that are better at building organizational capacity.
    - abc_lisper 5y ago
      Yeah, that long term is not useful for the engineer whose skills should be valued right. He will be older by that time
      - MichaelZuo 5y ago
        Well that’s sorta how life works? It’s like any other market dynamic that organizes society. No guarantees that anyone will be utilized to their highest and best purpose.
munchbunny 5y ago
I'm not fully convinced that this is just about the devs. 2-3 years is also about how long it takes for a nascent project to transition into a mature one, and when that happens the culture and energy of the team tends to shift. The same dev that thrives in one setting might end up out of place in the other.
- nostrademons 5y ago
  I think in tech 2-3 years is also about how long it takes for one's mental model of how the world works to become stale and outdated, usually coinciding with other projects (that had been too nascent to use) maturing. I remember that in my peak webdev years in 2008, you built webapps by designing the HTML, converting it to templates, filling in data with Django or Rails, and then adding judicious interactivity with JQuery. By 2011 the world had moved on to Angular and SPAs, and you built webapps as a single HTML page and large JS bundle with a bunch of components that you'd fetch data for over AJAX. By 2013 the world moved on to React, and you had all these tools (Gulp, Grunt, Bower, NPM, etc.) to automate packaging and code-reuse. In 2015 people were still using React and more mature versions of these tools, but what changed was the economic reality that you could make lots of money as a webdev, and the industry itself was maturing with demand for new apps dying out. I'm witnessing this with my team at work too. We have an "old guard" of leadership that joined the team in its peak years in 2018/2019, and learned (and often wrote) the tech stack as it existed then. Now our team is colliding with infrastructure efforts that started elsewhere in the company and were too immature to use last year, but are now starting to bear fruition and get widespread adoption throughout the org. People who were experts in the old way of doing things find that their skills and projects are now largely irrelevant.
  - alex-nt 5y ago
    Depends on what you work on. If you are not on pure tech (a minority of people are), as you get closer to the business you will get insights on how things work, how you can change them, make them better etc. Only part of our job is technical, and without the business knowledge you can't push the world in which you work further. There will be pushback from the "old guard" always, everywhere, as there will be push for the "new thing" always, everywhere. Neither is healthy, and both should be evaluated with a cool head.
nine_zeros 5y ago
This is ridiculous. I would prefer being at my current job, leverage my tribal experience to build things (and I have specific things on my mind) better and faster. If I pitch this to my CTO, he will agree that using my knowledge to build things better and faster aligns with business goals. Only middle management rationalizes theories such as you proposed. Middle management sometimes just forgets what is the goal of their job and instead focuses only on their actions (self obsession), ego and the presentation of success. An example of middle management self-obsession is your use and throw mentality. Middle management does this because they don't actually listen to their reports. Managers think they are on another dimension and don't need to hear anything from anyone. A really competent middle manager would know that senior engineers, especially ones with tribal knowledge are the real 10x engineers in practice. Not because they type fast, not because they are hungry and energetic but because they can process situations and circumstances faster in their head to yield results. If I were a middle manager, I would do my utmost to retain trustworthy people around me. It's almost a no brainer productivity boost.
- fizx 5y ago
  Hi, Person currently in middle management here. While we'd love to pay our good people more, at a moderately sized company and up, we operate under an unbelievable number of constraints, from HR, finance, etc.
  - nine_zeros 5y ago
    You might have constraints but you can still raise your voice EACH time attrition happens because of constraints. Only then will the system change and make lives easier for everyone. If not, you are forever going to be stuck in the cycle of hiring and attrition.
    - foobiekr 5y ago
      Speaking from experience, most large tech companies view engineers as area under the curve, as fungible hours. Speaking out about attrition usually doesn’t have any impact at all above the Director level.
esprehn 5y ago
You may enjoy the concept of the "tour of duty": https://hbr.org/2013/06/tours-of-duty-the-new-employer-employee-compact https://hbr.org/2013/06/tours-of-duty-the-new-employer-emplo... http://www.theallianceframework.com/about-the-book.html http://www.theallianceframework.com/about-the-book.html Thinking about my career (and others) this way has helped me remove a fair bit of stress when making job, role or project changes.
alex-nt 5y ago
Yes, it takes about 6m in a medium to big organizations to figure out what to do and with whom you have to speek to get stuff done. And for 2 years everything is rosy. Then you speak with you colleagues that changed jobs and find out that their income is 30% to 40% higher. That will, of course, put a downer on your day/week/quarter/year. You have 2 options, speak with your current company about compensation or leave. I tried the first option (admittently a bit late, but I did mention the problem in our review talks and other talks) after I found out that my income was 40% lower than colleagues that left 1 year before (was 3 years and a half at this company and had top marks every year, big company, a lot of cash to throw around). I was offered a measly 5% after being dragged in 4 meetings about how great I am. Left and almost doubled my income in 2 years. This is all anecdotal, but I hear it from everyone around me, you HAVE TO SWITCH jobs every 2 years, you can stretch to 3, maybe. Of course, during the last years you won't deliver as much, you have to prepare for intervews and such. This was of no benefit for the previous company. Over my 4 years there I've seen how we were bleeding knowledge that we never got back. The company didn't do so well, the thing I worked on just died after everyone left 6m after me. It's a shame, it could've been a nice thing compared with what I see offered by the competition.
- bla3 5y ago
  > I was offered a measly 5% after being dragged in 4 meetings about how great I am. The way you do this is interview elsewhere, get an offer for 40% more, and _then_ tell your manager that you have an offer for 40% more and that you'd really like to stay but they'd really have to do something about compensation. You'll get more than 5% then (but likely less than 40%). It's annoying that you have to invest the time for this, but it does provide data to your current company that your market rate is in fact what you think it is.
  - pklausler 5y ago
    Or take the 40% boost and come back two years later for even more.
    - alex-nt 5y ago
rfrey 5y ago
By retaining a person who has "stagnated" after 3 years (setting aside the ambiguity of what you mean by "stagnate"), you avoid: 1) Three years of lesser performance from the new employee as they climb that curve 2) The very real risk that your new hire will not be successful, or if they are successful, will not achieve the same level of performance. Also, I invite you to challenge what you consider "stagnation". It is not possible to continue linear improvement in a given role: good employees achieve mastery, and while they will still be improving that might not be evident to their managers who are looking only at work outputs. If a company does not want employees who are masters at their task, but rather want people to move up or move out (counter-productive as that might be), then it is literally middle management's job to find new roles for successful engineers, and I suppose fire the previously successful engineer if they're not up to the task. Complaining about an engineer "stagnating" in the same role after they've mastered it is just lazy thinking and lazy management.
suifbwish 5y ago
This isn’t surprising. 3 years is about the length of time it takes most humans to become bored with monogamous relationships. There is a very high rate of breakups and divorces in non arranged relationships by the 4th year.
- Ensorceled 5y ago
  The divorce rate for the first 5 years is less than 20% in the the US. The US has a higher divorce rate than many countries so, in general, this is untrue.
  - disgruntledphd2 5y ago
    Marriage != monogamous relationships
    - Ensorceled 5y ago
      True. But they said “divorces”, I’m disputing that part. They have no support for the rest either.
  - randomdata 5y ago
    I'm not sure you've shown that. I would be surprised if any meaningful number of (non-arranged) marriages are established in year zero of the relationship. A quick Google search suggests to me that the average relationship is established five years before getting married. The original assertion was that relationships tend to break down in year four, meaning that they aren't likely to make it to marriage in the typical case. Marriage data is only relevant to the outliers who married early, and as far as that goes they could all be found in that 20% quite easily, I'm sure. The data provided is not sufficient to know.
    - Ensorceled 5y ago
      No. The original assertion is that monogamous relationships AND marriages breakdown in the first five years at “very high rates”. Marriages do not. And, as you say, if you got married you were probably monogamous for some time before that. I’m not disputing that humans get together and break up all the time. It’s unclear that monogamous relationships breakup “at very high rates” due to boredom either. There are many reasons relationships falter, boredom being but one of them.
b3morales 5y ago
You're not really making an independent measurement here. You see developers "stagnating" and moving on; how do you know that's not caused by lack of pay increases and other things you're doing (letting people pick new projects, for example, to keep them interested)? Maybe if you did "go out of your way to retain employees" you'd have employees who end up making your business even more successful during their longer tenure.
- vsareto 5y ago
  I don't think pay increase will help stagnation. Maybe picking projects will if the company has enough variety. The best cure for stagnation I've found is to take long breaks and get into something else.
  - b3morales 5y ago
    Sure, and I don't really know either; my point was just that the parent is begging the question. :)
  - reedjosh 5y ago
    > I don't think pay increase will help stagnation. No, but lack thereof can certainly cause it. When there's no real reward, what's the point of putting in the extra work and taking risks? Two things that quickly break stagnation.
  - visarga 5y ago
    My cure for stagnation is to play more. Amazing how playing at a pet project will get your juices flowing.
  - mikepurvis 5y ago
    Agree. I've been at my place for 11 years now, and have had four very distinct roles over that time. Each change gave that revitalizing jolt of fresh challenges, technologies, etc, but with the benefit that I got to keep my seniority, influence, expertise with the in-house systems, and so on. Have I given up potential pay bumps by not going external? Sure, probably. But I have enough to be comfortable and my company has treated me well, both monetarily and in facilitating these kinds of changes when I've wanted them.
diob 5y ago
What came first, the chicken or the egg in your scenario? Did they stop doing great work because the rewards didn't match? Or did you stop matching because they stopped doing great work? Always hard to tell.
- HWR_14 5y ago
  It's not hard to tell at all. You could just, wait for it, make the rewards match the expected great work and test that way.
  - diob 5y ago
    I definitely agree. Pay what you expect (great for great work), and if someone isn't cutting it let them know (chance for improvement). Worse case, let them go. Instead, most companies reward no one and wonder why the good ones leave or burn out ("weird, they don't contribute at the same level anymore").
lmilcin 5y ago
> (...) that comes to an end after about 24-36 months of working at the same company. After that the vast majority of people just stagnate, get complacent, the job stops being interesting to them and they move on. Or, another explanation, you are mistaking cause and effect. Maybe the people figure out they could be earning so much more somewhere else but they are unlikely to get the kind of raise at their current place, so they get disillusioned and demotivated? And then they change the job getting the significant raise, further reinforcing the behavior. Now they join another company fully expecting the same thing to happen in 2 years.
wpietri 5y ago
I would look at inverting the causality there. If your data is accurate, I think it's better to say, "Most companies create developer jobs that get boring for people after 24-36 months." I was chatting with a Trader Joe's cashier Sunday. It turns out they change jobs every hour. That was a surprise to me; when I long ago worked in a grocery store, I was assigned to one position for 8 hours for every shift. Why does Trader Joe's do it? To keep things interesting: "She tells Money that the change in jobs during shifts helps to keep things interesting for employees. 'It's perfect because it breaks down your shift. You don't get tired doing one repetitive thing,' she told them." https://www.mashed.com/175743/workers-reveal-what-its-really-like-to-work-at-trader-joes/ https://www.mashed.com/175743/workers-reveal-what-its-really... If Trader Joe's can do it hour by hour, I think tech companies can do it at least every year or so. I'm hiring right now and one of the major draws for the good people I'm talking to is the chance to do something interesting. If that's why their coming, it's unsurprising that I'll have to keep giving them that over time. For us, and for most places I've worked, I think that's doable.
- wwweston 5y ago
  Yes, but this won't work because there's just not enough different things for an engineer to master. ;) More seriously, your observation is brilliant (and almost makes me wish I hadn't just accepted a new role). Because the software field contains such a breadth of things to know and breadth of potential applications, it's hard to get very far without having the kind of mind that is motivated by some level of intrinsic interest, and that can be a currency in its own right.
- itronitron 5y ago
  I would really appreciate that as a developer, I have definite gaps in my skillset that I haven't needed (been paid) to fill. But everyone would have to get out of the mindset that developer Joe 'knows everything' about X. The perfect match would be pairing a developer that can explain some technology to a 12 year old with a developer that has the equivalent knowledge of a 12 year old (for that technology.) That would keep things interesting and build a very resilient organization.
  - 5y ago
Pxtl 5y ago
3 years is also the amount of time it takes to become the resident expert in one of the company's Scary Basements, and then both your productivity and morale hits the crapper while this tired old beast that nobody wants to support you in modernizing needs fixes and tweaks.
brightball 5y ago
I'm going to make a suggestion for the cause of your observation. I think many people come into a job for a specific project(s) during which there is a ramp up period of understanding the requirements, limitations, team, how the company works, getting to know people (6-8 months). Then after working on that project, delivering it, iterating on it, tuning it, working through potential production support issues and some scaling items...in many cases the vast majority of the work is done (2-3 years). At that point, a few things happen because this developer is ready for a new project or new challenge, as are most of the people who were involved with that project. Their options are: - Find a new project at the company and restart the learning period as they transition in a potentially lateral move. If this happens, it's unlikely the company is going to give them a sudden compensation boost when in the eyes of management they're continuing to do their existing job. - Seek training related to some advanced problem that they solved to become the company's expert on the subject, in which case the company will likely pay for the training but not a subsequent boost in compensation (because in their eyes...they just paid for the training) - See how well they have marketed themselves to find out if the company has recognized their talent to promote them into a higher level position with an equivalent pay bump or potentially managing a team. The only problems is that you can only promote so many people, so this person will be the exception and not the rule. - Update their resume with the newly acquired skills and have somebody else pay them market rates to start a new project at a different company, using their current job as leverage to get a significant bump in compensation. Meanwhile, you'll be paying new market rates to hire the replacement. It's no secret why people often just jump jobs. You've finished one project and you're going to transition to a new one anyway, getting a fresh start can be a good choice. Additionally, no matter how much people like their situation in one job they will end up building up frustrations with certain people and/or management over time. As long as those people are still around, it will increase their likelyhood of leaving. But ultimately, you're looking at the likely timing of concluding one project and then exploring options for what's next. IMO, that coincides with your timeline.
commandlinefan 5y ago
> the vast majority of people just stagnate, get complacent Even if you're right - 100% of the time, about 100% of people - the value of having the one guy who remembers why it was done this way and how it was fixed last time it broke available to look at it when it needs looked at is priceless.
WYepQ4dNnG 5y ago
Totally agree, that's exactly how it works for me. I join a company, work hard the first year to get a promotion and do the fun stuff, after that, I relax and stick around to vest most of the stocks and leave around the 2nd/3rd year. I have seen so called "architects" at big co that had been there for decades bringing absolutely no value to the table. And always asked myself why would the the company retain, promote and pay these guys big bucks. Nonsense. I call them : the legacy guys. The only thing I can think of is that the "legacy guys" retain the memory of all the legacy stuff, and the ability for them to maintain that piece of legacy/core/monolith piece of software that no one dares to touch. I guess that's valuable for the company, but not certainly for the employee. They stagnate exactly because by working on that legacy stuff they can rarely learn new tech, thus they wont be able to find a job at that level anywhere outside their current company. They are stuck.
- burntoutfire 5y ago
  There are jobs for architects out there.
- N_A_T_E 5y ago
  My title is Architect. It can be easy to stagnate. Recently I've had success working on brand new projects. Setting up the skeletons of code bases, CI/CD, database/persistence layers and internal/external dependencies before teams get onboarded. You might think of that like a glorified lead engineer. I stick around for 6-12 months to help the team get up to speed then move onto the next project. The architect part might come into play in finding engineering economies of scale. At this point I know how many of our internal applications work so I find ways to reuse existing code and services when we start new projects.
- otikik 5y ago
  Do you have kids?
  - WYepQ4dNnG 5y ago
    I do. I know it is impossible to getting prep for interviews when having kids. What I do is to leave my current job, give myself a month to prep, interview get a new job. So far it has worked fine with me.
alkonaut 5y ago
I have the opposite observation. The first few years are needed just to learn a domain. Productivity doesn’t begin to take off until after a few years. If no one had worked 10 or 20 years in my team we’d struggle to get anywhere. The impact of new hires can still be great when it comes from bringing fresh ideas and perspective (e.g processes, tech knowledge) and that obviously fades as everyone with a long tenure at the company has used the same tech.
- throwawaysleep 5y ago
  Companies have basically said “don’t bother learn about the business except for the interview” with their compensation approaches. Why bother spend time learning anything not applicable at your next role?
- magicalhippo 5y ago
  Same here. Took me over a year before I got somewhat confident with the domain, and after two years before I became fully productive. My boss takes this into account and doesn't hire people he's confident will move on in less than 3 years.
mberning 5y ago
This absolutely happens. A lot depends on the company and role, but in my experience after 24-36 months you tend to become known more broadly in the company and are passed around as “person who knows about x” and these type of interactions characterize most of your days. It’s not a bad spot to be, but definitely not the most productive arrangement.
teawrecks 5y ago
I think there's more variables at play though. A person who has been at a company 3+ years has figured out how to be effective in certain areas, but is also now asked to be effective in a much wider range of areas. They are asked to maintain something they wrote in their first year, they are asked to attend meetings or respond to emails because they have the knowledge and influence, they can't start anything new because they are so pivotal to the thing they're currently doing. And yeah, these things are important to the company, but they make the worker feel like they're stagnating. The company starts to get in their way and they feel like the only way to do something they find interesting is to leave. Companies need to give engineers the opportunity at a clean slate. Let them shed responsibilities and pretend they're just a very competent new hire with the freedom to start working on whatever they want to. If it's a larger company, you can usually transfer to another team somewhere, but you still get pinged about stuff you never want to spend time on again.
rhacker 5y ago
That didn't piss me off at all. But agree that might offend others. I do see myself getting stale in different shops. I kinda stopped jumping around every 3 years at this point though. I might just sit for a while to make sure there is stability going forward.
abeppu 5y ago
I think there's also an issue that a software engineer's job changes as they're more tenured at an organization. When you're newer, no one expects anything of you other than to come up to speed and build new stuff. If you have a project that doesn't require deep knowledge of the existing systems, push it to the newer guy. Only once you have deep knowledge of the systems you work with does it really make sense to give you work like a complex redesign of a group of components in an online system. And you then have a responsibility to help new team members learn. You do more code reviews, and more consulting on projects for which you are not a primary contributor. And you get ugly projects that are related to your area of demonstrated "expertise". Is that "slowing down"? Or are you just doing different kinds of stuff? And is it because the engineer stagnated, or that the organization created a morass around them?
- redleader9345 5y ago
  Well said. Typically in year two your job has more than doubled in the workload and responsibility that you're asked to carry. Which makes the line chart even worse. Pay is flat but the demands of the job are not.
ed_elliott_asc 5y ago
Another thing that happens is people get dragged into more and more meetings and also become the “go to person” for stuff. I’ve seen it time and time again, start somewhere new and start with very few meetings and you can really deliver.
- SonOfKyuss 5y ago
  I’m living this currently. Fortunately, my manager understands and appreciates the value of being a domain expert and mentor and the time commitments that come with it.
justicezyx 5y ago
Developer stagnant? I was in Amazon and Google, I never saw a case where the developer stagnant before the product/management went into stagnant. Developers just write code, and they just accumulate more knowledgeable and skills with the stuff they work on. How can they stagnant is something not obvious to me at all...
NationalPark 5y ago
I'm not convinced this isn't explained entirely by compensation. There are perhaps a dozen large tech companies at which an only moderately remarkable engineer can make $500k a year right now. That number has gotten bigger every year for the last decade at least, and the much larger pool of "every other software company" is increasingly falling behind. You should follow up with your exits a few years down the line and see where they end up long term. I bet a few of them will have retired - how often do your engineers retire at 35?
aszen 5y ago
Sorry but I really cannot understand how this is the case. In my short experience one can't make a significant impact to a mature large scale software product in 2 years. What kind of impact I'm talking, the kind of impact that can affect the business bottomline, that can actually transform the company. Without anyone having more than 2 to 3 years of experience the level of insight into the product would be quite shallow. Not to mention people that only stay for 2 to 3 years at a job never get to experience the long term implications of their code and decisions. They never get to learn from their mistakes since they keep making new ones and moving on
hintymad 5y ago
It may well be true, but I doubt it for companies like AWS, which has enormous infrastructure, many implicit and explicit processes, and a peculiar culture to run such processes and leverage such infrastructure effectively. Losing good people means losing guardian of such culture, mavens of the infrastructure, and custodians of the processes.
jasonlotito 5y ago
This all just screams of issues with poor tech leadership.
jjav 5y ago
> that comes to an end after about 24-36 months of working at the same company Have you looked into why? The one job where I stayed over 10 years was the one where my expertise was highly respected (large degree of decision-making autonomy, no micromanagement via agile) and I was able to fluidly change projects every 2-4 years. The pay wasn't that great but it never mattered because the job was so rewarding. Most other jobs just micromanage one to death and stagnate career, so a couple years of that kind of abuse is all one can take before moving on to the next deathmarch.
jjav 5y ago
> What I do know is that it's much easier for me to hire a competent lawyer or UX designer than it is to hire a competent software developer I'm curious if you grill the lawyer on some abstract topic from their undergrad courses (possibly 20 years ago) and make them write it perfectly on a whiteboard? Meaning, the same way software developers get interviewed? Or do you look at the lawyer's professional experience and hire based on that? It's easy to hire people when you make it easy, it's difficult when you put up artificial barriers to prevent the hiring.
- ChrisMarshallNY 5y ago
  Here's a post I made yesterday, in another thread, that sort of speaks to that: https://news.ycombinator.com/item?id=28034629 https://news.ycombinator.com/item?id=28034629
tclancy 5y ago
A year to learn, a year to earn, a year to yearn is how I’ve heard the cycle explained.
alfalfasprout 5y ago
This ignores something very important: tribal knowledge. Truth is, losing a tenured engineer carries a MUCH larger cost than HR and some managers seem to understand-- these engineers understand the nuances behind why certain decisions were made, what kinds of things tend to work and don't, minutiae of various systems that simply will never get documented, etc. Not to mention the influence they can carry in the org. You're not wrong that a lot of engineers stagnate after a few years... but it's a big logical jump to put that blame on them rather than the org they're joining. That said, I like to always call out that there are "developers" and there are "engineers". The majority of software roles call for the former and these tend to be more "replaceable". It's harder to say that for the latter where they are involved in more strategic technical decisions.
- randcraw 5y ago
  The value of tribal knowledge is even more apparent when 'engineers' describes a) traditional engineers (EE, mechE, chemE, civilE, etc), or b) software types with deep specialized skills that grow with domain experience (e.g. image analysis in medical/pharmaceutical, signal processing in audio/radar/telecom, or finite element analysts in weather/mixture modeling). The experience gained with years in roles like these isn't just in the use of computer tools, but in how to approach and solve proprietary domain problems with constraints that often aren't obvious. Knowing the pitfalls or conventions inherent in complex or regulated domains like automobile or pharmaceutical safety takes time to learn, making those with such experience more valuable to retain.
- rightbyte 5y ago
  > a lot of engineers stagnate after a few years Stagnate is also a way of saying got good at the job. I mean after a couple of years at a place an engineer might be the person that know the systems best in the whole world if they are no commodity. It takes year to gain the experience and inside out knowledge of a complex system. To me it feels like I get a mental picture over a system after some time where I can smell where bugs comes from and very fast decide were functionality should be inserted. Up to that point things are just a hassle and then it clicks and becomes a breeze. Then I switch jobs to get a pay raise and the grind begins again ...
seventytwo 5y ago
This is probably very dependent on the exact role and field, but o see your point.
LAC-Tech 5y ago
> in my experience most developers do their best work after about 6-8 months of starting a job at a new company Fair. That's about as long as it takes me to realise "nothing fundamental is going to change", so I tend to start losing motivation at this point. Thankfully I'm a contractor so that's about when I exit anyway. Everybody wins!
the_gipsy 5y ago
Self-fulfilling prophecy?
bumby 5y ago
>there are many more competent lawyers and designers out there Curious if you could elaborate on how you came to this conclusion? According to ONET [1] there are 819k lawyers in the U.S. but 1.469MM software programmers. If you come from a software background I wonder if it’s easier to spot an incompetent programmer than an incompetent attorney which could bias the heuristic. Or do you think there’s something else at play that makes the proportion of competent software developers inherently much lower? E.g., there’s no “bar exam” for programmers to ensure a basic level of competence [1] https://www.onetonline.org/ https://www.onetonline.org/
Consultant32452 5y ago
I find the biggest problem I have is that as time goes on too many people come to recognize me as a person who can likely solve their problem. Somewhat ironically this makes it more difficult to accomplish things over time because I'm constantly getting pulled into things to give my $0.02. I fully recognize that some of this is my fault and possibly poor boundaries and time management. But it's easier to just leave every few years and also more lucrative. So there's zero incentive for me to stop this from happening.
machinelearning 5y ago
> “most developers do their best work after about 6-8 months of starting a job at a new company, and that comes to an end after about 24-36 months of working at the same company” From what I’ve observed, the reason for this is not that people intrinsically lose the motivation to do great work. Rather, often they realize that the company’s ability to reward their performance doesn’t scale with their effort. Company’s have to delicately balance incentivizing performance of newer employees vs. risking alienating older employees who probably have a lower base rate but are key to the company’s daily operation. The schelling point eventually settles to an environment where people surge for a few months and coast while doing the minimum amount of work. This is especially true in a smaller company where cash flow may be constrained. Though the smaller companies often have more flexibility to offer non-monetary rewards like an overblown title or growth opportunities. The “optimal” strategy for the company is to overpromise rewards to new hires to get them to do most of the challenging work while doling out minor incentives when needed once employees are indoctrinated and somewhat burnt out.
vp8989 5y ago
"in my experience most developers do their best work after about 6-8 months of starting a job at a new company, and that comes to an end after about 24-36 months of working at the same company. After that the vast majority of people just stagnate, get complacent, the job stops being interesting to them and they move on." Thanks for sharing this, I think you are probably "right" even though what you said is not an easy/popular thing to say. What is your observed sample size on this? Could you elaborate on how you see people stagnate, and why you think this might be?
mcot2 5y ago
IMO I think your hiring is broken. You should look for things like willingness to learn and ask about previous jobs to see if the candidate experience stagnation. Is your company really getting a decent ROI after only 2-3 years of an employee in a specific role??
mathattack 5y ago
My 2 cents - if some stagnate, it’s still worth working hard to retain the ones with upwards trajectory. And he kind on the way out for the others. There is a benefit to institutional knowledge. By your reasoning do you agree with Amazon’s explicit 4 years and out model?
deleted 5y ago
[deleted]
cbushko 5y ago
I agree with you that most developers do their best work after 6-8 months and that developers get less productive after 24-36 months but for totally different reasons. Developers don't get 'lazy', 'bored' or 'comfortable', they get overburdened by the company. It is common knowledge that the average developer leaves after the 2 year mark. When that happens, everyone else is left holding the bag and they become the new experts. Companies are full of self created abandonware. Another person leaves and it is now two extra things that the vet has to become the expert on. Then three, then four and on and on. Next thing you know, your vet isn't getting any work done because they are holding too many bags. As the expert, they are in too many meetings trying to keep other people productive. They are pulled into too many critical issues and they are trying to mentor new developers in your ever revolving door of new people. But they are unproductive No. They are keeping your company afloat and you aren't compensating them for it.
- makeitdouble 5y ago
  I think it's worse than that, as some of the bags they are holding are full of junk. Yet they can't just throw them away, because their peers are not confident enough to support the conclusion that there's nothing of value in there. A litany of "How can we be sure that XXXX" are thrown at the expert to clear, creating continuous inertia. The choice becomes to keep holding the bags eternally, or go elsewhere they can start fresh.
  - cbushko 5y ago
    Sometimes yes, sometimes no. Is it really junk or are we lacking in time/money/tribal knowledge to understand how it deeply works? I like to think that I am a Very Good Engineer™ but I am sure that I would produce a similar piece of "junk" if I was under the same lack of requirements, training and time. who wrote this garbage??? > git blame oh crap, it was me 2 years ago!
    - lolinder 5y ago
      > Is it really junk or are we lacking in time/money/tribal knowledge to understand how it deeply works? I think OP was talking not about code quality but code value. A lot of legacy systems are maintained simply because we don't know for sure that there's not something that relies on them, or that they won't be needed later. The expert wants to discard them, but everyone else insists on keeping them around just in case. That adds burden on the expert.
KirillPanov 5y ago
You seem to attract people with short attention spans. Imagine if academia tried this.
craftinator 5y ago
> After that the vast majority of people just stagnate, get complacent, the job stops being interesting to them and they move on. > so I pay them less, regardless of whatever objective measure of impact may exist. Ah, the classic "blame the person you hired for being bored with a low paid, dead end, high churn rate job", most excellent.
danielscrubs 5y ago
My anecdotal opinion is that the first year it's important to show that you are productive. You cut the Jira tasks into extremely small ones and seem very productive to management because tickets get moved, but it's all smoke and mirrors (hell, you haven't seen half of the tech stack, and there is little documentation on the architecture most of the time). A senior developer on the other hand might say they didn't do much because they think "it was just small things that I've done before". You really have to look at the commits. Companies have been bankrupted because of the "let's just get two new ones"-mentality, not seeing that the lead time for developers to become relatively productive by knowing the ins and outs of large codebases is very, very long (for backend development, frontend is more cookie cutter).

by Kranar 5y ago

535188B17C93743 5y ago

While I think it's an organizational failure, even if folks aren't "growing" after 36 months, I definitely think there's institutional knowledge they have that helps them be more effective... the more time that elapses, the more of that institutional knowledge is lost and not documented. Obviously it's not great to have companies hanging on by the thread of a single person's knowledge over 10 years, but I feel like at a lot of companies (especially smaller companies), this is the reality.

sparker72678 5y ago
> but I feel like at a lot of companies (especially smaller companies), this is the reality. Exactly. There are many small companies that will be far more impacted be one of their 2 developers leaving than they would be by the owner being hit by a bus, but they'll still balk at raising salaries.
- MichaelZuo 5y ago
  Well market dynamics over the long term should take care of companies that short sighted. They will be outcompeted by others that are better at building organizational capacity.
  - abc_lisper 5y ago
    Yeah, that long term is not useful for the engineer whose skills should be valued right. He will be older by that time
    - MichaelZuo 5y ago
      Well that’s sorta how life works? It’s like any other market dynamic that organizes society. No guarantees that anyone will be utilized to their highest and best purpose.

munchbunny 5y ago

I'm not fully convinced that this is just about the devs. 2-3 years is also about how long it takes for a nascent project to transition into a mature one, and when that happens the culture and energy of the team tends to shift. The same dev that thrives in one setting might end up out of place in the other.

nostrademons 5y ago
I think in tech 2-3 years is also about how long it takes for one's mental model of how the world works to become stale and outdated, usually coinciding with other projects (that had been too nascent to use) maturing. I remember that in my peak webdev years in 2008, you built webapps by designing the HTML, converting it to templates, filling in data with Django or Rails, and then adding judicious interactivity with JQuery. By 2011 the world had moved on to Angular and SPAs, and you built webapps as a single HTML page and large JS bundle with a bunch of components that you'd fetch data for over AJAX. By 2013 the world moved on to React, and you had all these tools (Gulp, Grunt, Bower, NPM, etc.) to automate packaging and code-reuse. In 2015 people were still using React and more mature versions of these tools, but what changed was the economic reality that you could make lots of money as a webdev, and the industry itself was maturing with demand for new apps dying out. I'm witnessing this with my team at work too. We have an "old guard" of leadership that joined the team in its peak years in 2018/2019, and learned (and often wrote) the tech stack as it existed then. Now our team is colliding with infrastructure efforts that started elsewhere in the company and were too immature to use last year, but are now starting to bear fruition and get widespread adoption throughout the org. People who were experts in the old way of doing things find that their skills and projects are now largely irrelevant.
- alex-nt 5y ago
  Depends on what you work on. If you are not on pure tech (a minority of people are), as you get closer to the business you will get insights on how things work, how you can change them, make them better etc. Only part of our job is technical, and without the business knowledge you can't push the world in which you work further. There will be pushback from the "old guard" always, everywhere, as there will be push for the "new thing" always, everywhere. Neither is healthy, and both should be evaluated with a cool head.

nine_zeros 5y ago

This is ridiculous. I would prefer being at my current job, leverage my tribal experience to build things (and I have specific things on my mind) better and faster. If I pitch this to my CTO, he will agree that using my knowledge to build things better and faster aligns with business goals. Only middle management rationalizes theories such as you proposed. Middle management sometimes just forgets what is the goal of their job and instead focuses only on their actions (self obsession), ego and the presentation of success. An example of middle management self-obsession is your use and throw mentality. Middle management does this because they don't actually listen to their reports. Managers think they are on another dimension and don't need to hear anything from anyone. A really competent middle manager would know that senior engineers, especially ones with tribal knowledge are the real 10x engineers in practice. Not because they type fast, not because they are hungry and energetic but because they can process situations and circumstances faster in their head to yield results. If I were a middle manager, I would do my utmost to retain trustworthy people around me. It's almost a no brainer productivity boost.

fizx 5y ago
Hi, Person currently in middle management here. While we'd love to pay our good people more, at a moderately sized company and up, we operate under an unbelievable number of constraints, from HR, finance, etc.
- nine_zeros 5y ago
  You might have constraints but you can still raise your voice EACH time attrition happens because of constraints. Only then will the system change and make lives easier for everyone. If not, you are forever going to be stuck in the cycle of hiring and attrition.
  - foobiekr 5y ago
    Speaking from experience, most large tech companies view engineers as area under the curve, as fungible hours. Speaking out about attrition usually doesn’t have any impact at all above the Director level.

esprehn 5y ago

You may enjoy the concept of the "tour of duty": https://hbr.org/2013/06/tours-of-duty-the-new-employer-employee-compact https://hbr.org/2013/06/tours-of-duty-the-new-employer-emplo... http://www.theallianceframework.com/about-the-book.html http://www.theallianceframework.com/about-the-book.html Thinking about my career (and others) this way has helped me remove a fair bit of stress when making job, role or project changes.

alex-nt 5y ago

Yes, it takes about 6m in a medium to big organizations to figure out what to do and with whom you have to speek to get stuff done. And for 2 years everything is rosy. Then you speak with you colleagues that changed jobs and find out that their income is 30% to 40% higher. That will, of course, put a downer on your day/week/quarter/year. You have 2 options, speak with your current company about compensation or leave. I tried the first option (admittently a bit late, but I did mention the problem in our review talks and other talks) after I found out that my income was 40% lower than colleagues that left 1 year before (was 3 years and a half at this company and had top marks every year, big company, a lot of cash to throw around). I was offered a measly 5% after being dragged in 4 meetings about how great I am. Left and almost doubled my income in 2 years. This is all anecdotal, but I hear it from everyone around me, you HAVE TO SWITCH jobs every 2 years, you can stretch to 3, maybe. Of course, during the last years you won't deliver as much, you have to prepare for intervews and such. This was of no benefit for the previous company. Over my 4 years there I've seen how we were bleeding knowledge that we never got back. The company didn't do so well, the thing I worked on just died after everyone left 6m after me. It's a shame, it could've been a nice thing compared with what I see offered by the competition.

bla3 5y ago
> I was offered a measly 5% after being dragged in 4 meetings about how great I am. The way you do this is interview elsewhere, get an offer for 40% more, and _then_ tell your manager that you have an offer for 40% more and that you'd really like to stay but they'd really have to do something about compensation. You'll get more than 5% then (but likely less than 40%). It's annoying that you have to invest the time for this, but it does provide data to your current company that your market rate is in fact what you think it is.
- pklausler 5y ago
  Or take the 40% boost and come back two years later for even more.
  - alex-nt 5y ago

rfrey 5y ago

By retaining a person who has "stagnated" after 3 years (setting aside the ambiguity of what you mean by "stagnate"), you avoid: 1) Three years of lesser performance from the new employee as they climb that curve 2) The very real risk that your new hire will not be successful, or if they are successful, will not achieve the same level of performance. Also, I invite you to challenge what you consider "stagnation". It is not possible to continue linear improvement in a given role: good employees achieve mastery, and while they will still be improving that might not be evident to their managers who are looking only at work outputs. If a company does not want employees who are masters at their task, but rather want people to move up or move out (counter-productive as that might be), then it is literally middle management's job to find new roles for successful engineers, and I suppose fire the previously successful engineer if they're not up to the task. Complaining about an engineer "stagnating" in the same role after they've mastered it is just lazy thinking and lazy management.

suifbwish 5y ago

This isn’t surprising. 3 years is about the length of time it takes most humans to become bored with monogamous relationships. There is a very high rate of breakups and divorces in non arranged relationships by the 4th year.

Ensorceled 5y ago
The divorce rate for the first 5 years is less than 20% in the the US. The US has a higher divorce rate than many countries so, in general, this is untrue.
- disgruntledphd2 5y ago
  Marriage != monogamous relationships
  - Ensorceled 5y ago
    True. But they said “divorces”, I’m disputing that part. They have no support for the rest either.
- randomdata 5y ago
  I'm not sure you've shown that. I would be surprised if any meaningful number of (non-arranged) marriages are established in year zero of the relationship. A quick Google search suggests to me that the average relationship is established five years before getting married. The original assertion was that relationships tend to break down in year four, meaning that they aren't likely to make it to marriage in the typical case. Marriage data is only relevant to the outliers who married early, and as far as that goes they could all be found in that 20% quite easily, I'm sure. The data provided is not sufficient to know.
  - Ensorceled 5y ago
    No. The original assertion is that monogamous relationships AND marriages breakdown in the first five years at “very high rates”. Marriages do not. And, as you say, if you got married you were probably monogamous for some time before that. I’m not disputing that humans get together and break up all the time. It’s unclear that monogamous relationships breakup “at very high rates” due to boredom either. There are many reasons relationships falter, boredom being but one of them.

b3morales 5y ago

You're not really making an independent measurement here. You see developers "stagnating" and moving on; how do you know that's not caused by lack of pay increases and other things you're doing (letting people pick new projects, for example, to keep them interested)? Maybe if you did "go out of your way to retain employees" you'd have employees who end up making your business even more successful during their longer tenure.

vsareto 5y ago
I don't think pay increase will help stagnation. Maybe picking projects will if the company has enough variety. The best cure for stagnation I've found is to take long breaks and get into something else.
- b3morales 5y ago
  Sure, and I don't really know either; my point was just that the parent is begging the question. :)
- reedjosh 5y ago
  > I don't think pay increase will help stagnation. No, but lack thereof can certainly cause it. When there's no real reward, what's the point of putting in the extra work and taking risks? Two things that quickly break stagnation.
- visarga 5y ago
  My cure for stagnation is to play more. Amazing how playing at a pet project will get your juices flowing.
- mikepurvis 5y ago
  Agree. I've been at my place for 11 years now, and have had four very distinct roles over that time. Each change gave that revitalizing jolt of fresh challenges, technologies, etc, but with the benefit that I got to keep my seniority, influence, expertise with the in-house systems, and so on. Have I given up potential pay bumps by not going external? Sure, probably. But I have enough to be comfortable and my company has treated me well, both monetarily and in facilitating these kinds of changes when I've wanted them.

diob 5y ago

What came first, the chicken or the egg in your scenario? Did they stop doing great work because the rewards didn't match? Or did you stop matching because they stopped doing great work? Always hard to tell.

HWR_14 5y ago
It's not hard to tell at all. You could just, wait for it, make the rewards match the expected great work and test that way.
- diob 5y ago
  I definitely agree. Pay what you expect (great for great work), and if someone isn't cutting it let them know (chance for improvement). Worse case, let them go. Instead, most companies reward no one and wonder why the good ones leave or burn out ("weird, they don't contribute at the same level anymore").

lmilcin 5y ago

> (...) that comes to an end after about 24-36 months of working at the same company. After that the vast majority of people just stagnate, get complacent, the job stops being interesting to them and they move on. Or, another explanation, you are mistaking cause and effect. Maybe the people figure out they could be earning so much more somewhere else but they are unlikely to get the kind of raise at their current place, so they get disillusioned and demotivated? And then they change the job getting the significant raise, further reinforcing the behavior. Now they join another company fully expecting the same thing to happen in 2 years.

wpietri 5y ago

I would look at inverting the causality there. If your data is accurate, I think it's better to say, "Most companies create developer jobs that get boring for people after 24-36 months." I was chatting with a Trader Joe's cashier Sunday. It turns out they change jobs every hour. That was a surprise to me; when I long ago worked in a grocery store, I was assigned to one position for 8 hours for every shift. Why does Trader Joe's do it? To keep things interesting: "She tells Money that the change in jobs during shifts helps to keep things interesting for employees. 'It's perfect because it breaks down your shift. You don't get tired doing one repetitive thing,' she told them." https://www.mashed.com/175743/workers-reveal-what-its-really-like-to-work-at-trader-joes/ https://www.mashed.com/175743/workers-reveal-what-its-really... If Trader Joe's can do it hour by hour, I think tech companies can do it at least every year or so. I'm hiring right now and one of the major draws for the good people I'm talking to is the chance to do something interesting. If that's why their coming, it's unsurprising that I'll have to keep giving them that over time. For us, and for most places I've worked, I think that's doable.

wwweston 5y ago
Yes, but this won't work because there's just not enough different things for an engineer to master. ;) More seriously, your observation is brilliant (and almost makes me wish I hadn't just accepted a new role). Because the software field contains such a breadth of things to know and breadth of potential applications, it's hard to get very far without having the kind of mind that is motivated by some level of intrinsic interest, and that can be a currency in its own right.
itronitron 5y ago
I would really appreciate that as a developer, I have definite gaps in my skillset that I haven't needed (been paid) to fill. But everyone would have to get out of the mindset that developer Joe 'knows everything' about X. The perfect match would be pairing a developer that can explain some technology to a 12 year old with a developer that has the equivalent knowledge of a 12 year old (for that technology.) That would keep things interesting and build a very resilient organization.
- 5y ago

Pxtl 5y ago

3 years is also the amount of time it takes to become the resident expert in one of the company's Scary Basements, and then both your productivity and morale hits the crapper while this tired old beast that nobody wants to support you in modernizing needs fixes and tweaks.

brightball 5y ago

I'm going to make a suggestion for the cause of your observation. I think many people come into a job for a specific project(s) during which there is a ramp up period of understanding the requirements, limitations, team, how the company works, getting to know people (6-8 months). Then after working on that project, delivering it, iterating on it, tuning it, working through potential production support issues and some scaling items...in many cases the vast majority of the work is done (2-3 years). At that point, a few things happen because this developer is ready for a new project or new challenge, as are most of the people who were involved with that project. Their options are: - Find a new project at the company and restart the learning period as they transition in a potentially lateral move. If this happens, it's unlikely the company is going to give them a sudden compensation boost when in the eyes of management they're continuing to do their existing job. - Seek training related to some advanced problem that they solved to become the company's expert on the subject, in which case the company will likely pay for the training but not a subsequent boost in compensation (because in their eyes...they just paid for the training) - See how well they have marketed themselves to find out if the company has recognized their talent to promote them into a higher level position with an equivalent pay bump or potentially managing a team. The only problems is that you can only promote so many people, so this person will be the exception and not the rule. - Update their resume with the newly acquired skills and have somebody else pay them market rates to start a new project at a different company, using their current job as leverage to get a significant bump in compensation. Meanwhile, you'll be paying new market rates to hire the replacement. It's no secret why people often just jump jobs. You've finished one project and you're going to transition to a new one anyway, getting a fresh start can be a good choice. Additionally, no matter how much people like their situation in one job they will end up building up frustrations with certain people and/or management over time. As long as those people are still around, it will increase their likelyhood of leaving. But ultimately, you're looking at the likely timing of concluding one project and then exploring options for what's next. IMO, that coincides with your timeline.

commandlinefan 5y ago

> the vast majority of people just stagnate, get complacent Even if you're right - 100% of the time, about 100% of people - the value of having the one guy who remembers why it was done this way and how it was fixed last time it broke available to look at it when it needs looked at is priceless.

WYepQ4dNnG 5y ago

Totally agree, that's exactly how it works for me. I join a company, work hard the first year to get a promotion and do the fun stuff, after that, I relax and stick around to vest most of the stocks and leave around the 2nd/3rd year. I have seen so called "architects" at big co that had been there for decades bringing absolutely no value to the table. And always asked myself why would the the company retain, promote and pay these guys big bucks. Nonsense. I call them : the legacy guys. The only thing I can think of is that the "legacy guys" retain the memory of all the legacy stuff, and the ability for them to maintain that piece of legacy/core/monolith piece of software that no one dares to touch. I guess that's valuable for the company, but not certainly for the employee. They stagnate exactly because by working on that legacy stuff they can rarely learn new tech, thus they wont be able to find a job at that level anywhere outside their current company. They are stuck.

burntoutfire 5y ago
There are jobs for architects out there.
N_A_T_E 5y ago
My title is Architect. It can be easy to stagnate. Recently I've had success working on brand new projects. Setting up the skeletons of code bases, CI/CD, database/persistence layers and internal/external dependencies before teams get onboarded. You might think of that like a glorified lead engineer. I stick around for 6-12 months to help the team get up to speed then move onto the next project. The architect part might come into play in finding engineering economies of scale. At this point I know how many of our internal applications work so I find ways to reuse existing code and services when we start new projects.
otikik 5y ago
Do you have kids?
- WYepQ4dNnG 5y ago
  I do. I know it is impossible to getting prep for interviews when having kids. What I do is to leave my current job, give myself a month to prep, interview get a new job. So far it has worked fine with me.

alkonaut 5y ago

I have the opposite observation. The first few years are needed just to learn a domain. Productivity doesn’t begin to take off until after a few years. If no one had worked 10 or 20 years in my team we’d struggle to get anywhere. The impact of new hires can still be great when it comes from bringing fresh ideas and perspective (e.g processes, tech knowledge) and that obviously fades as everyone with a long tenure at the company has used the same tech.

throwawaysleep 5y ago
Companies have basically said “don’t bother learn about the business except for the interview” with their compensation approaches. Why bother spend time learning anything not applicable at your next role?
magicalhippo 5y ago
Same here. Took me over a year before I got somewhat confident with the domain, and after two years before I became fully productive. My boss takes this into account and doesn't hire people he's confident will move on in less than 3 years.

mberning 5y ago

This absolutely happens. A lot depends on the company and role, but in my experience after 24-36 months you tend to become known more broadly in the company and are passed around as “person who knows about x” and these type of interactions characterize most of your days. It’s not a bad spot to be, but definitely not the most productive arrangement.

teawrecks 5y ago

I think there's more variables at play though. A person who has been at a company 3+ years has figured out how to be effective in certain areas, but is also now asked to be effective in a much wider range of areas. They are asked to maintain something they wrote in their first year, they are asked to attend meetings or respond to emails because they have the knowledge and influence, they can't start anything new because they are so pivotal to the thing they're currently doing. And yeah, these things are important to the company, but they make the worker feel like they're stagnating. The company starts to get in their way and they feel like the only way to do something they find interesting is to leave. Companies need to give engineers the opportunity at a clean slate. Let them shed responsibilities and pretend they're just a very competent new hire with the freedom to start working on whatever they want to. If it's a larger company, you can usually transfer to another team somewhere, but you still get pinged about stuff you never want to spend time on again.

rhacker 5y ago

That didn't piss me off at all. But agree that might offend others. I do see myself getting stale in different shops. I kinda stopped jumping around every 3 years at this point though. I might just sit for a while to make sure there is stability going forward.

abeppu 5y ago

I think there's also an issue that a software engineer's job changes as they're more tenured at an organization. When you're newer, no one expects anything of you other than to come up to speed and build new stuff. If you have a project that doesn't require deep knowledge of the existing systems, push it to the newer guy. Only once you have deep knowledge of the systems you work with does it really make sense to give you work like a complex redesign of a group of components in an online system. And you then have a responsibility to help new team members learn. You do more code reviews, and more consulting on projects for which you are not a primary contributor. And you get ugly projects that are related to your area of demonstrated "expertise". Is that "slowing down"? Or are you just doing different kinds of stuff? And is it because the engineer stagnated, or that the organization created a morass around them?

redleader9345 5y ago
Well said. Typically in year two your job has more than doubled in the workload and responsibility that you're asked to carry. Which makes the line chart even worse. Pay is flat but the demands of the job are not.

ed_elliott_asc 5y ago

Another thing that happens is people get dragged into more and more meetings and also become the “go to person” for stuff. I’ve seen it time and time again, start somewhere new and start with very few meetings and you can really deliver.

SonOfKyuss 5y ago
I’m living this currently. Fortunately, my manager understands and appreciates the value of being a domain expert and mentor and the time commitments that come with it.

justicezyx 5y ago

Developer stagnant? I was in Amazon and Google, I never saw a case where the developer stagnant before the product/management went into stagnant. Developers just write code, and they just accumulate more knowledgeable and skills with the stuff they work on. How can they stagnant is something not obvious to me at all...

NationalPark 5y ago

I'm not convinced this isn't explained entirely by compensation. There are perhaps a dozen large tech companies at which an only moderately remarkable engineer can make $500k a year right now. That number has gotten bigger every year for the last decade at least, and the much larger pool of "every other software company" is increasingly falling behind. You should follow up with your exits a few years down the line and see where they end up long term. I bet a few of them will have retired - how often do your engineers retire at 35?

aszen 5y ago

Sorry but I really cannot understand how this is the case. In my short experience one can't make a significant impact to a mature large scale software product in 2 years. What kind of impact I'm talking, the kind of impact that can affect the business bottomline, that can actually transform the company. Without anyone having more than 2 to 3 years of experience the level of insight into the product would be quite shallow. Not to mention people that only stay for 2 to 3 years at a job never get to experience the long term implications of their code and decisions. They never get to learn from their mistakes since they keep making new ones and moving on

hintymad 5y ago

It may well be true, but I doubt it for companies like AWS, which has enormous infrastructure, many implicit and explicit processes, and a peculiar culture to run such processes and leverage such infrastructure effectively. Losing good people means losing guardian of such culture, mavens of the infrastructure, and custodians of the processes.

jasonlotito 5y ago

This all just screams of issues with poor tech leadership.

jjav 5y ago

> that comes to an end after about 24-36 months of working at the same company Have you looked into why? The one job where I stayed over 10 years was the one where my expertise was highly respected (large degree of decision-making autonomy, no micromanagement via agile) and I was able to fluidly change projects every 2-4 years. The pay wasn't that great but it never mattered because the job was so rewarding. Most other jobs just micromanage one to death and stagnate career, so a couple years of that kind of abuse is all one can take before moving on to the next deathmarch.

jjav 5y ago

> What I do know is that it's much easier for me to hire a competent lawyer or UX designer than it is to hire a competent software developer I'm curious if you grill the lawyer on some abstract topic from their undergrad courses (possibly 20 years ago) and make them write it perfectly on a whiteboard? Meaning, the same way software developers get interviewed? Or do you look at the lawyer's professional experience and hire based on that? It's easy to hire people when you make it easy, it's difficult when you put up artificial barriers to prevent the hiring.

ChrisMarshallNY 5y ago
Here's a post I made yesterday, in another thread, that sort of speaks to that: https://news.ycombinator.com/item?id=28034629 https://news.ycombinator.com/item?id=28034629

tclancy 5y ago

A year to learn, a year to earn, a year to yearn is how I’ve heard the cycle explained.

alfalfasprout 5y ago

This ignores something very important: tribal knowledge. Truth is, losing a tenured engineer carries a MUCH larger cost than HR and some managers seem to understand-- these engineers understand the nuances behind why certain decisions were made, what kinds of things tend to work and don't, minutiae of various systems that simply will never get documented, etc. Not to mention the influence they can carry in the org. You're not wrong that a lot of engineers stagnate after a few years... but it's a big logical jump to put that blame on them rather than the org they're joining. That said, I like to always call out that there are "developers" and there are "engineers". The majority of software roles call for the former and these tend to be more "replaceable". It's harder to say that for the latter where they are involved in more strategic technical decisions.

randcraw 5y ago
The value of tribal knowledge is even more apparent when 'engineers' describes a) traditional engineers (EE, mechE, chemE, civilE, etc), or b) software types with deep specialized skills that grow with domain experience (e.g. image analysis in medical/pharmaceutical, signal processing in audio/radar/telecom, or finite element analysts in weather/mixture modeling). The experience gained with years in roles like these isn't just in the use of computer tools, but in how to approach and solve proprietary domain problems with constraints that often aren't obvious. Knowing the pitfalls or conventions inherent in complex or regulated domains like automobile or pharmaceutical safety takes time to learn, making those with such experience more valuable to retain.
rightbyte 5y ago
> a lot of engineers stagnate after a few years Stagnate is also a way of saying got good at the job. I mean after a couple of years at a place an engineer might be the person that know the systems best in the whole world if they are no commodity. It takes year to gain the experience and inside out knowledge of a complex system. To me it feels like I get a mental picture over a system after some time where I can smell where bugs comes from and very fast decide were functionality should be inserted. Up to that point things are just a hassle and then it clicks and becomes a breeze. Then I switch jobs to get a pay raise and the grind begins again ...

seventytwo 5y ago

This is probably very dependent on the exact role and field, but o see your point.

LAC-Tech 5y ago

> in my experience most developers do their best work after about 6-8 months of starting a job at a new company Fair. That's about as long as it takes me to realise "nothing fundamental is going to change", so I tend to start losing motivation at this point. Thankfully I'm a contractor so that's about when I exit anyway. Everybody wins!

the_gipsy 5y ago

Self-fulfilling prophecy?

bumby 5y ago

>there are many more competent lawyers and designers out there Curious if you could elaborate on how you came to this conclusion? According to ONET [1] there are 819k lawyers in the U.S. but 1.469MM software programmers. If you come from a software background I wonder if it’s easier to spot an incompetent programmer than an incompetent attorney which could bias the heuristic. Or do you think there’s something else at play that makes the proportion of competent software developers inherently much lower? E.g., there’s no “bar exam” for programmers to ensure a basic level of competence [1] https://www.onetonline.org/ https://www.onetonline.org/

Consultant32452 5y ago

I find the biggest problem I have is that as time goes on too many people come to recognize me as a person who can likely solve their problem. Somewhat ironically this makes it more difficult to accomplish things over time because I'm constantly getting pulled into things to give my $0.02. I fully recognize that some of this is my fault and possibly poor boundaries and time management. But it's easier to just leave every few years and also more lucrative. So there's zero incentive for me to stop this from happening.

machinelearning 5y ago

> “most developers do their best work after about 6-8 months of starting a job at a new company, and that comes to an end after about 24-36 months of working at the same company” From what I’ve observed, the reason for this is not that people intrinsically lose the motivation to do great work. Rather, often they realize that the company’s ability to reward their performance doesn’t scale with their effort. Company’s have to delicately balance incentivizing performance of newer employees vs. risking alienating older employees who probably have a lower base rate but are key to the company’s daily operation. The schelling point eventually settles to an environment where people surge for a few months and coast while doing the minimum amount of work. This is especially true in a smaller company where cash flow may be constrained. Though the smaller companies often have more flexibility to offer non-monetary rewards like an overblown title or growth opportunities. The “optimal” strategy for the company is to overpromise rewards to new hires to get them to do most of the challenging work while doling out minor incentives when needed once employees are indoctrinated and somewhat burnt out.

vp8989 5y ago

"in my experience most developers do their best work after about 6-8 months of starting a job at a new company, and that comes to an end after about 24-36 months of working at the same company. After that the vast majority of people just stagnate, get complacent, the job stops being interesting to them and they move on." Thanks for sharing this, I think you are probably "right" even though what you said is not an easy/popular thing to say. What is your observed sample size on this? Could you elaborate on how you see people stagnate, and why you think this might be?

mcot2 5y ago

IMO I think your hiring is broken. You should look for things like willingness to learn and ask about previous jobs to see if the candidate experience stagnation. Is your company really getting a decent ROI after only 2-3 years of an employee in a specific role??

mathattack 5y ago

My 2 cents - if some stagnate, it’s still worth working hard to retain the ones with upwards trajectory. And he kind on the way out for the others. There is a benefit to institutional knowledge. By your reasoning do you agree with Amazon’s explicit 4 years and out model?

deleted 5y ago

[deleted]

cbushko 5y ago

I agree with you that most developers do their best work after 6-8 months and that developers get less productive after 24-36 months but for totally different reasons. Developers don't get 'lazy', 'bored' or 'comfortable', they get overburdened by the company. It is common knowledge that the average developer leaves after the 2 year mark. When that happens, everyone else is left holding the bag and they become the new experts. Companies are full of self created abandonware. Another person leaves and it is now two extra things that the vet has to become the expert on. Then three, then four and on and on. Next thing you know, your vet isn't getting any work done because they are holding too many bags. As the expert, they are in too many meetings trying to keep other people productive. They are pulled into too many critical issues and they are trying to mentor new developers in your ever revolving door of new people. But they are unproductive No. They are keeping your company afloat and you aren't compensating them for it.

makeitdouble 5y ago
I think it's worse than that, as some of the bags they are holding are full of junk. Yet they can't just throw them away, because their peers are not confident enough to support the conclusion that there's nothing of value in there. A litany of "How can we be sure that XXXX" are thrown at the expert to clear, creating continuous inertia. The choice becomes to keep holding the bags eternally, or go elsewhere they can start fresh.
- cbushko 5y ago
  Sometimes yes, sometimes no. Is it really junk or are we lacking in time/money/tribal knowledge to understand how it deeply works? I like to think that I am a Very Good Engineer™ but I am sure that I would produce a similar piece of "junk" if I was under the same lack of requirements, training and time. who wrote this garbage??? > git blame oh crap, it was me 2 years ago!
  - lolinder 5y ago
    > Is it really junk or are we lacking in time/money/tribal knowledge to understand how it deeply works? I think OP was talking not about code quality but code value. A lot of legacy systems are maintained simply because we don't know for sure that there's not something that relies on them, or that they won't be needed later. The expert wants to discard them, but everyone else insists on keeping them around just in case. That adds burden on the expert.

KirillPanov 5y ago

You seem to attract people with short attention spans. Imagine if academia tried this.

craftinator 5y ago

> After that the vast majority of people just stagnate, get complacent, the job stops being interesting to them and they move on. > so I pay them less, regardless of whatever objective measure of impact may exist. Ah, the classic "blame the person you hired for being bored with a low paid, dead end, high churn rate job", most excellent.

danielscrubs 5y ago

My anecdotal opinion is that the first year it's important to show that you are productive. You cut the Jira tasks into extremely small ones and seem very productive to management because tickets get moved, but it's all smoke and mirrors (hell, you haven't seen half of the tech stack, and there is little documentation on the architecture most of the time). A senior developer on the other hand might say they didn't do much because they think "it was just small things that I've done before". You really have to look at the commits. Companies have been bankrupted because of the "let's just get two new ones"-mentality, not seeing that the lead time for developers to become relatively productive by knowing the ins and outs of large codebases is very, very long (for backend development, frontend is more cookie cutter).