5 ms·

I don't quite agree with that. Specialization is a good thing, but having managers and coders seems too much specialization. It leads to the situation where a m

by nawitus 13y ago

I don't quite agree with that. Specialization is a good thing, but having managers and coders seems too much specialization. It leads to the situation where a manager could fix something small in the same time he communicates someone to fix it. Or situations where the manager slowly loses touch with technology. It's not likely someone will "understand" programming over the years without doing it constantly. And over time the manager's value to the team withers away. I like this idea that there are no managers who manage and engineers who engineer. Instead, there's maybe one person who takes the responsibility of managing work, but does programming or other non-managing work the rest of the time. The engineers can also do a bit of managing, but they'll focus on the engineering. The assumption is of course, that managing work can be automated away sufficiently and the team is a not huge. These are realistic assumptions, but are often untrue because of organizatonal flaws (or flaws with the manager). The baseball coach argument doesn't really fit here, because baseball is not reinvented every 5 years. Programming quite often is. A C++ systems programmer probably can't understand much about HTML5 frontend programming. But a manager with C++ background can learn.

edwinnathaniel 13y ago
It is rarely the fix is "something small" when you have dev-manager leading the team of 5. The actual fix might be small (changing one line), but the real effort to: 1) Make sure there's unit-test, integration-test 2) Make sure nothing breaks 3) Maybe test the deployment script 4) Maybe test the database migration is rather involved. If the dev-manager knows all of these steps then sure, why not. But that's like saying that QA should be able to do the same thing too (after all, QA should be a little bit more technical and more in-depth than the dev-manager). While these are nice, I rarely see them work like that. I'm not against it, but I just don't think that there is "simple fix" when a dev-manager present (because it implies the size of the project and the size of the software).
- drdeadringer 13y ago
  I am reminded of a chart of sorts that described "what the software engineer forgot" when describing how long a task would take. "Oh that's 5 minutes." You forgot logging in, powering on the computer, searching for the particular lines of code, a quick test that the fix didn't break anything, and then [if applicable] shunting over to version control.
- nawitus 13y ago
  Well, I didn't say that every project and every change is something small. I said that there's a subset of changes that are sufficiently small and don't even require new tests (like some small stylesheet change). I think it's rather strange to claim that small fixes don't exist at all.
  - Kluny 13y ago
    Even a stylesheet change could require the dev manager to pull down a local copy of the site, get it running locally, make the change, then push it - that could take days if something goes wrong. For an engineer who already has a local working copy, it really is a quick change. Of course, it would be very quick if he simply edited the live code - but I, for one, would have some very stern words for a manager who thought he could get away with doing that.
    - nawitus 13y ago
      I think the assumption is that a manager who codes occasionally has the dev environment running.
peterwwillis 13y ago
> It leads to the situation where a manager could fix something small in the same time he communicates someone to fix it And when you have 50 small things? Or when the one small thing turns out to have been bigger than you thought, and you waste time trying to do the work that the engineers are probably more familiar with because one of them has been working on the same thing for months? Or when you have managing to do? > Or situations where the manager slowly loses touch with technology This is what design reviews are for. > It's not likely someone will "understand" programming over the years without doing it constantly I don't necessarily ride bikes over the years. But I understand it well enough to look at a bike and see how it works, or tell someone else where to go and how to ride it. > Instead, there's maybe one person who takes the responsibility of managing work, Like a manager? > but does programming or other non-managing work the rest of the time What 'rest of the time'? You mean when they're not fulfilling the first obligation you gave to them, which is managing work? > The engineers can also do a bit of managing, but they'll focus on the engineering. Why not just let them focus on the engineering? Why give them extra crap to do when somebody else was already tasked with managing the work? > The assumption is of course, that managing work can be automated away sufficiently You can't automate managing work. That's why it's called "management". Because you have to do work to manage it. > and the team is a not huge. These are realistic assumptions, but are often untrue because of organizatonal flaws (or flaws with the manager). Or because the organization is just big and the workload is high. > baseball is not reinvented every 5 years. Programming quite often is. Programming has not been "reinvented" in the last 40 years. It's pretty much the same, with some languages and tools re-addressing the same issues that were seen decades ago. Programming evolves, but so far it has never changed so much that an old programmer can't figure out what's going on with a new language or tool or system after looking at it for a while. When you're a manager, you don't sit in an ivory tower and stick your fingers in your ears and expect to know what the hell is going on. You are constantly reading documentation released from teams within the company and become aware of changes between releases, hopefully well before they come into effect. You can even set up and maintain a development environment to run unit tests to verify your application works, reviewing build reports, and so on. I think the reason so many people underestimate what takes up a manager's time is mostly they're people who never learned how to be a manager; they're often glorified team leads with the privilege to fire someone. It does a disservice to the people who have skills that don't apply to programming.

