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?
I like to procrastinate.
I don’t really enjoy procrastinating, but it is one of my weaknesses. I’ll delay doing something that I know is important until the last moment that it needs to be done.
I’ve learned to overcome this weakness of mine by trying to be more productive to compensate for it.
Blah, blah, blah, productivity system… procrastination… blah blah blah!
I know you’ve heard it all before, but here is the strange part—I almost always get things done well before the deadline.
So what is my problem then?
My problem is that when I sit down to actually do the work, I end up doing a million other little things.
Even though I am overcoming the results of my procrastination by self-imposing much earlier deadlines, I am still fighting against the core of my procrastinating nature.
It is like I have put the angry demon of procrastination in a cage where he can’t harm me, but because I have to constantly feed him and deal with his demands, he’s still slowing me down.
I call it micro-procrastination
Perhaps you suffer from it to.
The symptoms are as follows:
- Sit down to do work and first check Facebook, Twitter, emails and every other single site that could have something interesting and updated for you.
- Justify in your head that you need a 10 minute or so transition period to check all this stuff before you sit down to actually do the work you intend.
- Pick something smaller that is not important and work on that instead. (Clean out email inbox, etc.)
Just about every week, my goal for the week is to record 2 modules for whatever my next Pluralsight course is.
I really never miss this goal, but it would often take me a while to get started each night. I would sit down to do the work, but not actually get to working until about 30 minutes to an hour after when I had first sat down at the computer.
Once I got started, I usually found that I didn’t have any problem continuing with the work until it was finished.
I tended to do the same thing with my blog posts as well. I know now I need to get a blog post down each week, but it would always take me a while to get started writing the post itself.
Even when I went to write code or solve a programming problem, I noticed that I would try to do many other work related activities like answering emails or further investigating a problem, rather than just working solely focused on the task at hand.
I started to notice a common occurrence between all of these situations in my life. If I got about 15 minutes into actually doing my Pluralsight course, writing my blog posts, or coding up a feature, I’d almost always end up staying focused on the task.
I found that I would often not want to quit something once I got started. I’d even miss lunch or be late for lunch or bed because of this.
The 15 minute rule is born
Based on this observation, I decided to try a little experiment. The next time I was going to work on something, instead of doing my usual ritual of checking email, checking twitter etc, I did the following steps:
- Pick out the single task I am sitting at the computer getting prepared to work on. (It helps to define this very clearly.)
- Turn of all distractions for 15 minutes or just decide not to let them bother me for that time period.
- Work without pause, without break and without excuse for 15 minutes straight.
- At the end of 15 minutes, if I want to quit, then I can quit or multi-task.
What I found is that after 15 minutes of working steadfast and diligently on a single task, I didn’t want to quit.
I found that something that I had no motivation or desire to actually be working on 15 minutes before was now all I could think about.
I found that just like it takes the first few chapters to get into a book and actually feel compelled to continue reading it, it takes about 15 minutes for me to get drawn into my work and want to see it finished.
I’ve been applying this “15 minute rule” pretty regularly now, and I have been having some pretty fantastic results.
I’ve also slipped up on occasion and reverted back to my old ways and have had quite the opposite of results.
I’ve tried other systems
Now I’ve definitely tried many other systems that attempt to solve the problem of procrastination or productivity or both, but none of them seemed to work all that well for me.
I know these other systems work, and I know plenty of people are successful with them and that my system isn’t really much of a system at all—it’s just what I do.
The problem I have found with other systems though, is that they are either:
- Too complicated to apply regularly unless you are 100% devoted. (Big barrier to entry.)
- Only address productivity, and priority, but not actually doing work.
- Assume you can sit down and actually do what you have set out to do. (Which remember, was the hardest part for me.)
I am a big fan of Getting Things Done and I highly recommend it. At the very least read it, because it just has some great overall advice, but…
I don’t apply it anymore, because I don’t need to organize what I need to get done. My life is currently so packed and scheduled every day that I already know exactly what I need to be doing just about every hour of my day.
I don’t even watch TV or movies… Ever. No really, I mean never ever.
So, with my schedule being so packed, my biggest problem isn’t figuring out what I should be doing—I’ve got that covered. Instead, my biggest problem is doing it efficiently.
The closest technique to what I am doing is probably the Pomodaro technique. I also think this is a great technique and is likely to work for many people.
I’ve just found that my mind tends to defeat the technique by telling me that I don’t have enough time to get a whole Pomodoro done right now, so I should just do part of one.
You could call what I am doing a modified Pomodoro technique, whereby I set the duration to 15 minutes and actually try to avoid taking breaks for as long a possible.
Why the 15 minute rule works
I suspect the main reason why this technique works is because of momentum.
When we start to get momentum going for us (and 15 minutes seems to be just about enough time to do so) it is much harder to change course.
Focus is also a big part of the 15 minute rule. The world today is a fast paced multi-tasking parallel processing rat race in which we are conditioned to switch our attention between multiple things all at once.
If you are reading this post right now, you probably have even switched back and forth between multiple browser tabs or chat windows or something else and aren’t focusing 100% on reading. I don’t have 15 minutes to grab your full attention and draw you in (unless you are a very slow reader, in which case I congratulate you for making this far.)
The point is, we have to purposely focus on a single thing in order to turn off that natural tendency to try to be omnipresent.
Doing the 15 minute rule forces me to focus, and that focus tends to shut off everything else in my mind with has the potential to distract me.
The 15 minute rule also prevents me from overthinking about a problem and standing back to admire the problem instead of working on it.
It frees me from obligation. If I know I have to work for 15 minutes, I am not afraid of not making much progress. My only obligation is to be working on the task at hand, without interruption and with complete focus for 15 minutes.
I also find that after 15 minutes, I’ve developed a commitment to the work. Because of the time I’ve already invested in the task, I feel more compelled to complete it.
Applying the rule
Hopefully you’ll find this technique useful and if not perhaps you have a better suggestion or technique. If you do I’d very much like to hear it, since I am always looking for some practical ways to be more efficient.
Before I let you be on your way, I’ll leave you with some parting advice that I’ve found useful when applying the 15 minute rule.
- Remove all distractions. That may mean closing browser windows or turn your phone off or just deciding to ignore everything else.
- Don’t forget to focus. Removing distractions is not enough, you must also focus intently on what you are doing. Be present in the moment.
- Work, don’t think. I know thinking is working, but the mind wanders too easily and merely thinking about a topic doesn’t seem to create that same mental traction. This might mean you start writing a first draft or first hack, but it is important to be actually “doing.”
- If you feel like you can’t start “doing,” make your “doing” brainstorming, but brainstorm by actually writing a list or making a mind map.
- If at the end of 15 minutes you are still not into the work and want to quit, go ahead. Come back a little later and try again.
- Take breaks when you need to, as long as the initial focused 15 minutes has passed, I’ve found that I can take a break and actually want to get back to my work.
- Put a sticky note on your monitor or somewhere you’ll notice that reminds you that when you sit down to work to start off with the 15 minute technique.