I’ve been seeing quite a few posts on Hacker News lately about why you should not work too hard and even saying you should work less than 35 hours a week.
(Now, don’t get me wrong. I think the authors of these articles are awesome people who have accomplished huge things. I don’t mean to disrespect anyone of these great entrepreneurs. I just think some of them have confused where they are now, with how they got there.)
Would we ever want to live in a world where working harder didn’t amount to anything more, but rather ended up returning you less?
I know plenty of people who work less than 35 hours a week, and I wouldn’t say they are doing the best work of their life.
In contrast, I know plenty of people who are working 50 to 60 hours per week and they are doing some amazing things.
You have to work hard now to reap the benefits later
At the beginning of every episode of Pat Flynn’s podcast he says
“Welcome to the smart passive income podcast where it’s all about working hard now so you can sit back and reap the benefits later.”
There is no way around this. It is the principal of sowing and reaping at work.
While many well intentioned bloggers have urged you to not put in those extra hours at night, but rather to take time to do what you want and live a life outside of your work, they have forgotten the very path they took to get to where they are today.
If you are in that season of your life, then please take their advice. They are 100% right. There is this point of diminishing returns where you don’t gain much more benefit by spinning the wheel harder.
Ever rode a bike down hill really fast?
You know how at first you can start pedaling and it will actually make you go down the hill faster, but at some point the pedals just start spinning themselves?
You reach that point where you can’t actually move your legs fast enough to make much of a difference. Every couple of seconds, your foot will hit that tiny bit of resistance which tells you that you actually did something, but most of the time you are just spinning your loose pedals, not actually adding any speed.
It’s a pretty good feeling zooming down that hill with minimal effort on your part. There is no need to pedal furiously like you did to get up the hill. If you are pedaling furiously at that point, not only are you wasting your effort, but you are missing out on taking time to enjoy the best part of the ride.
You have to climb the hill before you can sail down it
Altitude change down, requires previous altitude change up. No way around it.
Pedaling a bike up a hill is hard work.
Not only do you have to keep working to move the bike up the hill, but every time you stop pedaling, you run the risk of rolling backwards.
The faster you want to get up the hill, the harder you have to pedal and the more you risk tiring out and rolling down the hill.
There is no rest, there are no breaks when pedaling up the hill. The best you can do is get off the bike for a while and walk it up the hill, but that will surely slow you down.
And so it is with life in general.
My personal hill
I’d like to buy into the story that we can just take it easy and good things will come, but the reality of the situation is that you’ve got to put in work first—hard work.
I started buying real estate when I was 18 years old. I bought my first house, which is a rental I still have today.
Since then, I’ve been buying properties at a rate of about 1 every couple of years.
It hasn’t been easy. Huge sacrifices to be able to do it, but from when I started I knew that I was pedaling my bike up the hill.
I also had been working as a developer full time for about the past 15 years. During that time, I was working nights and weekends to handle my real estate, building apps, and most recently creating online courses for Pluralsight.
Only at the beginning of this year was I able to finally quit my regular job working for someone else and start working completely for myself.
It took a lot of extra hours on nights and weekends, week after week for over 2 years to get there.
Just within the last year have all the real estate investments that I have been making for the last 15 years started to actually put some money in my pocket.
I’m still at the point where I am working 60 hour weeks just about every week. I am still climbing up the hill.
But, the good news is I can see the crest and I know that if I keep pushing down on those pedals, I’ll reach the peak from where I can coast down.
Don’t buy into the idea that there is someway to get around hard work.
Stop running away from hard work and start embracing it. I’ve learned from experience that it takes much more effort overall to avoid hard work than it does to do it, and avoiding hard work engenders no benefits long term or short.
Make the right sacrifices.
Don’t sacrifice your marriage or family in order to get ahead. In the end, it will put you behind. Remember, there is no more costly pursuit than divorce.
Make time to be with your spouse, set aside time to play with the kids every day, if you have them. Take a day off to have a family day.
Instead, sacrifice from this list:
- Watching TV
- Hanging out with friends
- Playing games
- Goofing around
- Browsing the web
Yeah, it might suck for awhile, but if you want to climb that hill now, so that you can cruise down it later, you are going to have to make some sacrifices.
Don’t waste your time.
Here is a list of things I don’t do:
- Cut my own lawn
- Wash my car
- Clean my house
- Any kind of home improvement work
I pay for these things and instead spend that time—not sitting on the couch watching TV—but working hard at what I do best. Working at doing things that will generate me more money than it will cost me to pay someone else to do the other things I mentioned in this list.
I use a service called Fancy Hands to handle many of the time consuming tasks I can delegate out. I have saved tons of time and money by using that service. (Disclosure: that link is my referral link to that site.)
Every time I am doing something, I ask myself if I should be paying someone else to do this. And if your time is escaping you completely, start tracking it.
Lighten your load.
Want to make it easier to pedal a bike up a hill?
Good, all you have to do is carry less stuff with you.
This means, get your expenses down. Start being smart with your money.
Pay off debts, don’t go into debt. Don’t be pennywise and pound foolish, but at the same time learn to live on less.
If you learn to live on 2k a month, guess how much you need to live? That’s right 2k.
If you have saddled yourself with debt and expenses that make it so you need 10k a month to live, you are going to have to pedal a lot harder… just saying.
(If you want to read a good book that helps you learn this mindset, read Rich Dad Poor Dad by Robert T. Kiyosaki.)
It all comes down to this
Be willing to work hard now in order to have a better, more relaxed tomorrow.
Don’t try to take shortcuts or get rich quick, those roads lead to disaster and wasted time.
Instead, if you are working a full time job now for someone else, give yourself 10 hours a week of “your time,” where you work for yourself.
Put in the time now to build that business on the side. Make that sacrifice for 2 years or 5 years or however long it takes to get your bike pushed up that hill.
Don’t give up, don’t be afraid to work hard, and don’t be sucked in by any preacher that preaches a fast way to riches and leisure by doing less.
Remember, those who show up everyday eventually beat out both the faster and the smarter.
What slows down the development of software?
Think about this question for a bit. Why is it that as most software evolves it gets harder and harder to add features and improve its structure?
Why is it that tasks that would have at one point been simple are now difficult and complex?
Why is it that teams that should be doing better over time seem to get worse?
Don’t feel bad if you don’t have an immediate answer to those questions. Most software practitioners don’t. They are hard questions after all.
If we knew all the answers, we wouldn’t really have these problems to begin with.
Regardless though, you’ll find many managers, business owners, customers and even software developers themselves looking for the answers to these questions, but often looking in the wrong place.
Process is almost always the first to be blamed. It stands to reason that a degradation of process or problems with the software development process are slowing things down.
Often there is some merit to this proposition, but I’ve found that it is often not the root cause. If your team is not sitting idle and the work that is important is being prioritized, chances are your process is not slowing you down.
Now don’t get me wrong here. I am not saying that these are the only two important aspects to judge a software development process, but I am saying that if generally your team is working hard on important stuff most of the time, you can’t magically improve process to the point of increasing productivity to any considerable order of magnitude. (In most cases.)
Often questions are asked like:
- Should we pair program or not pair program?
- Should we be using Scrum instead of Kanban?
- Should we be changing the way we define a backlog?
- Should we use t-shirt sizes or story points or make all backlogs the same size?
- Do we need more developers or more business analysts?
- Do we need to organize the team differently?
Now these are all great questions that every software project should constantly evaluate and ask themselves, but I’ve found over and over again that there is often a bigger problem staring us in the face that often gets ignored.
Let’s do a little experiment.
Forget about process. Forget about Scrum and backlogs and story points and everything else for a moment.
You are a developer. You have a task to implement some feature in the code base. No one else is around, there is no process, you just need to get this work done.
It might help to think about a feature you recently implemented or one that you are working on now. The important thing with this experiment is that I want to take away all the other “stuff” that isn’t related directly to designing and implementing that feature in the code base.
You will likely come to one of these conclusions:
1. The feature is easy to implement, you can do it quickly and know where to go and what to modify.
Good! That means you don’t really have a problem.
2. It is unclear what to do. You aren’t sure exactly what you are supposed to implement and how it fits into the way the system will be used.
In this case, you may actually have somewhat of a process problem. Your work needs to be more clearly defined before you begin on it. It may be that you just need to ask more questions. It may be that half baked ideas are ending up in your pipeline and someone needs to do a bit more thinking and legwork, before asking a developer to work on them.
3. Its hard to change the code. You’ve got to really dig into multiple areas and ask many questions about how things are working or are intended to work before you can make any changes.
This is the most likely case. Actually usually a combination of 2 and 3. And they both share a common problem—the code and system do not have a design or have departed from that design.
I find time and time again with most software systems experiencing a slow down in feature development turnaround that the problem is the code itself and the system has lost touch with its original design.
You only find this problem in successful companies though, because…
Sometimes you need to run with your shoelaces untied
I’ve consulted for several startups that eventually failed. There was one thing in common with those startups and many other startups in general—they had a well maintained and cared for codebase.
I’ve seen the best designs and best code in failed startups.
This seems a bit contradictory, I know, but let me explain.
The problem is that often these startups with pristine and well maintained code don’t make it to market fast enough. They are basically making sure their shoes laces are nicely tied as they stroll down the block carefully judging each step before it is taken.
What happens is they have the best designed and most maintainable product, but it either doesn’t get out there fast enough and the competition comes in with some VB6 app that two caffeine fueled not-really-programmers-but-I-learned-a-bit-of-code developers wrote overnight or they don’t actually build what the customer wants, because they don’t iterate quick enough.
Now am I saying that you need to write crap code with no design and ship it or you will fail?
Am I saying that you can’t start a company with good software development practices and a clean well maintainable codebase and succeed?
No, but what I am saying is that a majority of companies that are successful are the ones that put the focus on customers and getting the product out there first and software second.
In other words if you look at 10 successful companies over 5 years old and look at their codebase, 9 of them might have some pretty crappy or non-existent architecture and a system that departed pretty far from the original design.
Didn’t you say something about pulling up your pants?
Ok, so where am I driving at with all this?
Time for an analogy.
So these companies that are winning and surviving past year 5, they are usually running. They are running fast, but in the process of running their shoelaces come untied.
They might not even notice the shoelaces are untied until the first few times they step on one and trip. Regardless they keep running. And to some degree, this is good, this is what makes them succeed when some of their failed competitors do take the time to tie their shoelaces, but those competitors end up getting far behind in the race.
The problem comes pretty close to after that 5 year mark, when they want to take things to the next level. All this time they have been running with those shoelaces untied and they have learned to do this kind of wobble run where they occasionally trip on a shoe lace, but they try to keep their legs far enough apart to not actually step on a shoelace.
It slows them down a bit, but they are still running. Still adding those features fast and furious.
After some time though, their pants start to fall down. They don’t really have time to stop running and pull up those pants, so as they are running those pants slip further down.
Now they are really running funny. At this point they are putting forth the effort of running, but the shoelaces and pants are just too much, they are moving quite slow. An old woman with ankle weights power walks past them, but they can’t stop now to tie the shoelaces and pull up those pants, because they have to make up for the time they lost earlier when the pants first fell down.
At this point they start looking for ways to fix the problem without slowing down and pulling up the pants. At this point they try running different ways. They try skipping. Someone gets the idea that they need more legs.
I think you get the idea.
What they really need to do at this point though is…
Stop running, tie your shoes and pull up your pants!
Hopefully you’ve figured out that this analogy is what happens to a mature system’s code base and overall architecture.
Over time when you are running so fast, your system ends up getting its shoelaces undone, which slows you down a little. Soon, your system’s pants start to fall down and then you really start to slow down.
It gets worse and worse until you are moving so slow you are actually moving backwards.
Unfortunately, I don’t have a magic answer. If you’ve gotten the artificial speed boost you can gain from neglecting overall system design and architecture, you have to pay the piper and redesign that system and refactor it back into an architecture.
This might be a complete rewrite, it might be a concerted effort to get things back on track. But, regardless it is going to require you to stop running. (Have you ever tried to tie your shoelaces while running?)
Don’t feel bad, you didn’t do anything wrong. You survived where others who were too careful failed. Just don’t ignore the fact that your pants are at your ankles and you are tripping over every step, do something about it!