5 ms·

Learning is great. It expands horizons, potential, and current capabilities. Learning is not producing though. Learning is a cost center. If you want to increas

Learning is great. It expands horizons, potential, and current capabilities. Learning is not producing though. Learning is a cost center. If you want to increase productivity start by minimizing required learning. That exchange is called usability.

gentleman11 5y ago
Interesting phrasing, I like it. But you can also reduce the cost by making learning easier, whether with good interfaces or naming, or just good docs
creshal 5y ago
> Learning is not producing though. Learning is a cost center. Spoken like a true MBA. > If you want to increase productivity start by minimizing required learning. Deciding your tech stack solely on avoiding having to train people for a few days sounds like a terrible way to organise projects. Is your employee churn so bad that you can't afford even this little familiarisation?
- austincheney 5y ago
  There are two fundamental practical problems with your thinking. 1. Employers don’t train on languages/frameworks. In most circumstances employees are expected to learn on their own or from a prior employer before applying for a job. Worse, the last place I interviewed only asked about learning from the current employer while never asking about self learning outside the office. 2. Employees, in many cases, believe they can cheat learning by using a tool or framework. That is largely due to a lack of boundaries and experience in a given environment or platform resulting in low trust of peers and the technology. If you want to require learning then provide sufficient learning material expecting a predefined structured outcome.
  - creshal 5y ago
    We are training our employees. Learning the ropes of a new language/framework enough to make easy changes is trivial, so why wouldn't we? Much better than crippling our choices in software stacks we can use.
- Silhouette 5y ago
  Deciding your tech stack solely on avoiding having to train people for a few days sounds like a terrible way to organise projects. How often is it really only a few days, though? If you're talking about learning a different programming language, that's no small thing for a junior developer. For a senior who knows multiple languages already and has a few years of experience, learning the new language itself might only take a matter of days to be productive, as long as it's still a similar style of programming to something they've done before. But then you need to find your way around the ecosystem so you can make informed decisions, and that ecosystem might be huge and mostly low-quality, even if the good parts that you eventually want to use are not. For similar reasons, in the case of web development specifically, I think people often have unreasonably high expectations from using JS/TS both front and back. Yes, it's the same language, more or less. Yes, sharing code can sometimes be useful. But the JS standard library is limited, and the ecosystem beyond that has almost nothing in common on the front and back ends. In practice, assuming you have some decent senior devs on your team, that ecosystem jump is still likely to be the biggest time sink even if you're running something in Node on the server. So I kind of agree with both the parent and GP comments. It is beneficial to use familiar tools and reduce the need to learn new things before you can be productive, but you are going to have to learn new things sometimes anyway and that might require significant time no matter what you decide to do. When it comes to making fundamental architectural decisions for a new project, it's wise to keep the potential costs of using new things in mind, but it's foolish to disqualify choices that might be better in the long term because of small differences in up-front costs.
  - creshal 5y ago
    > How often is it really only a few days, though? Depends entirely on what you expect the devs to do, naturally. Junior devs are IMO not supposed to make informed decisions of significance in any language, that's what you have senior devs for. GP's use case of having frontend devs do small changes to backends and vice versa to avoid having to wait for The Other Team to have time, is very easily covered with really minimal training.
    - Silhouette 5y ago

gentleman11 5y ago

Interesting phrasing, I like it. But you can also reduce the cost by making learning easier, whether with good interfaces or naming, or just good docs

creshal 5y ago

> Learning is not producing though. Learning is a cost center. Spoken like a true MBA. > If you want to increase productivity start by minimizing required learning. Deciding your tech stack solely on avoiding having to train people for a few days sounds like a terrible way to organise projects. Is your employee churn so bad that you can't afford even this little familiarisation?

austincheney 5y ago
There are two fundamental practical problems with your thinking. 1. Employers don’t train on languages/frameworks. In most circumstances employees are expected to learn on their own or from a prior employer before applying for a job. Worse, the last place I interviewed only asked about learning from the current employer while never asking about self learning outside the office. 2. Employees, in many cases, believe they can cheat learning by using a tool or framework. That is largely due to a lack of boundaries and experience in a given environment or platform resulting in low trust of peers and the technology. If you want to require learning then provide sufficient learning material expecting a predefined structured outcome.
- creshal 5y ago
  We are training our employees. Learning the ropes of a new language/framework enough to make easy changes is trivial, so why wouldn't we? Much better than crippling our choices in software stacks we can use.
Silhouette 5y ago
Deciding your tech stack solely on avoiding having to train people for a few days sounds like a terrible way to organise projects. How often is it really only a few days, though? If you're talking about learning a different programming language, that's no small thing for a junior developer. For a senior who knows multiple languages already and has a few years of experience, learning the new language itself might only take a matter of days to be productive, as long as it's still a similar style of programming to something they've done before. But then you need to find your way around the ecosystem so you can make informed decisions, and that ecosystem might be huge and mostly low-quality, even if the good parts that you eventually want to use are not. For similar reasons, in the case of web development specifically, I think people often have unreasonably high expectations from using JS/TS both front and back. Yes, it's the same language, more or less. Yes, sharing code can sometimes be useful. But the JS standard library is limited, and the ecosystem beyond that has almost nothing in common on the front and back ends. In practice, assuming you have some decent senior devs on your team, that ecosystem jump is still likely to be the biggest time sink even if you're running something in Node on the server. So I kind of agree with both the parent and GP comments. It is beneficial to use familiar tools and reduce the need to learn new things before you can be productive, but you are going to have to learn new things sometimes anyway and that might require significant time no matter what you decide to do. When it comes to making fundamental architectural decisions for a new project, it's wise to keep the potential costs of using new things in mind, but it's foolish to disqualify choices that might be better in the long term because of small differences in up-front costs.
- creshal 5y ago
  > How often is it really only a few days, though? Depends entirely on what you expect the devs to do, naturally. Junior devs are IMO not supposed to make informed decisions of significance in any language, that's what you have senior devs for. GP's use case of having frontend devs do small changes to backends and vice versa to avoid having to wait for The Other Team to have time, is very easily covered with really minimal training.
  - Silhouette 5y ago