The great telecommuting debate

There’s a big debate going on in the hacker community.

On one had, you have pundits like Seth Godin forseeing the switch from offices to something else.

If we were starting this whole office thing today, it’s inconceivable we’d pay the rent/time/commuting cost to get what we get. I think in ten years the TV show ‘the Office’ will be seen as a quaint antique.

That’s great, but what about hackers?  There are something like 8 million of us, and 90% of the our workday we’d be better of 100% alone.

But I was reading an article today on the Boston Globe about IBM’s new Massachusetts campuses (Cambridge, MA respresent) and they emphasized the

“At the end of the day, we’re really much more primitive than we think in how we interact,’’ Howe said. “We like to talk to people, not to machines.’’

And just last week, at Railsconf I was at a talk on Agile by Pivotal Labs (which was awesome by the way) where Ian emphasized having the team all in one location. Also, I don’t really see startups all going remote, as it really helps to be together in the same room for several reasons – motivation and communication, generally.  It’s sad, because I’d really like to not have to go to an office every day.  Not all offices are created equal, but most of them foster an environment that is counter to one of programmer happiness.

Pomodoro Technique v2.0

Don’t get me wrong, I love the Pomodoro Technique. Some people have a hard time understanding why someone would use it, so in case you aren’t sure, here are the reasons.

Concentration

The primary reason to use the Pomdoro technique is to seperate work-time from distraction time in a reasonable manner.   The distractions come in two forms – internal and external.    External distractions/interrupts are people IMing you, calling you on the phone, walking up and talking to you.   Internal interrupts are you deciding to check your work or personal email, twitter, doing something else so you don’t forget it, or deciding to get a cup of coffee.   Good workers structure their days so that they have large blocks of time where they can just work, but ideally to be most productive a worker would be able to pace those break times and work times throughout the day.

Breaks

RSI is a serious problem and we all need to manage the amount of time we spend reading personal emails and twitter.   Pomodoro technique, if tightly adhered (which I’ve found incredibly hard, at least at a noisy office), can provide you with a way of having to do do some of these things and not feel bad about it.

What I’d like to change

There are some things that need to change about the Pomodoro technique.

Goal Based vs Time Based

Pomdoro is time based, but I find it more rewarding to set daily goals and deadlines deadlines throughout the day and try to hit them instead of arbitrary Pomodoro estimates.   I’m thinking of having Chorus combine the two, so that you have something to shoot for in your daily todo list but you still get the benefits of time tracking and break structure of the Pomodoro but with some actual motivation to get things done in a timely fashion.

Break Structure

It’s too easy to get distracted during the breaks.  I get distracted a lot during the breaks for 3 major reasons.   One is coworkers (no fault of them) for work stuff or just to chat and have fun.  Two is myself, checking email then trying to do some quick personal things like respond to an email, check on a not really urgent finance thing (bills, whatever).   Some of these are aggragated by me using a pomodoro OSX timer so when I get up from my desk to stretch and whatnot I no longer have the time to keep track of how long my break is going.

Some solutions are: change the structure of the breaks so that in a 4 Pomodoro set, the 1st and 3rd Pomodoros I don’t leave my work area or maybe even don’t get up from my desk.  Use an iPhone pomodoro timer exclusively – that would be neat.  Minimize the amount of personal stuff I do during breaks.

Also, I sometimes have trouble returning to the Pomodoro after a long break.  I think part of it is that my estimation isn’t as good, so I’m not sure what my next task is so I procrastinate a bit before starting a Pomodoro after returning from break.  This depends on what I’m working on and how clear my path is.

Chorus

If you have any questions or suggestions about how you like to use the Pomodoro technique to your own advantage, send me an email via the contact form. I’m building a web app to help with using the Pomodoro technique with programming (and I guess other knowledge workers could use it to) called Chorus,

The French Paradox

I love French culture.  I’m not sure when it started.  Maybe when I read the Three Musketeers.  I’m even more facinated by their culture than that of the Greeks, who maybe were the closest to self-actualization of any of our civilization.  I’m enchanted by their language, delighted by their food, and jealous of their savoring of life epitomized by things such as having lots of vacation time where Americans only have two weeks.     On the whole, I really think that their values are superior to typical American values.    One of the cooler things about French culture is their unique diet and it’s effects, often referred to as “The French Paradox”:

Well, during my recent attempts at weight loss, I thought of the French Paradox and why it works so well when you eat foods like this:

Your road to weight loss

And still look like this:

