Joshua Volz

Part of the reason to come to SF was to get better at my craft.  I’ve learned a lot since moving here 6 months ago. Last week I learned about evolving a codebase instead of designing one.   Nobody actually presented it that way to me, they simply told me how they work and that’s my attempt to characterize it.

How I used to work (design everything then type it in):

1. Know everything about the code
2. Think about the new feature you want to implement
3. Figure out the smallest diff between what you have and what you want
4. If results of #3 are elegant enough, do that.
5. If results of #3 aren’t elegant enough, keep thinking until you come up with something better.
6. Type it in.
7. Commit your changes, usually an entire feature.

This patterns works really well under a couple of circumstances.  It requires you know the entire codebase intimately, which means you work alone and you have been doing so on this project for a great deal of time.  Previous to my current employment situation I spent almost a decade being either the only or one of two programmers working on my target project at any given time.  Because I have a pretty good memory, I can basically remember everything I’ve ever written on a project, particularly if that project is one I’ve been working on everyday for more than a year.

It turns out that when you join a team that is working on several different projects, and everyone is touching everything, you cannot possibly know everything about the code.  Someone is always changing it without you knowing.  You cannot reason about the code in a logical manner without a structure or pattern to the code.  I thought at my new position I would be able to get to know the codebase and then get back into the mode I was working in before where I could reason about the code without looking at it.  I thought other people structured their code so that this was possible.  NOPE.

How I’m learning to work now (iterate everything):

1. Have well defined requirements for the functionality of the code.
2. Pick one of those requirements, as small a piece as you can reasonably break off.
3. Write some tests for that functionality from #2
4. Write the code to fulfill those tests.
5. Commit results of #3-4.
6. Pick another tiny requirement and repeat steps 2-5.  Continue to do this until you have all the functionality defined in #1 completed.
7. You’ve got working code and passing tests; time to refactor.
8. Pick a tiny refactor that lets the code be more modular, easier to work with, easier to understand.  Basically anything from the Refactor book.
9. Commit the refactor.
10. Keep doing #8 until you run out of time or until you reach a refactor that is so large you cannot justify doing it.

You evolve it.  The rules of the system are the tests.  Nobody bothers to learn them because that’s why you have tests.  When you ask someone who’s been working this way for some time about a portion of the code they wrote, they invariably say “lets look at the code.”  The reason is that they have no idea what they did because they didn’t have a full design in their mind when they started.  They evolved it from the interaction between the requirements, the tests and the existing code.

I suspect the second methodology is a reaction to time requirements combined with working on a codebase with multiple people.  I’m not yet sure what the long term consequences are for using the iterative methodology.  Time will tell.

How do you work?

1. You are going to walk.  A lot.
2. The state taxes are ridiculous, but they pay you more here (as a software engineer)
3. When you’re walking and it’s not raining, don’t step in any puddles.  They’re piss.
4. Everyone rock climbs, hikes, rides their bike or some other outdoor activity with cardio built in.
5. Everyone is a foodie, but they only drink water, beer, wine and sometimes the hard stuff.  No Coca-Cola.
6. Messenger bags are a big win when you are always lugging around a laptop and walking everywhere.
7. Like 1 in 50 people here are overweight.  Everyone else complains about the cold.
8. In the morning it’ll rain; in the afternoon the sun will shine.  Layer accordingly.
9. Everything costs the same as other cities, except rent and the gym, which are 4 and 10 times as much per month, respectively.
10. They are somehow both more savvy and more innocent here.
11. Recycle; it’s the law.
12. CA charges you a redemption fee for basically anything you buy.
13. Riding the bus is only horrible because of the other people riding the bus.
14. Everywhere has WIFI.
15. Everywhere has good cell phone reception, except the bathroom in building where Tech Crunch and Yammer are located.  Weird.
16. The difference in incomes is staggeringly large even in the same block.
17. It’s not uncommon to see a Bentley.
18. If you stop for breakfast, you can call your order in to save time.
19. It only takes 18 minutes to shower and get ready for work.
20. Network, network, network.
21. Finding good engineers to hire is hard.
22. Renting an apartment is harder than finding a quality engineer to hire.
23. Yes, that homeless guy IS taking a crap in the street.
24. There are two belt notch settings: walking and sitting on the bus for an hour.
25. Always wear a bike helmet when riding a bike.
26. A clipper card with lots of credit is Willy Wonka’s Golden Ticket.
27. Bridges are expensive to cross.  Like mob bosses they take cash only.  (note: and Fastrak)
28. There won’t be free parking when you arrive.  In fact, have quarters with you all the time.

