4 ms·

This is, I think, a very relevant case for the "Non-technical co-founders need to learn to code" argument. There are always problems with judging how much work

This is, I think, a very relevant case for the "Non-technical co-founders need to learn to code" argument. There are always problems with judging how much work is being done in any creative project - heaven knows my best marketing work comes in spurts that tend to happen at 2 AM. But the larger issue here is that the guy issuing raises has no idea what is actually happening in the codebase. I'm by no means an incredible engineer, but I've spent a couple hours a day over the past few months building basic Ruby/RoR apps, and it makes an enormous difference. Of course, I still have a long way to go before I'm able to really estimate anything, but if nothing else I understand why my co-founder would just sit there for hours with a whiteboard and model data. I know that "burnout" is a real thing, especially when you're not overcoming little bugs you've had for a long time. I know the value of getting a second pair of eyeballs on some code. etc. It's just impossible to understand what you don't understand the technical aspects of what you're trying to do.

GrinningFool 13y ago
Actually, it's a very relevant case to keep non-technical co-founders as far away from the code as possible. Educate founders to entry-level coding skills (or below) and they will have entry-level abilities at estimating project technical scope and difficulty.
- ygra 13y ago
  Funnily enough, I have two bosses – one has a PhD in computer science and one in geology. The latter one usually is much easier to deal with and understands more of what's going on. This might in part be because the geologist (a) is in our office and doesn't just burst in every two weeks and (b) does at least a little scripting from time to time, while the other one didn't write a line of code in years.
