3 ms·

> meaning things break easily, testing is low, or where maintenance or new dev is difficult - is a genuine business problem. The solution to that is engineering

> meaning things break easily, testing is low, or where maintenance or new dev is difficult - is a genuine business problem. The solution to that is engineering managers that can make a persuasive case to non-technical people for why something needs to be done a different way At an engineering company management up to the board should all be engineers. Then, these conversations become much easier, since things that break (and a pattern of repeated failures for the same thing) should be obvious to any real engineer. > But as a founder and an active software engineer, far too often "technical debt" is used by programmers to advanced their personal preferences, which may not be aligned with the businesses in any way. That's often a comp problem. Are your engineer's incentives aligned with the company (via stock options for instance)? If not, it's probably better for them to refactor your product to use whatever tech is pushed by the place they want to jump ship to (for a better comp package of course). > using a mono repo (again, zero business problems caused) Mono repos have a lot of advantages (most notably that it makes cross-component changes atomic). There's a reason Google adopted that model. > using any number of 3rd party libraries (vs the developers desire to build from scratch) Keep in mind there's a hidden cost to any third party dependency, especially if you have to modify it but your patches won't make it upstream.

Xylakant 4y ago
> At an engineering company management up to the board should all be engineers. > Then, these conversations become much easier, since things that break (and a pattern of repeated failures for the same thing) should be obvious to any real engineer. This is a fallacy that I often observe in engineers. We believe that our work is the one that brings value and all decisions should be made by people that do what we do. We also believe, that non-tech folks cannot understand what we try to explain. I also very often observe that many engineers have no idea of basic concepts that are required to run a business (and often, no interest to learn about them). Opportunity costs for example: We could pay down this tech debt, but what else could we do with the same money. We all love shining codebases over everything else, because it makes our work easier. But finance folks have other priorities - and balancing those priorities is one of the core tasks that management has. Placing only tech folks in management is unlikely to produce balanced results.
- 908B64B197 4y ago
  > This is a fallacy that I often observe in engineers. We believe that our work is the one that brings value and all decisions should be made by people that do what we do. And yet it does. At least, at tech companies. > We also believe, that non-tech folks cannot understand what we try to explain. I also very often observe that many engineers have no idea of basic concepts that are required to run a business (and often, no interest to learn about them). That's a very good point. However, my observation over the years is that great engineers can pick up business concepts (it's often a requirement to graduate anyways) but non-technical managers can't generally master engineering to the same degree.

Xylakant 4y ago

> At an engineering company management up to the board should all be engineers. > Then, these conversations become much easier, since things that break (and a pattern of repeated failures for the same thing) should be obvious to any real engineer. This is a fallacy that I often observe in engineers. We believe that our work is the one that brings value and all decisions should be made by people that do what we do. We also believe, that non-tech folks cannot understand what we try to explain. I also very often observe that many engineers have no idea of basic concepts that are required to run a business (and often, no interest to learn about them). Opportunity costs for example: We could pay down this tech debt, but what else could we do with the same money. We all love shining codebases over everything else, because it makes our work easier. But finance folks have other priorities - and balancing those priorities is one of the core tasks that management has. Placing only tech folks in management is unlikely to produce balanced results.

908B64B197 4y ago
> This is a fallacy that I often observe in engineers. We believe that our work is the one that brings value and all decisions should be made by people that do what we do. And yet it does. At least, at tech companies. > We also believe, that non-tech folks cannot understand what we try to explain. I also very often observe that many engineers have no idea of basic concepts that are required to run a business (and often, no interest to learn about them). That's a very good point. However, my observation over the years is that great engineers can pick up business concepts (it's often a requirement to graduate anyways) but non-technical managers can't generally master engineering to the same degree.