In the last year, I:
- Created and produced 30 full length video courses for Pluralsight
- Wrote 56 blog posts
- Produced 40 episodes of the Get Up and CODE podcast
- Created 50 YouTube videos
- Published a book
- Spoke at 4 events
- Billed over 100 hours of contract work
- Created a full product, that I am about ready to launch
- Ran 5 kilometers 3 times a week, every week
- Lifted weights 3 times a week, every week
I’m not saying this to brag–although I am certainly proud of these accomplishments. I am saying these things to prove that I know what I am talking about when it comes to productivity.
Being super productive
Right now–as I type–I have a timer ticking down. The clock shows approximately 14 minutes before I’ll take my next break. I live and die by this clock.
You may have guessed it, but the clock is a Pomodoro timer. For the last year, I’ve been religiously using the Pomodoro technique to not only stay on task, but to plan out my days and weeks.
If you aren’t familiar with the Pomodoro technique, the concept is remarkably simple. So simple, that I first dismissed it as ridiculous. But, thanks to my good friend Josh Earl’s success with it, I decided to give it another try.
You basically set a timer for 25 minutes. During that time you pick a single task to accomplish and work on that task, uninterrupted. After 25 minutes you take a break for 5 minutes and then begin again. After 4 cycles, you take a longer 15 minute break. (There are some variations on this, but that is the basic idea.)
Like I said, it seems pretty simple and unremarkable, but I can’t even begin to express how powerful this technique is for getting things done.
I’m lazy by nature. I have to constantly fight against the side of me that wants to procrastinate and slough off my work. The Pomodoro technique helps keep me focused by forcing me to work uninterrupted for a period of time. It also gives me a measure to compare myself against and realistic targets to aspire to achieve.
My week beings on Monday. On Monday morning I wake up and go to the gym to lift weights. When I get back, I have a protein shake and get to work.
The first thing I do when I get to my desk on Monday is start my Pomodoro timer and open up my “Weekly Plan” Trello board. I use this board to organize my week. It has nine columns. Seven columns for the days of the week, one column for today, and one column for done.
My first task of the day is to create the rest of the tasks that I think I can get done that week. I start off with a checklist of things that I know I need to do every week:
- Blog post
- Podcast episode
- YouTube video
- Newsletter email
- Buffer social network posts
Then, I add cards for the current projects I am working on for that week.
Once I’ve got all the cards I can think of on the board, I start tagging each card with a color that represents how many Pomodoros I think that task will take. I have three categories:
- Green: 1 Pomodoro
- Yellow: 2 Pomodoros
- Orange: 3 Pomodoros
If something is going to take up more than three Pomodoros worth of time, it needs to be split into multiple tasks.
Next up is planning the week. For each day of the week–unless there is something that will take up most of my time–I figure I can get about 10 Pomodoros done. This may not seem like a lot, but believe me, it is. I drag cards into the columns until I have filled up each weekday with 10 Pomodoros worth of cards. For weekends, I usually just drag in about three or four.
My estimates are always on the high side, but they are pretty accurate, because it is fairly easy to estimate based on half hour intervals–especially when many of your tasks are repeated each week. (For example, a blog post is estimated at three Pomodoros.)
I have a similar ritual every single day. The first thing I do, after exercising each day, is to open up my Trello board again and this time plan the day.
New things come up and other things need to get shifted around, so planning for the week alone is not sufficient. Often, I’ll have different tasks that I had vaguely identified at the beginning of the week which I’ll give more clarity to later on.
I first drag things over from the appropriate day into my “Today” column until that column is filled with about 10 Pomodoros worth of work. After that, I’ll take a look at the today columns and think about anything I might have missed that needs to get done that day. Finally, I’ll sort the “Today” column based on priority–I want to make sure I am always working on the most important things first.
Once I’ve got the day sorted out, I go back to the rest of the days in the week and move around cards until everything is balanced again. If I find that I’ve got some empty slots, I’ll create new cards and start filling those slots until I am back at full capacity again.
Once all the prep-work is done, it’s time to actually start working on tasks. I grab the first task off the list, start a timer and get to work. At about 5:00, I stop for the day and add up my Pomodoros. If I didn’t hit at least 10, I count on working a little bit that evening. If I did hit 10, it’s optional.
Why this works
So, you may be wondering why this works–why it is worth even writing about such a simple workflow. Well, even though this workflow seems really simple, there are a few key things going on here that aren’t immediately obvious.
First of all, I am using quotas to make sure that I accomplish the volume of work that I want to produce each week. I have quotas for how many blog posts, podcasts, YouTube videos, and other content that I need to produce each week. The things that are being measured by a quota get dropped onto my board first.
I’m also using a daily and weekly quota when it comes to Pomodoros. Pomodoros are little measurable units of work for me. I know that I should be able to get 10 done each day and that I should be able to get roughly 50 done in a week without killing myself. I know from experience that hitting 60-70 will cause a measurable dip in performance the next week and that if I am doing less than 50, I am slacking off.
Because I have those quotas in place, I know what is expected of me each and every week. I have the power to hold myself accountable to a real measurable standard. I can’t emphasize enough how important this point is. If you don’t have a way to hold yourself accountable to a standard that you want to achieve, human nature will cause you to fall way below the bar.
Another major component that makes this technique successful is the awareness of my capacity within a given amount of time. It is really easy to over or under estimate what you can get done in week, because you don’t normally have a ruler that you can use to measure task duration versus your actual capacity. When I start the week, I know that my capacity is about 50–I’ve got that much gas in my car. I get to choose where I want to drive that car that week–I can only go so far. I have to make a realistic prediction of what I can actually get done. From that prediction I have to prioritize my tasks so that the most important things get done first.
Without this understanding of my capacity, it is easy to fall into the trap of overestimating my ability to get work done and underestimating the take it will take to get the work done. With this system, I have a real metric to compare to. I know that I am not going to get 80 Pomodoros done in a week. I know that in an 8 hour day, I will not get 8 hours of work done. I am eliminating my biases by replacing them with real statistics.
Finally, the dedicated focus of the Pomodoro technique makes me more efficient at the work I am doing. When I am solely focused on one task at a time–without checking Facebook or Twitter–I work much more efficiently. Several studies have shown that multitasking causes a drop in efficiency. When I stay focused on a single task, I get much more done. I’ve written about this before, when I talked about quitting your job, but you can easily lose hours of time in a day to small distractions. Over the period of a year’s worth of time, all those wasted minutes can end up equaling weeks of lost productivity.
One huge benefit of this technique is that I am able to do most of this work without stress or guilt. Normally, when I am working, I always feel guilty about how much time I am wasting during the day. I also feel stressed about not getting as much done as I should be getting done. This situation of stress and guilt actually ends up being the perfect breeding ground for procrastination and burnout.
When I am using the Pomodoro technique, I don’t feel the guilt of wasting time, because I know that as long as I get done 10 Pomodoros in a day I have reached my productivity goal for the day. If I get more done, great.
I also don’t feel stressed about getting as much done as I should have, because how much I get done is no longer what is being measured–I’ve taken the burden off of my shoulders. My focus has shifted from results to process. I can’t control the results. Work takes as long as work takes. But, I can control the process. If I put in my 10 Pomodoros for the day and I have sufficiently prioritized my work, then I have done the best that I can do–no need for guilt, shame or stress.
Time for a break
If you are interested in getting started with the Pomodoro technique, I’d recommend checking out Pomodoro Technique Illustrated. And if you have any questions about my process and how it works, feel free to ask and I am happy to answer them in the comments below.
Also, if you liked this post and are interested in more of what I have to say about being productive and boosting your career, sign up for my weekly newsletter here. You also might want to check out the course I am putting together called “How To Market Yourself as a Software Developer.”
The best way to guarantee success in almost any pursuit is to be prolific. Not all successful people are prolific, but almost all prolific people–regardless of vocation–are successful.
When you take so many swings at the ball, it is hard to not eventually hit a home run.
Rewards are unfairly skewed towards the top.
I used to be addicted to playing poker tournaments online. I would spend countless hours in the evenings with multiple poker tables open, happily clicking away as I could hear the mechanical chk chk chk of the computerized dealer dealing me out hand after hand.
A typical breakdown of a poker tournament prize pool goes something like this:
- 1st place = 25%
- 2nd place = 15%
- 3rd place = 10%
- 4th and lower = remaining 50%
Half of all the money goes to the top 3 places. A quarter of it goes to 1st place.
In a poker tournament, you want to win first place.
This same kind of payout structure exists in many areas of life. You see it everywhere you look. 1st place gets the big bucks, the endorsement deals, and a unfair share of the glory. 2nd place and lower get much less.
As Ricky Bobby says, “If you ain’t first you’re last.”
Because so much of life is weighted to give those who end up on top a lion’s share of the bounty, it makes much more sense to take a lot of big swings than it does to take a few little swings.
Keep swinging that bat as hard as you can, and even if you have your eyes closed, you are bound to eventually connect with the ball, and when you do you are going to knock it right out of the park.
Rarely when you find someone who is wildly successful, do you find them taking small carefully calculated conservative steps, instead you find them wildly flailing in every direction until success just walks right into one of their haymakers.
One of the most famous examples of prolific people who produce amazing results is Thomas Edison. (By the way, if you don’t know what prolific means, it basically means producing a lot.)
Thomas Edison had 1,093 US patents in his name. That means he basically invented a new thing every single day for the equivalent of 3 years. Imagine waking up every morning and filing a patent for 3 years–talk about being productive.
Here is another example. You’ve probably heard of the famous romance and fiction novelist Nora Roberts. Any guesses to how many books she has written?
She has written over 208 novels. Not blog posts, not eBooks–novels.
She doesn’t use a ghostwriter. She doesn’t have a research assistant. She does it all herself and she publishes about 5 complete novels a year. I can’t even imagine writing that much.
Want to know how many blind swings Nora Roberts took before she knocked one out of the park?
Well, she got rejection letters for her first 6 books and got her first book published in 1981. From 1982 till 1984 she wrote 23 novels which were published and she didn’t make the New York Times Best Seller List until 1991 when she had already produced close to 100 novels–that is a whole lot of swinging.
Now, every single novel she has published since 1999 has been a New York Times bestseller.
I want you to stop and think for a minute about how many authors or would-be-authors write one book or two books or even 10 books and give up. Think about it. If it took Nora Roberts almost a hundred tries to hit a home-run, why do so many people think they can do it in one?
I used to be lazy
I used to produce almost nothing. Weeks would go by and I would have no real tangible asset which I produced. During those times in my life, I wasn’t a failure, but I wasn’t going anywhere. I was just sort of floating in the pond.
But, one day something changed. I can’t quite tell you what it was, but something lit a fire under my ass. I started being productive. I turned off the TV, put the XBox controller down and started producing instead of just consuming.
I went to work and I tried to see how many backlogs I could get done in a day. I got home and wrote blog posts and created Android apps. Everyday I was doing something. Everyday I was taking big swings and stepping into them–hard.
Then one day, crack–my bat connected with something.
I got a chance to do some developer training videos for Pluralsight.
I took a bunch more swings, producing courses as rapidly as I could. 3 years went by and somehow 54 courses manifested themselves out of nights and weekends of sitting in front of my computer recording. crack! crack! crack!
It started to become harder to miss the ball than it was to hit it.
Lazy me had become… prolific?
By the way, one of the first books that helped me become more productive was Getting Things Done by David Allen, I highly recommend reading this book if you’ve never read it before.
Also, if you are having trouble staying on task and actually producing the work you know you should be producing, read one of my all time favorite books, The War of Art by Stephen Pressfield. This book will kick your ass.
Quantity breeds quality
Many software developers focus on quality. And while quality is important, it can’t be manufactured on its own. You can’t force quality to appear. It takes practice; it takes quantity to produce quality.
If you want to become a better developer, write more code. Produce some applications. There has never been an easier time for a developer to publish their own application, whether it be a web application, mobile app or even a standalone desktop one.
If you want to write good code, you need to write a lot of it. No matter how hard you try, you aren’t going to write better code by gritting your teeth and concentrating really hard. You’ve got to be actively producing code and solving problems if you want to produce better code and solve harder problems.
It’s not that quantity beats quality, so much as it breed quality. The more you produce the better you become at producing.
Back to you
If you want to guarantee success, more than anything else, you need quantity. You can’t just assume that your first try is going to be successful, you’ve got to assume it is going to take 5 tries or 10 tries or maybe even 100 tries to hit a big success.
Far too many people give up early and far too many people aren’t willing to put in the hard work that is required to be prolific.
If you are having trouble hitting your stride it may be because you just haven’t stuck with it long enough.
Your first application might not be a success. Your first attempt at solving a difficult problem may be a dismal failure. But, the question is, are you going to keep trying?
If you want to be successful, you have to learn how to produce. You’ve got to learn how to put a crank in your back and wind that thing up until you can’t turn it any more.
Are you going to be the kind of person who takes a few halfhearted whiffs at the ball and gives up? Or are you going to be the kind of person that is there day after day, swinging that bat, knowing the outcome will come if you only are willing to put in the time?
Prolific people generate prolific results.
What is it that you could be doing, but you’re not?
If you like what you’ve read, please take a moment to sign up here and become part of the Simple Programmer community.
I write quite often on this blog about starting a side business or becoming self-employed, but one of the biggest struggles in getting something new started is finding time.
The same goes for getting fit and getting in shape.
So, if you want to be successful in your career, or in life in general, it is really beneficial to find out where you are wasting your time—so you can stop wasting your time.
I’ve found there is one major time-waster out there that many of us indulge in. One that can easily be cut out, or at least reduced significantly, to give you back much of that time you are wasting each day.
I’m not going to give away the answer here, but you can probably guess what it is already.
Check out my video for this week below and let me know what you think.
In this video I talk about how important it is to build a routine for yourself.
I’ve found that having a routine, while boring at times, is really important for long term success. I used this technique to get 30 Pluralsight courses created this year alone and 54 overall.
Watch the video to find out why I think having a routine is so important.
This is the 3rd post in a three part series about quitting your job and working for yourself. Check out the first post about why you should want to quit your job, and the second post about the fantasies and realities of quitting your job.
I want to start off by saying that I, myself, have had several false starts and I’ve witnessed countless others who think that they are going to quit their job and live their dream only to wash up, shipwrecked on the shores of reality.
I’ve already talked about the harsh realities of working for yourself. If that part didn’t scare you at least a little bit, or you think that what I said doesn’t apply to you, there isn’t much point reading any further, because this advice won’t help you either.
But, if what I said earlier made you sweat just a little bit; made you just a little bit more unsure of your brilliant plan, then you’ll probably find the advice I offer here immensely useful (I wish I would have had this, advice when I started out.)
Transition into working for yourself
Now, for some people this ends up working out. These are the people you hear of that quit their job to follow their dream and then they created some startup company that got purchased for millions of dollars. Some people also win the lottery and others, unfortunately, get hit by lightning.
But, what you don’t hear about is all the people who quit their jobs to follow their dreams and end up wasting a year or two of their life eating up all the savings they have accumulated from the past 10 years while they suffer from a bout of writer’s block that never ends up being cured.
The truth is, working for the man is quite a bit like slavery or prison. You can’t just be set free and expect that you’ll adapt comfortably to your new life and start fulfilling your dreams. It is a bit like when you get off that 6 week diet you were on and say “ok, I’m just going to pig out a little as a reward, then I’ll get back to ‘normal eating.’” What ends up happening is this instant transformation from the shackles of a restrictive diet to “free eater” doesn’t land us in the comfortable norm of “normal healthy eater” like we’d expect. Nope, instead we take a 1 way ticket to pig-out land until we eventually come crawling back to the comfortable diet prison that we hated, yet required.
The same happens to software developers, and other professionals who go from working for the man to being the man– they can’t handle it! They go nuts, and waste lots of time being unproductive without the structure of a workplace and someone cracking the whip on their back. Eventually, they crawl back to their cruel masters and begrudgingly reenter the rat race.
The problem is that working for yourself requires self-discipline. More than you’ve got right now. Yes, I know that your parents and friends have commented on how self-disciplined you are because you have excelled at your job by actually showing up to work each day and doing your job, but there is a huge difference between doing what you are supposed to do because you are supposed to do it and doing what you are supposed to do, because there are immediate and dire consequences if you don’t.
Stop shaking your head for a moment and listen to me. I know you think you are better than that, but you aren’t. Take a deep breath, dig deep and realize what I am saying is true. If you really want to succeed on your own, you are going to have to learn this skill as well; seeing an unfiltered view of reality.
In order to be ready to be successful on your own, without a boss, without a formalized structure and system of consequences, you are going to have to exorcise a few demons.
The best place to perform this religious rite is at your current workplace, in your current job. You will use this as a transition period and training ground to prove yourself, before you cut loose your chains.
The first demon: productivity
In my last post, I talked about the fantasy and reality of working for yourself and really what it focused on was the most critical component: productivity.
These days, productivity is like a drug; lots of people are peddling productivity hacks and productivity tools as if productivity means more than just working hard on what you are supposed to.
The trick is that it is much easier said than done. As I highlighted in the last post, most of us are spending very little time actually working productively at work. And, you will probably be in for quite a shock when you lose your shackles and find out that you aren’t getting nearly as much done as you thought you were– oh, and now you aren’t getting paid for goofing off.
So, my advice is: before you quit your job, you need to actually be able to put in a 6 hour day of hard work. No better place to practice doing that than in a paid learning environment.
How do we get there?
It isn’t going to be easy. But, nothing ever is, right?
I use a productivity technique called the Pomodoro technique to both measure and help me achieve a high level of productivity. The idea behind this technique is pretty simple. So simple that I actually overlooked it the first time I had been introduced to it and only later came back to it when a friend of mine, Josh Earl, mentioned how much success he was having using it.
The idea is that you set a timer for 25 minutes. During this time, you work on one focused task without interruption. After you are done, you take a 5 minute break and repeat. Nothing magic here. The magic is actually in the measurement. You see how many of these you can get done in a day and you track them. You can actually then plan out your work and estimate your work in terms of Pomodoros, which it turns outs, is extremely useful.
I’d recommend getting this book, Pomodoro Technique Illustrated (Pragmatic Life), to learn more about this deceptively simple seeming productivity tool.
I’d recommend starting to put this into practice at your regular job. Try to achieve 8 Pomodoros a day. This would represent close to 6 hours of productivity. And only count time that you are actually being productive. This means producing something of tangible value. You are going to end up not replying back to lots of emails and dismissing yourself from a bunch of meetings.
The second demon: gold-plating
On someone else’s dime it is pretty easy to forgo pragmatism. But, something I had to learn really quickly when I struck out on my own is that good enough really is good enough.
Don’t get me wrong. I’m not saying do shoddy work. And you already know that I’m not advocating not working so hard. What I am saying is, if you want to be super productive, you can’t make every piece of work you do a masterpiece. You have to find the right balance of time and effort.
Take this blog post, for example. I’m putting quite a bit of work into this post and the series of blog posts it belongs to, but I could actually spend weeks or months writing and rewriting parts of this post. If I did this, I might end up with a true work of art at the end of the process, but I’m not going to do that. Instead, I’m going to ship it when it gets to the 80-90% effectiveness mark and not worry about squeezing out that extra 10% of quality for another 300% cost of time and effort.
Don’t take this as an excuse to do s!*# work and ship a bunch of crap. That is easy, anyone can do that. Instead focus on being pragmatic. Get to the point where the work is good enough and let it go, then move onto the next thing. This is much harder than you might think– it is a delicate balance.
The third demon: consistency
Success is usually not the result of a glorious fight with a single dragon which you vanquish in a fierce battle, instead the road to success looks much more like running around Midgaard naked, killing rats over and over again.
Working hard and being pragmatic is completely worthless if you can’t do these things consistently week after week month after month. It is like starving yourself for a day and thinking you are going to lose weight, or running a marathon and sitting on the couch for the rest of the year.
So, how do you learn consistency? Simple, you cut out all the excuses. Make being consistent a matter of life and death. Don’t act like failure is an option. Pretend like just missing a single day or skipping a beat is the end of the world.
Eventually, you’ll be able to use your judgment to decide what you should do and when to make exceptions, but for now make rules for yourself. Rules that you will not break under any circumstances. Learning to live by rules like this will be a huge benefit to you. Everyone is weak-willed, no one can resist temptation; if you want to be successful, avoid judgment calls and decision making. Make your decisions ahead of time and codify them as rules that you follow every day.
I’ll give you an example, before I wrap up this post, because it is already getting quite long. Right now I am learning Spanish. I am using an app on my iPad called Doulingo to do this. I have a rule that I do this app at least 30 minutes a day, every day– no excuses. What do you think will happen if I obey this rule every single day for a year? I think I am going to be pretty good at Spanish. Unless I stick my finger in an electrical socket and fry my brains, it will be pretty hard for me not to succeed, so long as I follow my rule.
The hard part
If I haven’t lost you yet, you must really be serious. Good. You are going to need to be serious to stomach what I am going to tell you next.
At this point, if you start right now, you are probably still at least two years out from the point where you are going to be able to quit your job and not end up coming crawling back to the rat race battered and beaten.
I see far too many people come up with the ill-conceived plan of saving up perhaps 6 months to a year’s worth of living expenses and then quitting their job to pursue their dreams of starting their own business. (I’ve entertained this idea myself several times in my career.)
But, let me tell you why this is a very bad idea and then give you a much better one– a plan that will actually work and isn’t likely to leave you homeless or broke.
The reason why saving up a bunch of money and quitting is a bad idea is, because if you do this, you will be constantly racing against time. Instead of time working for you, you will have time working against you. You’ll make bad choices, you’ll feel panicked, you will not be operating under ideal conditions and you won’t be giving yourself room to fail– which you will inevitably do.
Here is a better plan. Instead, of thinking in terms of saving up X amount of dollars, think in terms of earning X amount of monthly income from a side business. Whatever business you plan on creating once you quit your job, start doing it now. Start building you future business while you are still working for the man. If you can’t get something going on the side without the stress and pressure of potential financial ruin, you aren’t going to succeed when you go it alone and add all the extra pressure and stress that comes with being self-employed and not getting a pay check.
Sure, it will take you longer. Sure, it is going to be hard to essentially work two jobs, but the question is, how bad do you want it? If you don’t want it that bad, fine, I’m not going to try and convince you otherwise– to each his own. But, if you really want it, and you are willing to both work and wait for it, then do it the smart way; build your business on the side while you are still getting a regular paycheck.
Well, I hope this series was helpful to you. I’m not an expert by any means on the subject, but I can speak from personal experience, and I’ve talked with enough other people who have made the transition to know that what I am telling you here is not my advice alone.
When I first quit my job, I was shocked at how different life was from how I had imagined it would be. I had to make some big adjustments really fast, because I wasn’t prepared. Hopefully, after this advice, you won’t find yourself in the same situation, or at least you’ll have a rough idea of what to expect and how to deal with it.
This is part two in a series about quitting your job. Check out the first post here.
Imagine you are going for a run in your neighborhood; just a casual jog. You are running along comfortably, not really straining that much or breathing heavy, but making good progress. Now imagine that all of the sudden a tiger jumps out of the bushes and starts chasing you.
What do you do?
For the longest time I had this fantasy of quitting my job and working for myself. Well, actually my real fantasy was playing video games all day and not having to work at all, but even fantasies need to have some basis in reality, so I modified it to be a little more reasonable.
Anyway, I always wanted to be my own boss; to work for myself. I thought that life would be so much better if I had more control over my life; if I could come and go as I pleased and set my own work hours.
Now that I’ve actually done it, I’ve found that working for yourself is not exactly as I had imagined it… let me explain.
The 8 hour fantasy
One of the main things I thought about when I had dreams of working for myself was just how much I could accomplish if I had 8 full hours in a day to work on goals and projects that I set for myself.
For a couple of years my life was pretty miserable. I would work 8 hours during the day for my employer and then when I was done doing my first job I would take a little break to eat dinner and spend some time with my daughter and then back to work for another 4 hours doing Pluralsight courses at night. Weekends usually involved at least another 4 or so hours of doing Pluralsight courses and perhaps another 3-4 to create a blog post each week.
I kept thinking to myself that if I could work full time on the Pluralsight courses I would get an additional 4 hours a day and not even have to work nights. I should be able to get twice as much done and work far fewer hours during the week.
I ran some calculations to see if the payment for creating Pluralsight courses would cover the income I made from my regular job if I produced twice as much content. The numbers seemed to say I would come out pretty far ahead, so as far as I was concerned “quitting my day job” was a no brainer.
The 8 hour reality
My first week of working for myself turned out to not be the fun lighthearted adventure I had set out on.
When the end of the first week had come, instead of completing 4 to 5 modules of a Pluralsight course, like I had anticipated, I had actually only barely completed 3, and that was with me putting in the same 12 hour days that I had put in before quitting my job.
Something was wrong; something was seriously wrong. Working a full time job I was completing 2 modules a week, so if I had 40 extra hours in the week, shouldn’t I have been able to easily get done another 2 more, perhaps even 3 more?
I shook it off as just a fluke. The particular course I was working on required a large amount of research and prep-work as well as scripting out paragraphs of text for each slide—it must have just been bad timing.
The next week I fared a little better, but still not anywhere close to what I had anticipated. I got 4 modules done but it still required around 12 hours of work each day during the week and some on the weekend; the math just didn’t add up.
Here I was busting my butt for only slightly improved results over what I was getting before.
There is work and then there is work
I bet you are probably wondering what exactly happened at this point. What can explain the results I was seeing?
You see, at a job you get paid just for showing up. Now I don’t mean to say that you can just sit at your desk and do nothing all day, but in reality you can just sit at your desk and practically do nothing most days at most jobs.
Again, I don’t want to make it seem like I wasn’t working hard for my employers. As an employee, I have always worked hard and done a good job, usually performing well beyond the level that I was expected to perform at. But regardless for how hard I ever worked at any job, I never worked so hard as when I started working for myself.
The reality of the situation is that even the hardest desk worker I know who is working for someone else usually only actually works less than 4 real hours in an 8 hour day. I would actually venture to guess that actual hard nose-to-the-grindstone hours would probably average about 2 per day.
Now, before you get all upset about what I am saying, let’s take a moment to think about why this is.
There are a number of reasons why employees work much fewer hours than the hours they are on the clock. The first, most obvious reason is because they are getting paid by the hour and not the job. When you are getting paid by the hour you have no real motivation to be fast or efficient or to make sure you are working every minute of every hour.
This means that a task that would perhaps take you an hour to do if you were working as diligently and as hard as possible, might take you 2 to 3 hours if you are working, but just not working hard at the task.
Think about the difference between jogging down the street and running for your life because a man-eating lion is chasing you. It isn’t like you are being lazy when you are jogging down the street, it is just that you aren’t in any real rush.
Another major source of distraction is office conversations. In most work environments, people socialize. It is not unreasonable to assume that 2 hours of each day, on average, is eaten up by socializing about non-work related topics or remotely work related topics.
Let’s take another slice out of that 8 hour pie and account for general job overhead. This would be things like checking your work email, reading bulletins and memos, attending pointless meetings, etc. I’ll be absolutely ridiculous and assume this kind of thing only takes up an hour of time a day on average, (although we really know that it probably takes up much more.)
Finally, we get to just plain laziness and doing personal stuff on company time. Life is life and things happen. Your kid gets called into the principal’s office and you get a call at work about it that you have to deal with. You are buying and house and need to fax those loan documents to your mortgage broker. Sometimes you get to work and you just feel burnt out and tired and can’t really manage to do much other than pretend to code while you scroll repeatedly through lines of code waiting for the clock to tick 5:00.
I’ll be nice again and attribute this to only taking up an average an hour a day, but based on my Facebook and Twitter streams, I am pretty sure we all know that number is greater than even the most candid of us will be willing to admit.
So let’s go ahead and do the math. Take your 8 hours and subtract away 2 hours for socialization. That leaves you with 6 hours. Take away 1 for work related overhead and another 1 for life related overhead and laziness and you are already at 4 hours right there. Now take the 4 hours of work that could be done at a running pace and reduce it to a jogging pace, and you are effectively cutting it in half to about 2 hours of actual real work. If you come in late or leave early or you are more social or more lazy or you have more meetings than average, the number could even be further reduced. Some of you might be coming up with negative numbers. It is a wonder anyone gets any work done at all!
So, where did my hours go?
Just because you switch from working for someone else to working for yourself doesn’t mean that you immediately go from getting 2 hours of work done a day to a full 8. Some of the office distractions are eliminated by working for yourself, but others are not.
Most importantly though, there is a big difference and adjustment from being used to working 2 actual hours of real hard work to working 6 to 8 hours of real hard work.
It is sort of like going for a 3 mile jog every day for a couple of years than suddenly one day deciding to start running 12 miles instead. You might be able to do it, but you are going to feel like total crap until you adjust.
It turns out for me that my old routine, before I quit, was working my regular job during the day, which wasn’t all that taxing on me, then working 4 hours each night, at which time I would accomplish perhaps 3 hours of real hard work.
Each day I was perhaps doing 5 hours of real hard work.
When I started working for myself, I found that I was actually doing about 5 hours of real hard work during the day and by the time the night came, I would work perhaps 4 hours, but was so exhausted that I was only getting about 1 hour of real hard work done.
So overall, I was only adding about an hour or two of actual real work worth of progress each day. This lines up about perfectly with the results I was seeing. I was still having to work the same number of hours and I was just getting marginal improvements in my results.
Tracking my time
I’ll put things as civilly as possible here, but to say the least, this was royally pissing me off.
I mean, I was not happy at all with this revelation I was discovering.
I thought long and hard about different jobs I had and what I did during the day at work. I tried to count up the hours and determine if it was really true that I was only spending a couple of hours of real hard work, on average, a day at any given job. Then, I thought about how at most jobs I was getting a lot more work done than most developers were and it made me even more sad.
I decided to start tracking every minute of every day I spent doing work on my Pluralsight courses and whatever else I was working on during the day in order to see where my time went.
My results after several weeks confirmed what I had already known. In any given day, I was lucky to get 5 hours of solid work done during the daytime and 6-7 hours overall in the entire day was about the average.
I was also busting my butt harder than I had ever before.
Summing it up
So, what am I trying to say here? What can you learn from my experience?
Well, first of all, working for yourself is much harder than you might imagine. When you are working for yourself, you are only getting paid if you are working. You don’t just show up and get paid.
You may think you are busting your butt at your job now, and you may very well be, but I can almost guarantee you that you are not working nearly as hard as you would if you were working for yourself. There is a huge difference between doing 2 hours of hard work per day and 6 hours or more of real hard work per day. If you aren’t ready for this change of pace, you can easily be crushed and discouraged by it.
You might just think that this doesn’t apply to you; that you can just sit down at 9:00 AM, plug in your headphones and work hard until 5:00 PM when you disconnect and smile happily at your 8 hours of good old hard work you put in that day.
But, if you are of this mindset, I’d encourage you to do two things before quitting your day job. First, take a week off and try it out. During that week track your time and see how much work you actually get done. Only count work that results in you creating something you get paid for. Don’t count all the overhead and checking emails, etc.
Second, after you see how dismal your results are, get a copy of “The War of Art” and learn that you are not alone. We all struggle with the same problem of being lazy creatures who want to do what is pleasurable instead of being productive and habitually rationalize all our actions until we are reduced into believing that the course of action we are taking is the only possible and reasonable choice.
I’m not saying don’t quit your job. In fact, I encourage you to find a way to build your own business and work for yourself. But, just realize that if you don’t like the idea of working hard every single day you probably won’t like working for yourself very much.
I recently wrote a post called The Hacker News Generation (Afraid of Hard Work.) Ok, the post itself wasn’t so recent, but it recently got a large amount of traction on Hacker News and I was surprised to see such a large and vocal negative response to what I said. Of course, I expected there to be some kind of negative reaction to telling people to work hard and stick with things even if they don’t like them.
But, I do think that I did not communicate part of the message I was trying to convey as well as I could have, so here my attempt to clarify some points.
First off, I think it is important to admit when I am wrong, and I was wrong about two things.
- I shouldn’t have make such a sweeping generalization about an entire generation. As many people pointed out, this is not a generational thing, this is a very personal thing. The truth is we are all afraid of “hard work,” myself included. Some of us learn to overcome it, others of us don’t. The problem is not the next generation. The problem is the message that many of us are lifting up saying that you can get somewhere by being smart or hitting the start-up lottery, instead of from being wise and willing to do the work.
- It appears I was wrong about Loren. I didn’t mean to lambast him personally. I originally felt like the sentiments in his blog post were exactly the kind of thing I had a problem with today in our field. People saying they quit something because it wasn’t interesting and deciding to follow an uncharted road instead without a real plan of any kind and without a clear focus in a particular direction. Since then, Loren has actually produced some awesome software that I am actually alpha testing to write this blog post. Kudos to Loren, it appears I had you pegged wrong. I am earnestly happy to be proven wrong.
Are you saying that mental illness isn’t real and people just need to “man up” if they have depression or real “burnout?”
No. Well, perhaps a little– let me explain.
So, most people who claim to have depression or burnout just have a case ofpansyitious. I’m not saying that you can’t actually be clinically depressed or physically and mentally overworked to the point of total exhaustion or mental breakdown. Sure, you can. But, if you are reading this post, it is more likely that you just need to suck it up and figure out how to stop avoiding the work you need to be doing and do it.
People who actually burnout physically and have nervous breakdowns mentally are not people who push themselves too hard pursuing their dream or reaching their goal. They are people who push themselves too hard pursuing other people’s dreams, reaching other people’s goals.
You know what you need to be doing. I don’t need to tell you. Maybe you know that you need to stick with that crappy job you have right now for the next two years while you build the thing you really want to do on the side 2 hours a pain-staking-night-a-time.
Get off the couch. Turn of the TV. Do it!
Stop commenting on blog posts about how stupid and preachy other people are and write a blog post, build a business, create something. I’m not the best writer in the world, some of my ideas sound like the rantings of a mentally slow 5 year old, but at least I am doing something, creating something– and working hard at it.
Do you need some motivation? Need a good kick in the butt from someone who is way more successful than I am, but shares exactly the same view? Read Steven Pressfield’s book, The War of Art. Seriously, will be the best book you read all year.
Are you saying I should stick at a crappy job and do something I don’t like?
No. I am not sure why some people got this message from what I said. When I complained about Loren quitting his job, I wasn’t faulting him for quitting a job he didn’t like anymore.
The big issue I had was his reason for quitting was, as he stated, “being bored.” He explicitly said that he didn’t find a new job, didn’t start a side business, or anything else.
If you don’t like your job and you don’t like your life change it, but don’t do it on a whim, don’t do it because you are bored, and have a plan– a good one.
Also, recognize that you have to sometimes do s!#& jobs and that is just how it is. But, you have the choice to look at those times as an apprenticeship or as prison time. How you perceive it is up to you. If you are smart, you’ll bide your time while working for someone else, as you are careful not to use up all of yourself and learn as much from them as possible, all the while building your own thing on the side.
Sometimes to do this, it takes grit, plain and simple. If you don’t have it, fine, but let’s not mash words and play pretend games here.
Passion dies. It always dies.
You may be too young to understand this. I can’t fault you for that, but believe me, trust me, when I tell you that passion always dies. It doesn’t matter what your passion is for, indulge in it enough and you will lose it.
What is my point in saying this?
Simple. The dream you are following today, will be the prison you’ll be trying to escape from tomorrow.
This means that if you are ever going to do anything meaningful, you are going to have to learn to see things through to the end. This isn’t easy. It is really hard. I’ve got a whole closet full of good ideas that I took to 90% and then got bored with. Every single one of them at one time in my life was my greatest passion.
So, again. I’m not saying put on the fireman hat everyday and just grit through it when you really want to be an astronaut. What I am saying is that which thing you pick isn’t really all that important, so long as you are doing something, and stick with it and continue to force yourself to learn and grow in whatever thing you are pursuing even after the passion is gone.
Do you hate Loren and are you just a mean guy who like to pick on people?
No, I like Loren. That is why I don’t want to see him financially broke, wasting away years he could be using to either build a business or product of his own, or at least work for a company long enough to sock away enough money to one day have the actual freedom to spend his time as he likes.
And it turns out, Loren is doing something pretty awesome. I can’t tell you if he’ll stick to it long enough to see it to the end or not, but I hope he does. And, I am very glad that he didn’t decide to just do whatever he felt like doing and narrowed down his focus to Penflip. Ironically, I am sitting here writing this blog post on Penflip, the project the Loren created, that is in alpha mode right now.
I sincerely hope I get the chance to sit down and have lunch with Loren some day and that we can really hash out what it means to pursue something you care about deeply and the kinds of sacrifices and risks it involves.
I don’t pretend to have all the answers, even though my writing may make it sound like I think I do. I just write passionately about what I think. And what I think is always subject to revision. I am learning. This blog is one of the ways I am learning and sharing what I learn.
The reality of the situation is that there are two extremes we have in life and work.
On one end of the spectrum is pursing your passion without compromise; doing what you are called to do. We’ll call those people starving artists.
On the other end of the spectrum is pursuing money above all else. Lie, cheat and steal if you have to; sell yourself out; do whatever it takes– it doesn’t matter, so long as you bring in those Benjamins. We’ll call those people the passionless hacks.
Neither one is good. You’ve got to find the middle. If you spend all your life working hard pursuing money, never finding something that you actually care about and that is meaningful to you, you’ll end up washed out with nothing to show for it besides a big bankroll, if you are lucky.
On the other hand, if you just do what you like all the time and never hunker down and put in the work and think about the financial consequences of your actions, you’ll end up washed out, but poor.
The middle ground is where success is. It is where people find things that they are passionate about, that are meaningful to them, and they pursue them with the vigor of the passionate artist when they have the motivation and with the whatever-it-takes dedication of the passionless hack when they motivation wanes.
Most people, especially young people today, are on the side of the starving artist mentality. They want to ignore the reality that they may have to work a 9-5 job and build the thing they really want to build on the side for a few years so that they can some day leave the employ of another and do their own thing, the thing they are passionate about.
How I am trying to help solve this problem
I’ve made a large number of mistakes in my career, but I’ve also figured out what works and have learned how to work hard and stick to something. I think this is valuable information, so I’ve decided to package it up along with things I’ve learned about marketing yourself as a software developer and other career tips.
If that sounds like something you would be interested in, sign up here and I’ll let you know the second this project launches. I appreciate your support and hope that what I am building will be useful to you.
What is the hardest thing about writing code?
There are many common answers to this question:
- Learning a new technology
- Naming things
- Testing your code
- Fixing bugs
- Making software maintainable
The list goes on and on.
But as I reflect back on my programming career, and I’ve conversed with many new programmers that are learning the craft, I’ve found the single hardest thing about programming is learning the problem domain.
A familiar problem
In a good portion of my Pluralsight courses I show the viewer how to build the “Protein Tracker” application.
I am often asked why I keep demonstrating how to build the same simple application over and over again in each of my courses.
The answer is “familiarity.”
When I first started using the Protein Tracker example in my Android course, I was just looking for a simple example of an application that could be easily understood and implemented.
The idea behind the Protein Tracker application is that it allows a user to set a goal for the amount of protein to consume in a day. The user can add protein amounts which are added to a total protein count that is tracked for that user.
Very simple functionality, easily explainable, but most importantly, easily understood.
What I found with this simple application was that because it was so easy to understand, the focus was taken off of the problem domain and put instead on the technology.
Not only this, but as I reused this same exact application for teaching a variety of different technologies, it served as a reference problem domain that didn’t have to be re-learned, and provided a way to compare and contrast different technologies—I was getting this teaching mechanism for free if a viewer had already watched one of my other Pluralsight courses.
By creating a familiar problem domain, I found that both the tasks of me teaching a new technology and the viewer learning that technology were much easier, because it is very difficult to learn more than one thing at once.
So what am I trying to say here?
Simply that by taking away the problem domain, or making it so trivial that it is easily understood, I am able to make both teaching and learning easier.
Why problem domains are hard
Have you ever tried to put together a jigsaw puzzle that didn’t have any picture on it? How about one like this one, that has a very similar pattern repeated on it and is double-sided?
The reason why puzzles like this one are so hard, is because you can’t really see what you are trying to build very clearly. Normally when you put together a jigsaw puzzle you follow steps that might look something like this:
- Figure out what the major components of the picture are
- Sort the pieces by color or component
- Put together all the border pieces
- Put together each component of the picture from the piles you created
This all breaks down when you don’t have a picture with clear components that you can identify.
The same thing happens when writing code. Writing code is a lot like putting together a jigsaw puzzle. We put together code with the purpose of building components that we have taken out of the “bigger picture” of the problem domain.
The big issue is that many problem domains are like a puzzle with a blurry picture or no picture at all.
The real world is a messy place. Many of the problem domains we face as programmers are difficult to understand and look completely different depending on your viewpoint.
As programmers, we also are often not given complete information about the problem domain, so we don’t even have the information we need to understand it.
Just try and read the famous Domain Driven Design book and you’ll quickly see how complicated and difficult problem domains can be. (Great book by the way, although you may have to read it twice or three times—I certainly did.)
Programming is easy if you understand the problem domain
A long time ago, I worked for Hewlett Packard writing software for multi-function printers.
There was however something really interesting about the waterfall approach and the extreme amount of specification that was done before anything was built—it was very easy to write the code for a feature.
I remember writing a tab control for the user interface of a printer and having the complete pixel perfect specs handed to me before I began to write any code. I was also given all the possible use cases and told exactly how it should function and what it should do under just about every circumstance.
Guess how easy it was to write the code to produce this tab control? Super easy.
As much as I frown upon this approach for software development today, there is something interesting to think about here.
I was essentially given the entire problem domain in the form of a spec that was clear and unambiguous. I was easily able to learn that problem domain and because of it, I was able to write the code very easily as well.
Perhaps you have had a similar experience, not necessarily working on a waterfall project where you were given the spec, but perhaps on an Agile project where you took the time to clearly understand the problem domain before writing any code.
I’ve spent days trying to implement a feature only to finally go back and talk to a product owner and hash out completely how something should work and why it should work in a particular way, only to go back to my desk and crank out the code in a matter of hours.
The more and more I write code, the more I learn that understanding the problem is the most critical piece to the equation. It is very difficult to solve a problem before you know the question. It’s like buzzing in on Jeopardy before you hear the clue and shouting out random questions.
What can you do about it?
If understanding the problem domain is the hardest part of programming and you want to make programming easier, you can do one of two things:
- Make the problem domain easier
- Get better at understanding the problem domain
You can often make the problem domain easier by cutting out cases and narrowing your focus to a particular part of the problem.
What I mean by this is that it is often beneficial to take a part of the problem and fully understand that part before expanding the problem domain.
Games are really good at this. Look at most games today and you’ll find that you start with a very small problem domain. The first level is usually a tutorial that has a basic set of things you can do so that you don’t get overwhelmed. But, as you advance through the levels, you usually find they get harder and introduce new concepts that build gradually on what you know, until you understand a pretty large problem domain. (Starcraft is really good at this.)
The other choice is to become better at understanding problem domains. As developers, we tend to think that sitting down and talking to customers or business people who know about the problem domain is a waste of time. It is easy to fall into the trap of thinking you understand enough of the problem to get started coding it. Best to resist the temptation to “not waste anymore time talking” and make sure you understand a problem inside and out before you try and solve it with code. It is much more expensive and time consuming to do things over than it is to do them right the first time. I learn this lesson the hard way time and time again.
Quick update on my new product
I’m still not ready to unveil exactly what I am building, but I do have an active mailing list where you can sign up to find out when I release the product I’m working on to help developers get better career opportunities and market themselves.
So many developers don’t realize how much of an impact marketing themselves and branding can have on their opportunities. I’m hoping to help developers learn not only how valuable marketing and branding is, but how to do it most effectively.
If you are interested, please sign up. (I won’t spam you.)
I always hear the advice that we should tackle hard problems first.
It seems like pretty legitimate advice, and many of the reasons for saying so make sense, at least at a surface level.
The reasoning usually revolves around the idea that by tackling the hard problems first you can eliminate your biggest risk early and everything will be smooth sailing from there.
When you really think about the reasoning for solving hard problems first though, most of it is not actually reasoning, but based of off one emotion… fear.
We tend to think it is best to solve hard problems first, because we are thinking about eliminating our fear, not because we are thinking about what approach has the highest chance of success or is the most optimal.
I call this FDD, or Fear Driven Development.
And when I think about it that way, I find myself hard pressed to find a real good reason for tackling hard problems first besides being able to abort early. Which, in some cases might be good, but I’d rather focus on success.
Here are 7 reasons why it might be a good idea to tackle the hard problems last instead of first.
1. Solving easy problems first gives you momentum
When a large ball starts rolling down a hill, it picks up speed rapidly and that large ball can bust through many barriers that it couldn’t before, simply because of one thing it has after rolling down a hill that it didn’t have before—momentum.
On the converse, trying to push a heavy ball up a hill is pretty hard. And if there are barriers on the way to the top of the hill, not only do you have to fight gravity, but you have to be able to push extra hard to get through those barriers.
Life is hard enough, why make it harder?
I recently received an email from a developer that was concerned that his team wasn’t gelling and that they didn’t have the expertise in the technology needed to solve the complicated problem ahead of them.
They were going to start the project by trying to integrate this fairly complex technology and he was afraid that it would cause them a large delay before they would be able to get version 1 out.
Start with your simple problems; get working software out there as soon as possible. Not only will the team gel much more easily as they are having success and making real progress, but that momentum will help them when it is time to solve the more difficult problem.
Even if they have to throw the first version away, when they get to the hard problem, the momentum alone will make them much more likely to reach success in the end.
I could give 100 examples of how solving easy problems to gain momentum can benefit you, but you probably already know intrinsically that this is true.
Long story short, get a running start before taking a big leap.
2. Avoid solving the wrong problem
The big problem with solving the hard problems first is that the hard problems usually require a large amount of context in order to fully understand them.
It is very hard to get the right context for a hard problem when we take it out of its natural order of progression and artificially cut it to the front of the line.
You’d probably like to start a college class by taking the final exam first, so you don’t have to worry about it, but the problem with doing so is that you’ll lack the context and information to understand the questions and to know the answers.
When we try to tackle problems out of order to avoid leaving the hard problems to the end, we end up losing all of the learning and context that would help us to solve the hard problems at the end and we are much much more likely to end up solving the wrong problem, which is a complete waste of time.
3. Someone else may solve the problem for you
Sometimes procrastination is a good thing.
Sometimes, when you purposely push off solving a hard problem till the end, you end up finding that someone else already solved your problem.
I spent a few minutes trying to troubleshoot it, but nothing I was trying was working, so I had to make a decision.
I had 3 choices:
- Keep trying to solve this hard problem before moving on.
- Go on and do other videos and send off a support request to see if they could handle it.
- Make a new project and re-edit all the clips.
Choices 1 and 3 involved tackling a hard problem right then and there.
Choice 2 was to tackle easy problems and see if support could solve my hard problem for me, and if not, I would solve it at the end.
I ended up choosing option 2 and it paid off. It turned out Camtasia support was able to solve my problem. By the time I needed the project to complete my course, they had solved my hard problem for me and I didn’t waste any time upfront trying to tackle it myself.
Now it could have worked out differently; I might have had to solve the problem myself at the end, but instead of assuming I would have to and wasting perhaps a day or 2, trying to solve the problem myself, I pushed it off and kept working on easy problems and I gave someone else a chance to solve my hard problem for me.
It doesn’t happen all the time, but many times if we push off the hard problems we face, we find that by the time we get to them, someone else has already solved the problem for us.
4. Your own subconscious mind may solve the problem
When I said someone else might solve the problem for you, that someone else might actually by you—at least your subconscious mind.
Have you ever had the experience of thinking about a problem and not being able to figure it out, but then you wake up the next morning and suddenly have the answer?
It seems that our subconscious mind is more powerful than we are aware of.
In many cases, if we know of the hard problem we need to solve and have thought about it a little bit, our subconscious mind will start working on the solution, even though we are not aware.
Obviously this isn’t going to work all the time, and your subconscious mind isn’t going to write a bunch of code for you, but in many cases there is at least some benefit to throwing the problem off to our internal “worker thread.”
5. You are more committed to solving the hard problem when you risk everything you do so far
One benefit to saving the hard problem for last is that you have some extra motivation in the form of loss aversion.
We can use this knowledge to our advantage by doing the easy work first and letting our loss aversion help motivate us to solve the harder problems, because we don’t want to lose all the work we put into a project so far.
By starting with easy problem, we put some “skin in the game.”
If we try to solve the hard problems first, we have nothing to lose, so we are much more likely to give up.
6. Hard problems are often easy problems bundled together
And it turns out that many hard problems (not all) are decomposable into many small easy problems.
If you strive to never solve hard problems and to always push them off, you may actually find out that you never have to solve hard problems.
Many times we can chip away at hard problems, by taking bits of them off a little at a time and solving those easier problems. Eventually, you may find that you’ve reached the tootsie roll center of your hard problem lollipop and it is filled with chocolate candy!
Now, some problems aren’t very easily decomposable, but a good majority of problems are. Once you develop the skills to chip off bits of hard problems into smaller easy problems, the world looks like a much more conquerable place.
So, saving hard problems for last and breaking off little pieces of them as you go, can be a good strategy to help you to wear down your opponent before you have to face him.
7. Some hard problems are never truly solved
One of the big problems with tackling the hard problems first is that they tend to fill up as much time as you’ll give them.
If I give you an easy problem, like write a function to reverse a string, there isn’t much to think about. You can solve it a number of different ways and there isn’t a huge difference in the efficiency of the different methods of solving it. It is pretty unlikely you’ll spend weeks revamping your solution and thinking that it’s not quite right.
But, if I give you a problem like, create an in-memory database, not only is it a hard problem, but it has a huge number of possible solutions and can be optimized from now until the end of time. You could spend 2 weeks working on that task or 2 years.
The problem is that many hard problems don’t have a good scope to them when they are solved in isolation.
If you design an engine for a car that isn’t built yet, you won’t know when you are done.
But if you design an engine for a car and you know how much it weighs and know what kind of transmission it will use and what kind of fuel efficiency it needs to have, you can have a much clearer understanding of when your engine design is done.
If you save the hard problems for last, the scope of those hard problems will be much more defined, which will keep you from wasting valuable time over solving a problem or, like I mentioned earlier, solving the wrong problem altogether.
Let me ask you a question.
How would you develop your next software project if I told you that if you “succeeded” you would be given $1 million dollars, but if you failed you would get nothing?
Success of course is a very fuzzy term, but let’s assume that success means:
- You built a working functional product
- Your customers are happy with it, content enough to call it done
- You delivered it on time
- You delivered it within budget
- It can be fairly easily modified and maintained with its current design for the next 5 years.
This is an all or nothing proposition. Everything is on the line. If you were to succeed, you would be rewarded handsomely, but if you fail, your effort would be entirely wasted.
Oh, also, you can’t work more than 8 hours a day 5 days a week—no winning by heroics alone.
Why ask this question?
Simple, because after thinking about “how to build software” for the last 10 or so years, (in my beginning years, I didn’t really ponder this question) I have decided the answer to this question is the way that software should be built.
I don’t mean that developers should be given an all or nothing proposition. What I mean is that we should be building and designing software as if I proposed the above situation.
This might sound a bit crazy, but think about it for a bit.
Most developers today are paid a salary. Some salaries have bonuses attached for performance, but rarely are we put in a situation where making mistakes or not being as efficient as possible results in dire consequences. The worst that can happen in most cases is that we would get paid for the work we did and then be looking for a new job at the end of the project.
Losing all the time we put into the project and losing out on an opportunity to make a million dollars would be some consequence.
We’d think about software development quite differently
It’s really hard for me to answer the question of whether or not practices like TDD are worth it. I mean sure, I tell my manager it is. I emphasize quality over speed. I say we need to do this or that, but honestly I don’t really know.
I’ve never been put to the test.
No one has ever said to me, “succeed or die.”
No one has ever put the consequences of my choices directly in my own hands.
Never have I actually had to weigh the weight of extra time spent refactoring code, writing unit tests or using an ORM instead of writing SQL directly in my source code.
I choose technologies because they seem good to me or it seems like they’ll help me get things done faster, but I am never really staking much on that choice.
Sure, I may be staking my reputation, or I might lose my job, but chances are I’ll just blame some failure on some other reason or worse yet, I won’t even recognize my failure, because it will be disguised by “good enough.”
“Man, John, you are a big fraudulent a-hole! I can’t believe you go around touting to know stuff, leading people down paths that you yourself don’t even know are correct. Burning up other people’s money in your test lab of software development.”
Maybe it’s true. Maybe I am a big ignorant and arrogant jerk, but somehow I feel that I am not alone.
I’m not saying we don’t or shouldn’t have strong convictions.
I’m not saying that we don’t have good reason to believe the development methodologies and practices we suggest and follow are correct.
What I am saying is…
Our beliefs about software development are mostly theoretical
8 years ago I would have told you that you needed to create UML diagrams before you write any code.
5 years ago I would have probably emphasized the importance of always having an XML schema. I would have told you data without schema is meaningless.
I don’t hold either of those views today.
Perhaps you’ve changed your views in the past few years as well?
The point is that even though we may be down in the trenches doing software development and to some degree finding out what works and what doesn’t, we are basing the results on OUR motivations not the motivations of our customers or our employers.
So, we may eventually get good at making things easier for ourselves, but unless your feet are held to the fire, you’ll never really optimize for building the best software as efficiently as possible.
If you think you already are focusing on building the best software as efficiently as possible and I am just full of crap and you don’t operate that way, I would strongly suggest doing a thorough self-check and also please tell me the secret of the most efficient way to build software, because I definitely want to know.
What about startups or open source projects?
You might be tempted to think that working for yourself or not for money at all would change things, but I’m really not sure that is the case.
I’ve worked on plenty of my own software projects where my fate was directly in my hands.
I’ve built applications like PaceMaker where my financial success with the endeavor was directly tied my own efforts and my efforts alone.
But, do I think I built PaceMaker as efficiently as possible?
No, definitely not!
The problem with PaceMaker and other projects where there is a big potential upside, is that the upside potential is not guaranteed.
I can assure you that if someone said to me that I have 6 months to build PaceMaker and if I succeeded (according to the rules I stated above) that I would be given $1 million dollars, but if I failed I would be given nothing, I would have probably gone about the whole process an entirely different way.
I’m not saying I would have built it with perfect efficiency, but my motivations would have entirely matched up with the footprint of building software as perfectly as possible.
What I mean by this is that I would be trying as hard as I could to do what I absolutely believed was mostly likely to benefit me, and by doing so I would be trying as hard as possible to completely optimize the process of building that software.
What can we do about this?
Now I can’t tell you how I would have built PaceMaker had I been given the million dollar challenge.
There is no way that I could objectively put myself into that situation and give you an answer.
Would I have bothered with unit tests? Would I have have created backlogs and written UATs to make sure they pass? Would I have used an IoC container?
The plain and honest answer is, I don’t know. All I know is that I would have done things differently and on any software project you’ve worked on, you probably would also.
There are a few things we can gather from thinking about this hypothetical proposition.
- Don’t think you know the answer, but at the same time have convictions about what you currently believe. Just hold on to those convictions loosely.
- Even though you can’t realistically be completely objective and build software as if someone was going to pay you 1 million dollars (just like you can’t tickle yourself) you can still try to think as much as possible with this mindset. It is a worthwhile exercise to imagine as if the decisions you are making and the convictions you are holding onto are based on idealism or reality. We could also all examine and at least understand our own motivations.
- Recognize others are in the exact same boat you are. Don’t believe everything an expert says or even believe there are experts. Experience and wisdom count for something, but no one has anywhere close to all the answers.
I’d love to see this experiment actually played out. I’d really be curious to see what the outcome was, especially in a team situation.
Perhaps someday, someone will actually conduct this experiment and share the results.
What about you? How do you think being given the million dollar challenge would change the way you develop software?