I know it’s been a few weeks since my last Nate and Natty / Everlater post on learning to program. I’ve gotten a few notes asking for more – expect a couple of posts over the next few days. In the mean time, here’s Nate’s view on how to divide tasks between partners – in this case him and Natty.
Having good systems in place around your coding is just as important as the coding itself. Natty and I spent a huge chunk of our time figuring out a great workflow that would allow us to program more effectively, and we think it’s paid huge dividends over the lifespan of Everlater.
The first and most important decision we made was to work together and divide the tasks we had to learn in half. I (Nate) took most of the backend server tasks — everything from SysAdmin stuff to Ruby/Rails and a good chunk of the javascript that interacted with the server too, and Natty took everything that appears to the user — everything from learning Photoshop/Illustrator to HTML/CSS and quite a bit of javascript as well.
Nothing too special about our division of labor, but it bears worth repeating that this worked well because we worked so closely together to make sure that the other person still had an idea about what was going on. I needed to know the basic structures of the HTML Natty was creating so I could work on the javascript, and Natty needed to know a good deal of Ruby for creating and displaying the content coming out of the database. We’ve worked on how we pass work back and forth, and while I believe it’s pretty personal, having some basic workflow where you have several stages of planning, we do something like this:
- Mock up the pages super roughly with pen and paper and figure out the different database models
- Do Photoshop mockups and build the routes and models
- Actually build the pages in HTML/CSS and build out the controller actions associated with each view
- Finishing touches (usually javascript), and testing
At each point in the process Natty and I would sit down and talk about how it was going, and implement our side of the task. It bears repeating that this is also a highly personal part of learning how to program. The following worked very well for Natty and I but other people might be better off pair programming the whole thing, work at completely different speeds, etc. The most important thing is thinking about the workflow in general and making sure it’s a conscious decision rather than something that just happens.