Category Archives: Psychology

5 Ways Software Developers Can Become Better at Estimation

In my last post, I detailed four of the biggest reasons why software developers suck at estimation, but I didn’t talk about how to solve any of the problems I presented.

While estimation will always be inherently difficult for software developers, all hope is not lost.

In this post, I am going to give you five real tips you can utilize to become better at estimation–even for complex software development tasks.

Tip 1: Break Things Down Smaller

In my last post, I talked about how lengthy time periods, that are so common with software development projects, tend to make estimation very difficult and inaccurate.

If you are asked to estimate something that will take you five minutes, you are much more likely to be accurate than if you are asked to estimate something that will take you five months.

So, how can we solve this problem?

There is actually a relatively simple fix: Break things down into smaller chunks and estimate those smaller chunks.

smaller 5 Ways Software Developers Can Become Better at EstimationYes, I know this seems simple and obvious–and I know that this approach is often met with skepticism. There are plenty of excuses you can make about why you can’t break things down into smaller pieces, but the truth is, most things can be broken down–if you are willing to put forth the effort.

I’ve actually talked about why smaller is better and how to break down a backlog in the past, so I won’t rehash all the details again here.

The key point to realize is that you are never likely to get good at estimating large things. Well, let me rephrase that: The only way you are going to get good at estimating large things is to be learning how to break them down into many smaller things.

If you really need to accurately estimate something, it is well worth the effort to spend the time breaking down what you are estimating into much smaller pieces.

For example, suppose I was going to estimate how long it will take me to write a blog post. It’s not a very large task, but it’s big enough that estimates can be a bit inaccurate.

If I want to be more accurate, I can break down the task into smaller pieces.

Consider the difference between trying to estimate:

  • Write and publish a blog post

And:

  • Research blog post and brainstorm
  • Outline blog post
  • Write first draft of blog post
  • Add images, links and call-outs
  • Schedule post for publishing

By breaking things down into smaller pieces, I can more accurately estimate each piece. In fact–here is a little trick–when things are broken down this small, I can actually time-box certain parts of the process–which is effectively ensuring my estimate is accurate (but, we are jumping ahead, we’ll talk more about time-boxing in a little bit.)

The next time you are asked to implement some feature, instead of estimating how long you think it will take you to do it as a whole, try breaking down the task into very small pieces and estimating each piece individually. You can always add up the smaller estimates to give a more accurate estimate of the whole.

But wait! I know exactly what you are going to say is wrong with this kind of estimation. Sure, each individual piece’s estimation may be more accurate, but when you add them back together, in aggregate, you’ll still get the same level of error as you would from estimating one large thing.

All I can say to that argument is “try it.” To some degree you are right, the smaller errors in the smaller pieces will add up and cause the whole to be off by more in aggregate, but the smaller pieces also tend to average out. So, some take less time and some take more, which means that overall, you end up a lot more accurate than estimating one large thing with a large margin of error.

Tip 2: Taking time to research

Why do you suck at estimation?

Because you don’t know enough about what you are estimating.

In the previous post, I talked about how the unknown unknowns, that plague many software development projects, make estimation extremely difficult, but I didn’t really talk about how to deal with these things that we don’t know that we don’t know.

Again, the answer is really quite simple: research.

research 5 Ways Software Developers Can Become Better at Estimation

The best way to get rid of an unknown unknown is to know about it.

Whenever you are tasked with estimating something, your first instinct should be to want to do some research–to try and discover what it is that you don’t know that you don’t know yet.

Unfortunately, most software developers don’t immediately think about doing research when trying to estimate something. Instead, they rely on past experience. If they’ve done something in the past that they deem similar enough, they will confidently estimate it–ignoring the possible pitfalls of the unknown unknowns. If they’ve never done something similar to what they are being asked to estimate, they’ll assume there are unknown unknowns everywhere and come up with estimates full of padding.

Neither approach is good. Instead, you should first try and estimate how long it will take you to research a task before giving an estimate of how long the actual task will take. I’ve found that most software developers are pretty good at estimating how long it will take to research a task, even though they may be very bad at estimating how long it will take to complete the task itself.

Once you are armed with research, you should have fewer unknown unknowns to deal with. You may still have some unknowns, but at least you’ll know about them.

But, how does this look in reality?

How do you actually research tasks that you are supposed to be estimating?

Well, sometimes it involves pushing back and planning things out a bit ahead of time. I’ll give you an example of how this might work on a Scrum or Agile team.

Suppose you want to start improving your estimates by doing research before estimating tasks. The problem is that when you are working on an Agile project, you usually need to estimate the tasks in an iteration and don’t really have the time to research each and every task before you estimate it–especially the big ones.

I’ve found the best thing to do in this scenario is instead of estimating the big tasks right up front, to push the tasks back one iteration and instead estimate how long it will take to research each big tasks.

So, you might have in your iteration any number of small research tasks which only have the purpose of getting you enough information to have a more accurate estimate for the big task in the next iteration. During these research tasks, you can also break down large tasks into smaller ones as you know more about them.

Wait… wait.. wait… I know what you are thinking. I can’t just push a task into the next iteration. My boss and the business people will not like that. They want it done this iteration.

Right you are, so how do you deal with this problem?

Simple. You just start planning the bigger tasks one iteration in advance of when they need to be done. If you are working on an Agile team, you should adopt the habit of looking ahead and picking up research tasks for large tasks that will be coming up in future iterations.

By always looking forward and doing research before estimating anything substantial, you’ll get into the habit of producing much more accurate estimates.

This technique can also be applied to smaller tasks, by taking, sometimes, just five or ten minutes to do a minor amount of research on a task, before giving an estimation.

The next time you are trying to estimate a task, devote some time upfront to doing some research. You’ll be amazed at how much more accurate your estimates become.

Tip 3: Track your time

One of the big problems we have with estimating things is that we don’t have an accurate sense of time. My memory of how long past projects took tends to be skewed based on factors like how much I was enjoying the work and how hungry I was.

This skewed time in our heads can result in some pretty faulty estimations.

For this reason it is important to track that actual time things take you.

It is a very good idea to get into the habit of always tracking your time on whatever task you are doing. Right now, as I am writing this blog post, my Pomodoro timer is ticking down, tracking my time, so that I’ll have a better idea of how long blog posts take me to write. I’ll also have an idea if I am spending too much time on part of the process.

Once you get into the habit of tracking your time, you’ll have a better idea of how long things actually take you and where you are spending your time.

It’s crazy to think that you’ll be good at estimating things that haven’t happened yet, if you can’t even accurately say how long things that have happened took.

Seriously, think about that for a minute. No, really. I want you to think about how absurd it is to believe that you can be good at estimating anything when you don’t have an accurate idea of how long past things you have done have taken.

Many people argue that software development is unlike other work and it can’t be accurately estimated. While, I agree that software development is more difficult to estimate than installing carpets or re-roofing houses, I think that many software developer’s suck at estimation because they have no idea how long things actually take.

Do yourself a favor and start tracking your time. There are a ton of good tools for doing this, like:

If you are curious about how I track my time and plan my week, check out this video I did explaining the process I developed:

By the way, following this process has caused me to become extremely good at estimating. I can usually estimate an entire week worth of work within one-to-two hours of accuracy. And I know this for a fact, because I track it.

Tip 4: Time-box things

I said I’d get back to this one, and here it is.

One big secret to becoming a software developer who is better at estimating tasks is to time-box those tasks. It’s almost like cheating.

When you time-box a task, you ensure it will take exactly as long as you have planned for it to take.

You might think that most software development tasks can’t be time-boxed, but you are wrong. I use the technique very frequently, and I have found that many tasks we do tend to be quite variable in the time it takes us to do them.

I’ve found that if you give a certain amount of time to a task–and only that amount of time–you can work in a way to make sure the work gets done in that amount of time.

Consider the example of writing unit tests:

For most software developers, writing unit tests is a very subjective thing. Unless you are going for 100% code coverage, you usually just write unit tests until you feel that you have adequately tested the code you are trying to test. (If you do test driven development, TDD, that might not be true either.)

If you set a time-box for how long you are going to spend on writing unit tests, you can force yourself to work on the most important unit tests first and operate on the 80 / 20 principle to ensure you are getting the biggest bang for your buck.

For many tasks, you can end up spending hours of extra time working on minor details that don’t really make that much of a difference. Time-boxing forces you to work on what is important first and to avoid doing things like premature optimization or obsessively worrying about variable names.

Sure, sometimes, you’ll have to run over the time-box you set for a task, but many times, you’ll find that you actually got done what needed to be done and you can always come back and gold-plate things later if there is time for it.

Again, just like tracking your time, time-boxing is a habit you have to develop, but once you get used to it, you’ll be able to use it as a cheat to become more accurate at estimates than you ever imagined possible.

You may want to get yourself a Pomodoro or kitchen timer to help you track your time and time-box tasks. Sometimes it is nice to have a physical timer.

Tip 5: Revise your estimates

Here is a little secret: You don’t have to get it right on the first go. Instead, you can actually revise your estimates as you progress through a task.

revision 5 Ways Software Developers Can Become Better at Estimation

Yes, I know that your boss wants you to give an accurate estimate right now, not as you get closer to being done, but you can always give you best estimate right now and revise it as you progress through the task.

I can’t image any situation where giving more up-to-date information is not appreciated.

Use the other four tips to make sure your original estimate is as accurate as possible, but every so often, you should take a moment to reevaluate what the actual current estimate is.

Think about it this way: You know when you download a file and it tells you how long it will take? Would you prefer that it calculated that duration just at the beginning of the download process and never updated? Of course not. Instead, most download managers show a constantly updated estimate of how much time is left.

Just going through this process can make you better at estimations in general. When you constantly are updating and revising your estimates, you are forced to face the reasons why your original estimates were off.

What about you?

These are just a few of the most useful tips that I use to improve the accuracy of my estimates, but what about you? Is there something I am leaving out here? Let me know in the comments below.