Most of the time rewriting isn’t the best option, but when you have access to a significantly higher level of programmer the 2nd time around, it’s worth not typing their hands with the left over crap of a dead project.

It’s important to distinguish between a common pattern in code that exists because your programming language doesn’t have certain features (usually, macros) and a cut and paste poor programming job.

Bureaucracy is the same thing as code rot.  In both systems it’s left over rules and regulations that don’t make sense anymore.

I suffer from writer’s block, or as I think of it the Procrastination-Stress Negative Feedback Loop.  For the last 3 days I’ve had the worst case of writer’s block I’ve ever experienced.  I’m sure everyone has experienced this at one time or another.  You have some easy stuff you need to do, something you know how to do, but you just cannot bring yourself to do it.  You think it’s a passing phase, but it lingers. Or maybe you don’t have clear requirements, or you’re not sure of the most elegant solution to your problem is, so you wait for inspiration.

Most of the time when I have this I can wait 24 hours and it’ll blow over.  Not this time.  This time I couldn’t get anything done, and as more time passed I got more and more stressed about how I was going to overcome it.   The extra stress snowballs and suddenly you find yourself buried in work that should have been done a week ago, deadlines looming, dreading the ringing of your phone because it could be your customer or your boss.  I was supposed to have two days off this week, and I would have had I finished this project on Wednesday like I should have.  Now not only is the project not done, but I’ve missed my time off opportunity.

Normally, when this happens I take steps to curtail it:

1. Get some sleep.  I’m normally blocked when I don’t get enough rest, which happens a lot when I’m under deadline to get something done.
2. Exercise.  I simply don’t plan in time to get enough of this done to make a difference.  Don’t be like me.
3. Eat.  I don’t suggest this on a repeating basis, but sometimes eating can change my brain chemistry enough to kick the machinery into gear.
4. Get marital help.  Sometimes your wife can *AHEM* help you out and get you into a mind state that is more conducive to work.
5.  Do something else.  Sometimes taking a break from your main project and working on something else that interests you can help get the ball rolling.  I think this is the true brilliance of the Google 20% time.
6. Grind your way through it doing the easy parts.  This has rarely worked for me, but when it has worked, it has worked extremely well.  Start with the easy parts of what you’re looking to achieve, then move on to the more challenging parts.
7. Get Help.  Get someone else’s opinion on it, or even maybe their help getting it done.  A second pair of eyes can be motivating, and everybody needs help sometimes.
8. Take a break.  This means putting your mind on a shelf for a little while and returning when you’re more refreshed.  I like reading for this purpose, but I could see anything from video games to television or movies filling this role.
9. Mind altering substances.  I don’t do any sort of drugs or alcohol, but as I haven’t tested them myself for this purpose, I cannot rule them out as an option.  I’d like feedback from any readers on their thoughts on this.

You might be wondering how I have finally broken my current bout with writer’s block: let’s just say it involves a football game, a girl puking and breaking up a 8 man fight in the men’s bathroom.  Thank you adrenaline.

I have a 2 year old daughter.  I plan spending time with her into my week, because I don’t want to miss out on her growing up.  She is fond of animals in all their forms: stuffed, real, as bath toys, on TV and as educational opportunities.  Here’s the tip:  A good pet store is actually a small and specific zoo.  When you daughter is used to seeing animals in the zoo paradigm (obviously we cannot take home a lion from the zoo) she is less apt to try to get you to buy her a puppy from the pet store, and thus it becomes a $0 experience that is fun for the whole family.  You’re welcome.

In response to Technical Cofounders are a Myth which paints software engineers as people who give up on projects and as people who won’t work for free (correct!) I have this to say:  business cofounders are a dime a dozen.

It’s incredible how many people have proposed to me that I do all the work and get as much as 20% of the company.  I enjoy listening to these business types as they tell me about their business plan and how the website should work (because they’re masters of UI design).  If I could somehow turn each of these pitches into $0.01 I would already be a millionaire.  I enjoy it when people ask me to utilize a skill I spent 10 years perfecting, that I earn a top 10% income at, for free.  I love it when they offer me 5-20% of the company I’ll end up building.

I sometimes wonder if this sort of insanity is what they teach in business school.  Step 1: find someone you can exploit.  Step 2: exploit them and make it look like they’re getting a fair shake for doing all the work by giving them a non-controlling stake in the company.

