5 ms·

Not to mention, for most engineering jobs, the onboarding/training process is long and expensive. Generally I think an engineer has negative productivity within

by ruler88 10y ago

Not to mention, for most engineering jobs, the onboarding/training process is long and expensive. Generally I think an engineer has negative productivity within the first 3 months of employment. So if an employer is willing to put down so much effort upfront for you to work there, you better to willing to work 100%.

jchrisa 10y ago
I hear this perspective but in my experience hiring people who've been pushing an open source project forward already, it can be more like unleashing a coiled spring. They'll bring code and question the culture in productive ways.
Yokohiii 10y ago
This is a very valid point. But what stops both parties to agree on 40h weeks during onboarding phase and then shift to the reduced work time?
flukus 10y ago
Not sure about engineering in general, but I find places that expect 3 months for a programmer to become productive are a huge red flag. A programmer should be able to checkout, build, run in minutes and then to start fixing bugs on day 1.
- hibikir 10y ago
  Companies often feel that they are moving fast when they are setting up huge tech debt pits and building custom infra that will be hard to learn quickly. Then they wonder why they are not being successful with all the new hires, given how productive the old timers are. Welcome to the midsized, pre IPO startup.
- asveikau 10y ago
  Building, running, and nominally fixing bugs (are you tracking regressions well?) is not always the same as being productive. It's important to not treat the work as fungible units that go from developer to developer equally, without accounting for getting used to the code base, problem space, etc.
  - flukus 10y ago
    I wouldn't expect them to be as productive, or anywhere close to it. But IME a 3 month ramp up time is usually a sign of too much complexity for individuals to deal with. Usually from technical debt or too broad an area of responsibility.
- Retra 10y ago
  I'm 6 months into my current job and I'm still 60% useless to them. And a couple other people have already been moved out of this position because they couldn't hack it.
  - flukus 10y ago
    What is it making you/them 60% useless? Tech debt? Responsibility?
- PhasmaFelis 10y ago
  > A programmer should be able to checkout, build, run in minutes and then to start fixing bugs on day 1. I have never met a programmer who could do that. I'm sure some of them can, in specific domains. But I'd consider expecting that to be a huge red flag: I've worked at exactly one place that expected a day 1 hire to match their veteran coders, and I wouldn't work there again.
  - flukus 10y ago
    To be clear, I wouldn't expect them to match the veterans, or even to fix anything, but they should be able to get started on a simple issue given decent reproduction steps. My main objection was that there shouldn't be 3 months of negative or near zero productivity. Or there should at least be a good reason for it.
    - wastedhours 10y ago
      Whilst being helpful is one thing, if you can't afford to give people a proper amount of time to bed in (3 months doesn't seem unreasonable), then you might hurt your chances of retention going forwards as well - depending on the size of the org of course, but there's plenty of places where to really understand the business needs to make informed decisions, it takes a long time. If you fail that step, then staying for any reasonable amount of time becomes untenable.
  - joncrocks 10y ago
    I'd note that this could be seen as much as a statement about the organisation one is moving into as to the skill of the programmer involved. i.e. If it takes someone 3 months to be productive, there's probably something wrong with the build system/documentation, or code organisation/structure (+ comments, or lack of), lots of knowledge in people's heads etc.
- dingaling 10y ago
  I would not ever permit a new programmer near production code on day 1, let alone fix a bug. That ramp up period involves learning the subtleties of the business, inter-team dynamics and processes. The first bug I ever fixed resulted in costs for the company. My mentor had left the company within a week of me starting and I waded into the code with good intentions, but put us out of compliance with regulations.
  - flukus 10y ago
    > I would not ever permit a new programmer near production code on day 1, let alone fix a bug. You wouldn't let them check out and run the code? The business processes etc all have to be learned of course, but the code is where most of the time should be spent. > The first bug I ever fixed resulted in costs for the company. My mentor had left the company within a week of me starting and I waded into the code with good intentions, but put us out of compliance with regulations. I would consider that a failure of the company, too many responsibilities are pushed down to the developer. If there are strict compliance regulations then there should have been some sort of QA process and/or a domain expert validating the results.
    - hueving 10y ago
      >I would consider that a failure of the company, too many responsibilities are pushed down to the developer. If there are strict compliance regulations then there should have been some sort of QA process and/or a domain expert validating the results. This is detached room reality. There arent many jobs (other than junior level programmer) where you just churn out code without actually having to think about the requirements, use cases, security, etc. Having responsibilities is a very common thing as a software engineer.
      - flukus 10y ago
        Yes there are a lot of things you have to think about, as well as a lot of domain knowledge to pick up. But expecting the developers to act as the domain experts is also detached from reality. I've never worked with anyone who I would consider a domain expert that also keeps up to date on a technical level.