Also, if you liked this post, join over 6,000 other software developers that are part of the Simple Programmer community. Just sign up here and start your journey to becoming a better, more fit, and productive software developer.

 

4 Biggest Reasons Why Software Developers Suck at Estimation

Estimation is difficult.

Most people aren’t good at it–even in mundane situations.

software development estimation 4 Biggest Reasons Why Software Developers Suck at Estimation

For example, when my wife asks me how much longer it will take me to fix some issue I’m working on or to head home, I almost always invariably reply “five minutes.”

I almost always honestly believe it will only take five minutes, but it never does. Most of the time my five minutes ends up being half an hour or more.

But, in comparison to the world of software development efforts, my five minutes estimation is usually fairly accurate–it’s only off by a factor of six or so.

It’s not unheard of to have software development estimations be off by as much as one-hundred-fold. I’ve literally had an hour long estimation turn into two weeks.

But, why are software development estimations usually off by so much?

Here are the four biggest reasons I have found:

Reason 1: The unknown unknowns

This phrase was first uttered by former Secretary of Defense of the United States, Donald Rumsfeld. It basically refers to those things that we don’t even know that we don’t know.

donald rumsfeld 4 Biggest Reasons Why Software Developers Suck at Estimation

You don’t know what you don’t know

By far, this is the biggest reason why software developers often flub at giving good estimations. It also happens to be the primary reason why I suck at telling my wife how long it will take me to get home–I don’t know about the distractions that I don’t know about yet.

Software development has a lot of unknowns. Some of the unknowns we know about.

When we first start a project, we might have a good idea that we need to store the data in a database, but we don’t know how we’ll do it. That is a known unknown. We know that we don’t know something that we’ll eventually need to know.

Estimating a known unknown is pretty difficult, but we can do a decent job of it if we can compare it to something similar we’ve already done before.

I don’t know how long it will take me to write this particular blog post, but I know about how long it has taken me to write other blog posts of a similar length.

What is really scary though, are the things that we don’t even know we don’t know yet.

These unknown unknowns sneak up on us, because we don’t even know they exist–by definition they are unknowable. It’s one thing to know that we have a gap in a bridge somewhere that we have to cross, it is a whole other thing to have to cross a bridge blindfolded and only find out about gaps when you fall through them.

Constantly, in software development, we are faced with situations where we have to encounter these unknown unknowns. There is no good way to estimate around them. The best we can do in these cases is give ourselves a lot of padding and a lot of rope so that we can climb out of any gaps in the bridge that we fall into.

Reason 2: Lengthy time periods

As if unknown unknowns weren’t bad enough, the deck is stacked against us even further.

Most software development estimations involve fairly long periods of time. This has changed somewhat with Agile development practices, but we still are often asked to estimate a week or more worth of work at a time. (Plus, let’s not forget those sneaky project managers who try to throw Agile projects into Microsoft Project anyway and say “yeah, I know this is Agile and all, but I’m just trying to get a rough idea of when we’ll be done with all of the features.”)

It’s fairly easy to estimate short periods of time–well, I guess unless it’s me telling my wife how long it will take for me to get off the computer. Most of us can pretty accurately predict how long it will take us to brush our teeth, write an email or eat dinner.

Long periods of time are much more difficult to estimate accurately. Estimating how long it will take you to clean out the garage, write a book, or even just to go grocery shopping is much more challenging.

grocery shopping 4 Biggest Reasons Why Software Developers Suck at Estimation

The longer the period of time you are trying to estimate, the more that small miscalculations and the effects of known unknowns can cause an initial estimate to be grossly off target.

In my experience, I’ve found that estimating anything that will take more than about two hours is where things really start to go off of the rails.

As a mental exercise, try and estimate things of varying lengths.

How long will it take you to:

  • do 10 pushups?
  • make a cup of coffee?
  • go to the convenience store and buy something?
  • write a one page letter?
  • read a 300 page novel?
  • get the oil changed in your car?

Notice how the things that can be done in under half an hour are very easy to estimate with a high level of confidence, but as you go out further in time it gets much more difficult.

Most of the time when we do software development estimates, we don’t try and estimate short things, like how long it will take to write a single unit test, instead we tend to estimate longer things, like how long it will take to complete a feature.

Reason 3: Overconfidence

I’m pretty presumptuous when it comes to estimations. I usually think I’m very accurate at making estimations. My wife would disagree–at least when it comes to making estimations of time things will take me. History would probably tend to vindicate her viewpoint.

As software developers, we can often become pretty convinced of our ability to accurately predict how long something will take. Often, if the programming task we are about to embark upon is one we feel confident about, we can be pretty aggressive with our estimates–sometimes to the point of absurdity.

overconfident 4 Biggest Reasons Why Software Developers Suck at Estimation

Oh ye of little faith, of course I can rewrite the application in half an hour

How long will it take you to get that feature done?

Oh, that? That’s easy. I can get that done in a few hours. I’ll have it done by tomorrow morning.

Are you sure? What about testing? What if something comes up?

Don’t worry, it’s easy. Shouldn’t be a problem at all. I just need to throw a few buttons on a page and hook up the backend code.

But, what happens when you actually sit down and try to implement the feature? Well, first you find out that it wasn’t quite as easy as you thought. You forgot to consider a few of the edge cases that have to be handled.

Pretty soon you find yourself taking the entire night to just get set up in order to actually start working on the problem. Hours turn into days, days into weeks and a month later, you’ve finally got some shippable code.

Now, this might be a bit of an exaggeration, but overconfidence can be a big problem in software development–especially when it comes to estimations.

Reason 4: Under-confidence

Under-confidence isn’t actually a word. I suppose that is because someone wasn’t confident enough to put it in the dictionary.

But, just as overconfidence can cause a software developer to under-estimate how long a programming task will take, under-confidence can cause that same software developer to overestimate a completely different task, which may even be much easier.

I don’t know about you, but I often find myself in situations where I am very unsure of how long something will take. I can turn a simple task that I don’t feel comfortable doing into a huge mountain that seems almost impassible.

We tend to view things that we’ve never done before as harder than they are and things that we have done before as easier than they are–it’s just human nature.

Although it may not seem like it, under-confidence can be just as deadly to estimations though. When we are under-confident, we are more likely to add large amounts of padding to our estimates. This padding might not seem all that bad, but work has a way of filling the time allotted for it. (This is known as Parkinson’s law.)

So, even though, when we are under-confident, it might appear that we are pretty accurate with our estimations, the truth is we may be wasting time by having work that might have been done in half the time fill the entire time that was allotted for it.

(By the way, if you are looking for a good book on Agile estimation, check out Mike Cohn’s book: Agile Estimating and Planning.)

What else?

Did I leave anything out? What do you think is the biggest reason why software development estimations are so difficult?

This post is the first in a series of posts about software development estimation. If you’d like to make sure you get the following post in this series talking about how to get better at estimation, make sure you subscribe here and you’ll get the post directly in your inbox.

The Caffeinated Coder: Is Caffeine Good or Bad?

For a long time I’ve wondered about the benefits or detriments of caffeine. I’ve always been one of those coffee drinkers who didn’t have to have coffee, but drank it when it was available.

I’ve never really noticed how caffeine affected me, because I never really paid that much attention.

But, I’ve always been curious, especially as a software developer, whether or not caffeine had an overall positive or negative effect.

For the purposes of this post, I’ll equate drinking caffeine with drinking coffee, since most of the studies are done on coffee and not caffeine specifically, and most of my caffeine intake comes from coffee.

coffee The Caffeinated Coder: Is Caffeine Good or Bad?

Anyway, about 4 months ago or so, I stopped drinking coffee completely. I tried to cut out pretty much all caffeine. About a month or so again, I started drinking coffee again. In fact, I am sitting in a coffee shop here in Maui drinking some coffee as I type this post.

Quitting coffee

When I first stopped drinking coffee I didn’t really notice any withdrawal effects. Some people report massive headaches and nausea, but I didn’t notice anything really. Perhaps just a bit more sleeping. Now, that might have been because I never was a big coffee drinker. I would usually have 1 or 2 cups a day and a few diet cokes.

You might be wondering why I decided to quit caffeine in the first place. Mostly it came from the idea that I didn’t want to be dependent on any substance and I thought that the extra energy or boost I was getting from caffeine must have been coming at some cost. I wanted to see if I could achieve more even energy levels by avoiding caffeine completely. And really I was just curious to see if I would even notice the difference.

One of the first differences I did notice, after about a week, was that I did feel more level. In general, I felt like my energy levels were the same throughout the day, except for at night when I was a bit more tired than usual.

no coffee1 The Caffeinated Coder: Is Caffeine Good or Bad?

Being more level was what I was going for, so in a way that was good, but I also started to feel more depressed. At first I thought I was imagining it, but having been back on caffeine now for over a month, I am sure that being off caffeine was causing some amount of depression. I figured this mood change would lessen over time, but after about 3 months, it didn’t seem to change. I only started to see improvements in mood after I started drinking coffee again.

I also noticed that I started to feel less motivated. Now, this could have been somewhat of a coincidence, since I had just gone through a period of working very hard, but I suspect it was somewhat related to not having the caffeine.

Part of the reason for the lack of motivation might have been related to my difficulty in focusing. I did notice that without the caffeine, I was having a more difficult time sitting down and working for extended periods of time. I was much more likely to be distracted and start checking Facebook or doing something else, rather than staying on task.

Overall though, quitting caffeine didn’t really seem to have any positive benefits. I was expecting to feel better and have steady energy levels throughout the day. I was also expecting better sleep, but I really didn’t notice anything but negative effects.

Adding caffeine back

I finally decided to start drinking caffeine again. I’m not sure exactly why, but I think I got to the point where I realized that I wasn’t getting any notable positive benefits from quitting caffeine, so I was curious to see if I would now gain some positive benefits from adding it back.

