3 ms·

+1 on this. If you learn enough to do a bad job building your prototype, you will learn what you don't know. Right now you don't even know what you don't know

+1 on this. If you learn enough to do a bad job building your prototype, you will learn what you don't know. Right now you don't even know what you don't know. Also, you can't hire someone for a job you know nothing about. Doing (even a poor) job on your prototype will teach you to evaluate a technical co-founder.

Tyrannosaurs 16y ago
That's one scenario. The other is you muddle through, learn a bit and do an OK job pulling together the prototype. Sure it doesn't look exactly right but you can log in, see some records, make some updates and it's all fine in demos and pitches - hell you've even stuck it on the web for friends to poke and prod. You now think it's all straight forward and you're nearly there. The whole this isn't secure, is held together with sticky tape, updates aren't transactional so when something does go wrong the data is left in a mess, it has no error handling or referential integrity and won't scale beyond half a dozen users which is all it's ever had to put up with as a prototype but you've only been coding for six months so you hardly understand that these problems even exist let alone understand what's involved in solving them. Personally I really really don't want to be the tech lead who has to then deal with someone who knows way less than they think and is being told that the thing needs to be rewritten and by doing so is not only delivering bad news but is also having to criticise the persons own personal work. Some CEOs will benefit from this sort of knowledge, others will be damaged by it - there is no simple rule.
- TWAndrews 16y ago
  <i>Some CEOs will benefit from this sort of knowledge, others will be damaged by it - there is no simple rule.</i> Sure, but that's a pretty good test as to whether or not you should work for them.
  - Tyrannosaurs 16y ago
    I see that as an startlingly programmer-centric view of the world. I've worked with some great CEOs and not one of them could code or had any interest in coding. In no instance I have ever experienced have I looked at a CEO, good or bad and thought, the best thing you could do for this company would be to spend six months learning to code. A good CEO shouldn't have to have every skill used by their organisation and I don't see how coding is any different to accounting, legal, sales or any other skills in this respect. The mark of a good CEO is to be able to build good teams, be trusting enough to let them do the work they need to and smart enough to see when the wool is being pulled over their eyes. If you need to be able to code to trust your developers, you've either got the wrong developers or a trust problem, neither of which are likely to be solved by programming.
    - jtheory 16y ago
      You're missing the point here, I think, which is that if a founder (not the same thing as a CEO necessarily...) puts a few months into learning the basics of coding and attempting to build a rough prototype, they may end up: 1) with a greater appreciation of the talent/experience required for good development, a better BS detector arond technical issues, and a stronger understanding of what they don't know OR 2) a false impression that proof-of-concept = product and an over-inflated idea of what they've learned. I definitely agree that founder #2 here is someone to be avoided. Not because either one of them would be expected to contribute to the actual development, but because founder #2 is showing flaws of perception, ego, etc. that are serious red flags, and will affect their execution of non-development tasks.

Tyrannosaurs 16y ago

That's one scenario. The other is you muddle through, learn a bit and do an OK job pulling together the prototype. Sure it doesn't look exactly right but you can log in, see some records, make some updates and it's all fine in demos and pitches - hell you've even stuck it on the web for friends to poke and prod. You now think it's all straight forward and you're nearly there. The whole this isn't secure, is held together with sticky tape, updates aren't transactional so when something does go wrong the data is left in a mess, it has no error handling or referential integrity and won't scale beyond half a dozen users which is all it's ever had to put up with as a prototype but you've only been coding for six months so you hardly understand that these problems even exist let alone understand what's involved in solving them. Personally I really really don't want to be the tech lead who has to then deal with someone who knows way less than they think and is being told that the thing needs to be rewritten and by doing so is not only delivering bad news but is also having to criticise the persons own personal work. Some CEOs will benefit from this sort of knowledge, others will be damaged by it - there is no simple rule.

TWAndrews 16y ago
<i>Some CEOs will benefit from this sort of knowledge, others will be damaged by it - there is no simple rule.</i> Sure, but that's a pretty good test as to whether or not you should work for them.
- Tyrannosaurs 16y ago
  I see that as an startlingly programmer-centric view of the world. I've worked with some great CEOs and not one of them could code or had any interest in coding. In no instance I have ever experienced have I looked at a CEO, good or bad and thought, the best thing you could do for this company would be to spend six months learning to code. A good CEO shouldn't have to have every skill used by their organisation and I don't see how coding is any different to accounting, legal, sales or any other skills in this respect. The mark of a good CEO is to be able to build good teams, be trusting enough to let them do the work they need to and smart enough to see when the wool is being pulled over their eyes. If you need to be able to code to trust your developers, you've either got the wrong developers or a trust problem, neither of which are likely to be solved by programming.
  - jtheory 16y ago
    You're missing the point here, I think, which is that if a founder (not the same thing as a CEO necessarily...) puts a few months into learning the basics of coding and attempting to build a rough prototype, they may end up: 1) with a greater appreciation of the talent/experience required for good development, a better BS detector arond technical issues, and a stronger understanding of what they don't know OR 2) a false impression that proof-of-concept = product and an over-inflated idea of what they've learned. I definitely agree that founder #2 here is someone to be avoided. Not because either one of them would be expected to contribute to the actual development, but because founder #2 is showing flaws of perception, ego, etc. that are serious red flags, and will affect their execution of non-development tasks.