Downloaded 21 times
Uploaded byMichael Eaton
(Best) Practices for the Solo Developer
Michael Eaton, owner of Validus Solutions, shares best practices for solo developers based on his extensive experience in software development and consulting. Key recommendations include using source control, writing tests, maintaining task and time tracking, and engaging in social networks and user groups for collaboration. His contact information and resources are also provided for further insights.
More Related Content
Similar to (Best) Practices for the Solo Developer
(Best) Practices for the Solo Developer
- 1. (BEST) PRACTICES OF THESOLO DEVELOPER Michael Eaton Validus Solutions, LLC. @mjeaton
- 2. Who is MichaelEaton? • Owner / Validus Solutions, LLC • Custom Software Development / Training / Coaching • Speaker • C# MVP, MCSD • Kalamazoo X Conference lead organizer • Ann Arbor Give Camp organizer • mjeaton@validussolutions.com • Blog: http://mjeaton.net/blog • Twitter: @mjeaton
- 3. History • 1994 to1995 – Worked remotely on a team of 6 or 7. Worked in a silo. • 1996 – Sole developer for small, custom dev shop • 1997 to 2000 – Worked on a team of 5. Best team EVER. • 2000 to 2001 – Project Director/Team Lead for mid-size consulting firm. Led several project teams. • 2001 to early 2006 – Independent consultant – worked mostly alone, but did contribute to a couple project teams during that time. • 2006 (roughly 9 months) – Tried my hand at working for “The Man” again. Worked on a small dev team. • 2006 to Now – Independent consultant. Work mostly alone, but one of my projects has me on a team of 5 “local” developers + an offshore contingent.
- 4. “A team ofone is never wrong” – Tim Wingfield, 2011
- 5. Considerations • Get hitby a bus • Get sick • Get fired • Quit • Someone else joins the team
- 6.
- 7. Always use sourcecode control • It’s not about sharing code with others, it’s about security • A folder on your drive is NOT good enough • Dropbox is NOT good enough • External, when possible • Github • Bitbucket • Commit early, commit often
- 8. Write tests • Testsgive you: • Confidence in your code • Safety net when changes come • Documentation • Potentially saves time
- 9. Continuous Integration • Movebuilds and deployment from your personal computer • Isolated from day-to-day changes to your system
- 10. Get virtual (machines) •Allows custom environments • Gives you a safety net if your laptop (or work computer) dies unexpectedly
- 11.
- 12. Track your tasks •Keep it simple, but keep your task list somewhere other than in your head • I <3 AgileZen and my moleskine and my whiteboard and my phone and my Kindle Fire and RememberTheMilk
- 13. Track your time •Be able to account for all your time, even if you’re not a “billable asset” • Harvest • Timesnapper
- 14.
- 15.
- 16. Social Networks • Themore people you know, the more you know
- 17. User Groups /Conferences • The more people you know, the more you know
- 18. Blogs • Run intoa problem? Blog about it! • Figure out how to solve a complex problem? Blog about it!
- 19. “It's easier toask forgiveness than it is to get permission.” – Grace Hopper
- 20. Contact Info • Email:mjeaton@validussolutions.com • Blog: http://mjeaton.net/blog • Twitter: @mjeaton • LinkedIn: http://www.linkedin.com/in/mjeaton
Editor's Notes
- #4 I have been a self-employed software developer since 2001, but have been developing software since 1994. I tend to focus on Microsoft tools and technologies where possible but I’m also a big believer in using the best tool for the job. I am a C# MVP. The MVP is an award from Microsoft for contributing to the software development community. The MVP is pretty cool in that it gives me access to a lot of cool people as well as ton of great software.I head up the Kalamazoo X Conference – this is a 1-day, single-track conference that’s devoted to many of the non-technical areas that developers are historically bad at doing – things like interpersonal skills, design and architecture. Check us out at kalamazoox.org.I also head up the Ann Arbor Give Camp.Here is my contact information if you have ay questions or comments about what we discuss today, or if you just want to keep in touch. During the course of the session, several other independent developers will be in and out of the room to help me answer questions and to provide you with other perspectives on the topics presented.We’ll wrap up the session with a panel discussion where you can ask us about things not covered during the rest of the session. My friend Dave Giard will be facilitating that discussion.
- #5 1994 to 1995 – Worked remotely on a team of 6 or 7. Worked in a silo.1996 – Sole developer for small, custom dev shop1997 to 2000 – Worked on a team of 5. Best team EVER.2000 to 2001 – Project Director/Team Lead for mid-size consulting firm. Led several project teams.2001 to early 2006 – Independent consultant – worked mostly alone, but did contribute to a couple project teams during that time.2006 (roughly 9 months) – Tried my hand at working for “The Man” again. Worked on a small dev team.2006 to Now – Independent consultant. Work mostly alone, but one of my projects has me on a team of 5 “local” developers + an offshore contingent.
- #7 Get hit by a busGet sickGet firedQuitSomeone else joins the team
- #9 It’s not about sharing code with others, it’s about securityA folder on your drive is NOT good enoughDropbox is NOT good enoughExternal, when possibleGithubBitbucketCommit early, commit often
- #10 Tests give you:Confidence in your codeSafety net when changes comeDocumentationPotentially saves time
- #11 Move builds and deployment from your personal computerIsolated from day-to-day changes to your system
- #12 Allows custom environmentsGives you a safety net if your laptop (or work computer) dies unexpectedly
- #14 Keep it simple, but keep your task list somewhere other than in your headI <3 AgileZen and my moleskine and my whiteboard and my phone and my Kindle Fire and RememberTheMilk
- #15 Be able to account for all your time, even if you’re not a “billable asset”HarvestTimesnapper
- #16 Focus, focus, focus
- #18 The more people you know, the more you know
- #19 The more people you know, the more you know
- #20 Run into a problem? Blog about it!Figure out how to solve a complex problem? Blog about it!