I have to say that as soon as I started drinking coffee again, I began to notice an increase in overall happiness. My mood, in general, seemed to improve. I did not expect this at all, but after a few weeks, it was pretty apparent that adding caffeine back into my diet was the cause.

I also immediately noticed that my ability to focus increased. I found it much easier to sit down and write a blog post or work on something for several hours at a time without becoming distracted. Even now, as I am writing this post, I am finding it extremely easy to write without being tempted to do something else. The whole time I was not taking caffeine, I was struggling with sitting down for more than 30 minutes to work on something.

About the time I started taking caffeine again, I had decided to start doing some all-day fasts in order to drop some weight and to keep from gaining weight while I was on semi-vacation here in Maui. I had seen several studies that showed that caffeine, especially combined with Yohimbine, (which I am also taking,) had some positive effects on fat loss. I can’t completely confirm that this is the case, but I have lost significant fat during this time period and do feel like my appetite is suppressed to some degree.

Now, I don’t want to pretend that adding caffeine back was all good. There was at least one detrimental effect I noticed. Once I started drinking coffee again, I noticed that it was much more difficult to get good sleep. I noticed that even drinking decaf coffee in the evening seemed to cause me to have sleeping difficulties. Fortunately, those effects did seem to subside, especially when I started making sure to cut my caffeine consumption after noon each day. But, really that was the only detrimental effect I noticed.

What about the studies? What do they say about caffeine?

Obviously, everything I’ve talked about so far has been from my own observations, experimenting on myself, but there have been plenty of studies done on drinking coffee and consuming caffeine. So what do they say?

Well, most studies say that drinking coffee is good for you. I really couldn’t find anything that showed any conclusive evidence that caffeine was bad for you. There were a few studies that showed some possible negative effects–especially if you drank way too much–but, overall almost all the research points to positive effects for coffee and caffeine.

One of the most documented effects of caffeine is on energy levels–no surprise there. Caffeine has been shown to increase energy levels by basically suppressing adenosine in the brain. This has the effect of letting more of the brain’s stimulants do their work. So caffeine doesn’t actually give you energy, it just stops your brain from regulating it so much.

Studies have also shown a positive increase in brain function. Focus levels and memory seem to be improved by caffeine consumption and some studies have shown that it may help stave off diseases like Alzheimer’s and even Parkinson’s.

I talked about this a little before, but caffeine is in just about every fat burning pill out there. The reason is because studies have shown that it has appetite suppressing effects and can help increase metabolism. These effects have generally been shown to be pretty small though, so I wouldn’t give them that much weight.

Finally, and not so surprisingly, caffeine has been shown to ward off depression. I wouldn’t have believed this one if I hadn’t experienced it myself, but I’ve seen a couple of studies mentioning this effect.

There was some early research that pointed to coffee and caffeine causing heart disease and higher rates of cancer, but most of those studies were flawed because they failed to take into account that the more frequent coffee drinkers were also more likely to be smokers. In fact, many of the recent studies show that drinking coffee is likely to help you live longer.

If you want to read a good book on caffeine, check out: Buzz: The Science and Lore of Alcohol and Caffeine.

So should coders drink caffeine?

I’m sure you can guess what my opinion on this is. Overall, I think it is beneficial–but, in moderation.

Plenty of data suggests that drinking too much caffeine starts to decrease the effectiveness of it. If you drink 10 cups of coffee every day, your body will adapt to it and pretty soon you will stop getting the benefits of being more alert and focused.

It seems that you get the best benefit if you don’t let your body get too adapted to it and you time the caffeine intake with the times when you need extra focus and energy.

I would say that you can actually get extra work done with no real additional cost if you can consume caffeine at the right times. I always suspected that you paid for that extra energy somehow, but now I don’t think that is the case. So, yes, caffeine can actually help you be a better coder.

With that said, I would avoid drinking caffeine later in the day, because it definitely can disrupt your sleep. Caffeine usually has a half-life of about 6 hours, so it is probably best to steer clear of it in the afternoon, not just the evening.

In summary, after experimenting on myself and reading all the research I could find, I don’t see any benefit from abstaining from caffeine. It seems that if you do it right, you can get a net positive effect with almost no drawbacks. So, drink up.

If you liked this blog post and you’d like to read more about how you can be a better programmer, join over 5,000 other software developers who have become part of the Simple Programmer community.

Don’t Focus on Your Strengths

Guys, guys, guys… (and gals)

I think we are starting to becoming a little “wussy”–all of us–no offense.

I’ve found the most success in my life by working on my weaknesses and making them strengths. Why? Because, when you make a weakness into a strength you appreciate it more and you are more committed and dedicated to improve it further.

A weakness that became a strength is a trophy; something you worked for

trophy Dont Focus on Your Strengths

It takes discipline, determination and focus to make a weakness into a strength. That means when you do it, you are much more likely to stay with it for the long term.

Strengths we tend to take for granted. We tend to follow our passions with strengths because they come naturally, but we don’t feel as proud of our accomplishments because they come naturally.

And I’m not just saying this.

Honestly, I am naturally lazy, un-athletic, introverted, shy, and suck at written communication.

One day I decided to stop being un-athletic. So, I joined wrestling and track in high school and started lifting weights and running. Totally against my nerdy, weak, frail, fat, lazy nature. Now, it is one of my strengths and I stick with it because I put so much into it. I am dedicated.

Drawing and art comes naturally to me. Ever since I was little I could draw near perfect Marios and cartoons. No joke, I’ll prove it sometime. Anyway, do I draw now? Do I develop that strength further? No. Sure, I could, but I lack the motivation, because I never had to work for it. I’ve got no true appreciation for it. Natural strengths we take for granted and we don’t feel as good about because they aren’t something we earned, they are something we were born with.

I’m not saying you never focus on your strengths, but what I am saying is this:

You are only as strong as your most limiting weakness. The whole weakest link thing. You can’t just focus on your strengths, because you have to attack the problem at the bottleneck. Getting faster and faster CPU speeds does you no good when you have a slow hard drive.

weak link Dont Focus on Your Strengths

Also, the things that suck the most are usually the most beneficial for you. I feel like we’ve all become a bit soft lately–myself included. Sure, you can’t go at 100% all of the time, but no success is ever achieved without hard work, discipline and most importantly commitment.

Commitment is the real killer. Sure, I can spend a day doing something I don’t want to do. I can even make it a week, but can I do it day in and day out for a year? For a decade? It takes a long period of dedication and commitment to be successful. So many people stop just short of success.

Where does success come from?

The crappiest most painful things were the things that made me the most successful–and if you look carefully, I’m sure you’ll find the same for yourself.

Don’t forget where you came from. Don’t forget about the hill you already climbed to get here now. Don’t forget how many bargains with the devil you would have made perhaps just a few years ago to get where you are now and think carefully how you got here. The same way that you got here will be the same way that you get to there.

Or perhaps you aren’t there yet. Perhaps you haven’t even climbed that first hill yet. If so, what is stopping you? Are you afraid of doing some things you don’t want to do? Maybe it’s time to put on those coveralls, grab the shovel and shovel some manure.

A head-start will only take you so far

I know I’ve started to wander away from the point a little bit, but my point is that you aren’t going to get by based solely on your strengths and if you try to focus on your strengths alone, you are going to find that you lack the commitment and follow-through to be successful.

I’m not saying to not use or develop your strengths–do that–but, just realize that the effort you put into developing your weaknesses–especially the ones that are holding you back the most–will probably pay you back the most in the long run.

Think of it this way: A strength or natural talent is like having a small head-start in a race. It’s helpful and against equally strong competitors, it’s an unbeatable advantage. But, in a really long race with competitors that have trained hard and developed their ability, that head-start means virtually nothing. If you rely on the head-start your strength is going to give you in life, you are eventually going to get passed.

Looking at it from another angle, you can become that person who doesn’t have the head-start, but is a way better runner than someone who does. I know plenty of naturally talented people who end up doing nothing with that talent, because they never develop it beyond that initial head-start it gave them.

Who do you think will be a better musician in the long run, someone who has a natural talent for music and plays their instrument once a week or someone who is practically tone-deaf and practices for several hours every single day?

Again, I’m not saying to not use your strengths, but instead use them strategically. Use your strength to knock down the wall with one blow instead of chipping away at it. Augment your natural strength by developing ancillary strengths from your weaknesses that compliment it.

Also, use the development of your weaknesses as a way to develop skills that none of us are born with naturally. Self-discipline and patience must be developed and they can’t be developed directly. They are always an indirect result of working on a weakness. You don’t learn how to control yourself, focus and stay the course by doing something you enjoy. You learn it by doing something that feels like it is going to kill you.

(By the way, I know I keep plugging this book, but it really is one of the best books for getting your ass kicked and motivating you to power through, so if you haven’t read The War of Art, do yourself a favor and get it and read it.)

Can you make up for a weakness?

Yeah, I know I am being a hard-ass. That’s my job. If you want someone to sugarcoat things for you, you probably should go read another blog. I’m just telling you how it is.

What about focusing on your strengths and surrounding yourself with people who can help compensate for your weaknesses? This is a great idea, but it has its limits. You can’t use this as a cheat code to keep yourself from fully developing your own character and discipline.

Sure, you can’t be good at everything, but if you–for example–hire an accountant, because you suck at finances and don’t understand money, guess what is going to happen to you? You are going to get ripped off and you won’t even know it. I’m not saying you should do your own taxes or handle every job yourself, but before you hire someone for a job, you need to know how to do it yourself–and you have to even be a little bit good at it.

I’ve talked about this before, but you can’t know how good someone is at something unless you are at least moderately good at that thing yourself. Trust me, I’ve made the mistake myself of trying to hire someone to make up for my weakness instead of working on the weakness and I’ve always regretted it. You can’t cheat the system.

So, am I advocating burning yourself out, stretching yourself in so many directions that you just become mediocre at a lot of things instead of an expert at one?