kriro 10y ago
Negative productivity for 3 months seems like a very conservative estimation. Most places I know have people commit to the code base pretty early. Quite often the onboarding process already has them commit small stuff. You might say...well they are only doing small things like fixing minor bugs but that's a minor bug a more experienced developer doesn't have to fix. If you also assume that people strengthen their own understanding of a topic if they teach it new engineers don't drain resources if they ask other developers questions. They might make your other workers more productive in the long run. At the very least I'd argue that the time other devs spend on onboarding isn't wasted 100%. I suppose the dynamics change if you hire fairly bad people who make things worse with their early commits but that mostly means your hiring process (and most likely your code review or whatever measure you set up to prevent bad code) is broken.
- olau 10y ago
  You are forgetting the time other members of the team are spending explaining things.
- sotojuan 10y ago
  I'm guessing it depends on the company... at my last place (small startup so makes sense) I was expected to be productive the first week and actually got in trouble for looking at non-work stuff every now and then :p Meanwhile some of my friends at large companies "train" for weeks. Pretty interesting difference.
- sheepmullet 10y ago
  > If you also assume that people strengthen their own understanding of a topic if they teach it new engineers don't drain resources In practice I've found this assumption is only true if you have very small growth/turnover. I.e. If you hire a new engineer once every couple of years it's probably the case, but if you hire a new engineer every few months it isn't. On average I'd say we have our senior engineers spend 40-50 hours total in the first month teaching/helping a new senior dev. Probably a similar number of hours in the second month, and then it drops to maybe 10 hours/month for the next year. From what I have seen a new senior dev is around 10% of the productivity of a existing senior dev for the first month, 20% for the second, and rapidly reaching 80% by the end of a year. So they are at 1 unit/hour of productivity for the first month and add 160 units of productivity for the month. However, senior devs, at a cost of 10 units/hr, have spent 40-50 hours helping them at a cost of 400-500 units of productivity. Second month they add 320 units but cost another 400-500. By the third month they add maybe 450 units and only cost 100 units. And at this point they have managed to pretty much break even. Of course if you assume training costs are not a real cost but rather beneficial for your existing senior devs then the new senior dev looks productive from the first month. But then you are really just talking past each other.
hacknat 10y ago
I disagree with this so much. I'm not saying there isn't some onboarding cost, but with experienced engineers its a lot less than you think. At worst you should be "breaking even" with a Senior Engineer almost immediately. When I look back at what I've done for the company I just started with 7 months ago, I completed a highly valuable, and large project for them in the first 3 months. I could probably get the same project done a lot faster now than I did then, but that doesn't mean it wasn't worth it to the company.

by ruler88 10y ago

jchrisa 10y ago

I hear this perspective but in my experience hiring people who've been pushing an open source project forward already, it can be more like unleashing a coiled spring. They'll bring code and question the culture in productive ways.

Yokohiii 10y ago

This is a very valid point. But what stops both parties to agree on 40h weeks during onboarding phase and then shift to the reduced work time?

flukus 10y ago

Not sure about engineering in general, but I find places that expect 3 months for a programmer to become productive are a huge red flag. A programmer should be able to checkout, build, run in minutes and then to start fixing bugs on day 1.

hibikir 10y ago
Companies often feel that they are moving fast when they are setting up huge tech debt pits and building custom infra that will be hard to learn quickly. Then they wonder why they are not being successful with all the new hires, given how productive the old timers are. Welcome to the midsized, pre IPO startup.
asveikau 10y ago
Building, running, and nominally fixing bugs (are you tracking regressions well?) is not always the same as being productive. It's important to not treat the work as fungible units that go from developer to developer equally, without accounting for getting used to the code base, problem space, etc.
- flukus 10y ago
  I wouldn't expect them to be as productive, or anywhere close to it. But IME a 3 month ramp up time is usually a sign of too much complexity for individuals to deal with. Usually from technical debt or too broad an area of responsibility.
Retra 10y ago
I'm 6 months into my current job and I'm still 60% useless to them. And a couple other people have already been moved out of this position because they couldn't hack it.
- flukus 10y ago
  What is it making you/them 60% useless? Tech debt? Responsibility?
PhasmaFelis 10y ago
> A programmer should be able to checkout, build, run in minutes and then to start fixing bugs on day 1. I have never met a programmer who could do that. I'm sure some of them can, in specific domains. But I'd consider expecting that to be a huge red flag: I've worked at exactly one place that expected a day 1 hire to match their veteran coders, and I wouldn't work there again.
- flukus 10y ago
  To be clear, I wouldn't expect them to match the veterans, or even to fix anything, but they should be able to get started on a simple issue given decent reproduction steps. My main objection was that there shouldn't be 3 months of negative or near zero productivity. Or there should at least be a good reason for it.
  - wastedhours 10y ago
    Whilst being helpful is one thing, if you can't afford to give people a proper amount of time to bed in (3 months doesn't seem unreasonable), then you might hurt your chances of retention going forwards as well - depending on the size of the org of course, but there's plenty of places where to really understand the business needs to make informed decisions, it takes a long time. If you fail that step, then staying for any reasonable amount of time becomes untenable.