I think the french are the best life hackers ever.

So how do they do it?

Walking everywhere
We drive, they walk. Walking > Driving. End of story.
Quality over Quantity
Don’t eat too much of one thing
3 Meals a day
Snacking is avoided as it’s not truly enjoying food

Ruby-debug is awesome and always TDDin is dumb

http://gilesbowkett.blogspot.com/2007/10/debugger-support-considered-harmful.html

I really like Giles and his blog, but I disagree on this point.  I also get what he’s saying.  When your doing TDD, it’s a lot easier to find the point of failure because you are coding incrementally.  Red, Green, Refactor.  If you hit an error in the “refactor” point then it’s easy to see where because you just made a tiny change.

However, I don’t always TDD. I don’t agree with the idea that every code needs a test that goes along with it. At a certain point you have to decide which tests are worth your time and which aren’t. Also, most people agree that 100% test coverage is a waste of time which backs me up. With a lot of code, you would have to write 10x as much code in tests to cover all the possible different permutations of the code you just wrote.

So there you go: you don’t have tests for everything. So when you have a bug you are trying to fix, how do you narrow down what’s causing it? At that point, you have 2 choices. Logger statements, or ruby-debug. And I find ruby-debug to be a much quicker and more interesting to way to see what’s going on with the code than using puts statements. There are times when puts statements are faster…but usually not.

That said, I agree with the general idea that we should test first and debug later.

Does hating tools make sense?

Rails developers are a funny lot.
A lot of us would be seriously pissed if we had to use anything but Ruby and maybe Rails, and we would often be pissed if we were forced not to use Macs.

Why is this?

Because bad tools cause frustration.  If you are regularly frustrated by something, you start to think of it as annoying.  If you find a better way to solve a problem, you start to think of the old solution as pointless and dumb.   If you’re forced to still use that old solution, you move up into another layer: hate.   We all know that Java solutions are much more frustrating then Rails solution.s  As a result, we hate java.

We hate not using the best tool for the job

OSX is great because its based on unix i.e. command line, but it also has a bunch of great graphic tools that are very modern.   Linux doesn’t have a bunch of great GUI software on there, and Windows has shitty command line capabilities.

Programmers who claim to be business savvy are snake oil salesman

As soon as a “programmer” comes to me and claims to be `business savvy` I immediately get a little suspicious.   It’s very similar to someone naming themselves as  `social media expert`.   It’s just bullshit.  Often time the first thing I think is “shit, is this guy going to put his code where his mouth is?”

For a lot of the social media stuff and the business stuff, it’s very domain-specific.   This is why startups that hire a large amount of executive types are dumb and will often fail – they all have to “shake things up” and don’t actually add that much to the bottom line.  Plus, business isn’t enough of a definitive skillset to be very transferrable between different types of careers and organizations.  This is why Business majors do so badly on post-graduate testing.

The larger problem with this whole I’m a business man and programmer is that it’s meaningless.   In reality, I think most smart people, and especially engineers, are capable of making smart day to day  business decisions when properly informed.  It’s just that good engineers don’t have the time.

Now if you have an engineering background and you have run a few startups and enjoy being a CEO-type and want to continue doing that, good for you. I love working for engineer CEOs.

But if you are an engineer who just wants to claim he is business savvy for whatever reason, do us all a favor and just concentrate on being a good engineer and use your common sense for everything else.  There’s more than enough ways your organization can likely use your intelligence and dedication to improve it’s engineering to where all our companies can actually execute business goals better and faster.   In a lot of cases, there are business people who have been hired to do the real business roles – managment, corporate negotiation, and market analysis.

That said there is one type of engineer who relates to this conversion – the CTO in a heavily technically aligned organization.  I’m thinking of the great Eric Reis in an organization where the focus is on the technology to be so agile that the “problem finding” part of the organization can rapidly change directions based on results from engineering i.e. split testing and whatnot.   That’s the kind of business-minded programmer I like to see – one who wants to engineerisize business instead of businessize engineering.

In the end, just

Put your code where you mouth is.

And you’ll be just fine

Programming faster with the help of technology

I think it’s funny that programmers, being as tool-fanatical as they are (see my earlier posts on Textmate), often times we really only have one awesome must-have tool – our text editor of choice.  Maybe this is why GNU Emacs has grown to be so much like an operating system – we’re so obsessed with our text editors, that we feel the need to roll everything into them instead of just using something else.

But tools to accomplish programming are great.  Text editors, different types of unix tools to do different things like connect to databases (psql) and mess with files (autojump).  Search (ack).