By all means no. What I am saying is that instead of band-aiding over your weaknesses and trying to avoid them, you need to confront them directly–especially if they are stopping you from going down some path that could lead to your success.

I’m just trying to make you aware of the reality that natural strengths and head-starts in life don’t mean much at all unless you happen to be 7 feet tall, in which case, you’ll probably be an excellent basketball player. (But, even with that advantage without a lot of practice a shorter player will still be able to beat you.)

basketball Dont Focus on Your Strengths

So, to sum it all up. Be smart. Use your strengths but also develop your weaknesses. Don’t just not do something or shy away from it because it is a perceived weakness for you. If you do that you’ll be robbing yourself of the true opportunity to achieve meaningful personal growth. If you never deal with your weaknesses you’ll be like that heavyweight boxer that can throw a powerful knock-out blow, but has a glass jaw.

If you’d like more developer-centric, hard-ass advice from a developer who cares about making you a better version of yourself and you’d like to join over 5,000 other developers who are part of the Simple Programmer community, sign up here. I’ll occasionally try and sell you stuff, but I’ll mostly kick you in the ass.

 

 

Your Worst Enemy Is Yourself

Here’s the thing…

You could have been exactly where you want to be right now.

You could have gotten the perfect job.

You could have started that business you always wanted to start.

You could have gotten those 6-pack abs.

You could have even met the love of your life.

There has only been one thing standing in your way, and there will always be one thing standing in your way–you!

You are constantly at war with yourself

war self Your Worst Enemy Is Yourself

Ask most people what they need to do to solve their problems and they can give you a definitive answer.

Most people know how reach their fitness goals, their financial goals, and any other goals they have. Knowledge is rarely the problem.

Right now, I guarantee you that there is at least one goal that you’d like to achieve, that you know how to achieve, but you still haven’t been able to do–why?

It’s not lack of knowledge that is holding you back, it is a war within yourself–a fierce battle that is raging between different parts of your conscious mind. One side is telling you what you need to do, the other side is justifying all kinds of short-term excuses in order to hold you back.

One of my favorite authors, Steven Pressfield, calls this mysterious force that is fighting you resistance, in his excellent book, The War of Art.

But, I’m going to level with you here and tell you that the truth is that the enemy you are fighting is actually yourself. As humans we are constantly involved in a self-sabotage that holds us back from achieving what we desire.

That is one of the reasons that you’ll notice, if you follow this blog regularly or my YouTube videos or other productions, that I focus on the mental aspect of software development.

I can give you all the knowledge in the world about how to write good code and how to succeed at your career, but ultimately it won’t do you any good if you can’t learn to conquer yourself.

Conquering yourself

How do you beat an enemy that knows everything about you?

How can you possibly defeat an adversary that has the power to undermine any defense you prepare against him?

Let me tell you a little story that might help to illustrate the answer.

Yesterday, I took my family on a drive to the northern part of west Maui. We hadn’t gone around the northern part of Maui, but we knew that the road was a bit dangerous and scary.

My wife and I discussed whether we should try and make the trip all the way around the north side of the island. We heard there was some killer banana bread at a little stand about halfway around.

After some deliberation, we finally decided to do it. We got on the road and drove past a sign that said “end of state highway.” From there on out it was a single lane road–actually less than a single lane road for many parts–that wrapped around steep mountains and sheer cliffs with no guard-rails in sight.

highway Your Worst Enemy Is Yourself

In all honesty, the road itself wasn’t all that scary. The biggest fear was that someone would be coming the other way and we’d have to drive backwards down the road until we could find a turn-out to let them pass. After about an hour and a half, we made it to the other side, world’s best banana bread in hand.

Now, here is the interesting thing about that trip; for the scary parts of the road, there was no place to turn around. Once you were winding around the golf-cart sized lane going around the mountains, you had to keep going forward, because you didn’t have the option of going back.

Had there been places to turn around, I might have chickened out and turned around, but because I didn’t have the option, I had to keep going forward.

That is the key in conquering yourself–leaving no quarter.

Pre-make decisions and commit to them

If you want to be victorious in this battle with yourself, you have to realize that you can’t win.

That’s right, you can’t win, so don’t even try… at least not in a battle of the wills.

If you constantly put yourself in positions where you have to make judgement calls, you’ll constantly find yourself making the wrong calls and being defeated time and time again.

When you are at the decision-making point of a judgement call, you’ll find your enemy has all kinds of tricks up its sleeve.

You’ll suddenly feel hopeless. You’ll convince yourself that you don’t really want what you are seeking. You’ll tell yourself that one piece of cake won’t hurt anything. You’ll promise yourself to get back on the wagon tomorrow. There is no end to the excuses and the justifications you’ll come up with to stop yourself from achieving success.

So, here is the trick: eliminate as many of the judgement calls as possible.

When you want to to do something, spend time to carefully form a plan, take time to think things through, then commit to the plan and don’t allow yourself the opportunity to question the plan until after it has been executed.

Basically, take the part of your brain that always defeats you hostage. Tie him up, throw him in the backseat of your car, and drive forward down that one-lane mountain road. Even if he ends up breaking free, he won’t be able to convince you to turn around, since you can’t.

Rules, rules, rules…

The key is to set up rules for yourself that will govern your actions in certain situations.

If you want to lose weight, eating healthy is not a good plan. You need an actual diet that is planned out in advance. Making judgement calls every time you need to eat will eventually wear down your resolve and you’ll find yourself stuffing your face with foods that definitely aren’t healthy.

If you want to write a blog post every week, you need to make a rule about it. Don’t give yourself the option of not doing it. Don’t write only when you feel like it.

Want to improve your programming skills by practicing solving problems or reading technical books? Come up with a certain amount of time you have to devote to the task each day and don’t allow yourself to question whether or not you should do it, instead make it a rule you must obey every single day.

This concept of applying so many rules to your life may not seem very appealing, but the truth is we all hate freedom. We just can’t handle it. We think we want freedom, but when we have it all we do is sit on the couch and do nothing all day.

True freedom is doing exactly what you want to do and in order to do that you need discipline and discipline comes from following rules. The difference here is who the master is. Is someone else setting the rules for you to follow or are you setting the rules?

If you can’t set and obey your own rules, you will always be subject to the rules of others. If you can’t learn to be your own master, you’ll always have another person as a master over you.

The level of true, actual freedom you are afforded is directly related to your ability to obey the rules you set for yourself.

Think of it another way: If you can’t control yourself to do what you intend to do then you don’t have any freedom at all. Paradoxically, the most free person is the person who is able to constrain themself the most, because they always do exactly what they intend to do.

Sticking to the plan

Now, just because you make rules and follow them, doesn’t mean that you can’t ever break those rules, or change your mind, but it is critical you stay the course long enough to achieve the results you are trying to achieve or to at least be sure you aren’t giving up prematurely.

I have a standing rule that I would suggest you apply to your life right now.

The rule is that I can’t ever quit anything at the time of making a decision of whether or not to do it.

What this means is that if I set some rules for myself, like going for a run three times a week, I can’t break that rule or rewrite that rule when I wake up in the morning and don’t feel like running. I also can’t break or change that rule in the middle of the week. I could decide this week that next week I will drop the running down to two times a week or quit it all together, but this week, I’ll carry forward with the plan.

By having this master “no quitters” rule in place, you protect yourself from the nasty self-sabotage of changing course midstream. It’s not that you can never change course–you can–you just have to limit how often you change courses–if you ever want to get anywhere–and you need to make sure you are not changing courses for the wrong reason.

By making sure you never quit midstream, by making sure you always follow through with at least the current leg of the journey, you prevent yourself from making critical mistakes due to just having a bad day or having the wrong mental attitude.

Some final advice

So, if you want to defeat your worst enemy–yourself–here is my advice:

  • Plan as many things in advance as possible. Always have some plan that will take you forward towards your goal.
  • Set rules for yourself around your plan. Make these rules as strict as possible and obey them at all costs. Once you go down the slippery slope of breaking your own rules, they’ll have less and less power, so take these rules seriously.
  • Implement the “no quitters rules.” Don’t quit or change your rules at the time of making a decision. Plan ahead when you’ll change the rules or break them.
  • Don’t give up. You’ll fail and that is ok. But don’t ever accept failure or defeat. Get back on the horse, and keep fighting the battle.

So, set some rules, strap your brain into the backseat and drive right right through those one-lane mountain roads of life. Who knows, there might even be some tasty banana bread waiting for you on the other side.

If you liked this post, you might want to join over 5,000 other developers who are part of the Simple Programmer community. Just sign up here and you’ll get access to exclusive content I only release to Simple Programmers.

 

Anything Worth Doing is Worth Doing Right

It seems that I am always in a rush.

I find it very difficult to just do what I am doing without thinking about what is coming next or when I’ll be finished with whatever I am working on.

rushing Anything Worth Doing is Worth Doing Right

Even as I am sitting and writing this blog post, I’m not really as immersed in the process as I should be. Instead, I am thinking about the fact that I need to get this post done and ready to be published today.

For some reason, I always feel like the clock is ticking down on me. I always feel rushed and that I need to rush things along.

I don’t think I’ve ever sat down and written something that had more than a single rough draft and a final draft. I can’t imagine having multiple drafts of a thing.

Why am I saying this? Because, lately I’ve been meditating on the phrase “anything worth doing is worth doing right.”

Am I really giving it my all?

I’ve been thinking about that phrase a lot and how much I tend to ignore it. I get a lot done, but what I get done isn’t always as satisfying as it should be, because I often find I’m not applying myself as much as I should be.

This “weakness” seems to permeate every area of my life. As I’m running or lifting weights at the gym, I often realize that I’m not giving it my all. As I am writing a blog post, or writing code, I get the same feeling of not giving 100%. When I’m playing with my daughter, or spending time with my family, I’m often not 100% there—but, it’s not like I’m somewhere else either. I’m often just sort of wandering through life a little bit “checked out.”

The best word I can use to describe this is slothfulness. I’ve been feeling this pressing need to eliminate as much slothfulness from my life as possible.

