Who here is solo?
Who here is part of a team?
Who Am I?
Indianapolis, IN
Partner / Senior Developer, Reaktiv Studios
Design Palette Pro for Genesis
Formerly a solo developer
Formerly Enterprise Planning, Budgeting, Forecasting Systems at Deloitte
An agency that does custom WordPress development. We build some pretty cool stuff. We also sell plugins like Design Palette Pro for Genesis, which let's you style your Genesis site without having to know any code.
They say your first hire should be for support.
Why Do We Need to Talk about this?
Take devs, put them together, team!
Solo vs. Team are very different!
Gathering a bunch of solo devs and telling them to be a team isn't enough.
Working with other developers is HARD. But it's also really rewarding, as there's only so much you can do alone. WE celebrate what solo developers are able to do, but don't give much creedence to what a team can accomplish. At some point, you need to work with other people.
Possible Teams
Working at an agency / product team
Starting your own company
Subcontracting for an agency
Contributing to open source
As a solo dev you may already work in a team.
Joining a team
Let's say your a solo dev joining a team, what sort of things do you need to do to prepare?
Set Expectations
Letting go, put self in team mindset
People will be reading your code
You're going to have to communicate with people.
You will not see eye to eye on everything
Everyone has a different way of doing things
Patience, Respect, Kindness. Acceptance of criticism will go a long way
One negative comment can affect someone wanting to share code
Learn the Tools
Solo dev joining a team should be familiar with how these work. A team leader needs to know how to choose and set these up and configure processes and methodologies to use them effectively.
Learn Best Practices
Writing maintainable code.
Code Review.
How to best use those tools.
Structure
Solo Dev starting a project just goes.
Won't work in a team.
*Lead in* First thing you may think of when you think of structure...
First thing you may think of when you think of structure.
Memos, TPS reports
Structure != Bureaucracy
Structure means no one is stepping on anyone's toes or duplicating work
Consistency is key - code, docs, standards, etc.
Tools
Processes
Communication / Leadership
Tools / Processes
I don't use all of these today. Hoping to introduce these to you to help improve your teams.
Communication
Slack / HipChat / Hall / IRC...
Asana / Trello / BaseCamp...
Daily Standup
Learn how people communicate.
Will take some time and trial and error.
More people will need to contact you, use the appropriate methods.
Async vs Sync communication. Let go of async so you can still focus when in a team but be there for sync comm
Turn off notifications wherever possible
Code For The Maintainer
(or else!)
Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.
~ C2 Wiki, Code For The Maintainer
Code For The Maintainer
Self-documenting code
Comments
Abstraction / Code Reuse / Frameworks (Balance these!)
Comment (don't over-do it), and comment all hacks/tricks/clever code
Version Control
Git, Subversion, Mercurial. Command line or GUI
Not a panacea, must use correctly
Small, logical commits
Develop features in separate branches, merge often
Small, logical commits
Forces you to self-review every line of code
Separate Local and Staging servers
No cowboy coding. Works for solo, not in TEAMS.
Separate Local and Staging servers
Do push changes to a staging server
Don't edit code directly on production
Don't go straight from local to production
Run many of our staging servers on a simple shared hosting plan, if it will work there, it'll work on the better hosts.
Everyone has their own local copy, in sync
Local Development
Sync between team members
Vagrant / VVV
Document how to set up a local environment
Sync dev environments between team members
DEV should be as close to production as possible.
Issue Tracker
Github / Bitbucket (comes with your repo)
Redmine, FogBugz, Bugzilla
Use anything, just make sure it's centralized.
Automated Testing
PHPUnit / qUnit
WordPress Unit Tests
(Ever have code you're afraid to touch because you don't want to break anything?)
Makes refactoring a less scary situation.
Safeguards you against regressions.
Code Review / Pair Programming
Have not tried pair programming but willing to try it as it appears to improve code quality.
Automated Builds
Compile preprocessors
Run linters
Minify Assets
Package releases
Shouldn't just be one person on the team who can build the project.
Shouldn't be a list of manual steps to run.
Build system should be available for all team members, shouldn't depend on a manual process or for one person to be the only "releaser". Create a repeatable build system for packaging releases.
Example: Design Palette Pro, 3 version, 3 separate EDD products, all built from the same source with grunt
Deployment
Not going to spend too much time on this one. Instead of FTPing your changes up to your staging server and then to production, have an automated way to deploy the code to the servers. Eliminates human errors.
Teamwork!
Automate
Systematize
Be Kind
I don't have it all figured out. If you takeaway anything, take
Case Study: WordPress Core
Subversion
Trac
Unit Tests
Grunt
Travis CI
IRC Meetings
make.wordpress.org Blogs
THE END
BY Josh Eaton reaktivstudios.com josheaton.org