- joncrocks 10y ago
  I'd note that this could be seen as much as a statement about the organisation one is moving into as to the skill of the programmer involved. i.e. If it takes someone 3 months to be productive, there's probably something wrong with the build system/documentation, or code organisation/structure (+ comments, or lack of), lots of knowledge in people's heads etc.
dingaling 10y ago
I would not ever permit a new programmer near production code on day 1, let alone fix a bug. That ramp up period involves learning the subtleties of the business, inter-team dynamics and processes. The first bug I ever fixed resulted in costs for the company. My mentor had left the company within a week of me starting and I waded into the code with good intentions, but put us out of compliance with regulations.
- flukus 10y ago
  > I would not ever permit a new programmer near production code on day 1, let alone fix a bug. You wouldn't let them check out and run the code? The business processes etc all have to be learned of course, but the code is where most of the time should be spent. > The first bug I ever fixed resulted in costs for the company. My mentor had left the company within a week of me starting and I waded into the code with good intentions, but put us out of compliance with regulations. I would consider that a failure of the company, too many responsibilities are pushed down to the developer. If there are strict compliance regulations then there should have been some sort of QA process and/or a domain expert validating the results.
  - hueving 10y ago
    >I would consider that a failure of the company, too many responsibilities are pushed down to the developer. If there are strict compliance regulations then there should have been some sort of QA process and/or a domain expert validating the results. This is detached room reality. There arent many jobs (other than junior level programmer) where you just churn out code without actually having to think about the requirements, use cases, security, etc. Having responsibilities is a very common thing as a software engineer.
    - flukus 10y ago
      Yes there are a lot of things you have to think about, as well as a lot of domain knowledge to pick up. But expecting the developers to act as the domain experts is also detached from reality. I've never worked with anyone who I would consider a domain expert that also keeps up to date on a technical level.

kriro 10y ago

Negative productivity for 3 months seems like a very conservative estimation. Most places I know have people commit to the code base pretty early. Quite often the onboarding process already has them commit small stuff. You might say...well they are only doing small things like fixing minor bugs but that's a minor bug a more experienced developer doesn't have to fix. If you also assume that people strengthen their own understanding of a topic if they teach it new engineers don't drain resources if they ask other developers questions. They might make your other workers more productive in the long run. At the very least I'd argue that the time other devs spend on onboarding isn't wasted 100%. I suppose the dynamics change if you hire fairly bad people who make things worse with their early commits but that mostly means your hiring process (and most likely your code review or whatever measure you set up to prevent bad code) is broken.

olau 10y ago
You are forgetting the time other members of the team are spending explaining things.
sotojuan 10y ago
I'm guessing it depends on the company... at my last place (small startup so makes sense) I was expected to be productive the first week and actually got in trouble for looking at non-work stuff every now and then :p Meanwhile some of my friends at large companies "train" for weeks. Pretty interesting difference.
sheepmullet 10y ago
> If you also assume that people strengthen their own understanding of a topic if they teach it new engineers don't drain resources In practice I've found this assumption is only true if you have very small growth/turnover. I.e. If you hire a new engineer once every couple of years it's probably the case, but if you hire a new engineer every few months it isn't. On average I'd say we have our senior engineers spend 40-50 hours total in the first month teaching/helping a new senior dev. Probably a similar number of hours in the second month, and then it drops to maybe 10 hours/month for the next year. From what I have seen a new senior dev is around 10% of the productivity of a existing senior dev for the first month, 20% for the second, and rapidly reaching 80% by the end of a year. So they are at 1 unit/hour of productivity for the first month and add 160 units of productivity for the month. However, senior devs, at a cost of 10 units/hr, have spent 40-50 hours helping them at a cost of 400-500 units of productivity. Second month they add 320 units but cost another 400-500. By the third month they add maybe 450 units and only cost 100 units. And at this point they have managed to pretty much break even. Of course if you assume training costs are not a real cost but rather beneficial for your existing senior devs then the new senior dev looks productive from the first month. But then you are really just talking past each other.

hacknat 10y ago

I disagree with this so much. I'm not saying there isn't some onboarding cost, but with experienced engineers its a lot less than you think. At worst you should be "breaking even" with a Senior Engineer almost immediately. When I look back at what I've done for the company I just started with 7 months ago, I completed a highly valuable, and large project for them in the first 3 months. I could probably get the same project done a lot faster now than I did then, but that doesn't mean it wasn't worth it to the company.