by nawitus 13y ago

edwinnathaniel 13y ago

It is rarely the fix is "something small" when you have dev-manager leading the team of 5. The actual fix might be small (changing one line), but the real effort to: 1) Make sure there's unit-test, integration-test 2) Make sure nothing breaks 3) Maybe test the deployment script 4) Maybe test the database migration is rather involved. If the dev-manager knows all of these steps then sure, why not. But that's like saying that QA should be able to do the same thing too (after all, QA should be a little bit more technical and more in-depth than the dev-manager). While these are nice, I rarely see them work like that. I'm not against it, but I just don't think that there is "simple fix" when a dev-manager present (because it implies the size of the project and the size of the software).

drdeadringer 13y ago
I am reminded of a chart of sorts that described "what the software engineer forgot" when describing how long a task would take. "Oh that's 5 minutes." You forgot logging in, powering on the computer, searching for the particular lines of code, a quick test that the fix didn't break anything, and then [if applicable] shunting over to version control.
nawitus 13y ago
Well, I didn't say that every project and every change is something small. I said that there's a subset of changes that are sufficiently small and don't even require new tests (like some small stylesheet change). I think it's rather strange to claim that small fixes don't exist at all.
- Kluny 13y ago
  Even a stylesheet change could require the dev manager to pull down a local copy of the site, get it running locally, make the change, then push it - that could take days if something goes wrong. For an engineer who already has a local working copy, it really is a quick change. Of course, it would be very quick if he simply edited the live code - but I, for one, would have some very stern words for a manager who thought he could get away with doing that.
  - nawitus 13y ago
    I think the assumption is that a manager who codes occasionally has the dev environment running.

peterwwillis 13y ago

> It leads to the situation where a manager could fix something small in the same time he communicates someone to fix it And when you have 50 small things? Or when the one small thing turns out to have been bigger than you thought, and you waste time trying to do the work that the engineers are probably more familiar with because one of them has been working on the same thing for months? Or when you have managing to do? > Or situations where the manager slowly loses touch with technology This is what design reviews are for. > It's not likely someone will "understand" programming over the years without doing it constantly I don't necessarily ride bikes over the years. But I understand it well enough to look at a bike and see how it works, or tell someone else where to go and how to ride it. > Instead, there's maybe one person who takes the responsibility of managing work, Like a manager? > but does programming or other non-managing work the rest of the time What 'rest of the time'? You mean when they're not fulfilling the first obligation you gave to them, which is managing work? > The engineers can also do a bit of managing, but they'll focus on the engineering. Why not just let them focus on the engineering? Why give them extra crap to do when somebody else was already tasked with managing the work? > The assumption is of course, that managing work can be automated away sufficiently You can't automate managing work. That's why it's called "management". Because you have to do work to manage it. > and the team is a not huge. These are realistic assumptions, but are often untrue because of organizatonal flaws (or flaws with the manager). Or because the organization is just big and the workload is high. > baseball is not reinvented every 5 years. Programming quite often is. Programming has not been "reinvented" in the last 40 years. It's pretty much the same, with some languages and tools re-addressing the same issues that were seen decades ago. Programming evolves, but so far it has never changed so much that an old programmer can't figure out what's going on with a new language or tool or system after looking at it for a while. When you're a manager, you don't sit in an ivory tower and stick your fingers in your ears and expect to know what the hell is going on. You are constantly reading documentation released from teams within the company and become aware of changes between releases, hopefully well before they come into effect. You can even set up and maintain a development environment to run unit tests to verify your application works, reviewing build reports, and so on. I think the reason so many people underestimate what takes up a manager's time is mostly they're people who never learned how to be a manager; they're often glorified team leads with the privilege to fire someone. It does a disservice to the people who have skills that don't apply to programming.