greenyoda 13y ago
No, you don't need to be able to code to understand that the team that's working fewer hours is generating the same results. You only have to understand what the business needs are and how well they're being met per dollar that you spend. In the article's example, the manager needs to understand how well his two cable provisioning systems are meeting the needs of his customers. That has nothing to do with code. If a manager's only metric about how well his line of business is functioning is how much overtime his employees work, then learning to code will not make him any more competent. It's more likely that if the manager learns a little bit about coding, he'll think that everything his team does is easy (since he never tried to implement anything complex). Also he'll be more likely to be an annoying micromanager, since he'll think that he actually understands the complex issues that his team is grappling with.
- bsirkia 13y ago
  The issue here is that "does it work" isn't a good enough metric for code quality. If two engineers deliver code that accomplishes the same task, one might have made it readable, testable, scalable, etc. and the other just jammed it together to accomplish the desired result, the manager that can't read code won't know the difference. Yes, in the long term, the shortcut taking programmer's shortcuts will catch up to him (code will break, you can't add more people to work on his code, etc.), but it could be too late for the manager.
  - greenyoda 13y ago
    "the manager that can't read code won't know the difference" The manager that spent a month "learning to code" but never worked on a big project will think he knows the difference, but probably doesn't either.
    - rattray 13y ago
      Sure; but he or she might have a better idea than someone who doesn't know `=` from `==`, right? And do you really want to turn your best engineers into managers, when they'd be much happier and more productive building themselves? EDIT: Of course, I do agree with you. It's just worth keeping in mind that perfection can be hard to reach, at least in the conventional manager-evaluates-engineer format.
    - bsirkia 13y ago
      Right that's true, it does come down to the manager's level of expertise. I guess my point is that you need someone with a solid understanding of code to review their output, not just a manager evaluating "does it work", whether that reviewer is another senior engineer, the CTO, the technical co-founder, etc.
    - austenallred 13y ago
      You're right. I'm not saying "Hey, I spent a month and now I can tell my co-founder how it should be done" - the first couple months is just the beginning. But I feel like I can relate to/understand 10% of the process when before I could relate to 0%, and that's a big jump. I can see how it could get out of hand if I started questioning things I don't understand, beating my chest and saying "Don't tell me that, I know how to code," but now at least I can have a discussion with him without everything going over my head. It's difficult to explain how big of a difference that makes.
awkward 13y ago
You seem like you've learned the right lessons, but more often I've found that learning just enough to be dangerous makes managers worse at this. Take the example in the article, where the developer who made a well factored application was "overcomplicating" the code. It's not uncommon for a beginner who understands the means of programming but hasn't been bitten by the results of bad design to make poor decisions for the sake of experience that need to be made up in extra work later. Having a manager who actively encourages solutions like "Why not just copy the entire method and wrap it in an if statement?", or "Can't we just comment out the existing code that's incompatible with this new feature?" can be demoralizing - if they're in a position to actually make that happen, it's even worse.
elwell 13y ago
I don't think I want my co-founders to learn how to code (unless they were to become experts). It could complicate design/product choices.

GrinningFool 13y ago

Actually, it's a very relevant case to keep non-technical co-founders as far away from the code as possible. Educate founders to entry-level coding skills (or below) and they will have entry-level abilities at estimating project technical scope and difficulty.

ygra 13y ago
Funnily enough, I have two bosses – one has a PhD in computer science and one in geology. The latter one usually is much easier to deal with and understands more of what's going on. This might in part be because the geologist (a) is in our office and doesn't just burst in every two weeks and (b) does at least a little scripting from time to time, while the other one didn't write a line of code in years.

greenyoda 13y ago

No, you don't need to be able to code to understand that the team that's working fewer hours is generating the same results. You only have to understand what the business needs are and how well they're being met per dollar that you spend. In the article's example, the manager needs to understand how well his two cable provisioning systems are meeting the needs of his customers. That has nothing to do with code. If a manager's only metric about how well his line of business is functioning is how much overtime his employees work, then learning to code will not make him any more competent. It's more likely that if the manager learns a little bit about coding, he'll think that everything his team does is easy (since he never tried to implement anything complex). Also he'll be more likely to be an annoying micromanager, since he'll think that he actually understands the complex issues that his team is grappling with.

bsirkia 13y ago
The issue here is that "does it work" isn't a good enough metric for code quality. If two engineers deliver code that accomplishes the same task, one might have made it readable, testable, scalable, etc. and the other just jammed it together to accomplish the desired result, the manager that can't read code won't know the difference. Yes, in the long term, the shortcut taking programmer's shortcuts will catch up to him (code will break, you can't add more people to work on his code, etc.), but it could be too late for the manager.
- greenyoda 13y ago
  "the manager that can't read code won't know the difference" The manager that spent a month "learning to code" but never worked on a big project will think he knows the difference, but probably doesn't either.
  - rattray 13y ago
    Sure; but he or she might have a better idea than someone who doesn't know `=` from `==`, right? And do you really want to turn your best engineers into managers, when they'd be much happier and more productive building themselves? EDIT: Of course, I do agree with you. It's just worth keeping in mind that perfection can be hard to reach, at least in the conventional manager-evaluates-engineer format.
  - bsirkia 13y ago
    Right that's true, it does come down to the manager's level of expertise. I guess my point is that you need someone with a solid understanding of code to review their output, not just a manager evaluating "does it work", whether that reviewer is another senior engineer, the CTO, the technical co-founder, etc.
  - austenallred 13y ago
    You're right. I'm not saying "Hey, I spent a month and now I can tell my co-founder how it should be done" - the first couple months is just the beginning. But I feel like I can relate to/understand 10% of the process when before I could relate to 0%, and that's a big jump. I can see how it could get out of hand if I started questioning things I don't understand, beating my chest and saying "Don't tell me that, I know how to code," but now at least I can have a discussion with him without everything going over my head. It's difficult to explain how big of a difference that makes.

awkward 13y ago

You seem like you've learned the right lessons, but more often I've found that learning just enough to be dangerous makes managers worse at this. Take the example in the article, where the developer who made a well factored application was "overcomplicating" the code. It's not uncommon for a beginner who understands the means of programming but hasn't been bitten by the results of bad design to make poor decisions for the sake of experience that need to be made up in extra work later. Having a manager who actively encourages solutions like "Why not just copy the entire method and wrap it in an if statement?", or "Can't we just comment out the existing code that's incompatible with this new feature?" can be demoralizing - if they're in a position to actually make that happen, it's even worse.

elwell 13y ago

I don't think I want my co-founders to learn how to code (unless they were to become experts). It could complicate design/product choices.