I’m beginning to realize how much time and effort is wasted on doing things in a half-ass manner. If I sit down to do some work and I don’t know exactly what I am doing, if I’m not focused on a specific task I need to get done, I end up wasting a lot of time.

But, it’s actually more than that. I’ve found ways to make sure I am focused on the task at hand in order to make sure that I don’t waste time by taking too long to accomplish a particular task, but what is more difficult is giving 100% to the task at hand. It’s quite possible to be 100% focused, but not to be giving it all you’ve got.

There is a huge penalty in not giving it all you’ve got. This is the real struggle—at least for me—at least right now.

I know the work I am producing could be better. I know the time I’m spending could be more fulfilling, if, I could just fully subscribe to the belief that anything worth doing is worth doing right.

Fixing the problem

The good news is that I have been thinking about some ways to combat this problem. Here are some of my ideas:

First of all, I am going to try and not do anything unless I know what I am going to do and I am going to devote 100% of my focus to that activity.

That doesn’t mean that I have to plan out every aspect of my day ahead of time, but it means that I have to at least plan out what I am going to do before I do it.

For example, today I decided that I was going to go to a coffee shop and get the intro letter for early readers of my book done, write an email that talked about the revisions to the chapters in my book and write this blog post.

I didn’t plan for reading through my email, checking Facebook or doing anything else during that time. I’m sitting here working on exactly what I had planned to work on and I am putting my full focus into that work.

I’ll also plan out when I’ll do certain things so that they aren’t hanging over my head and distracting me from other things I am doing. I find that I can’t focus on the task at hand when I have some uncertainty about another task that I need to get done. Whenever I feel that uncertainty about something that needs to get done, my plan is to schedule it so that I can take it off my mind.

Setting standards

Next up, I’m going to try to have a bit more rigorous standards for what I am doing before I start doing it. I’ve found that it’s often difficult for me to decide what “doing something right” means. It’s pretty subjective and when I feel like I am done with a task, my judgment tends to be skewed. I’m likely to call something done that is “good enough” rather than “right.”

Sometimes the effort to take something from “good enough” to “right” is very small, so it is worth taking the extra time and putting forth the extra effort to go the last mile. I can spend a large amount of time and effort on a task or project and have this gnawing feeling of discontent if I am willing to accept “good enough.” This acceptance of “good enough” often negates the entire reward of the effort, so I want to strive towards doing things right instead of just “good enough,” even if it takes more time.

Stop rushing

That brings me to the next point: stop rushing.

I’m always rushing. Always trying to get things done as fast as possible so that I can be as prolific as possible. While being more prolific might have a higher monetary reward, I’ve found it often comes at the cost of feeling discontent with the work being done.

flowers Anything Worth Doing is Worth Doing Right

This one is going to be one of the most difficult ones for me. Even now, thinking about this very subject, my fingers are still frantically striking the keyboard as I glance at the clock, worried about how long it is taking me to write this post.

I think a solution to this problem may be to block out ample blocks of time to work on a thing. To purposely give myself breathing room. For example, I might feel less rushed if I came here to write a blog post, that I figured would take me about an hour, but I gave myself two hours to work on it instead. And, if I forced myself to spend the entire allotted time working on it, I would probably not feel rushed and I’d would produce an overall better product.

The next task I do, I am going to try and block off time and force myself to use the entire allotted time.

Living in the moment

Let’s see what else is left. How about living in the moment—another extremely difficult one for me now. I have a difficult time stopping to smell the roses. I imagine that if I stop rushing, I’ll probably solve this problem as well, but for now, I am going to try to start purposely giving 100% to what I am doing at any given time.

With every activity I am doing, work or otherwise, I am going to try and focus 100% on what I am doing and also give 100% to that activity. This one will be difficult—I am sure of it. But, this might be the most important thing to focus on. Sometimes I feel like my life is passing me by because I’m always looking forward or backward—I’m never taking time to stop and smell the roses.

One aspect of this that I have been thinking about is to actively think about what I am doing at any given moment and to clearly define it. For example, if I am sitting on the couch, I should ask myself what am I doing. Am I having a conversation with someone? Am I relaxing? Am I doing something else? At any given time I should be able to define what it is I am doing. It doesn’t necessarily have to be something productive. It is better to actively decide that I am spending time browsing Facebook than it is to just be sitting at a computer “doing nothing.”

In fact, I just purchased The Power of Now: A Guide to Spiritual Enlightenment. Not sure if this book is good or not, but several people have recommended it to me and it came to mind today.

Drop more stuff

Finally, I think I need to drop anything that I am not going to do right. This is the full interpretation of “anything worth doing is worth doing right.” I simply need to make a rule that if I am not willing to do something right, if I am not willing to devote my full energy to it, if I am not willing to slow down and not rush through it, then I simply should not do it at all.

I often have thought that if I stopped splitting my focus so much that I’d be able to be much more successful at the things I do choose to do. This is another difficult one for me, because I tend to see one of my greatest assets as my ability to do so many different things. It’s scary and dangerous to either drop things that I am used to doing or to recommit to them, giving 100% effort.

At a surface level, I know that it would be better to focus on a smaller number of things and to dive deeper into those things, but at a deeper level, I’m scared to do it. I’m the kind of person that likes to leave as many doors open as possible. The thought of closing some doors scares me, but I know I need to do it.

Well, that is about it. I’m trying to use this time in Hawaii, away from my normal schedule to be as introspective as possible. Expect some big changes in the next few months as I start to get everything figured out and set the course for the future.

For more of my thoughts about life, and software development, join the Simple Programmer community here.

Taking Action

On any given day my inbox is full of emails from software developers asking me for advice on all kinds of topics. Even though many of these questions are unique, I’ve found that many of the emails have one root, all-encompassing solution: taking action.

Most people never actually do anything with their lives.

Most people are so afraid to make a mistake that they make the biggest mistakes of all—they do nothing.

nothing Taking Action

If you are completely honest with yourself, you’ll probably find that some of the biggest, most important questions you have, you already know the answer to.

You already know what you should do. You might be a bit unsure of your answer, you might feel like you need to think about things more or get some more opinions, but deep down, inside, when you really look hard, you already know the answer.

So, why don’t you just do what you need to do?

Good question.

In fact, if you just started doing what you know you should be doing right now, if you would just take action, you’d have a much better life, a more successful career, and you’d probably be a lot healthier as well.

At some level we all know this is true, yet we have such a difficult time doing what we are supposed to do.

Again, the question is why.

Uncertainty

There are many different whys, but I think it usually starts with the problem of uncertainty. We can do our best to make a decision, but we can’t ever really know for sure if we are right—at least not till we take some action and move forward.

I get a lot of software developers asking me how to improve their career or whether or not they should invest their time in a particular technology or platform. Most of the time these software developers already know the answer to these questions, but they are unsure of the answers they have come up with. They are looking for an outside party to validate what they already know. They are looking for me to bring some certainty to this uncertain world.

Unfortunately, I can’t. I mean, sure, I can tell you that I think learning mobile development is a good idea and that the approach you have planned out sounds reasonable. But, I can’t know for sure. Neither can you.

Life is too complicated to know for sure that some choice or path will lead to success—even if we imagine that we can define exactly what success is—which is more difficult than it sounds. The truth is that you might have to go down many paths to eventually find success. You might have to make a lot of mistakes and fail many times before you find the correct path.

And—that itself isn’t even accurate. What I actually mean is that the correct path has to be carved out. It doesn’t exist yet. You can’t see far enough ahead of you now to even know what the path looks like. As you walk the path, as you encounter and overcome obstacles, as you make slight course corrections and change directions, you discover and create the path at the same time.

Resistance

Now, some of us are held back by more than just uncertainty. Sometimes you know exactly what you should be doing, what action you should take, but you just don’t want to do it.

Most often when we are stopped by this barrier, we call it procrastination. We don’t just say we aren’t going to do what we know we should be doing, but instead we put it off until later. Your mind has a much easier time saying “I’ll do it tomorrow” than admitting that you have no intention of doing something—especially when you know it needs to be done.

(For a good book that can help you get past this habit, check out: Eat That Frog!: 21 Great Ways to Stop Procrastinating and Get More Done in Less Time)

Often the correct path is the difficult one. You might find yourself holding out for a simpler solution; waiting for someone else to blaze a path for you; to cut down the overgrowth with their machete and to build a nice smooth road for you to travel.

machette Taking Action

The reality of the situation though is that there is no one coming to rescue you and give you a simple solution. In fact, the brush may become more overgrown the longer you wait to take action.

Growth is often uncomfortable. Action that leads to growth can be quite painful. When I go into the gym in the morning and lift a heavy weight, it doesn’t exactly feel good. When I sit down to write a long blog post, it doesn’t feel that great either. It’s a bit painful to do something that will improve you or advance you in some way. Don’t waste your effort trying to avoid the pain, just face it head on and realize it is the only path to growth.

Failure

And let’s not forget the fear of failure. The reason why I hesitated so much to write the first few sentences of this post is because I thought it might suck. I still do. As I am typing this very sentence, I am tempted to highlight all the text above and push delete.

What finally got me to start writing? Well, I decided that I need to get a post done for this week and that no post is ever going to be as good as I want it to be, but that doesn’t matter. What matters is that I do something. Sure, this post might suck, but I’ve decided I am ok with that. What I am not ok with is doing nothing. I’m not ok with sitting here in this coffee shop browsing Facebook while I think about the perfect post to write and exactly how to word it. I’m not ok with letting a Monday go by that I don’t have a blog post to publish, because I’m too afraid to take action.

Perhaps that is where you are today. Perhaps you know what you should do, you are even willing to do it, but you are just so afraid of doing it and failing that you sit at your desk paralyzed with fear. If that describes your current situation, I want you to consider something: what is the cost of not acting?

The cost of doing nothing