Business guys:  it should come to you as no surprise that most software engineers aren’t going to work for free.  Furthermore, if they wanted to work for free they would work on their own idea that they entirely control and own.  Do you know how much of a pain in the ass it is to program for someone else?  It’s infinitely more enjoyable to program for myself, for my needs.  If I wanted to program for someone else I could get a job making more a year than your MBA cost you in student loans.

What you business guys should be thinking about is this:  what am I bringing to this business? And I don’t mean the idea.  The idea is basically valueless, that’s been established time and again.  It’s execution that matters.  What are you bringing to the execution of this idea?  Here’s a couple of things you can bring to get software engineers interested:

1. Money – it never hurts
2. The promise of money – as in signed contracts with customers
3. Connections – are you connected to the big wigs or customers in that industry?  Can you get me time with them so that we can refine your product idea?

If you cannot bring one of these to the table, you’re pretty much useless to me as a business guy.  So, before you go complaining about how software engineers won’t work for free or how we quit projects with no future, man up and do your job by bringing home one of the 3 above.  Thank you.

Among the many pursuits of Volz Software, I sell backup software called Llama Carbon Copy.  I wrote this software before the explosion of consumer off site backup software (Dropbox, Mozy, etc.).  I still get some interest in the software.  I received a technical support request from someone using my software last night.  I wrote back with some tips and to confirm that they were actually having the problem they descirbed.

This morning I got their response.  Turns out, they weren’t having an issue at all.  My prospective customer wrote this:

Looks good so far, it is simple and a little too straight forward.

Yes, I was just accused of writing software that is too easy to use.  I believe this to be the best backhanded compliment I’ve ever received.

You came out of the gate hard; you felt good.  You made great progress; your development environment was setup and you’d put some code in your repository.  Slicehost is treating you nice and backing everything up.  You just had to finish this one section of code, then you’d be off and running.

And it drags on.  You get some more done, but you have to go back and fix things because you’ve found a better way.  Quickly what you thought was a weekend job becomes something that isn’t done after six months.  This is where I am now.

I started this project on January 1st, 2008.  I completed the original version, I made some progress, I made some sales.  This validated the idea.  Now, I know I have a valid idea, that is actually making money (not ramen profitable, but making enough to pay for a slicehost slice to develop the idea on).

On January 1st, 2010 I decide: I’m going to get this done – if it takes me all year.  Grinding my way through the last 7 months on and off programming, I’m finally at the point where the whole system works in 1 dimension (each portion has many different dimensions that do similar things for different sources and that communicate with different end points).  It works on my local machine.  I get myself a 2nd slice just like the first.  I load everything up.  ..And I get a bug.  God Dammit IT WORKS ON MY MACHINE!

I’m debugging now, a week later.  The luminaries of the start up world are right: persistence and discipline are the qualities that matter.

Inspired by this article I got to thinking about shipping. The article talks about the pitfalls of shipping, whether your customers love it or hate it, whether they use the features you added or not. It glosses over the most traumatic possibility: nobody uses it at all.

Sometimes you put something out and nobody can find it.  Sometimes nobody wants it.  Sometimes nobody is looking for it at all.  You forgot to come up with a plan to show off your offering.

Shipping isn’t actually that hard.  Successfully shipping is.  Pushing code to github.com is technically shipping.  Nobody downloaded it, nobody used it, nobody cares.  That’s not shipping successfully.  Shipping successfully is getting software people want into the hands of the people who want it.

This morning I got up sore, at 6:10am.  I lifted weights the last two days so my legs and my shoulders are killing me.  I showered, got dressed, hugged my daughter and made my way to work.  As I drove, I was thinking about what I read on reddit last night.

I read the most depressing thread, a thread about people being out of work for more than a year.  First, I have trouble imagining that, but I’m a real programmer, and apparently we’re entirely immune to the ebb and flow of the economy. I know my company is looking for a good programmer in either Las Vegas or Milwaukee and we can’t find one.  As soon as we mention the programming test during the interview people start acting really weird.  Second, I read through this thread on purpose.  I read through it to remind me why I should be grateful.

I am grateful.  I have everything.  I have a healthy family, a good job that I enjoy, my own personal interests, and I’m getting into shape.  I make enough money so that my wife doesn’t have to work to earn a second income and instead she can stay home teaching and loving my daughter.  I am living the American Dream.