There's a good chance that you're working too hard right now. Well, maybe not right now, because you're reading this sentence, so perhaps these days. I'd bet there's a very good chance that you're working too hard these days, and you should consider stopping.
Fine, those sound like deliberately-provocative sentences designed to capture the reader's interest, as suggested by any of a number of articles on how to "write viral content". I'm trying.
Even so, deliberately-provocative sentences like these really only work if there is a grain of truth in them, and I absolutely do mean them. You are probably working too hard at your day job right now, although it really depends on "you". I'm talking specifically to programmers in typical enterprise-level jobs at pretty big companies. (Even if this isn't actually you, I hope you'll keep reading, out of inertia if nothing else.) If you're like I was at IBM in the late 1990s, then you have a fairly narrow assignment, you do it, you sense that you are constantly behind schedule, and you use your superpowers to try to keep up. And you manage to keep up. Your managers, and even the people around you, notice that you're "a producer". You make things happen. You get things done. You're building a bit of name for yourself within the company—or you've already done so.
Congratulations! You're almost certainly wasting your advantage.
Think about the mythical 10x programmer. (We all know that no such person exists, but we know that some programmers are more effective than others.) This is the person who works on the most important parts of the project, whom managers routinely look to in difficult situations, and who has a parade of people going into and out of their office asking questions all day. They probably end up coming early or staying late in order to find time to get some actual work done. Maybe this is you. Maybe this is the person you aspire to become. Let me burst your bubble a bit: even if the so-called 10x programmer existed, the 10x programmer wouldn't get paid 10x.
Don't just rush past that sentence. There's a huge opportunity in there. Even if a 10x programmer existed, the 10x programmer wouldn't get paid 10x. Not even metaphorically, not psychically, not in any way possible, unless they have an ego the size of a small nation. The so-called 10x programmer might feel like a hero, but that feeling, no matter how strongly one feels it now, fades over time. This happens as admiration and respect turn to co-dependence: the companies relies on the hero to pull its feet out of the fire and the hero relies on the company to do silly things that require their rescue. Over time, it does bad things to the psyche. When things go sour, we end up with extreme behavior like firefighters setting fires in order to save people.
I digress. (It was fun, though, wasn't it?) Let me return to my point: the 10x programmer doesn't get paid 10x. Worse, the 10x programmer probably gets paid slightly more than the 3x programmers, who gets paid almost exactly the same as the 1x programmer, who get paid almost exactly the same as the 0.4x programmer. When I first saw this, I got angry. Fortunately, after a while, I saw an opportunity.
Since I'm making about 50% more than most of the people around me, I bet I can produce less work (still of high quality) without losing the respect and appreciation of my managers.
When this thought first occurred to me, I was angry about how the division was operating around me, so I didn't worry at all about whether this was fair to the company. Since then, I have come to realize something important: the economic system within which we (most of us) operate demands that companies pay employees the least possible in order to get sufficient value out of them. This isn't a good thing or a bad thing; it's merely the way things are. I don't want to consider the moral implications of this system, but it would be foolish to pretend that it doesn't exist. As a result, when I, the employee, deliver excess value to my company, as compared with the salary they pay me, I am giving value to them. It is a gift. The nice thing about gifts: they are voluntary. I can decide to stop giving gifts with no moral or ethical concerns. This means that I can stop delivering excess value compared with my salary, and feel no ethical quandary.
Maybe this makes you nervous. I understand. It surprised me, too. Maybe this thought leaves a bad taste in your mouth. I understand that, too. Keep reading.
If you love your company, your managers, your co-workers, then you will naturally give them the gift of excess value. You will give it freely. This is wonderful. I'm not suggesting that you stop.
If, however, you don't give them excess value as a gift, but rather they squeeze it out of you by applying pressure and trying to appeal to some misguided sense of loyalty, then I'm suggesting that you wake up from your delusion that this is normal, acceptable, or right. It is not. In this situation, you have not only the right, but I would say the obligation, to stop delivering excess value for the money you're earning, because then you give the company the impression that the salary they pay and the experience they offer to employees is worth more than it is. If the company has a more realistic picture of the value of experience of working there, then they will be forced to pay employees better for what they expect from those employees. (Of course, the pendulum could swing in the other direction too far, but programmers don't have unions, so that seems unlikely.)
This Is Not About the Money
I didn't bring this all up to focus on the money. The money merely provides a way to detect and measure the imbalance between the value you offer the company and the value they offer you in return. (And remember, if you're thrilled with the value they offer you, then continue being thrilled and ignore me. Send this article back to your inbox in a year and ask yourself how it's going. Things change; people change.) I want to focus on how to exploit the imbalance.
If you generate excess value for salary compared to the people around you—if you're a 2x, 3x, or 10x worker—then you have something wonderful: slack. Specifically, you have time and energy slack. (If you happen also to make enough money to run your household with positive cash flow month to month, then you have money slack, but that goes beyond what I want to say today.) Time and energy slack at work is a resource that you can use to get something of value for yourself at work, and you can do this free of any ethical or moral concerns. No, really. (It took me a while to feel comfortable with this.) I used my time and energy slack to learn things.
Good For You; Good For Them
One problem with the constant pressure to deliver comes from not taking time to learn things. I don't just mean figuring out how to do things that you know you need to do in order to complete your work; I mean discovering new things out there to learn that you'd never thought of before. I mean opening yourself up to new ways of working. I mean challenging long-standing assumptions about how to write, design, deliver software. When I worked at IBM, I thought I didn't have time to do any of this. I did, however, have energy—I was very young—so I read books... on my own time. Having no children and an understanding spouse gave me the opportunity to do that.
I'm telling you that if you have time slack, then you should do some of that learning at work, because some of that time is your own time. You are giving it to your employer as a gift; you have the right to stop volunteering to do that.
Now you already realize that your employer doesn't see it that way. At least, they're not going to admit it in front of everyone, because the fact that you give them excess value is part of their advantage. It takes the pressure off them to invest in genuinely making the work experience better. It gives them the opportunity to threaten and frighten you with the typical "you need to work harder" pressures. They rely on your belief that this is normal and that you're stuck with them. This sounds cynical and extreme, especially to those people who think they work in a great environment, but wait until revenue goes down 30% over the weekend and see how things change. It becomes Lord of the Flies awfully quickly.
All this is to say: don't flaunt your decision to give less at the office. Do it discreetly. Start with 30 minutes per day. I bet that you could spend 30 minutes every day learning about things while at the office and nobody will notice the difference in your productivity.
What should you do with this 30 minutes? Learn something. Anything. I would limit it to learning something related to your job, but only because that's easier to justify to the people around you.
I spent hours learning about test-driven development when I worked at IBM. I read about it. I practised it. I literally nailed a copy of Ron Jeffries' seminal article "We'll Try" to the door of my office. I spent hours and hours hanging out on the various Yahoo! groups, at first asking questions on how to get pass little problems I had, but before long debating issues related to test-driven development, Extreme Programming, Agile software development in general, this strange "Scrum" thing, project management... the very topics that, by understanding them better, made me even more potentially valuable to my employer! Yes, it's true: I produced less code, but mostly because I stopped volunteering to fight fires (where I thought the action was) and mostly because I didn't need as much time to produce that code, and I didn't need as much code to produce more features. I became more valuable to my employers, but rather than give all that excess value to them, I reinvested most of it into myself.
Once again, all legitimate, ethical, moral, and so on. Your employer isn't buying your time; they're buying the value that they can extract from you. If you can deliver enough value in 4 hours per day, but they expect you to sit in that chair for 8 hours per day, then you have some flexibility in how to spend that other 4 hours. And eventually, it became 4 hours per day for me.
There were days that I walked in, puzzled how to write a test, and sat there, trying to figure it out. I would compose long, detailed questions to the Yahoo! groups. Sometimes, in the act of composing the question, I answered it for myself. (So-called "rubber ducking".) Sometimes, I needed to ask the question and wait days for an answer. Sometimes, I couldn't really make much progress until I got that answer. And it worked! I'm here, in a flat in Bucharest in the middle of a two-month tour or Europe, and not back in that office at IBM in Toronto. Something worked, anyway.
You can start with 30 minutes today of learning something that you can use to become more valuable to your employer. Start there. It's easy to justify. You can try installing a useful tool and learning how to use it. You can try reading a few articles or a chapter from a book. You can try opening up some tough part of the code and tearing it apart. As long as you do things that don't disturb the people around you, and as long as you continue to outperform enough of those people to keep your managers happy, and as long as nobody complains, then try again tomorrow. No commitment. Keep going until someone comments about it. Keep going until someone tells you to stop. (Probably no-one will tell you to stop.)
Turn your time and energy slack into greater opportunities for you in the future, whether they come at your current company or a different one. When they talk about taking charge of your own career development, this is what they mean.
Grab a timer. Set it for 30 minutes. Go. You can do it.
Laurent Bossavit, The Leprechauns of Software Engineering. A thorough discussion of the things we believe about software development, and specifically why we believe them even though they are not true and we know that they are not true.
Tom DeMarco, Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency. If you want options, then you need slack. If you want slack, then you have to learn to notice it. It's there. This books helps you find it.
The Big Books I Read At IBM
Just a laundry list of books that influenced me heavily in my early days at IBM. Classics, all, and listed in the order that they leapt to my memory.
Steve McConnell, Rapid Development: Taming Wild Software Schedules.
Steve Maguire, Writing Solid Code.
Andy Hunt and Dave Thomas, The Pragmatic Programmer: From Journeyman to Master.
Ron Jeffries, Ann Anderson, Chet Hendrickson. Extreme Programming Installed.
Alan Davis, 201 Principles of Software Development.
Tom DeMarco and Tim Lister. Peopleware: Productive Projects and Teams.
That's enough, I think. Enjoy.