5 ms·

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

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.

the_af 12y ago
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).
- nawitus 12y ago
  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 12y ago
    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 12y ago
      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 12y ago
        Can you give some concrete examples of in depth learning that one can't learn in a year?
        watwut 12y ago
        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.
        Iftheshoefits 12y ago
        Most of the things you describe are deep, but also very narrow and domain-specific; frequently it is also very company-specific. Such knowledge is far less transferable than one might imagine.
        sheepmullet 12y ago
        "Most of the things you describe are deep, but also very narrow and domain-specific; frequently it is also very company-specific. Such knowledge is far less transferable than one might imagine." Agreed. It is the quickest way to become a 10x employee but unfortunately your current company won't give you a substantial raise for knowing their product and domain well and it is not transferable to other workplaces.
  - the_af 12y ago
    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.
- scotty79 12y ago
  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 12y ago
    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 12y ago
      Yeah. What I said works for corporations. Start-ups tend to be as creative with ranks as with everything else.
    - x0x0 12y ago
      in your case, the right answer is, "k, good luck with that"
bubbleRefuge 12y ago
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 12y ago
Pair programming fixes the turnover problem
- michaelfeathers 12y ago
  It trades it for the problem: convince people to pair program.
- sheepmullet 12y ago
  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 12y ago
  How is that related at all? (If my company forced us to pair program, I'd leave in a heartbeat.)
lucisferre 12y ago
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 12y ago
  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 12y ago
  > 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 12y ago
    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 12y ago

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).

nawitus 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      Can you give some concrete examples of in depth learning that one can't learn in a year?
      - watwut 12y ago
        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.
        Iftheshoefits 12y ago
        Most of the things you describe are deep, but also very narrow and domain-specific; frequently it is also very company-specific. Such knowledge is far less transferable than one might imagine.
        sheepmullet 12y ago
        "Most of the things you describe are deep, but also very narrow and domain-specific; frequently it is also very company-specific. Such knowledge is far less transferable than one might imagine." Agreed. It is the quickest way to become a 10x employee but unfortunately your current company won't give you a substantial raise for knowing their product and domain well and it is not transferable to other workplaces.
- the_af 12y ago
  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.
scotty79 12y ago
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 12y ago
  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 12y ago
    Yeah. What I said works for corporations. Start-ups tend to be as creative with ranks as with everything else.
  - x0x0 12y ago
    in your case, the right answer is, "k, good luck with that"

bubbleRefuge 12y ago

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 12y ago

Pair programming fixes the turnover problem

michaelfeathers 12y ago
It trades it for the problem: convince people to pair program.
sheepmullet 12y ago
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 12y ago
How is that related at all? (If my company forced us to pair program, I'd leave in a heartbeat.)

lucisferre 12y ago

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 12y ago
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 12y ago
> 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 12y ago
  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.