5 ms·

Because what your boss does, day-to-day, is very different than what you do. So it seems natural that they'd need different skills. I'm a software engineer, a

Because what your boss does, day-to-day, is very different than what you do. So it seems natural that they'd need different skills. I'm a software engineer, and hiring managers has been a problem at every company I've worked at. You want someone who has written software earlier in their career, and has a degree in software engineering or similar. In other words, people who have chosen to spend a lot of time with computers -- devices that are very logical and literal. But you also want someone who has good people skills. In other words, someone who chooses to spend a lot of time organizing other people, maybe was on the yearbook club in high school, that sort of thing. And you don't want their knowledge of software construction to not be too out of date. So you want someone at a very specific point in their career, i.e. a few years after giving up coding.

christophilus 10y ago
In my experience, this part isn't true: "And you don't want their knowledge of software construction to not be too out of date." One of my best bosses was largely a C programmer (from back in the 80s). He'd still tinker with things from time to time, but I think the fundamental principles of software engineering haven't changed a whole lot since then. A software engineer who could have written a book like SCIP or Programming Pearls back in the day but were in management now, would probably make excellent managers.
- dahauns 10y ago
  > I think the fundamental principles of software engineering haven't changed a whole lot since then. Not sure I agree with that. A lot of todays best practices and workflows (and the tech to go with it), especially considering team and release management, simply weren't around or at least widespread even twenty years ago. You know, stuff like CI, TDD, DVCS etc. etc.
  - throwaway729 10y ago
    > CI, TDD, DVCS Are any of these concepts particularly difficult to understand for a seasoned developer? I have a really hard time imagining that a C and SVN expert couldn't learn how to use git "well enough" in an afternoon, and effectively within a few days, for example. In particular, the freaking author of git is an 80's C programmer and SVN expert...
    - 0xfeba 10y ago
      > In particular, the freaking author of git is an 80's C programmer and SVN expert... Uh, and you know, just the creator of the Linux kernel...
    - dahauns 10y ago
      > Are any of these concepts particularly difficult to understand for a seasoned developer? Depending on the personality of the developer: Absolutely. And most of the time it's not about the ability to understand, but the willingness to learn. Yeah, it's a cliché, the old fart, set in their ways, "get off my lawn!1". I know, I'm guilty of it myself sometimes . :) And it's one thing to learn some tech well enough to use it, and still another to grok the concepts and its ramifications, to actually get the whole picture of concepts, procedures and tools currently available to you, to be of help in higher-level planning and strategic decision-making. You know, all the stuff bosses are paid for. :)
  - dagw 10y ago
    A lot of todays best practices and workflows... Why does my boss have to know anything about that? The technical lead or senior developer(s) for each project should be the ones making decisions about those sorts of implementation details.
    - dahauns 10y ago
      Those aren't mere "implementation details". Those are aspects that influence the whole process, up to strategic decisions.
      - dagw 10y ago
        How do you figure? Why should my boss care about unit test frameworks and the relative merits of various TDD strategies. If he has some useful advice from previous projects then great. But otherwise, as long has we aren't having major problems, I don't expect him to interfere with those sorts of decisions. And if we are having major problems I expect him to sit the relevant people down and go "look, we're having too many regression bugs. Whatever you are doing with regards to testing isn't working, so let's come up with something better".
        dahauns 10y ago
        It's not about specific unit test frameworks or TDD strategies. It's about the fact that thirty years ago, for all intents and purposes, there was no such thing as "unit test frameworks" or "test driven development".
        dagw 10y ago
        It's about the fact that thirty years ago, for all intents and purposes, there was no such thing as "unit test frameworks" or "test driven development". Even if your boss has manged to get to today without even hearing about these concepts, hopefully there are other people on the team that have. And those people will decide on a testing strategy for the project. If your boss understand the details of that decision or not is isn't that important. What's important is that he lets the best people in room make the decision. Now if your boss decides to override and ignore those people, then that can be a problem, but that is problem due to a lack of managerial and people skills, not a problem due to a lack of technical skills.
  - randcraw 10y ago
    As a S/W dev who started 30 years ago and finished his MSCS 27 years ago, I totally agree - S/W engineering (SWE) today is NOTHING like it was in the 1980s. SWE then was seen as mainstream CS and often a required part of a CS degree. Today, CS profs working in SWE are rara aves. SWE's desiderata then was to become an engineering process, where components were marshalled into a formal blueprint, and only THEN did implementation begin. And when implementatione ended, only THEN did testing begin. And only pro TESTERs do the testing. And only pro librarians did the project configuring and building and SCCS control and S/W maintenance and releasing. Much of today's SWE is subsumed by the choice of programming tools, esp the language: its innate constraints its object model, its hierarchical library interdependence, and the sundry constraints & guidelines these impose. In 1985 there was a LOT of discussion of how to introduce more proscriptive programming models as ways to shape how programmers think and design and implement. Today most of that discussion is moot, since most prog. languages implicitly enforce most of that (implementation) proscription. And where voids exist (as in design), language convention and idiom (and community bias) tend to step in to constrain choice to shape thought and close the loop. No, I think SWE has changed enormously since the antedeluvian world views that wrought the invention of Ada or Beck's first writing on Agility. Perhaps for S/W devs under age ~50, who grew up in the mature world of OOPLs, unit testing, and 'Agile uber alles', that form of SWE seems to be inviolate and have existed since time began, perhaps discovered on clay tablets in an ancient Ark. But no...
    - Apocryphon 10y ago
      Sounds like the approach then was waterfall. If only we could apply the level of rigor and professionalism you describe to Agile...
    - battlebot 10y ago
      That process was too heavy for most business needs and far too expensive as a result. It could never last. I do think developers were more respected back then. Today, developers, like all non-managerial (and to a lesser extent HR) people are completely fungible. For various reasons, we let our expertise be commodified. And as a result, we cheapened the entire field. The way to get it back is thus: No non-developers ever manages a developer. This is how doctors keep their scam going.