What will certainly happen if you take no action at all? Think carefully about what the consequences of failure are versus the consequences of stagnation. Would it be better to do something and have it turn out less than you expected than it would be to do nothing at all?

Sure, in a few cases it is actually better to do nothing than to risk a critical failure. But, if we are honest with ourselves, we have to admit that those instances are pretty rare. In almost all cases it is much more beneficial to take some kind of action—even if it results in failure—than to do nothing at all.

Besides, usually when we fail we learn something—often, it is the only way to learn something or to make any progress. If we aren’t willing to embrace a few failures, take it on the chin a few times, we’ll never advance. You don’t become a world-class boxer without being punched in the face a few times.

So, bottom line is: if you are wondering what you should do with your life, if you are questioning what you should do with your career or what programming language you should learn, don’t ask me… ask yourself. But, don’t just ask yourself, actually take action and do something. Don’t worry if what you do ends up being wrong. Just don’t sit idle and let opportunity pass you by. I’ve made a lot of mistakes in my career. I’d say I bat at perhaps 25% on average. But, at the risk of sounding cliché, I miss 100% of the shots I don’t take.

Hey, did you like this post? Want to take some action right now? Join the Simple Programmer community by clicking here and you’ll be part of a community of over 5,000 other software developers who want to improve their careers and their lives by taking a holistic approach to software development.

How to Negotiate Your Salary

I’m often surprised how many software developers neglect to do any salary negotiations at all or make a single attempt at negotiating their salary and then give up and take whatever is offered.

Negotiating your salary is important—not just because the dollars will add up over time and you could end up leaving a lot of money on the table—but, also because how you value yourself and how you handle yourself in a salary negotiation will greatly influence how you are perceived at the company you are working for.

Once you are part of a company it is difficult to shake the first impression that has been pinned on you. If you handle salary negotiations in a tactful way that indicates your value while still respecting your prospective employer, you’ll likely paint yourself in a more positive light which can have huge implications on your future career with that company.

negotiating How to Negotiate Your Salary

Negotiations begin before you even apply for the job

Your ability to negotiate your salary will be greatly influenced by your reputation. Think about a famous athlete or movie star, how much negotiation power does having a well-recognized name have for either of these professions? The same is true for software development or any other field. The more recognized your name is, the more power you will have when it comes to negotiations.

So what can you do to build up a name in the software development field?

For some people it will happen by chance, but for most software developers it will require some careful planning and tactics. If you follow this blog, you probably know that I highly recommend building a personal brand and actively marketing yourself as a software developer.

The basic strategy to do this is to get your name out there through as many different mediums as possible. Write blog posts, get on podcasts, write books or articles, speak at conferences and user groups, create video tutorials, contribute to open source projects and whatever else you can do to get your name out there.

Since, marketing yourself isn’t the topic of this post, I won’t go into details here, but if you are interested in learning more about marketing yourself as a software developer, you can check out this post on the topic or if you want a real in-depth treatment of the topic, you can check out my How to Market Yourself as a Software Developer course.

Just remember the better job you do of marketing yourself and building a reputation, the easier it will be for you to negotiate. This might even be the most important factor. I’ve worked with software developers who have been able to literally double their salaries based on nothing but building up a bit of a personal brand and online reputation.

How you get the job is extremely important

The second biggest factor that will influence your ability to negotiate your salary will be how you got the job. There are many different ways to get a job and not all of them are equal. Let’s examine a few different ways you might get a job.

First, you might get a job by seeing a job posting and cold-applying to that job posting with your resume and hopefully a good cover-letter. In fact, many job seekers think this is the only way to get a job. This is in fact the worst way to get a job. If you get a job in this manner, it is difficult to have a good negotiating position, because you are in a much weaker position than the employer. You are the one taking all the initiative and asking for the job.

The person with the greatest need always has the disadvantage when negotiating anything. Ever played monopoly? Ever tried to negotiate with someone who didn’t really need anything from you, but you needed one of their properties to complete your monopoly? How did that go?

Another way to get a job is through personal referral. You know someone who works at a company, they personally refer you for the job and you end up getting offered the job. This is definitely a much better situation than just applying for a job. In fact, you should always try to get a personal referral when you are actively seeking a job. In this situation, the prospective employer might not even know that you are actively looking for a job—so, your need is going to register as less. And, because you got a personal referral, you already have some credibility. You are essentially borrowing the credibility of the person who referred you for the job. I’m sure you can figure out that the higher credibility of the person who referred you for the job, the higher credibility you will have. This credibility will greatly influence your ability to negotiate when given an offer.

Ok, so how else can you get a job? How about the best way possible? When the company who offers you a job finds you and comes after you either directly offering you the job or asking you to apply for it. How the situation presents itself will influence your negotiating power. Obviously, your best situation would be if a company knows of you and directly offers you a position without even an interview. In that case you’ll be able to just about name your own price. But, any time an employer directly seeks you out, you’ll have a very good position to negotiate from.

Now, you might be thinking “yeah right, an employer is not going to directly seek me out, much less offer me a job without an interview.” I’ll admit, it is somewhat rare, but it does happen. The best way to make these kinds of opportunities happen is to build up a name for yourself and market yourself like I mentioned in the first section of this post.

First person to name a number loses

money How to Negotiate Your Salary

Ok, so now that we’ve covered the preliminaries—which are actually the most important part of negotiating your salary—let’s get into the actual details of negotiations.

One important thing to understand is that the first person to name a number is at a distinct disadvantage. In any kind of negotiation, you always want to act second. Here’s why:

Suppose you applied for a job and you expected that the salary for that job was $70,000. You get offered the job and the first question you are asked is what your salary requirements are. You state that you are looking for something around $70,000. Perhaps you are even clever and say somewhere in the range of $70,000 to $80,000. The HR manager immediately offers you a salary of $75,000. You shake hands, accept the deal and are pretty happy—only there is one big problem: The HR manager had budgeted a range from $80,000 to $100,000 for the job. Since you named a number first, you ended up costing yourself potentially as much as $25,000 a year—whoops.

You might think this is an extreme example, but it isn’t. You have no way of knowing what someone else is expecting to offer until they tell you. Revealing your number first puts you at a distinct disadvantage. You can’t go up from the number you state, but you can certainly be talked down. So, when you name a number first, you have no upside, but a big downside potential.

Oh, but you are more clever than that you say. I’ll just name a really high number. This can blow up in your face as well. If you name too high of a number, you might not even get countered, or you may get countered very low in response. It is almost always to your advantage to have the employer name a number first.

The only exception to this is when an employer is purposely going to low-ball you. This situation is pretty rare, but if you have a good reason to suspect this will happen, you may want to name a number first, to set an anchor point. Why? Because if you get a low-ball number, it may be difficult to get an employer to come up a lot from that number. Of course, in that situation, you probably aren’t going to have much success no matter what you do.

But, what about when you are asked to name a number first?

Don’t do it. Just say “no.”

Yes, I know this is tough advice to follow, but let me give you some specific situations and some ways to deal with them.

First of all, you may get asked about your salary requirements before an interview or as a field on a job application. If you have a field on a job application, leave it blank if possible or simply put “negotiable depending on overall compensation package.” If you have to name a specific number, put $0 and then explain why later.

If you get asked directly in a pre-screening interview about what salary you require or are expecting try to answer the same thing. Say it depends on the overall compensation including benefits. You may get a response stating what the benefit would be or that they just need a general number. In this case, you should try to as tactfully as possible turn the question around and ask a series of questions like the following:

“I’d rather learn more about your company and understand more about the job I would be doing before naming an exact number or estimate, but it sounds like you are just trying to figure out if we are in the right range, so we don’t both waste our time—is that correct?”

Mostly likely you’ll get a yes. Then follow up with something like this.

“You must have a range that you have budgeted for this particular position, right?”

Again, you should get a yes. If you are brave, just pause here and don’t say anything else. You may then get them to answer with the range, but if you aren’t brave or they aren’t volunteering any information, you can follow up with:

“Well, if you tell me what the range is, even though I don’t know enough to state exactly what my salary requirements are, I can tell you whether or not the range matches up to what I am looking for.”

Now, obviously, this isn’t easy to do, but if an employer is going to ask you to name a number, there is no reason why they shouldn’t expect to name one as well—or even first. Try as hard as you can to get them to name one first.

If they absolutely refuse, you still have some options.

If you have to name a number, name a large range and make it conditional on the overall compensation package, but make sure the lower end of the range is slightly above the absolute lowest you are willing to go.

For example, you might say: “I can’t really name an exact figure because it is completely dependent on what the overall compensation package is, but I would generally be looking for something between $70,000 and $100,000—again, depending on the overall compensation package.”

What if you are asked about your current salary?

This is a tough one; technically it’s none of their business, but you can’t exactly say that. Instead, what you want to do is to turn the question around. There are a variety of different ways to do this, but here is one suggestion:

“I’d prefer not to say what my current salary is because if it is higher than what you expect to pay for this job, I wouldn’t want that to eliminate me from being considered for this job—since, I might be willing to accept less for the right position—and, if it is lower than what this job would pay, I wouldn’t want to sell myself short either—I’m sure you can understand.”

This is a pretty honest answer, which will mostly likely avoid the question without causing offense. You can also state that you’d just prefer not to answer that question or that you are under a confidential agreement with your employer to not talk about exact salary numbers.

If you absolutely have to name a number, try to make the number as variable as possible by talking about bonuses or benefits that affect the overall compensation or state it as the overall compensation package is valued at x dollars and add up what any benefits you are getting are worth.

When you have an offer

If you can avoid the salary question, you’ll eventually get an offer and it will have to have a number on it. You can’t really get an offer without a number, because it wouldn’t really be an offer. But, negotiations don’t end when you get an offer, that is unless of course you named a number and they gave it to you—whoops.

contract How to Negotiate Your Salary

(By the way, if you are in this situation, don’t try and pull any stunts. If they give you what you asked, you pretty much have to either take it or leave it. If you name a higher number than you first asked, not only will it be bad taste, but you’ll likely get the entire offer pulled.)

