I don't personally know anyone who would feel like they aren't unique or special enough because they had to learn some new tech as part of a team. That said, we do specialize a little--I'm a JavaScript specialist, and my team also includes a CSS specialist, a .NET specialist, and a Product Manager. The point is that we try to avoid a situation where any one person has domain-specific knowledge that nobody else has. In other words, my team lead is much better at .NET than I am, but between me and a couple of other devs, we know as much about the company's .NET codebase as he does. In rare cases we may choose to divide tasks based on specialty--especially if we're in a hurry--but the Dev Design process ensures that whoever takes a task knows how it should be done, with plenty of input from the specialist for that scenario.
And, of course, this means that any of us can go on vacation for a week or two without leaving the team incapacitated.
As far as technical debt goes, you're right that it's one of the easiest ways to speed up delivery. We've definitely cut our share of corners in the short-term in order to meet contract obligations. But we carve out time to go back and refactor--in fact, we demand it--and the time it takes is not usually an issue because:
Well-architected code is much easier and faster to build on. We are able to move far more quickly now because we took the time to refactor early on.
Technical debt-laden code is a breeding ground for bugs that are difficult to diagnose and resolve. By paying it down, we reduce our future workload.
So I believe that refactoring genuinely saves time in the medium- and long-term, and I'm lucky enough to work for a company that has the funding to think beyond the here and now. On top of that, I like to do it because I'm so much happier at work when I'm working with code that is smart and solid. Again, I don't personally know anyone who's reluctant to take part in refactoring, but maybe I've just been extraordinarily lucky in terms of who I work with.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Those are great questions.
I don't personally know anyone who would feel like they aren't unique or special enough because they had to learn some new tech as part of a team. That said, we do specialize a little--I'm a JavaScript specialist, and my team also includes a CSS specialist, a .NET specialist, and a Product Manager. The point is that we try to avoid a situation where any one person has domain-specific knowledge that nobody else has. In other words, my team lead is much better at .NET than I am, but between me and a couple of other devs, we know as much about the company's .NET codebase as he does. In rare cases we may choose to divide tasks based on specialty--especially if we're in a hurry--but the Dev Design process ensures that whoever takes a task knows how it should be done, with plenty of input from the specialist for that scenario.
And, of course, this means that any of us can go on vacation for a week or two without leaving the team incapacitated.
As far as technical debt goes, you're right that it's one of the easiest ways to speed up delivery. We've definitely cut our share of corners in the short-term in order to meet contract obligations. But we carve out time to go back and refactor--in fact, we demand it--and the time it takes is not usually an issue because:
Well-architected code is much easier and faster to build on. We are able to move far more quickly now because we took the time to refactor early on.
Technical debt-laden code is a breeding ground for bugs that are difficult to diagnose and resolve. By paying it down, we reduce our future workload.
So I believe that refactoring genuinely saves time in the medium- and long-term, and I'm lucky enough to work for a company that has the funding to think beyond the here and now. On top of that, I like to do it because I'm so much happier at work when I'm working with code that is smart and solid. Again, I don't personally know anyone who's reluctant to take part in refactoring, but maybe I've just been extraordinarily lucky in terms of who I work with.