IndianAstronaut 10y ago
One of the VPs at my prevoous companies used to sit in on our quarterly hackathons and build something. Made him a fantastic and well regarded engineering manager.

christophilus 10y ago

In my experience, this part isn't true: "And you don't want their knowledge of software construction to not be too out of date." One of my best bosses was largely a C programmer (from back in the 80s). He'd still tinker with things from time to time, but I think the fundamental principles of software engineering haven't changed a whole lot since then. A software engineer who could have written a book like SCIP or Programming Pearls back in the day but were in management now, would probably make excellent managers.

dahauns 10y ago
> I think the fundamental principles of software engineering haven't changed a whole lot since then. Not sure I agree with that. A lot of todays best practices and workflows (and the tech to go with it), especially considering team and release management, simply weren't around or at least widespread even twenty years ago. You know, stuff like CI, TDD, DVCS etc. etc.
- throwaway729 10y ago
  > CI, TDD, DVCS Are any of these concepts particularly difficult to understand for a seasoned developer? I have a really hard time imagining that a C and SVN expert couldn't learn how to use git "well enough" in an afternoon, and effectively within a few days, for example. In particular, the freaking author of git is an 80's C programmer and SVN expert...
  - 0xfeba 10y ago
    > In particular, the freaking author of git is an 80's C programmer and SVN expert... Uh, and you know, just the creator of the Linux kernel...
  - dahauns 10y ago
    > Are any of these concepts particularly difficult to understand for a seasoned developer? Depending on the personality of the developer: Absolutely. And most of the time it's not about the ability to understand, but the willingness to learn. Yeah, it's a cliché, the old fart, set in their ways, "get off my lawn!1". I know, I'm guilty of it myself sometimes . :) And it's one thing to learn some tech well enough to use it, and still another to grok the concepts and its ramifications, to actually get the whole picture of concepts, procedures and tools currently available to you, to be of help in higher-level planning and strategic decision-making. You know, all the stuff bosses are paid for. :)
- dagw 10y ago
  A lot of todays best practices and workflows... Why does my boss have to know anything about that? The technical lead or senior developer(s) for each project should be the ones making decisions about those sorts of implementation details.
  - dahauns 10y ago
    Those aren't mere "implementation details". Those are aspects that influence the whole process, up to strategic decisions.
    - dagw 10y ago
      How do you figure? Why should my boss care about unit test frameworks and the relative merits of various TDD strategies. If he has some useful advice from previous projects then great. But otherwise, as long has we aren't having major problems, I don't expect him to interfere with those sorts of decisions. And if we are having major problems I expect him to sit the relevant people down and go "look, we're having too many regression bugs. Whatever you are doing with regards to testing isn't working, so let's come up with something better".
      - dahauns 10y ago
        It's not about specific unit test frameworks or TDD strategies. It's about the fact that thirty years ago, for all intents and purposes, there was no such thing as "unit test frameworks" or "test driven development".
        dagw 10y ago
        It's about the fact that thirty years ago, for all intents and purposes, there was no such thing as "unit test frameworks" or "test driven development". Even if your boss has manged to get to today without even hearing about these concepts, hopefully there are other people on the team that have. And those people will decide on a testing strategy for the project. If your boss understand the details of that decision or not is isn't that important. What's important is that he lets the best people in room make the decision. Now if your boss decides to override and ignore those people, then that can be a problem, but that is problem due to a lack of managerial and people skills, not a problem due to a lack of technical skills.
- randcraw 10y ago
  As a S/W dev who started 30 years ago and finished his MSCS 27 years ago, I totally agree - S/W engineering (SWE) today is NOTHING like it was in the 1980s. SWE then was seen as mainstream CS and often a required part of a CS degree. Today, CS profs working in SWE are rara aves. SWE's desiderata then was to become an engineering process, where components were marshalled into a formal blueprint, and only THEN did implementation begin. And when implementatione ended, only THEN did testing begin. And only pro TESTERs do the testing. And only pro librarians did the project configuring and building and SCCS control and S/W maintenance and releasing. Much of today's SWE is subsumed by the choice of programming tools, esp the language: its innate constraints its object model, its hierarchical library interdependence, and the sundry constraints & guidelines these impose. In 1985 there was a LOT of discussion of how to introduce more proscriptive programming models as ways to shape how programmers think and design and implement. Today most of that discussion is moot, since most prog. languages implicitly enforce most of that (implementation) proscription. And where voids exist (as in design), language convention and idiom (and community bias) tend to step in to constrain choice to shape thought and close the loop. No, I think SWE has changed enormously since the antedeluvian world views that wrought the invention of Ada or Beck's first writing on Agility. Perhaps for S/W devs under age ~50, who grew up in the mature world of OOPLs, unit testing, and 'Agile uber alles', that form of SWE seems to be inviolate and have existed since time began, perhaps discovered on clay tablets in an ancient Ark. But no...
  - Apocryphon 10y ago
    Sounds like the approach then was waterfall. If only we could apply the level of rigor and professionalism you describe to Agile...
  - battlebot 10y ago
    That process was too heavy for most business needs and far too expensive as a result. It could never last. I do think developers were more respected back then. Today, developers, like all non-managerial (and to a lesser extent HR) people are completely fungible. For various reasons, we let our expertise be commodified. And as a result, we cheapened the entire field. The way to get it back is thus: No non-developers ever manages a developer. This is how doctors keep their scam going.

IndianAstronaut 10y ago

One of the VPs at my prevoous companies used to sit in on our quarterly hackathons and build something. Made him a fantastic and well regarded engineering manager.