New to WIP?
We're a group of makers shipping together. We help each other stay accountable and reach our goals.
Apply for access
Topics
Back
Question
Who to follow or hire to learn better software development processes?
I tought myself Python. My original background is in marketing. For coding there are a ton of great resources out there and many qualified freelancers to learn from.
However, I have a tougher time finding resources to learn better software related management. How to learn how to structure a development team, who to hire for what, which technologies to use. Of course, you can do learning by doing. However, I already got a successful business and it would be a poor use of my time to do all beginner mistakes myself. This is a very general question. But would be interested in what your thoughts are, how to get better in those things. Can you recommend resources? Would it make sense to hire somebody in kind of a coach / consultant position? And where to find such a person? Tried on UpWork, but the people who applied there didnt seem a good fit.
However, I have a tougher time finding resources to learn better software related management. How to learn how to structure a development team, who to hire for what, which technologies to use. Of course, you can do learning by doing. However, I already got a successful business and it would be a poor use of my time to do all beginner mistakes myself. This is a very general question. But would be interested in what your thoughts are, how to get better in those things. Can you recommend resources? Would it make sense to hire somebody in kind of a coach / consultant position? And where to find such a person? Tried on UpWork, but the people who applied there didnt seem a good fit.
👋 Join WIP to participate
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.
I've been developing for 2/3rds of my life, but still had a bit of a revelation when I saw SOLID and TDD together click into place properly.
I'm not sure how to incite this revelation in other people. I had nearly a decade of people talking about dependency inversion and unit/integration/systems tests and it just kind of washed over me. If there was a way to get these interlocking concepts across to people reliably, it would revolutionise software engineering.
It might be good to just go to the source and read the GoF book.