As a non-technical founder, should I enroll in a coding bootcamp?
1–8 of 8 posts
Re: As a non-technical founder, should I enroll in a coding bootcamp?
#2Re: As a non-technical founder, should I enroll in a coding bootcamp?
#3Re: As a non-technical founder, should I enroll in a coding bootcamp?
#4Re: As a non-technical founder, should I enroll in a coding bootcamp?
#5It'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.
Re: As a non-technical founder, should I enroll in a coding bootcamp?
#6What 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.