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.
There is a useful observation about the world that is often applied to software development called the Pareto principle or Pareto’s law.
This principle suggests that in many situations 80% of the results come from 20% of the causes.
For example, Pareto had realized that 80% of the land in Italy, during his time, was owned by 20% of the population.
Since then, many people, including Pareto himself, have applied the same observation of this 80-20 rule to many other areas of life from economics, to business and even software development.
But, I’ve found that we rely on Pareto’s law just a little bit too much.
The problem with generalizations
The biggest problem I have with Pareto’s law is that is applied way too often to too many situations. In many cases, especially in software development, Pareto’s law becomes a self-fulfilling prophecy—the more you look for Pareto’s law, the more you magically seem to find it.
None of this is to say that Pareto’s law isn’t a real thing—of course it is. If you go and take a look at real hard numbers about distributions of things, you’ll find Pareto’s law all over the place in your statistical data. But, at the same time, if you go and look for the number 13, you’ll find an alarming number of occurrences of that two digit number above all others as well.
It is very tempting to force things that don’t quite fit generalizations into those generalizations. How often do we use the phrases “always” and “never?” How often do we fudge the data just a little bit so that it fits into that nice 80-20 distribution? 82% is close enough to 80 right? And of course 17.5% is close enough to just call it 20 after all.
Not only can you take just about any piece of data and make it fit into Pareto’s law by changing what you are measuring a little bit and fudging the numbers just a little if they are close enough, but you can also take just about any problem domain and easily, unconsciously, find the data points which will fit nicely into Pareto’s law. There is a good chance you are doing this—we all are. I do it myself all the time, but most of the time I am not aware of it.
I’ve found myself spouting off generalizations about data involving Pareto’s law without really having enough evidence to back up what I am saying. It is really easy to assume that some data will fit into Pareto’s law, because deep down inside I know I can make it fit if I have to.
Seeing the world through Pareto colored glasses
You might think there is no harm in fudging numbers a bit and finding more and more places to apply Pareto’s law. But, looking at the world and blindly assuming all data falls into a distribution of 20 percent of the causes being responsible for 80 percent of the effects, is like walking around with blinders on your eyes—you are only seeing part of reality and even the reality you are seeing tends to be a bit distorted.
Again, this doesn’t mean that Pareto’s law isn’t correct a large amount of the time, but it means that when you are just assuming that any data that appears to obey this law will, or worse yet, that all data MUST obey this law, you are severely limiting your perspective and restricting your options to those that already fit your preconceived ideals.
Sometimes I wish I had never heard of Pareto’s law, so that I wouldn’t be subject to this bias.
Let me give you a bit of a more concrete example.
Suppose you blindly assume that 80% of your application’s performance bottleneck comes from 20% of your code. In that case, you might be right, but you might also be wrong. It is entirely feasible that there are some parts of your code that contribute more or less to the performance of the application. It is also pretty likely that there are some bottlenecks or portions of code that heavily impact the performance of your application. But, if you go in with the assumption that the ratio is 80-20, you may spend an inordinate amount of time looking for a magical 20% that doesn’t exist instead of applying a more practical method of looking for what the actual performance problems are and then fixing them in order of impact.
The same applies for bugs or testing. If we blindly assume that 20% of the code generates 80% of the bugs, or that 20% of our tests test 80% of our system, we are making pretty large conclusions about how our software works that may or may not be correct. What happens when you fix all the bugs caused by the 20% of code that generates 80% of them? Does a new section of code now magically produce 80% of the bugs? If 20% of your test cases test 80% of your code, can’t you just create those ones? Why create another 80% to only test another 20%? And if you did follow that advice, then wouldn’t you have the situation where 100% of your tests tested 80% of your code?
The problem is when you start applying and assuming that Pareto’s law applies blindly, you start making all kinds of incorrect assumptions about data and only see what you expect.
So, was Pareto wrong?
In short, no. He wasn’t wrong. Pareto’s principle is a thing. In general, in many cases, it is useful to observe that a small amount of causes are responsible for a majority of effects.
But, it is not useful to apply this pattern everywhere you can. The observation of the data should guide the conclusion and not the other way around.
I find it more useful, especially in software development, to ask the question “is it possible to find a small thing that will have a great effect?”
A good book on this very subject is The 4 Hour Chef. Although I don’t always agree with Tim Ferris, he is definitely the master of doing more with less and talks frequently about concepts like minimum effective dosages.
In other words, given a particular situation, can I find a small thing I can do, or change I can make, that will give me the biggest bang for my buck?
Sometimes the answer is actually “no.” Sometimes, no matter how hard we try, we just can’t find a minority that influences the majority. Sometimes the bugs are truly evenly distributed throughout the system. Sometimes the contributions of team members are fairly equal. One team member is not always responsible for 80% of the results.
And let’s not forget about synergy. Which basically is when 1 + 1 is equal to 3 or more. Sometimes the combination of things together makes the whole and separating out the parts at all greatly reduces the function.
For example: eggs, sugar, flour and butter can be used to make cake, and you could say that 80% of the “cakiness” comes from 20% of the ingredients, but if you leave one of those ingredients out, you’ll quickly find that 100% of them are necessary and it doesn’t even make sense to try and figure out which ingredient is most important, because alone each ingredient functions much differently than they do all together.
In software development this is especially true. Often in complex systems all kinds of interactions between different components of a system combine together to create a particular performance profile or bug distribution. Hunting for the magical 20% in many cases is as futile as saying eggs are responsible for 80% of the “cakiness” of cake.
Let me ask you a question.
Why do you think Bill Clinton gets paid $200,000 to speak for an hour?
Is it because he is such a good speaker that just hearing the magic words come out of his mouth will make you a better human being and drastically change your life?
Or do you think it might have something to do with the fact that he was the president of the United States of America?
I’m not doubting the Bill Clinton is a good public speaker. He is likely one of the best, but it is not his skill alone that commands such a high price. A large portion of his price tag comes from the name he has built for himself.
You might say that he has…
Style and substance
Just having style is not enough. Style is just a name without anything to back it up.
Have you ever been suckered into buying one of those products on late night TV? You know what I mean, the ones that they sell at 2:00 AM and throw in all kinds of extra things if you only act now?
That is an example of style, but no substance. You aren’t getting what is being sold. The infomercials are advertising a product much better than what you actually receive. When you open the box and try out the product, you feel like you got ripped off—and you did.
Substance alone is not enough either. I’ve known many very skilled people that couldn’t market their skills worth a dime. Often people who focus on developing their skills don’t feel that they have the ability or time to learn how to market those skills, so those kinds of people go underappreciated and never live up to their full potential. As a software developer, you are probably more likely to fall into this category.
To reach the ultimate level of success and truly increase your value, you have to have both style—the ability market yourself and make a name for yourself, and substance –the skills that pay the bills.
Whether you like Bill Clinton or not, you have to admit that he does have both; that is why he commands such a high price tag.
Skills are not as important as you think
One thing that many programmers and software developers find hard to believe is that skills are not the most important thing in advancing your career.
Don’t get me wrong, you have to have some skills and knowledge. Just like the dice-o-matic you bought at 2:00 AM and quickly discovered was actually a piece of junk, if you pretend to have skills and abilities that you don’t actually possess, your customers and clients will be just as disappointed and look for a trash can to drop you off in.
But, at the same time, most people can’t recognize the difference between someone who is in the 95% margin of skill in a field from a person who is in the 80% margin of skill in that field, unless they also happen to be an expert themselves in that field. Unless you are a doctor, or dentist or auto mechanic, you probably don’t have a way of really evaluating how good a doctor or dentist or auto mechanic is—although you can probably quickly spot a phony.
So, why is this important?
Because, if you are like me—or at least how I was—you are probably spending way too much time focused on increasing your skills and not enough time increasing your style; building a name for yourself.
What I mean by this is that if you are at a decent level of skill, you will see much bigger benefits in building a name for yourself than you will in increasing your skill further.
It doesn’t matter if you are an independent software developer trying to get more clients or sell a product, or you are looking to work for someone else who will pay you more money, or you just want to get that promotion at your current job. Whatever your goal or situation is, complimenting substance with style will multiply the value of your skills much more than increasing those skills themselves.
The best way to think about this is like a mathematical equation.
(Style ^ 2) * Substance – Expectation = Value
Let’s break it down.
Style is more important than substance, because while skills are essentially capped and become harder to increase over time, style can be increased to a much larger degree—you can always build a bigger name; get a bigger audience.
Plus, the effect of having a larger audience tends to increase exponentially. That is why commercial spots for the Superbowl are so expensive.
Now, from the style and substance multiplication we have to subtract expectation to get a true sense of value.
Consider the case where you bought that dice-o-matic from a late night infomercial. The style points were pretty high. Lots of great marketing techniques were at play to get you to make that purchase, but those techniques also tend to setup some pretty high expectations of what the product should do. When you see the guy on TV using the dice-o-matic to chop an iPhone into tiny pieces, it sets a pretty high level of expectation.
Style is high, but substance is pretty close to zero and expectations are high, so in many cases value can actually be negative.
You have to consider the same thing in your career, when you are marketing yourself and your skills. Some of the marketing techniques you could use to get a quick audience would also produce a very high expectation, so if you don’t have the skills to measure up, you are going to create some negative or very low value.
On the other hand, if you have a high enough level of substance behind what you are promoting and you are able to promote yourself in a way that doesn’t build up more expectation than you can deliver, you are going to be able to bring a pretty high amount of value.
Increasing your value
So, for many of us software developers and programmers the answer is simple. The most effective way we can increase our value is to learn how to market ourselves; a skill that I have found many IT people tend to lack. Of course there are some great examples of developers who do not lack this “style.” Most conference speakers and well known authors or consultants are very good at promoting themselves and really increasing their value by carefully paying attention to the equation above.
Now, of course, this is much easier said than done. I’ve also found that most software developers don’t really know how to go about marketing themselves. I didn’t either for too long of a time—and I am still learning how to do it every day. But, I have learned some valuable techniques that I think just about anyone can apply to build some points on the style side.
If you are interested in learning about how to market yourself to really increase your value, sign up for my newsletter here, so I can keep you updated on my future posts and videos covering that topic and much more.
I am planning some pretty exciting content around all of the information I’ve gathered over the years about marketing yourself as a software developer and I’ll be sharing a large amount of that information here on this blog.
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.
Yeah, you. Psst. Come over here.
I’m going to tell you something that you may not have heard before.
Are you ready for it?
Software developers are jerks.
Don’t get me wrong, there are lots of great developers and nice people who are software developers, and there are lots of great supportive environments and thriving communities in software development land, but there are also lots of jerks.
You have to learn to grow a thick skin
You don’t hear this much, because it isn’t really nice to say. And hey, I’m an eternal optimist, so I’d rather not look at the negative, but ignoring reality doesn’t make it go away.
The truth is not everyone has your best interests at heart. The truth is that a large number of people would like nothing more than to see you fail; to prove once and for all that they are smarter than you.
Chances are if you are doing something unique or you propose a new idea, you’ll have more critics than supporters. I don’t say this to be mean or to discourage you—I actually have the opposite intent. Rather, I say it so that you can be prepared and not think it has anything to do with your personally. Hopefully, I can help you grow the kind of thick skin you are going to need if you are going to succeed as a software developer.
There has been a good amount of griping and general banter about women in tech lately. Both sides of this imaginary war have crossed lines and drawn blood. I’ve stayed out of it so far, and I’ll continue to—I’m not taking sides. But, in some ways this whole debate has shown just how nasty people can be in our industry, and over some pretty petty things.
The problem is that most software developers, male or female, aren’t really ready for the nastiness they are about to encounter when they start writing code as a career. Worse yet, much of this nastiness is disguised in a very passive aggressive manner, so targets of this ire aren’t even aware of it—at first.
Where does this vileness come from?
We work in a sort of strange field where intelligence and ability are highly prized, but some of these same qualities made some of us victims of aggression and abuse earlier in life.
This tends to result in a culture in which many of the participants are constantly trying to prove themselves and evaluating themselves against others.
To put to plainly, it means there are lots of sensitive and bloated egos floating around.
It is sort of a “kick the dog” syndrome where software developers who were kicked earlier in life, or even earlier in their careers, tend to feel justified in kicking the programmers who they see beneath them.
This same kind of mentality also tends to foster cynical thinking and an outright rejection of any idea that doesn’t self-originate.
But, I probably don’t have to tell you this, so much as to remind you of it, because if you’ve been in the industry for any amount of time, you’ve probably felt and experienced this yourself. You may even be a perpetrator of it—we all are from time to time—just some of us more than others.
What you can do about it
So you might be wondering what my purpose is in telling you all this. Am I just complaining for the sake of complaining?
No, definitely not. Like I said, I spend much of my day trying to see the positive. I don’t like to dwell on the negative.
My real purpose is to put this out in the open so that I’ll stop getting emails from tired, beat up developers or want-to-be developers who have been beaten down so hard by their peers that they feel that they are somehow below them.
Everyone feels doubt in their abilities and worth from time to time, but you’ve got to learn to recognize where the doubt and fear is coming from. Sometimes, it is a healthy dose of skepticism in our own abilities that keeps us from floating our head way up above the clouds, but many times it is just the reflection of others who are making us feel inferior.
I’ve sat through countless meetings where good, smart software developers who had good opinions and ideas kept their mouth shut and didn’t say a word. I’ve been to leadership and effective communication classes that told me that the vocal participants in the room were to blame; that they were being too assertive and aggressive and forcing others into the room to become more introverted.
But, you know what? That is hogwash!
Are you going to live your life waiting for someone else to step out of the way, so your quiet voice can be heard? Or are you going to make your own voice louder?
You are much better off realizing that people are jerks and learning how to speak out and deal with criticism than you are believing that you are inferior and not worthy of a seat at the table.
Don’t blame your own situation on other people being egotistical loud mouth jerks and accept their bullying and allow them to project the image of how they want to see you onto yourself. Instead, realize that is just the way it is and you have to learn to adapt to this environment.
As much as I’d like it to change, it probably won’t, so at some point you’ve got to start living in reality or find a more peaceful and accepting atmosphere.
Don’t be part of the problem
Just because the situation is somewhat bleak, doesn’t mean you have to be part of the problem as well.
I originally started this blog, because I was fed up with all the egos that were trying to make programming seem so much harder than it really is. My whole mission in life for the past few years has been to take things that other people are trying to make seem complex (so that they can appear smarter or superior) and instead make them simple.
I charge you with taking up the same quest. You don’t have to start a blog dedicated to the cause or wear a Simple Programmer T-Shirt, but you can start helping other software developers and making them feel like they can do it instead of making them feel like they need years of practice to attain your level of skill.
If we want to make a difference in the community, we have to start trying to make things seem simpler rather than harder.
There are plenty of people out there who will gladly challenge a new idea or tell you why you can’t accomplish some goal, but there needs to be more of us—especially those of us who’ve been in the field for awhile—who tell people why they can do it and how easy it really is.
Real strategy to deal with this problem
Dealing with jerks and negativity is hard. It is really hard.
In my career, I’ve dealt with my fair share of it, and I still deal with it today. In this post, I just highlighted the problem and offered simple suggestions, but I’m actually working on a much bigger project to distill some of these specific software developer career tips into a bigger package.
If you are interested in finding out the moment this product is officially launched, sign up here, and I’ll be sure to let you know.
How about you?
Do you run into lots of egos in software development? How do you stay positive and not let them crush your spirit?
Update: be sure to check out this comment chain to see a bit more clarification on what code katas really are. Thanks for Cory Foy for pointing out that I was unfairly calling all code katas as solving the same programming problem over and over again. Only some people treat code katas that way and this post is about why that kind of code kata is not effective. I also updated a few words in this post to reflect this point.
I don’t want to seem like I am bragging, but there is something I just have to get off my chest.
But, before I tell you what amazing skill I have mastered through countless hours of boring practice, let me tell you a bit about my training schedule.
Everyday I get up in the morning. I put on my shoes. I begin my practice.
Usually I start with a small warm-up, just to get the blood flowing on the way to my office at the end of the hall.
Later in the day, I’ll wander out of my office for lunch and practice more on the way to the kitchen.
Right now as I am typing out this blog post, I am on the treadmill honing my craft one painstaking repetitive step at a time.
That is right, you may have guessed it by now—I am a master walker.
All my life I have been practicing this humble skill. Each and every day I practice my secret craft. I see other fools riding around on mopeds and motorized scooters sheepishly talking of their perceived skill at bipedal transportation. But, although outwardly I acknowledge their words, inwardly I know that I am special, because I hone my skill to a craft.
Sounds ludicrous? That is what it sounds like to me when some people talk about doing code katas.
What is a Code Kata you may ask? Some people think a Code Kata is when you solve the same programming problem over and over again, thinking you are actually practicing something other than using shortcuts in your IDE. (To be fair, not all people view Code Katas that way.)
These kinds of Code Katas come from a failed attempt to forcibly simulate the same kind of practicing that a musician or athlete would perform in order to become better at their vocation.
Why Code Katas aren’t effective
Don’t get me wrong, the intention behind Code Katas seems to be well placed, and I am all for software craftsmanship (although not the elitism that sometimes accompanies it.) But, just as walking every single day doesn’t make you a master walker, and driving a car every day doesn’t make you a superior driver, solving the same sets of programming problems over and over again won’t make you a master programmer.
If you still have your doubts, consider old people. Old people are not master walkers or master drivers, yet they have been doing both of those activities day in and day out for many years. Not only do they not master these skills, the skills actually atrophy—they become worse at them, and not just because their muscles and reflexes become worse from age, it is because repeating the same thing over and over again without an increasing level of challenge actually results in the mind becoming complacent with the activity which leads to the eventual degradation of it. (At least, this appears to be the case to me.)
Don’t lose hope though, a little later on I will tell you a real way to practice your craft in software development—one that will give you results—but, first let’s dissect the cases of walking and driving a little bit further to see why repeated practice of those activities seems to have diminishing returns.
Doing the same thing over and over again doesn’t make us better at it
We first learn from walking and driving, because everything is new and challenging. Although walking seems like a repetitive process, it is actually the lack of repetition that provides the challenge our brain and body need to actually benefit from it.
As a toddler learning to walk or a teenager learning to drive, we are constantly bombarded with new scenarios and challenges that we haven’t faced before. What happens when the dog runs by and brushes our leg? How does this affect our balance and what do we have to do to adjust? What about this new surface? The carpet seems to absorb our feet and create more friction when we attempt to walk on it. How do we compensate to balance on this surface? Walking with socks on the floor gives us less grip, etc.
But, as an adult, or experienced walker or driver, we are not challenged in nearly the same way; we’ve already seen most of the scenarios. Our daily commute to work rarely presents us with an unfamiliar stimulus or problem to solve. We operate on autopilot, automatically walking and driving to our destinations without much effort or thought.
Repeatedly writing the code to solve the same programming problem over and over again is exactly the same thing, except unless you are introducing new challenges by adding constraints and twists, you are only benefiting from the exercise the first, and perhaps, the second time, you undertake the activity.
Now, not all programmers who do Code Katas repeat the exact same code over and over again. Some of them attempt to solve the same problem, but this time not using any loops or limited the line count to a certain number or some other similar constraint. This kind of practice is actual worthwhile practice which challenges the mind and introduces new scenarios that create new neural pathways in the brain and strengthen others. (Here is a great example of book that encourages you to do just that. I highly recommend working through the problems in this book.)
Simply typing the same code into the same IDE over and over again for 10 minutes a day may make you feel relaxed and calm or even like a concert violinist arduously practicing their scales, but at the very best it will make you faster at using your IDE and typing code; skills which can be easily practiced through the course of a normal day’s work. If you want to be really good at writing the code to sort lists of words and calculate prices for grocery store items in a cart, go ahead, be my guest.
How real mastery is achieved
If you are resisting what I am saying at this point, it is likely because you still mistakenly believe that walking and driving are in a different category than playing music, sports and programming. But, the truth of the matter is that walking, running, music, sports, and programming are in the same category, or rather, there are no categories.
It turns out there are actually master walker and master drivers. One sport that is not all that widely known goes by the name of Parkour or Freerunning. Don’t believe me, check out this video for an example. In this sport, the athlete becomes exceptionally good at traversing around everyday locations on their own two feet. It is amazing what some of these practitioners can do—just watch the video if you don’t believe me.
And as for driving, I probably don’t need to convince you that Nascar is “kind of a big deal.”
My point is that you are not going to become a Parkour expert or Nascar driver by just walking around your neighborhood or driving your car to and from work, even if you do tend to drive like a bat out of hell. To get to that level of skill in those seemingly mundane activities, you have to constantly practice at a higher level of difficulty and continually introduce new challenges.
In fact, when we actually look at what real musicians and sports athletes do, it is much of the same. I seriously doubt many musicians you hear on the radio or see in concert repeatedly played “bah bah black sheep” or “twinkle twinkle little star” on their instruments until one day they achieved mastery. And in the professional sports world, achievement only comes through repeatedly pushing beyond one’s limits day after day.
The point is this: if you want to get better at something, repeating practice alone is not enough. You must practice with increased difficulty and challenge.
How to improve your programming skills
So, how then do you become a master craftsman at the vocation of software development? If you don’t use Code Katas, how do you practice your craft?
Let me start off by giving you the best example I have ever seen.
This is Jennifer Dewalt’s blog; she decided to learn to code by building 180 websites in 180 days. While you are sitting at your keyboard typing the same 20 lines of code into your IDE over and over again, Jennifer is creating a new thing every single day and facing a brand new challenge.
Who do you think will improve their skills more after 180 days, you or Jennifer? I know who I’d hire without even thinking twice.
I get lots of emails asking me about the best way to learn programming or how someone can improve their skills. Recently, I’ve gotten a lot of emails asking about how to learn Android development. Do you know what I tell all these inquisitive minds?
Make Android apps.
But, umm, what book can I read?
No book, just come up with an idea and try to create it. Figure out what you need to do along the way. When you get stuck, go look for the answer or seek help.
But, I need to know what I am doing first.
Says who? Do and then learn. Learn and do at the same time, reading a book or repeating the same exercise over and over again won’t make you smarter or more skillful; constantly challenging your mind and current skills will.
Want to learn more?
I’ve got plenty more to say on the topic and many more techniques that are way more effective then Code Katas which you can use to hone your programming skills. I can’t fit it into a single post like this, but I’ll be putting it into the top secret project I am working on to help developers boost their careers and learn to market themselves.
If you’d like to be one of the first to be notified when it is available, sign up here. I’ll be including lots of practical valuable information that you probably won’t find anywhere else.
So, what do you think? Do you do Code Katas right now? If so, do you think they are actually useful? Let me know in the comments below.
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 discovered something about myself—I have an amazing gift to always make the very best technology choice.
No really, it is quite amazing.
When I look back at my development career, it seems to me that every programming language I was using at any given time was clearly the best one.
The same goes for frameworks and even operating systems.
Yes, I have this amazing ability to pick from the vast ocean of technologies, without even trying them all out, the very best one, and to vehemently defend my choice.
Perhaps as you’ve been reading this, you’ve discovered you have this uncanny ability as well?
Most developers are religious about technology
Don’t be ashamed, you are not alone. Myself, and just about everyone else, is with you.
Some of use are recovering from our self-imposed brain washing. Others of us are blissfully unaware of our predicament. But most of us have at least one religion we’ve managed to craft ourselves.
It is perfectly natural because most programmers got into the field of software development because they were passionate about it. Anything you are passionate about is likely to cause you to develop some highly charged opinions.
Take sports fans for instance. I’m not really much of a sports fan myself, but I know many fans of all different kinds of sports that religiously believe their team is the best despite all the evidence to the contrary.
This defense of our own choices and ideas is core to human nature. It is easy for us to adopt a new idea but we religiously defend the ones we have without needing much evidence to back it up. The problem is we tend to tie up our ideas about things with our identity and even our value as human beings.
It takes some deep soul searching, but it you look within yourself you’ll probably find that you can make a list of the best operating systems, programming languages, frameworks and so on.
Ignorance is not bliss
The problem with this self-imposed religion is that our technological religion blinds us from the truth.
I spent countless hours arguing about why Macs sucked so much before I had even really used one. Ironically, I am writing this post on a Mac right now, but I am using Windows Live Writer which I am accessing through remote desktop. Oh, and this blog post, well, it is actually hosted on an Ubuntu Linux server in the cloud on a PHP application you may have heard of called WordPress.
My point is, most of us vehemently will argue that our technology choice is the best without even having really tried the alternatives.
It seems ludicrous when you think about it clearly, but I still catch myself doing it even today.
When I look within myself to honestly ask the question “why,” I find that most of my motivations come from a combination of pride in what I have learned and accomplished and a fear of what I don’t know.
I find that it is much easier to dismiss a technology that I don’t know as “garbage” or “worthless” than it is to take the time to learn about it and see why others like it so much. As they say, one man’s garbage is another man’s treasure.
The problem with thoughtless religion
I don’t need to tell you that mindless religious zealotry is a destructive force in our world. You only need to go to your favorite national news web site or look in any history book to see that is the case.
So, while we may think our ignorance isn’t harming anyone and that they deserve it anyway because they are clearly wrong, the truth is, there is quite a wake of destruction that our ignorance can leave behind us.
I look back on my own past and I am embarrassed that I harassed Perl developers to the degree that I did, completely discrediting their work and ignorantly pushing my holy statically typed C-based languages as their one and only savior who could cleanse them of their filth.
But more than anything, I realize that I hurt myself.
Stop hitting yourself, idiot!
The biggest growth in my career came when I was looking for a job doing C# development and found a really good opportunity to act as a technical architect for a project written in Java.
I was quite torn by the decision. In my heart I knew that Java was bad and evil. I knew that because Java lacked properties like C# and required the use of manually created getters and setters that everyone writing Java code was clearly an idiot.
I almost didn’t take the job, but I decided that the pay was too good to pass up and that I would suffer through this awful experience like a prisoner of war until one day my Microsoft would rescue me. I thought I would at least get to apostatize some filthy Java writing scoundrels.
Well, it turned out that after a couple of years of mentoring developers on writing good Java code and unit testing, I realized that not only was Java not so bad, but there were some actual merits of the language and Java frameworks that could be appreciated.
More importantly though, I began to realize that my past code bigotry had closed quite a few doors on my face. It began to occur to me that perhaps all of my technology choices in the past were not necessarily the best. I began to start thinking that there wasn’t actually all the much difference between many of the most popular technologies.
I began to realize that understanding a wide range of technologies and programming languages made me much more valuable than ignorantly subscribing to my own religion about a particular technology that I happened to choose.
I found that my own understanding of individual technologies increased rapidly, because instead of just “eating what I was fed,” I could use my brain to compare and contrast differences between programming languages and technologies which left me with a deeper understanding of all of then.
I was rudely reminded of my own shortcomings that still exist in this area when I recently converted my blogs over to a Linux server in the cloud from Digital Ocean.
I was predisposed to choose Windows technologies for deploying web applications, but it was pretty hard to argue that a complete Linux server in the cloud that performed extremely well for $10 a month was not a good choice.
My point in all this is to say that being closed-minded about technology choices only hurts yourself in the end and severely limits your personal growth as a developer.
There is no “best”
I’ll finish up this post by imploring you to believe me when I say “there is no best technology or programming language.”
I’m not going to insult your intelligence by saying that each language has a purpose for a different situation because the truth is much deeper than that.
After creating over 40 Pluralsight courses on a very wide range of technologies and programming languages, I’ve discovered a few truths.
The truth is that there are multiple great ways to do the same thing using different tools and different technologies.
The truth is that all programming languages and technologies have big mistakes and weaknesses in them.
The truth is the more you learn about different technologies, the more you will find that at the core most things are pretty similar. What I mean by this is that most of the core concepts about writing software apply regardless of technology choice or programming language syntax.
You’ll also find, as I have, that if you are accepting about others technology choices and are able to admit your own ignorance and learn from it, you’ll find helpful friendly people willing to teach you what they know, everywhere you go.
If you found this post useful–or at the very least entertaining–sign up here and join the thousands of other Simple Programmers out there. Also, I’m still preselling my complete package on How To Market Yourself as a Software Developer for a limited time.