In my day job, I work for a company that provides technical coaching services. This question is right up my alley.
It's one thing to learn how to program, but it's an entirely different thing to learn how to do it well. I think that could be said of many things.
Sites like roadmap.sh do an excellent job of showing the path towards learning how to code, but they stop at how to run a software project with a team.
The primary goal should be to organize your project in such a manner that by adding more developers, it doesn't interrupt the flow of building your product. Start day one pretending like it's not just you writing the code. Think about future people who will try and pick up what you're doing.
You should write automated tests that validate your product. Every commit to Git should cause these tests to run and let you know if your product is broken. This is called continuous integration (CI). CI is a more significant subject we could talk more about at a different time.
Production deployments should be automated. This is typically called continuous deployment (CD). This will involve learning about Git branching strategies, writing automated tests, database migrations, etc. Once you have this setup, then your team can get into a flow in which they're just focusing on your product.
In my opinion, the best team size is either 2 OR 4 developers. It's a whole other subject we can talk about later if you'd like.
Make sure you're getting developers who've worked in a team before, and somehow test if they're good product owners. Maybe ask them how they'd improve on your product or even just another product they know a lot about.
The technology doesn't matter as long as it's popular in your geographical area (if you're not hiring remote workers). Otherwise, just let the team pick the tools they enjoy. Happy developers can crank out products like nobody's business.
I believe this could be talked about quite a bit more. If you'd like to talk more about this, then please feel free to reach out to me directly on Telegram.
I am not sure how to write you on Telegram. Just signed up for wip and never used Telegram before (installed it already though).
What is the coaching company you are referring to?
I definitely have it on my to-do list to set up unit tests, though its a bit tricky with my product as its computer vision based and uses real-time input. But I could at least start setting it up for some parts of the software.
In my day job, I work for a company that provides technical coaching services. This question is right up my alley.
It's one thing to learn how to program, but it's an entirely different thing to learn how to do it well. I think that could be said of many things.
Sites like roadmap.sh do an excellent job of showing the path towards learning how to code, but they stop at how to run a software project with a team.
The primary goal should be to organize your project in such a manner that by adding more developers, it doesn't interrupt the flow of building your product. Start day one pretending like it's not just you writing the code. Think about future people who will try and pick up what you're doing.
You should write automated tests that validate your product. Every commit to Git should cause these tests to run and let you know if your product is broken. This is called continuous integration (CI). CI is a more significant subject we could talk more about at a different time.
Production deployments should be automated. This is typically called continuous deployment (CD). This will involve learning about Git branching strategies, writing automated tests, database migrations, etc. Once you have this setup, then your team can get into a flow in which they're just focusing on your product.
In my opinion, the best team size is either 2 OR 4 developers. It's a whole other subject we can talk about later if you'd like.
Make sure you're getting developers who've worked in a team before, and somehow test if they're good product owners. Maybe ask them how they'd improve on your product or even just another product they know a lot about.
The technology doesn't matter as long as it's popular in your geographical area (if you're not hiring remote workers). Otherwise, just let the team pick the tools they enjoy. Happy developers can crank out products like nobody's business.
I believe this could be talked about quite a bit more. If you'd like to talk more about this, then please feel free to reach out to me directly on Telegram.
Hey Cody,
I am not sure how to write you on Telegram. Just signed up for wip and never used Telegram before (installed it already though).
What is the coaching company you are referring to?
I definitely have it on my to-do list to set up unit tests, though its a bit tricky with my product as its computer vision based and uses real-time input. But I could at least start setting it up for some parts of the software.