After spending the last 6 hours catching up on Build & Analyze podcasts (one of the few podcasts that I never miss an episode of), I'm compelled to write down some thoughts on the development philosophies that were discussed.
I listen to the show for one reason: when Marco talks about certain development topics, I find myself utterly riveted by his logical reasoning. It's obvious that he thinks critically on every problem so when he talks about one of these topics in detail, like how he scales Instapaper, he starts with providing enough background for everyone to understand the problem. Then he proceeds to systematically deconstruct the problem and describe the available solutions. After he states which one he chose, he walks you through his solution and the way he arrived at that solution. I've found it to be very helpful for improving my own problem solving skills.
Now onto the topics I've come across through Build & Analyze or Marco's blog that I think are contrary to the industry standards for development teams.
Create the optimal, productive development environment
In a recent episode, Dan and Marco discussed the different ways to setup an office for a development team and some of the tips they had for people to be productive in those environments. They talked about wearing headphones to block out audible distractions or making sure your desk isn't pointed towards the door as you'll be momentarily interrupted every time someone walks in and you instinctively look to see who it is. These are two good tips, but the general theme is eliminating distractions so you're able to focus for longer periods of time.
Here's the thing: at a start-up, the only thing that matters is results. Unlike bigger companies, you don't have to worry about office politics, insane HR requests (I wasn't allowed to wear headphones when I worked at Toyota), or bureaucratic policies that make it harder for you to do your job. Start-ups are meritocracies. If you're twice as productive in a coffee shop then you are in the office, then work there. If you code best at night, then re-arrange your schedule to put the bulk of your work hours in those late night time slots. Ultimately, your bosses will know whether you're producing or not and if you really are more productive in certain environments than others, than make the change and prove yourself. As long as you can balance your team's responsibilities (team meetings, bug fixes, etc.) then it's best for the team and the company for you to utilize your hours in the most efficient way possible.
Whatever works best for you
Marco actually has a post on this very topic. In it he states this:
You should use whatever works for you. And I no longer have the patience or hubris to convince you what that should be. All I can offer is one data point: what I use, and how it works for me.
We have a similar policy at thredUP, whatever development setup that works best for you works best for us. In a very similar vein to the previous topic, we want you to be working with whatever will deliver the best results and make you happy while you're doing it. The reality is that you're going to spend the majority of your time in the year (excluding sleep) with your work computer. It's very important that your computer, desk, chair, keyboard, etc. is just the way you want it because when you're not working with your optimal setup, you're adding friction to your ability to stay on-task and be productive.
Work life balance is very important
From a work/life balance post on Marco's blog:
I never let a job prevent me from having a healthy relationship and home life. You just need to stand up for yourself: if you need to work long hours constantly (not just in occasional “crunch times”) to remain competitive and reasonably paid, your employer has serious cultural problems that will probably never be fixed.
First, I would like to say that if you're doing a good job managing your time and being efficient with it, working long hours is not necessary even at demanding start-up jobs. I know a couple of friends who complain about working long hours, but I know for a fact they spend an hour or two a day doing personal emails and surfing the web. If they were productive with those hours, working late wouldn't be necessary. The only caveat is in the "crunch times" that he references, which are necessary for any small development team when you release often and work quickly to hit aggressive deadlines.
thredUP has a very liberal vacation policy - in the simplest terms, there is no policy. As long as you don't abuse it, we want you to balance working hard with getting the necessary down cycles that keep you fresh. Developers are paid to code, but don't burn yourself out. If you're sick of coding it will make you miserable and it will affect your output. Manage your internal drive: rest when you need to, go code crazy when you're in the zone. Just remember that start-ups aren't built overnight so make sure you're pacing yourself for long haul.
Documentation, only when necessary
A lot of development teams harp on strong documentation - every method should be documented to explicitly state the purpose, the parameters and the result. I couldn't disagree more with this. When methods and variables are named intuitively, those methods will be self explanatory. The only situation in which I find documentation important is when you have a complex method or class that is doing something obscure or not easily perceived. If you spend a couple of hours re-factoring your code when your finishing up a project, it will become obvious which parts of your code could use a little documentation and which parts are fine as-is. No need to waste your time if you don't have to.
Lastly, Marco had a great point in a recent episode that wasn't particularly related to development but still great nonetheless. Don't underestimate how much your boss deals with that you're not aware of. Hiring, firing, salaries, taxes, bills, office leases, insurance, lawyers, funding, and much more. They have to deal with all of that while thinking ahead on the product roadmap and staying sharp in the present. Next time you think your boss has it easy, make sure to weigh in everything he/she might be dealing with offline before you jump to conclusions.
If you have any other gems from Marco or one of your favorites I didn't list, I'd love to hear it below in the comments.