Once you have an offer in hand, you will almost always want to counter. What you counter with is up to you, but I’d highly recommend countering as high as your stomach will allow. You might think that by coming closer to their number, you’ll be more likely to get a favorable response, but in general that approach will backfire. Pick a high number and counter back.

Now, you might be worried that doing this will cause you to lose the offer completely. As long as you do it in a tactful way, it is pretty unlikely that the offer will be completely taken off of the table. Usually, the worst case scenario is they stay firm on their offer and tell you that you’ll have to take it or leave it. If the offer does get pulled, you can always respond by saying that you made a mistake and after weighing everything you realized that their original offer was more than fair. (Not fun, but if you really need the job, you can always go down that road.)

The fact of the matter is that once you are offered a job, you aren’t likely to just get that offer pulled. Remember, an employer that has invested that much time in interviewing you and making an offer isn’t going to want to just start over again, so you can afford to be a little brave.

In most cases when you counter, with your high counter, you’ll get back another response with a slightly higher offer. You can accept this offer, but in most cases, I’d recommend countering just one more time. Be careful here, because you can piss people off. But, one tactful way to do it is to say something like this:

“I’d really like to work for your company. The job sounds great and I am excited to work with your team, but I am still just a bit unsure on whether the numbers will work out. If you can do x dollars, I can be sure and commit to it today.”

If you do this right and don’t ask for something too much higher, you can usually get a yes. Most employers would rather pay you a little bit more rather than lose you. Worst case, usually, is that they will tell you they can’t go any higher.

I really don’t recommend negotiating beyond this point. If you are really brave you can try, but past a second counter-offer, you are really risking losing good-will and souring the deal. You want to appear shrewd, but not greedy. No one likes to feel like they just got worked or taken advantage of.

(For a good book on negotiation, check out: Getting Past No: Negotiating in Difficult Situations)

Some final advice

Know your numbers well. Research as much as possible what the salary ranges are at the company you are applying for and what the salary ranges are for comparable positions. There are some sites online you can use to get salary ranges, although they aren’t always reliable. The better the case you can make for what your salary should be, the easier your negotiations will be. You are in a much better position if you can name exact number ranges and statistics that show why the salary you are asking for is justified.

A reason for the salary you are requesting is never because you “need” that much money. No one cares what you need. Instead talk about why you are worth a certain amount or what benefit you can bring to the table. Talk about what you have done for past employers and why investing in you at the salary you are requesting is a good investment.

Get as many offers as possible at any one time, but be careful playing them against each-other. You are at a distinct advantage in any negotiation if you can afford to walk away from the deal. To be in this position, you may need to get multiple offers lined up, so you may want to apply for several jobs all at once. Just be a bit careful in playing different offers against each other. You can do it in a tactful way by talking about how you have a couple of offers you are currently considering and want to make the best decision, but be careful not to sound arrogant. Confidence is good, arrogance is bad.

Become a Simple Programmer

Like this post? Found it helpful? Leave a comment below or share it and don’t forget to sign up to become part of the Simple Programmer community. Over 5,000 other developers have already joined.

 

 

 

The 4 Levels of Freedom For Software Developers

For quite some time now I’ve been putting together, in my mind, what I think are the four distinct levels that software developers can go through in trying to gain their “freedom.”

For most of my software development career, when I worked for a company, as an employee, I had the dream of someday being free. I wanted to be able to work for myself. To me, that was the ultimate freedom.

freedom The 4 Levels of Freedom For Software Developers

But, being naive, as I was, I didn’t realize that there were actually different levels of “working for yourself.” I just assumed that if you were self-employed, you were self-employed. It turns out most software developers I have talked to about this topic have the same views I did—before I knew better.

I’ve written in the past about how to quit your job, but this post is a bit different. This post is not really about how to quit your job, but the different levels of self-employment you can attain, after you do so.

The four levels

The four levels I am about to describe are based on the level of freedom you experience in your work; they have nothing to do with skill level. But, generally we progress up these levels as we seek to, and hopefully succeed, in gaining more freedom.  So, most software developers start at level one, and the first time they become self-employed, it is usually at level three—although it is possible to skip straight to three.

Here is a quick definition of the levels (I’ll cover them each in detail next.)

  1. Employed – you work for someone else
  2. Freelancer – you are your boss, but you work for many someone elses
  3. Product creator – you are your own boss, but your customers determine what you work on
  4. Financially free – you work on what you want when you want; you don’t need to make money

I started my career at level one and bounced back and forth between level two and level one for quite awhile before I finally broke through to level three. I’m currently working on reaching level four—although, I’ve found that it is easy to stay at level three even though you could move to four.

Along the way, I’ve found that at each level I was at, I assumed I would feel completely free when I reached the level above. But, each time I turned out to be wrong. While each level afforded me more general freedom, each level also seemed to not be what I imagined it would be.

Level one: employed

boss The 4 Levels of Freedom For Software Developers

Like I said, most software developers start out at this level. To be honest, most software developers stay at this level—and don’t get me wrong, there is nothing wrong with staying there—so long as you are happy.

At this level, you don’t have much freedom at all, because you basically have to work on what you are told to work on, you have to work when you are told and you are typically tied to a physical location. (Throughout this post, you’ll see references to these three degrees of freedom.)

Working for someone else isn’t all that bad. You can have a really good job that pays really well, but in most cases you are trading some amount of security for a certain amount of bondage. You are getting a stable paycheck on a regular interval, but at the cost of a large portion of your freedom.

Now, that doesn’t mean that you can’t have various levels of traditional employment. I think there are mini-levels of freedom that exist even when you are employed by someone else. For example, you are likely to be afforded more freedom about when you start and leave work as you move up and become more senior at a job. You are also likely to be given a bit more autonomy over what you do—although Agile methodologies may have moved us back in that regard.

You might even find freedom from location if you are able to find a job that allows you to telecommute. In my quest for more freedom, I actually made a trade of a considerable amount of pay in order to accept a job where I would have the freedom of working from home. I erroneously imagined that working from home would be the ultimate freedom and that I would be content working for someone else the rest of my career, so long as I could do it from home. (Don’t get me wrong, working from home has its perks, but it also has its disadvantages as well. When I worked from home, I felt more obligated to get more work done to prove that I wasn’t just goofing off. I also felt that my work was never done.)

Now, like I said before, more people will stay at level one and perhaps move around, gaining more freedom through things like autonomy and a flexible working schedule, but there are definite caps on freedom at this level. No one is going to pay you to do what you want and tell you that you can disappear whenever you want to. You are also going to have your income capped. You can only make so much money working for someone else and that amount is mostly fixed ahead of time.

Level two: freelancer

clients The 4 Levels of Freedom For Software Developers

So, this is the only other level that I had really imagined existed for a software developer, for most of my career. I remember thinking about how wonderful it would be to work on my own projects with my own clients. I imagined that as a freelancer I could bid on government contracts and spend a couple of years doing a contract before moving on to the next. I also imagined an alternative where I worked for many different clients, working on different jobs at different times—all from the comfort of my PJs.

When most software developers talk about quitting their jobs and becoming self-employed, I think this is what they imagine. They think, I like I did, that this is the ultimate level of freedom.

It didn’t take me very long as a freelancer to realize that there really wasn’t much more freedom, working as a freelancer, than there was working for someone else. First of all, if you have just one big client, like most starting freelancers do, you are basically in a similar situation as what you are when you are employed—the big difference is that now you can’t bill for those hours you were goofing off. You will likely have more freedom about your working hours and days, but you’ll be confined to the project your client has hired you to work on and you might even have to come into their office to do the work.

This doesn’t mean that you don’t have more freedom though, it is just a different kind. If you have multiple clients, you have more control over your life and what you work on. You can set your own rate, you can set your own hours and you can potentially turn down work that you don’t want to do—although, in reality, you probably won’t be turning down anything—especially if you are just starting out.

Don’t get me wrong, it is nice to have your own company and to be able to bill your clients, instead of being compelled to work for one boss who has ultimate control over your life, but freelancing is a lot of work and on a daily basis it may be difficult to actually feel more free than you would working for someone else.

Given the choice of just doing freelancing work or working for someone else, I’d rather just take the steady paycheck. I wouldn’t have said this five years ago, but I know now that freelancing is difficult and stressful. I really wouldn’t go down this road unless you know this is what you want to do or you are using it as a stepping stone to get to somewhere else.

From a pay perspective, a freelancer can make a lot more money than most employees. I currently do freelance work and I don’t accept any work for less than $300 an hour. Now, I didn’t start at that rate—when I first started out $100 an hour was an incredible rate—but, I eventually worked my way up to it. (If you want to find out how, check out my How to Market Yourself as a Software Developer package.) The big thing though, is that your pay is not capped. The more you charge and the more hours you work, the more you make. You are only limited by the limits of those two things combined.

Level three: product creator

product The 4 Levels of Freedom For Software Developers

This level is where things get interesting. When I was mostly doing freelancing, I realized that my key mistake was not in working for someone else, but in trading dollars for hours. I realized that as a freelancer my life was not as beautiful as I had imagined it. I was not really free, because if I wasn’t working I wasn’t getting paid.

I actually ended up going back to fulltime employment in order to rethink my strategy. The more and more I thought about it, the more I realized that in order to really gain the kind of freedom I wanted, I would need to create some kind of product that I could sell or some kind of service that would generate me income all the time without me having to work all the time.

There are many ways to reach this level, but perhaps the most common is to build some kind of software or software as a service (SASS) that generates income for you. You can then make money from selling that product and you get to work on that product when and how you see fit.

You can also reach this level by selling digital products of some sort. I was able to reach this level through a combination of this blog, mobile apps I built, creating royalty generating courses for Pluralsight and my own How to Market Yourself as a Software Developer package. (Yes, I have plugged it twice now, but hey this is my blog—and this is how I make money.)

