3 ms·

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 busine

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.

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.