[michaelfeathers]

For those of us in software development, an important thing to think about is what this does to code. The industry is full of old codebases tended by people who were never involved in the planning and initial design of those systems. Knowledge transfer rarely happens sufficiently to prevent accelerating maintenance headaches.

I think that we really need to find different ways of developing software to deal with this reality. A commenter here mentions the London financials community and people job hopping < 12-18 months. I've heard terrible horror stories about some of that code.

[lucisferre]

This is interesting, because I've also seen something that is quite the opposite. A codebase where an initially a small but quite inexperienced team wrote most of the original code and while these people are in fact still around they've been promoted to management roles based on their seniority in the company. Usually they never really advanced that far as software developers and are neither really experienced technically nor good technical managers.

These people protect and maintain the original code, architectures and practices almost reflexively. They resist better practices and refactoring, as well as education as they fear it will expose what they don't know. These companies also become a revolving door for anyone with any experience or talent for obvious reasons.

Honestly, I think the one of the worst problems for both codebase and technical culture is not beginning with a team of sufficient expertise and experience that can grow and mature appropriately over time.

[thejdude]

The problem with technical management is often that good developers stay where they are (they are NEEDED), but bad developers are often promoted because it's convenient, and because they don't exactly cling to their technical position - they're expendable.

So you have people that were bad coders to begin with and that don't have lots of technical know-how and experience making decisions that impact the project in very bad ways (like choosing absolutely the wrong frameworks or tools that HAVE to be used).

Also, good engineering skill isn't rewarded, because - of course! - a management or team lead position has more status and salary than a technical position, because it's worth so much more to the company.

[dennisgorelik]

> These people protect and maintain the original code

If business depends on robustness of that code - of course they protect it.

> They resist better practices and refactoring

How do you know that they resist "better" practices?

It could be they resist fancy practices that would cause more problems than they would solve.

[lucisferre]

So you just presume I'm exaggerating? On the basis of what exactly?

There is nothing robust about mountains of spaghetti code. If anything these businesses are spending countless dollars paying the interest on the technical debt left here. What's worse is it impacts their long term competitiveness as it resists even incremental improvements. Besides, there is nothing fancy about basic practices like solid design, proper planning or even just the appropriate use of tools for source control and build processes.

[the_af]

I had one junior guy who had been working for some years confess to me that he hadn't learned much in all his years of working. The reason? He was always chasing better pay, which in software development almost always means changing employers, and he never stayed long enough to learn the ropes of any job.

Granted, he was a junior developer, but I can see this applying to people with more "seniority" (measured in years, obviously).

[scotty79]

You become senior developer not by advancing technically. You just request salary that's too high for junior developer on your next job hop. If they want to hire you (and some will want to) they have to hire you as developer or senior developer. Also being older helps.

Once you are senior developer no one even dreams of offering you position of developer or junior developer.

[pyre]

I've been told that I would be in a entry-level position because I hadn't professionally worked with Python before, even though I had masses of experience in Perl, with Python being my free-time/side project language. Apparently I would be a "Senior Perl developer" but a "Entry-Level Python developer." (and this was at a start-up, not some big corp with an HR department)

[scotty79]

Yeah. What I said works for corporations. Start-ups tend to be as creative with ranks as with everything else.

[x0x0]

in your case, the right answer is, "k, good luck with that"

[nawitus]

How often did he change employers? I can't see how changing often somehow prevents learning. Even if he changes his employer every year, there should easily be enough time to learn.

[scarmig]

I'd guess that someone who jumps ship every year or two years will know more than someone of equivalent experience who's stayed at the same place for a decade. I learn the most the first six months at a new job.

Relatedly, there's the big benefit of much higher knowledge transfer of best practices in markets where job mobility is high. Individual companies, of course, end up giving up equal amounts of knowledge to peers and competitors, but ecosystems which support job mobility will outperform those that look down on it.

[null_ptr]

Sure, you learn the most in your first 6 months by quantity but that doesn't mean you learn the most valuable things. You won't learn anything of depth in half a year.

[nawitus]

Can you give some concrete examples of in depth learning that one can't learn in a year?

[encoderer]

Oh, lawd, help me.

Kidding. You ask a legitimate question. This is by no means a comprehensive answer, but...

1. Domain knowledge. I think most of us enjoy the creative and problem solving parts of software engineering. That takes domain knowledge and domain knowledge takes time. You will get an intro to your domain in a year, but mastery? I would bet against it.

2. Working on a hard project from start to finish and sticking around for the lessons learned after. This is just a math problem. You're useless for at least 30 days no matter how good you are. (More like 90 IMO...). So if you start working on a larger project with a new team, and that project takes 6 months, your year is ending rapidly.

3. Mastering truly large code bases. Not everything is a rails app. Some things are just hard. Mastery is difficult to achieve.

4. Engineering leadership. Even if you don't want to be on a management track, it's important for a seasoned, senior-level engineer to be able to lead/drive a project from start to finish.

...And I suppose you may think "But I do all of those." And maybe you do? Or maybe it's just really hard to see something that you're convinced isn't there.

[watwut]

Impact of architectural and design decisions. How hard to decipher certain code parts you are so proud about today are a year later - my experience is that people used to work on small projects or who change projects a lot generate hard to maintain/understand code.

Learning non-trivial codebase often takes much more time. I worked on bigger projects and someone who worked there only six months would not be allowed to do bigger or core changes.

Then there is domain knowledge (finance, healthcare, law, etc) if you do that kind of software. Six months is enough to learn surface in anything non-trivial and everything is much more effective if developer already learned that.

Of course, last two points are not really valid for small projects world.

[sheepmullet]

Working on a big/long running project end to end. If you jump ship after a year you won't really understand the impact of a lot of the decisions you made months ago.

Most companies wont let you make any high risk or big impact decisions in your first year of employment with them (regardless of whether you get hired at a junior or senior or tech lead level).

Experience in solving the more difficult problems that require expertise with the companies particular stack and internal architecture.

And many more. There are ways to mitigate these problems but few do.

[the_af]

About once a year, sometimes less. The constant shifting of tech stacks, architecture, domain, and also that he didn't have to maintain anything long term meant he was constantly at junior level.

[bubbleRefuge]

Good point. I've worked at 8 places in a 15 year career and have never seen a good code base. I've seen lots of clever code and some spots where the code quality was good but tight, clean , efficient, un-bloated, well doc'd code with automated tests on a large scale: nah, nicht.

[dustingetz]

Pair programming fixes the turnover problem

[michaelfeathers]

It trades it for the problem: convince people to pair program.

[sheepmullet]

How? High turnover + pair programming = paying significant amounts of money to upskill your staff who then leave.

It is no different to simply investing in a lot of employee training. Yes you keep the knowledge... But you are paying far more than if you just paid your staff enough to stay.

[kelnos]

How is that related at all?

(If my company forced us to pair program, I'd leave in a heartbeat.)