You have quite a bit of freedom at this level. You no longer have any real boss. There is no pointy-haired boss telling you what to work on and you don’t have clients telling you what projects to work on either. You most likely can work from anywhere you want and whenever you want. You can even disappear for months at a time—so long as you figure out a way to handle support.

Now, that doesn’t mean that everything is peaches and roses at this level either. For one thing, I imagined that if I was creating products, that I would get to work on exactly what I wanted to work on. This is far from the truth. I have a large degree of control over what I choose to work on and create, but because I am bound by the need to make money, I have to give a large portion of that control over to the market. I have to build what my customers will pay for.

This might not seem like a big deal, but it is. I’ve always had the dream of writing code and working on my own projects. I dreamed that being a product creator and making money from my own products would give me that freedom. To some degree it does, but I also have to pay careful attention to what my audience and customers want and I have to put my primary focus on building those things.

This level is also quite stressful, because everything depends on you. You have to be successful to get paid. When you are an employee, all you have to do is show up. When you are a freelancer, you just have to get clients and do the work—you get paid for the work you put in, not the results. When you are a product creator, you might spend three months working on something and not make a dime. No one cares how much work you did, only results count.

As far as income potential, there is no cap here. You might struggle to just make enough to live, but if you are successful, there is no limit to how much you could earn, since you are not bound by time. At this level you are no longer trading hours for dollars.

To me, it isn’t worth striving for level two, it is better to just work for someone else until you can reach level three, because this level of freedom is one that actually makes a big difference in your life. You still may not be able to work on just what you want to work on, but at least at this point—once you are successful—all the other areas of your life start to become much more free.

Level four: financially free

financial freedom The 4 Levels of Freedom For Software Developers

I couldn’t come up with a good name for this level, but this is the level where you no longer have to worry about making money. One thing I noticed when I finally reached level three was that a large portion of what was holding me back from potentially doing exactly what I wanted to do was the need to generate income.

Now, it’s true that you can work on what you want to work on and make money doing it, but often the need to generate income tends to influence what you work on and how you work on it. For example, I’d really like to create a video game. I’ve always dreamed of doing a large game development project. But, I know it isn’t likely to be profitable. As long as I am worrying about income, my freedom is going to be limited to some degree. If I don’t have passive income coming in that is more than enough to sustain me, I can’t just quit doing the projects that do make me money and start writing code for a video game—well, I could, but it wouldn’t be smart, and I’d feel pretty guilty about it.

So, in my opinion, the highest form of freedom a software developer can achieve is when they are financially free. What do I mean by financially free though? It basically means that you don’t have to worry about cash. Perhaps you sold your startup for several millions of dollars or you have passive income coming in from real estate or other investments that more than provides for your daily living needs. (For some good information on how to do this or how this might work, I recommend starting with the book “Rich Dad Poor Dad”.)

At this level of freedom, you can basically do what you want. You can create software that interests you, because it interests you—you aren’t worried about profitability. Want to create an Android app, just because, go ahead. Want to learn a new programming language, because you think it would be fun—go for it.

This has always been the level of freedom I have secretly wanted. I never wanted to sit back and not do anything, but I’ve always wanted to work on what interested me and only what interested me. Every other level that I thought would have this freedom, I realized didn’t. I realized that there was always something else that was controlling what I worked on, be it my boss, my clients or my customers.

Now, this doesn’t mean that you can’t still make money from your projects. In fact, paradoxically, I believe, if you can get to this stage, you have the potential to make the most money. Once you start working on what you want to work on, you are more likely to put much more passionate work into it and it is very likely that it will be of high value. This is where programming becomes more like art. I don’t have any proof of this, of course, but I suspect that when you don’t care about making money, because you are just doing what you love, that is when you make the most of it.

Don’t get me wrong, you might be able to focus on doing what you love, even if you aren’t making any money. I know plenty of starving artists do—or at least they tell themselves they do—but, I can’t do it. I’ve tried it, but I always feel guilty and stressed about the fact that what I am working on isn’t profitable. In my opinion, you really have to be financially free to experience true creative freedom.

I’m actually working on getting to this level. Technically, I could say I am there now, but I am still influenced greatly by profitability. Although, now, I am not choosing my projects solely on the criteria of what will make the most amount of money. I am turning down more and more projects and opportunities that don’t align with what I want to do as I am trying to transition to working on only what interests me as my passive income is increasing.

What can you gather from all this?

Well, the biggest thing is that freedom has different levels and that, perhaps, you don’t want to be a freelancer, after all. I think many software developers assume working for themselves by freelancing will give them the ultimate freedom. They don’t realize that they’ll only be able to work on exactly what they want to work on when they are actually financially free.

So, my advice to you is that if you want to have full creative control over your life and what you work on, work on becoming financially free. If you want a high degree of autonomy in most of the areas of your life, you should try to develop and sell products. If you are happy just being your own boss, even if you have to essentially take orders from clients, freelancing might be the road for you. And, if all of this just seems like too high of a price to pay, you might want to just stay where you are at and keep collecting your weekly paychecks—nothing wrong with that.

If you like this post and you’d like to read more posts about topics like these, sign up here to join over 5,000 other Simple Programmers and become part of the Simple Programmer community.

You Never Really Learn Something Until You Teach It

As software developers we spend a large amount of time learning. There is always a new framework or technology to learn. It can seem impossible to keep up with everything when there is something new every day. So, it should be no surprise to you that learning quickly and gaining a deeper understanding of what you learn is very important.

And that is exactly why–if you are not doing so already–you need to incorporate teaching into your learning.

Why teaching is such an effective learning tool

When we learn something, most of us learn it in bits and pieces. Typically, if you read a book, you’ll find the material in that book organized in a sensible way. The same goes for others mediums like video or online courses. But, unfortunately, the material doesn’t go into your head in the same way.

teaching You Never Really Learn Something Until You Teach It

What happens instead is that you absorb information in jumbled bits and pieces. You learn something, but don’t completely “get it” until you learn something else later on. The earlier topic becomes more clear, but the way that data is structured in your mind is not very well organized–regardless of how organized the source of that information was.

Even now, as I write this blog post, I am struggling with taking the jumbled mess of information I have in my head about how teaching helps you learn and figuring out how to present it in an organized way. I know what I want to say, but I don’t yet know how to say it. Only the process of putting my thoughts on paper will force me to reorganize them; to sort them out and make sense of them.

When you try to teach something to someone else, you have to go through this process in your own mind. You have to take that mess of data, sort it out, repackage it and organize it in a way that someone else can understand. This process forces you to reorganize the way that data is stored in your own head.

Also, as part of this process, you’ll inevitably find gaps in your own understanding of whatever subject you are trying to teach. When we learn something we have a tendency to gloss over many things we think we understand. You might be able to solve a math problem in a mechanical way, and the steps you use to solve the math problem might be sufficient for what you are trying to do, but just knowing how to solve a problem doesn’t mean you understand how to solve a problem. Knowledge is temporary. It is easily lost. Understanding is much more permanent. It is rare that we forget something we understand thoroughly.

When we are trying to explain something to someone else, we are forced to ask ourselves the most important question in leaning… in gaining true understanding… “why.” When we have to answer the question “why,” superficial understanding won’t do. We have to know something deeply in order to not just say how, but why.

That means we have to explore a subject deeply ourselves. Sometimes this involves just sitting and thinking about it clearly before you try to explain it to someone else. Sometimes just the act of writing, speaking or drawing something causes you to make connections you didn’t make before, instantly deepening your knowledge. (Ever had one of those moments when you explained something to someone else and you suddenly realized that before you tried to explain it you didn’t really understand it yourself, but now you magically do?) And, sometimes, you have to go back to the drawing board and do more research to fill in those gaps in your own knowledge you just uncovered when you tried to explain it to someone else.

Becoming a teacher

So, you perhaps you agree with me so far, but you’ve got one problem–you’re not a teacher. Well, I have good news for you. We are all teachers. Teaching doesn’t have to be some formal thing where you have books and a classroom. Teaching is simply repackaging information in a way that someone else can understand. The most effective teaching takes place when you can explain something to someone in terms of something else they already understand.

 

(Want a great book on the subject that might make your brain hurt? Surfaces and Essences: Analogy as the Fuel and Fire of Thinking. An excellent book by Douglas Hofstadter, author of Godel, Escher, Bach: An Eternal Golden Braid. Both books are extremely difficult reads, but very rewarding.)

becoming a teacher You Never Really Learn Something Until You Teach It

As human beings, we do this all the time. Whenever we communicate with someone else and tell them about something we learned or explain how to do something, we are teaching. Of course, the more you do it, the better you get at it, and adding a little more formalization to your practice doesn’t hurt, but at heart, you–yes, you–are a teacher.

One of the best ways to start teaching–that may even benefit your career–is to start a blog. Many developers I talk to assume that they have to already be experts at something in order to blog about it. The truth is, you only have to be one step ahead of someone for them to learn from you. So, don’t be afraid to blog about what you are learning as you are learning it. There will always be someone out there who could benefit from your knowledge–even if you consider yourself a beginner.

And don’t worry about blogging for someone else–at least not at first. Just blog for yourself. The act of taking your thoughts and putting them into words will gain you the benefits of increasing your own understanding and reorganizing thoughts in your mind.

I won’t pretend the process isn’t painful. When you first start writing, it doesn’t usually come easily. But, don’t worry too much about quality. Worry about communicating your ideas. With time, you’ll eventually get better and you’ll find the process of converting the ideas in your head to words becomes easier and easier.

Of course, creating a blog isn’t the only way to start teaching. You can simply have a conversation with a friend, a coworker, or even your spouse about what you are learning. Just make sure you express what you are learning externally in one form or another if you really want to gain a deep understanding of the subject.

You can also record videos or screencasts, speak on a subject or even give a presentation at work. Whatever you do, make sure that teaching is part of your learning process.

For more posts like this and some content I only deliver via email, sign up here.