But how many tools do we have that actually make us faster programmers?  Not many.   Maybe none at all.  Here’s a short list.

RescueTime – analyze how you are spending time and then later optimize. I haven’t used this yet.

Pomorodo Technique and Timer software – this is pretty sweet.

To-Do Lists like Emacs Org and collaboration ones like Trac, Basecamp. I think it’s funny there hasn’t become a defacto to-do list standard for programmers yet.

Blockers like Leechblock and Concentrate

I use all of this in conjunction (except RescueTime) to try to make me more productive.  However, two of them should really be integrated.  Namely, the Pomodoro Technique and the to-do list.

Here’s what I’d like to see – an application that does the following.

1. Presents you with a list of (programming) tasks and their percentage done, the estimated hours remaining, and the option to start.
2. Clicking start with then start a 25 minute timer for the pomodoro technique and ding when it’s done.
3. Later you can view reports on what you did today and how long it took you off estimate.

Later you could add features like

• Subtasks with projects as the parent
• Planning todays tasks given available pomodoros
• Per project notes
• More advanced reporting
• Desktop front ends for the timer

I think what this would allow you to do would be more accurate track what you’re spending your time doing so that you can learn how to be more efficient.

Update

I found an app that does basically what I wanted

Favourite Iphone Apps

Yelp – find restraunts on the go

Tweetie/Twitter – no explanation necessary

Waze – free turn by turn gps

Kindle – buy amazon ebooks and sync with with your ipad, kindle, or mac/pc

TWIT – streams new episodes of macbreak weekly and This Week in Tech

DailyBurn – find new workouts and do them on your phone

C25K – a running plan

Managing config files in Version Control – an idea for a gem

http://stackoverflow.com/questions/1449836/how-to-manage-rails-database-yml

First, move database.yml to a template file.

If you’re on Git:

git mv config/database.yml config/database.yml.example
git commit -m "moved database.yml to an example file"

Or, if you’re on Subversion:

svn move config/database.yml config/database.yml.example
svn ci -m "moved database.yml to an example file"

Second, ignore the .yml version.

If you’re on Git:

cat > .gitignore
config/database.yml

git add .gitignore
git commit -m "ignored database.yml"

If you’re on Subversion:

svn propset svn:ignore config "database.yml"

Third, install Where’s your database.yml, dude?:

script/plugin install git://github.com/technicalpickles/wheres-your-database-yml-dude

That plugin alerts developers before any Rake tasks are run if they haven’t created their own local version of config/database.yml.

Fourth, set up a Capistrano deploy task:

# in RAILS_ROOT/config/deploy.rb:
after 'deploy:update_code', 'deploy:symlink_db'

namespace :deploy do
  desc "Symlinks the database.yml"
  task :symlink_db, :roles => :app do
    run "ln -nfs #{deploy_to}/shared/config/database.yml #{release_path}/config/database.yml"
  end
end

Fifth, upload the server’s version of database.yml:

scp config/database.yml my_server.com:/path_to_rails_app/shared/config/database.yml

I found this while researching random stuff about config files.  Let’s ignore how long it is and focus on the long term maintenance hassles.

First off, you have to make every change in at least two files.

Secondly, if you have more than 2 environments this system falls down.

Thirdly, if you have multiple developers with their own database.yml files this option sucks because they won’t get changes on git pull or svn up.

Fourthy,   if you want to run QA in production mode or development mode, it’s not gonna work.

A better solution

I’ll look into creating a gem that does this at some point, but this is how I envision it.

Files

database.yml.master

database.yml.qa

database.yml.production

database.yml.slave

When Rails goes to read out of database.yml, it will first read database.yml.master, then overrwrite any settings in there with database.yml.slave.   Capistrano will sym-link database.yml.save on deploy to the appropriate environment.  This way, when you make a change, it should be tracked in svn but your .slave file can have it’s own specific overrides.

Release with bugs

Bugs are inevitable.

You can have a QA team and rely on them, to find all the bugs – but there are going to be bugs in there, QA or not.

I think what’s way more valuable is having a lean enough team to respond to bugs quickly and having code reviews to prevent seriously malicious code to get in (i.e. stuff that’s really going to mess up your database).

I am, however, curious about the recent WordPress.com issue that led to an hour or so downtime of a lot of famous blogs, including you-know-who famous tech blogger (left out so they don’t get more press).  I’m just wondering what sort of code caused the messing up of the config files and how that got through their automated testing.