That's actually not a bad answer, I think. Along with david927's comment this could be setting someone down the right path.
I think it's a good answer because understanding what they are and how they relate to each other through the stack is good knowledge to have. They're the building blocks of everything that gets done. Not understanding that, at minimum, is no different than having a CFO of a manufacturing company that has no idea what SolidWorks is or why things need to be welded together (or even what a weld is!).
I wouldn't guide people away from learning to code, unless they didn't really want to do it. Unless you really, really want to learn, don't. You'll waste your time and the result won't be nearly as good as spending time on something that would be more useful.
Don't learn any of that! Non-technical founders shouldn't focus on becoming semi-hacks. That won't really help anyone.
There are many technical founders, like me, who have interesting technology and a unique viewpoint, but who can't package it and proposition it to the right people.
That's what you can bring to the table:
- Figure out who might be avid users and target them.
- Figure out which facets of the technology shine most brightly and get the focus on that.
There are many, many things you can do to add infinite value, but learning Rails is not one of them.
If you want to learn anything on a technical level, learn about big-O bounds on runtimes. This will give you an understanding of why some things can't realistically be done by machines. You don't need to hack things together, but you should be able to talk coherently with your tech founders about issues.
I find an exchange like the following hard to imagine:
Technical Cofounder: We can't realistically do <foo> because it'd have to process a huge amount of data and it'd take way too long.
Ignorant Non-technical Cofounder: I don't believe you! You're just a dumb programmer.
Enlightened Non-technical Cofounder: Oh, you're right. I can see that it's O(n^2).
My advice, for what it's worth, is to find a technical cofounder you trust, and then give him the benefit of the doubt on any features he says are unimplementable.
Learn the actual principals and practices behind engineering before forcing the company to adopt your vision of it. Learn how not to hire non-devs or fake devs to dev manager positions.
8 comments
[ 3.6 ms ] story [ 23.4 ms ] threadI think it's a good answer because understanding what they are and how they relate to each other through the stack is good knowledge to have. They're the building blocks of everything that gets done. Not understanding that, at minimum, is no different than having a CFO of a manufacturing company that has no idea what SolidWorks is or why things need to be welded together (or even what a weld is!).
I wouldn't guide people away from learning to code, unless they didn't really want to do it. Unless you really, really want to learn, don't. You'll waste your time and the result won't be nearly as good as spending time on something that would be more useful.
There are many technical founders, like me, who have interesting technology and a unique viewpoint, but who can't package it and proposition it to the right people.
That's what you can bring to the table:
- Figure out who might be avid users and target them.
- Figure out which facets of the technology shine most brightly and get the focus on that.
There are many, many things you can do to add infinite value, but learning Rails is not one of them.
Technical Cofounder: We can't realistically do <foo> because it'd have to process a huge amount of data and it'd take way too long.
Ignorant Non-technical Cofounder: I don't believe you! You're just a dumb programmer.
Enlightened Non-technical Cofounder: Oh, you're right. I can see that it's O(n^2).
My advice, for what it's worth, is to find a technical cofounder you trust, and then give him the benefit of the doubt on any features he says are unimplementable.
It is a realistic target for noobs.
Instead, (if the business is web-based,) I'd suggest SEO.