Category Archives: Careers

Thoughts on overtime

In general I think overtime is usually pretty dumb.

How much can the productivity of two people differ? Can one person be 100 times more productive than another person? An easier question to say yes to (although it’s the same question) might be: could someone be just 1/100th as productive as you? Yes, of course they could.

There’s a false belief shared by many that says you get twice as much done in 80 hours as in 40 hours. That might be true for one particular week. I don’t think it’s true stretched across a career. For those people who are 100 times as productive as others, it’s of course not because they work 100 times as much. High achievers increase their leverage by becoming more knowledgeable and finding more effective ways of working.

I do think that overtime is sometimes necessary and a good idea. I happen to be in the middle of a stretch right now where I’m working a lot of hours. I committed to 40 billable hours per week with a client, and then I have other responsibilities on top of that, like email, various administrative tasks, and my product business.

I think the tragedy is when people confuse an investment with a donation. I used to work with a guy at an agency who would regularly put in 70-hour weeks even though he was salary. He was working on client projects for clients he would never meet. As far as I could gather, no one appreciated his extra time. He might have thought he was making an investment in his career by working all this overtime, but really, since no one was noticing his overtime, he was just making a donation. It’s dumb to make donations to for-profit companies. My current overtime situation is justifiable to me because it’s totally mercenary. The more I work, the more I get paid. Money is what I want right now so I’m working as much as I can. I’ll be using some of this money to help situate myself so I don’t have to work as hard in the future.

Another bad reason for overtime is bad planning. Just because a manager committed to an unrealistic timeline doesn’t mean you’re all the sudden on the hook for a bunch of overtime. “Bad planning on your part doesn’t translate to an emergency on my part.” You might think you’re a hero for trying to meet the unrealistic deadline. It’s possible that you’ll be seen that way. It’s also possible that your overtime will go unnoticed or unappreciated. It’s also possible that you’ll send a signal to management that you’re okay with this “bad planning = overtime” arrangement and make yourself a candidate to receive more such jobs in the future.

Then there are genuine emergencies. If there’s a genuine emergency and refuse to work overtime, then you’re of course just a dick.

Overtime is also pointless if you dilute yourself, through lack of sleep or whatever, to the point of being, say, 50% as productive as normal. What good is it to work 80 hours if you’re only being half as productive? What’s worse yet, and probably not that uncommon, is when you drive yourself to be 0% as productive as normal. You’re just a zombie, sitting there, pretending to work. I’ve done that before. Pure stupidity.

Here’s what my advice would be to someone considering some overtime. Ask yourself these questions:

  • Is this an emergency or just bad planning?
  • By working this overtime, and I diluting my own productivity such that the overtime is actually a net loss?
  • Will my extra effort be appreciated or even noticed?
  • Am I making an investment or a donation?

How to Get a Job Using a Technology You Don’t Know

Getting a job using any certain technology is kind of a chicken-and-egg problem. You can’t get a job using Ruby on Rails until you have experience with Rails, but then you can’t get Rails experience until you have a job using it. Frustrating.

Is there a way around the catch-22? There is.

But first, here’s what not to do

One popular piece of advice when you’re trying to break into new skills is to work for other people for free. I don’t think this is the absolute worst idea in the world, but it does have problems. Here are some:

  • It sets a precedent with your client that your work is worth isn’t worth much. Not every client has worked with a software engineer before, and the only notion they have of market rates might be their experience with you. So if you charge a client $200/hr, $20/hr or $0/hr, that very well might be what gets stuck in his or her head as to the value of your work. It is of course possible to tell the client up front that this kind of work normally goes for a three-figure rate and that you won’t be working for free forever. I think it’s probably likely, though, that the client will get attached to whatever rate you charge him or her initially. That’s been my experience.
  • It’s kind of tricky to limit project scope. When you’re working with a client for money, you work however many hours they can pay you for. When you’re not requiring the client to pay you anything, there’s kind of a battle between “I can’t just work an unlimited amount of time for free” and “I don’t want to be a dick to my client.” That’s the tug-of-war that has always happened in my head whenever I’ve done free work in the past. Again, you can attempt to somehow limit scope in the beginning, but I don’t know that any mechanism you might set up would be nearly as effective as the “that would cost more actual money” mechanism.
  • You’ll probably get shitty clients. This one probably doesn’t need much explaining, but it’s a phenomenon that not everyone seems to be aware of. Penny-pinching clients tend also to be the most painful to work with.

The simple solution

My solution is not very complicated: instead of working for other people for free, work for yourself for free. This approach has the following benefits:

  • You own what you create, and can show off the source code freely if desired
  • You get to pick all the technologies with which you work
  • You call the shots with regard to features, timelines, workflows, etc.
  • If you build a useful product, you might even be able to earn some money off of it

There are also drawbacks, like the fact that you don’t get the “real world” experience of interacting with clients. To me the trade-off is worth it.

I’ve used this approach multiple times with success. Examples:

  • Throughout the mid-1990s I built my own websites using HTML. Later, around 2000, my dad hired me to build his business’s website.
  • In 2005 I started tinkering with Linux and PHP. Later that same year I got a job using Linux, PHP, and other technologies I already had experience with like HTML and CSS.
  • In 2011 I started my first Ruby on Rails project. I built a product that did scheduling for hair salons. Later that year I got my first minor freelance Rails gig, and then in 2013 I was hired at a full-time (contract-to-hire) job doing Rails. Now Rails is all I do.
  • In fall 2013 I started building a side project using Ruby on Rails and AngularJS. Just a couple months later I got a freelance gig where I had the freedom to choose AngularJS as the JavaScript framework. Then, in early 2014, I did several mentorship engagements where it was my job to teach AngularJS. I was seen as not only competent but expert.

I’ve used this same approach to get paid to teach guitar lessons, do rudimentary SEO, and manage a Google AdWords campaign. The bar for “competent enough to be paid” is not all that high.

How to come up with something to work on

It might be easy or hard for you to come up with an idea for a project to work on. My advice would be to find a problem that real people actually have, and, crucially, actually want a solution for. Two products I’ve built that have gotten a certain amount of traction include scheduling software for hair salons and a tool for office workers to coordinate their lunch outings. Here are some ideas of untested viability that you’re welcome to use:

  • Storage facility management software
  • Logistics software for transportation companies
  • A CRM specifically for credit card processors

I’m not suggesting that you set out to build a software company, but if you’re going to pour time into a side project, might as well make it a side project that has a chance of earning some money. If you are interested in building a software company, though, you might want to check out the Micro-ISV community.