3 ms·

> Coding the same thing over and over may mean stagnation, but projects that change tech leads that often are usually mess. Absolutely. > It takes time to get

by sidlls 9y ago

> Coding the same thing over and over may mean stagnation, but projects that change tech leads that often are usually mess. Absolutely. > It takes time to get up to speed to that position, it takes time to people around to adjust (handle related turf wars and what not), create relationships and all that political stuff. What you describe has value within an organization. These skills don't actually mean one is better at designing or implementing any software. They also don't necessarily transfer to another company. The people, political systems and bureaucracy at a given company aren't the same as at any other. > Nor does it allows you to see long term consequences of your decisions. True, but the way this industry works in most cases there is very little one can do about that after the fact. And, even if there were, it doesn't necessarily translate into having learned something. There's a reason it's common that it is hard to get time and resources to work on technical debt: it's because companies (generalizing here--exceptions exist) don't value what you describe.

watwut 9y ago
It means that if you was tech lead for two years and then for a year, I don't really want you for long term tech lead position here. Because you don't value nor see precisely things tech leads needs to do and be good at. Júst being good in architecture is not enough, through you need that too. Political and negotiation skills are transferable actually, you learn then with experience. Fine for coder though. As for your last point, we are in the middle of rather large refactoring. New people here are not trusted with refactoring, because they are not trusted as much. If you have track record not to underestimate difficulties, you are placed at positions that are assumed to require refactoring. The issue with refactoring is that many if not most refactoring attempts fail and leave system in even larger mess. That is why many managers are scared of it. Inexperienced highly confident person trying, unfinishing due to difficulties (whether technical or political) and then leaving mid job. Refactoring larger project where half the team is still learning and the other on the way out sounds like bad idea. Of course you need to change people to get new ideas in, but positions for stable and less stable people are different. Guess I am lucky with my current job.
- sidlls 9y ago
  > It means that if you was tech lead for two years and then for a year, I don't really want you for long term tech lead position here. Because you don't value nor see precisely things tech leads needs to do and be good at. Being tech lead on the same project for more than a year or two (or possibly longer for more complex systems) yields rapidly diminishing margins. Put it this way: other things being equal a person who was lead on the same project for 4 years has less added experience than a person who has been lead on two different projects for 2 years each. In fact, the second guy very likely has a much larger cumulative value, because he's carried two projects through and has the perspectives and experiences of having to make different tradeoffs. I'd rather have one of my tech lead reports leverage his skills learned from leading one project to leading a different one. Then he can draw on the experience of leading each in addition to having the ability to compare different experiences. That is is itself valuable experience, and positions him to grow even more.

by sidlls 9y ago

watwut 9y ago

It means that if you was tech lead for two years and then for a year, I don't really want you for long term tech lead position here. Because you don't value nor see precisely things tech leads needs to do and be good at. Júst being good in architecture is not enough, through you need that too. Political and negotiation skills are transferable actually, you learn then with experience. Fine for coder though. As for your last point, we are in the middle of rather large refactoring. New people here are not trusted with refactoring, because they are not trusted as much. If you have track record not to underestimate difficulties, you are placed at positions that are assumed to require refactoring. The issue with refactoring is that many if not most refactoring attempts fail and leave system in even larger mess. That is why many managers are scared of it. Inexperienced highly confident person trying, unfinishing due to difficulties (whether technical or political) and then leaving mid job. Refactoring larger project where half the team is still learning and the other on the way out sounds like bad idea. Of course you need to change people to get new ideas in, but positions for stable and less stable people are different. Guess I am lucky with my current job.

sidlls 9y ago
> It means that if you was tech lead for two years and then for a year, I don't really want you for long term tech lead position here. Because you don't value nor see precisely things tech leads needs to do and be good at. Being tech lead on the same project for more than a year or two (or possibly longer for more complex systems) yields rapidly diminishing margins. Put it this way: other things being equal a person who was lead on the same project for 4 years has less added experience than a person who has been lead on two different projects for 2 years each. In fact, the second guy very likely has a much larger cumulative value, because he's carried two projects through and has the perspectives and experiences of having to make different tradeoffs. I'd rather have one of my tech lead reports leverage his skills learned from leading one project to leading a different one. Then he can draw on the experience of leading each in addition to having the ability to compare different experiences. That is is itself valuable experience, and positions him to grow even more.