Finding a Partner Was Key For Us

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.

  • Love hearing how other teams work. It always inspires me to examine my own team's work-flow. Great post Brad.

  • I've really been digging the posts about these guys. I have a coding background, but haven't done it in some time and have some unique app models I want to start production on for fun. It would be cool just to see them gain some traction and posts like this definitely help me figure out who to lay out the tasks for anybody else I involve. Thanks

  • David L

    Just for feedback purposes–I was eagerly anticipating the next post in this series and was on the verge of an email onslaught demanding more. So, thanks!

  • I would happily travel to Boulder for the opportunity to interview Nate and Natty for StartupTrek.TV! What an awesome story. Or, perhaps i can catch them in Seattle sometime.

    Just the fact that *investment bankers* can teach themselves not only to become great coders; but also great entrepreneurs, is "front page of the WSJ" material, imho:)

    Very interesting storyline. And, as a self-taught coder myself… i'm taking notes.

    • Steve — glad you like our story! If you'd like to talk about doing an interview for, we'd be more than happy to do it — just email me at nate [at] everlater [dot] com.

  • Bradley

    These posts may not get into the nitty-gritty detail, but they are certainly helpful for those of us in a similar situation. Maybe some of it is intuitive to others, maybe some of it just comes through enough experience, but at least I know others of similar ilk go through similar pain and discovery. Thanks for this!

  • I think that the way you divide the workload is a good thing, you may work a bit slower than having both people that are just as good at both but you get a more focused result by dividing the work load.