For example, Hack Reactor. Was thinking the purpose is to get basic understanding of programming and being able to speak the same language as the technical folks. Thoughts?
As a non-technical founder of a technical start-up you need to learn about technology. Coding bootcamp programs teach how to program. Being able to code (program) does not translate into an understanding of technology. I know of no bootcamp or academic program that teaches the theory and technology rather than the nuts and bolts of coding. Problem is deep understanding is hard while programming is relatively easy.
So, I kinda did this - I needed a developer for my startup but couldn't afford to pay one. So I learned myself, though I didn't use a bootcamp, just tried to build what I could and learn more from MOOC's like udemy or youtube channel or discord servers. As my startup grows my first hire is going to be a lead developer. (Whom I will probably have to give some equity when he sees how much of my code he is going to have to fix)
It's a tremendous advantage if you ask me, that I can speak in his language. Ideas are a lot easier to plan out and conceptualize.
If your product is purely software, yeah, learn to code some, but remember you are doing it as a means to an end. The moment you get a professional, hand the reins over, because that's not your main strength.
I think you are doing the right thing by browsing on HN. Read what developers are talking about, there's a fair amount of time I won't even understand what the title is talking about but every time I read it, it gives me an idea about what developers struggle with.
There's no checkbox for "is now a good communicator". It's a spectrum, you just have to keep learning.
A bootcamp is going to focus more on the day-to-day of how to code, and practicing coding. That isn't really what you need. You need to understand what coders do, but you don't need to get into algorithms or the syntax of any particular language or framework.
What you do need to know is how to prioritize. You need to understand that while everyone shares the goal of getting features out the door, some take longer than others. Some build upon others. Some block others. Coding Feature A today might be a 4 month effort, but coding smaller features X, Y, and Z, might build the foundation work the A needed... so you could get all 4 features out the door in 5 months by doing A last, and being ahead of the game in the long run even though you deferred the feature most important to you by the same amount of time it would have taken to just code it.
Making such decisions is less about knowing how to code, and more about understanding the different layers of technical architecture, how they integrate, and how they can both enable some components, while blocking and restricting others.
It is also about knowing your team. You don't need to be able to figure out all the answers yourself, but you do need to be able to communicate well with the senior devs who can give you those answers. And you need to figure out which devs are good at figuring out such things. We do not all share the same skills, and don't all look at software the same way. Get to know your team, and who has which strengths. Your decisions will be empowered far more by knowing the team, getting their input, and looking at the big picture of planning how to move a product forward than they would be by knowing how to code.
Only if you find it interesting or if its causing issues, otherwise its a waste of time. Be clear about what strengths you bring to the table and work on those. If you have a sales background for example hone that craft. Let the techies do the tech, the same way you let the lawyers do the legal stuff.
If you can afford a bootcamp, you’re better off hiring a senior developer and learning from immersion by seeing how they work. If you’re lucky you’ll find someone who is patient, and a good communicator who can spend an hour a day on screenshares with you explaining how things work.
7 comments
[ 4.2 ms ] story [ 30.5 ms ] threadIt's a tremendous advantage if you ask me, that I can speak in his language. Ideas are a lot easier to plan out and conceptualize.
If your product is purely software, yeah, learn to code some, but remember you are doing it as a means to an end. The moment you get a professional, hand the reins over, because that's not your main strength.
I think you are doing the right thing by browsing on HN. Read what developers are talking about, there's a fair amount of time I won't even understand what the title is talking about but every time I read it, it gives me an idea about what developers struggle with.
There's no checkbox for "is now a good communicator". It's a spectrum, you just have to keep learning.
What you do need to know is how to prioritize. You need to understand that while everyone shares the goal of getting features out the door, some take longer than others. Some build upon others. Some block others. Coding Feature A today might be a 4 month effort, but coding smaller features X, Y, and Z, might build the foundation work the A needed... so you could get all 4 features out the door in 5 months by doing A last, and being ahead of the game in the long run even though you deferred the feature most important to you by the same amount of time it would have taken to just code it.
Making such decisions is less about knowing how to code, and more about understanding the different layers of technical architecture, how they integrate, and how they can both enable some components, while blocking and restricting others.
It is also about knowing your team. You don't need to be able to figure out all the answers yourself, but you do need to be able to communicate well with the senior devs who can give you those answers. And you need to figure out which devs are good at figuring out such things. We do not all share the same skills, and don't all look at software the same way. Get to know your team, and who has which strengths. Your decisions will be empowered far more by knowing the team, getting their input, and looking at the big picture of planning how to move a product forward than they would be by knowing how to code.