I already know your biggest problem.
Because, I have that same problem and so do millions of other people across the globe.
To quote the internets, “Ain’t nobody got time for that.”
I don’t know a more true statement in all of history.
It seems that no matter how much time we have, it’s never enough.
It seems the perfect excuse for any situation is simply that we don’t have time.
But, it’s not true. We actually have enough time. In fact, in most cases, we have plenty of time. We just have trouble realizing it.
Why we think we don’t have enough time
There are two main reasons why we think we don’t have enough time.
First, we waste a large amount of time. And, second, we don’t use the time we have wisely.
To sum it up, we procrastinate and watch too much TV.
This may seem like a joke, but I’m dead serious.
If you think you don’t have enough time, it’s probably because you are wasting a big chunk of your day each day doing something completely unproductive, like watching TV, or it’s because when you do sit down to work, you spend more time procrastinating instead of actually getting what you need to do done.
I’ve ranted before on the dangers of watching TV. I don’t watch any TV myself and very rarely even watch a movie. But, it’s not just TV that is the problem. I pick on TV, because it is easy to pick on. Most people would get back two-to-four hours a day if they just quit watching TV—more than enough time to do whatever it is you claim to not have enough time for.
The real problem is anything that is taking your time, but not giving you anything in return. I’m not saying that you should spend all your time working, but what I am saying is that whatever activity you are doing with your time, you should be getting some tangible benefit from it.
But TV relaxes me, you say. Really? Does it? I mean yes, it feels good to plop down in front of the TV and laugh at some silly sitcom character’s latest plight, but does it really relax you so much that you get more time out of it than what you put into it?
What I mean by this is that if you stopped watching TV, and instead did something else with your time, do you honestly think you’d be less productive at everything else you did, because you were not as “relaxed?”
I keep picking on TV, but maybe your waste of time is playing World of Warcraft online, playing on social networks, reading the news, or even spending an inordinate amount of time going through some ritual to get ready for work in the morning.
Figuring out where your time is going
Your first step on your quest to reclaiming your time is to track it.
Look, I’m going to be honest with you here. This part isn’t going to be fun and you are not going to want to do it correctly, but if you really want to know where your time is going, you are going to have to start tracking it—at least temporarily.
Here is what I want you to do:
First, make a sketch of where you think your time is going. Pull out a piece of paper, or print out a sheet from a daily time planner and chart exactly where you think you spend your time during the day.
Make this chart pretty detailed. If you think you get up at 7:00 AM, put that down. Put down how long it takes you to get ready for work and what time you are out the door. Put how long it takes you to “settle in.” Put how long you work. How long you take for lunch. Put it all down and chart it on a 24 hour timeline.
Now, just looking at this “sketch,” you’ll probably already have a good idea of where you are wasting your time. But, here is the clincher: It’s not even accurate.
So, here is what you do next:
After you have your chart of how you think you spend your day, get another blank schedule and carry it around with you for at least three days. Plot exactly how you spend your day.
Yes, this is tedious. Yes, you won’t want to do it, but do it anyway. Track exactly how long it takes you to eat lunch—just don’t show your boss. Track exactly how long it takes you to “settle in.” (Again, you might not want to show your boss that one either.) And, don’t forget that TV time.
Ok, so once you’ve done this you’ll have two things:
- How you think you spend your time
- How you actually spend your time
Now, the only thing you are missing is…
How you actually want to spend your time
The next, step—and you may have guessed it already—is to chart how you’d actually like to spend your time each day. What is your ideal schedule?
Using the information about how you are actually spending your day and how you thought you were spending your day, you should be able to come up with an ideal division of your time for a typical day.
You might end up having a few different schedules for different days of the week, but this is the first step to actually taking back control of your time—and your life.
Think about it this way: You probably know where you are spending your money. Well, let me take that back. If you are financially responsible, you know where you are spending your money. If you aren’t financially responsible, you at least have to make a conscious effort to spend money—it doesn’t happen automatically. You usually have to pull out a card or some cash.
Spending time though, seems to have no cost associated with it. If you feel like you don’t have enough time, it’s not because you are actually living in time-proverty, it’s because you are not actually aware of how you are spending it. You need a time budget.
Now, let me say this right off the bat: You are not going to perfectly live your pre-planned schedule. That is ok. You don’t have to, you just have to be close.
You aren’t going to be able to change everything overnight. The reason you spend your time like you do is because of the ingrained habit that you’ve formed over years or even decades. It takes time to develop new habits to replace old ones.
So, you are going to have to go through a bit of a transition period, while you recalibrate your schedule from the default way you are currently spending—wasting—your time, to the new budgeted schedule of how you want to spend your time.
You’ll probably find that you actually have time to do the things you claimed you didn’t have time to do—now that you’ve actually planned them into your schedule.
If you still find that you don’t have enough time to do what you want to do, you’ll really have to question whether or not you really want to do it, or if you are even trying to do too much.
It’s all about priorities
The whole point of this exercise—of this blog post—is to make you realize that time management is all about priorities.
What I mean to say by this is not that your priorities determine how you spend your time, but rather that how you spend your time shows you what your priorities currently are.
You have to understand your current priorities in order to create new ones or to lower the value of current ones.
By tracking how you are actually spending your time, you are learning about your current priorities.
By projecting how you think you are spending your time, you are indicating what you think your current priorities are.
By actually scheduling your time, you are setting your priorities.
So, if you do all this and still don’t have enough time to learn how to cook, get your degree, get a better job, start that side project, or even start a blog, it’s not really because you don’t have enough time, it’s because you choose to spend your time somewhere else.
(Also, if you are interested in more about this topic, I recommend the book: Eat That Frog!: 21 Great Ways to Stop Procrastinating and Get More Done in Less Time)
But, didn’t you say something about not using time wisely?
So, we’ve only really solved half of the problem here.
Remember how I said there were two main problems? That not only were you wasting a large amount of time, but you also weren’t using that time wisely?
We’ve already covered wasting time. If you are allocating the time in your day how you would like to allocate it, time is no longer being wasted. You are using your time exactly how you want to be using it.
To be clear, this could include watching TV or playing video games. As long as you have made a conscious decision of how you want to be spending your time and that is how you are doing it, you aren’t wasting that time at all. (You might not be meeting your objectives in life, or accomplishing what you want to accomplish, but at least you are making the conscious choice to do so—not blaming it on the lame excuse of not having enough time.)
Now, about using time wisely.
This really boils down to productivity and procrastination.
If you’ve already budgeted your time, the only other thing you can do to get back more time is to reduce the time budgeted things take.
If you lollygag your way through getting ready for work in the morning and something that should take you one hour takes you two hours, you are not using your time wisely. I won’t say wasted, because you planned out that time, so it’s not truly wasted, but you could have accomplished the same goal in a lot less time.
The same goes with “settling in for work,” or even getting a task done at work. The more you procrastinate and choose to use your time in an unwise manor, the longer you have to allocate for the various things you are doing.
But I can’t cut down my nine-to-five, so why bother
Now, you may say, well John, that is nice and all, but I have to be at my desk from 9:00 AM until 5:00 PM, what difference does it make if I use that time “unwisely” or not?
It might not make that much of a difference to your paycheck, but it might make a whole lot of difference to your bottom line and your career.
If you can accomplish more work and learn more things during your nine-to-five, over time this is going to add up to a huge benefit.
Besides, not everything falls into that nine-to-five category, and even though most employers would probably frown on it, wouldn’t it be better to spend time working on some side-project or personal development project than browsing Facebook?
Let’s be honest here. We all waste time at work. At the very least we could waste that time in a productive manner.
Getting serious about lost time
I get most of my blog posts done in under two hours. It literally takes me less than two actual hours from when I sit down to write the blog post until it is scheduled and ready to go.
That might seem like a lot of time, but considering that many of my blog posts are around 2,000-3,000 words and contain a bunch of images and links, that is a pretty short amount of time.
The secret to how I get my blog posts done so quickly each week is that when I sit down to write a blog post, I sit down and actually write it. I don’t sit and ponder the subject for an hour, forget what I was doing and check Facebook or my email. I don’t write a little and then go grab a snack. I sit down and I write until I am done.
I make an efficient use of my time.
You should apply this kind of work-ethic to everything you are doing if you really want to maximize your time.
It’s not for the faint of heart though. When I first started using the Pomodoro technique and actually focusing on making the most of my time and not procrastinating, it took a lot out of me. I did not expect how exhausting it would be.
For a detailed account of how I plan my week, check out my YouTube video.
And to learn more about how I use the Pomodoro technique, you might want to check out my book “Soft Skills: The Developer’s life manual.”
The point is: there is a lot of hidden lost time in the tasks that you are doing that you aren’t doing very efficiently. If it took me four hours to write a blog post instead of two, I’d get a lot less done each day. I’ve have to choose some things I couldn’t get done.
Summing it all up
Ok, so to sum it all up, if you think you don’t have enough time and you want to get back more of your time, here is what you need to do:
First, go through the process of charting how you think you spend your time, how you actually spend your time and how you want to spend your time.
Once you do this, you’ll shift your priorities and hopefully get rid of some big time wasters that are taking up time you’d rather be using somewhere else.
This should be the single biggest way you find more time. It may involve dropping some things that turn out not to be that important, but at least you’ll be making a conscious choice.
If you still don’t have enough time, the only other place to squeeze time from is tasks you are already doing.
If you can do things more efficiently and use your time more wisely, you’ll get a lot more done and have a lot more time on your hands.
Try to find one or two things you do in your day that take up a large amount of time and see if you can cut them in half or at least reduce them by a third.
All the bonus time you get from implementing these techniques you can allocate to other things you want to be doing, but just haven’t had enough time for.
It’s time to stop using that old excuse of not having enough time and to actually do something and make it so you do.
If you liked this post and would like to hear more of what I have to say, join the Simple Progammer community and get blog posts like these, inspirational videos, tutorials and more directly in your inbox—all for free. I won’t spam you, but I will try and motivate you.
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.
Yes, 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.
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
- 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.
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.
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.
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.
Estimation is difficult.
Most people aren’t good at it–even in mundane situations.
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.
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.
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.
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.)
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.
I don’t do many product reviews on this blog–and there is a good reason for it.
I get plenty of requests for companies asking me to “pimp” their stuff on this blog, but most of the stuff I am asked to write about I just don’t use or would never really find myself using.
However, I was pretty excited when Telerik contacted me and asked if I would be interested in letting them sponsor a post about their Devcraft developer tools, because I actually really like these tools–I’ve always been a big fan of Telerik–and the whole Devcraft package is something that I truly feel increases developer productivity.
So, yes, this is a sponsored post. Those of you who follow this blog know that this blog is one of my main income streams. But, as I am sure you can tell if you read this blog regularly, I hardly ever allow sponsored posts or guest posts, because the money is not worth trying to make up some crap about how some product I’ll never use is so great.
That that said, here is my honest opinion of Telerik’s Devcraft offering.
What is it?
I guess, before I can really get into what I think of Devcraft, I have to address what it is.
You can check it out for yourself here: Telerik Devcraft.
But, essentially it is a collection of almost all of Telerik’s .NET focus tools–all together. So, if you aren’t a .NET developer, you might not find all that much value–although, I have to say that the Kendo UI part (which is a jQuery-based framework with a bunch of responsive widgets and and other nice HTML components, including an MVVM framework) is great for any kind of web development.
Here is roughly how it is broken up:
There are a bunch of different UI controls for ASP.NET AJAX, ASP.NET MVC, Silverlight and even SharePoint. Plus, the Kendo UI framework that I already talked about. It is really a crazy amount of controls, and they look really good.
Again, tons of controls, and all of them look really great. I designed some custom controls for Windows Forms myself back in the day and these controls put everything I ever did to shame. They have controls for both WPF and the old Windows Forms.
As you might have guessed, the mobile side has Windows Phone 8, Windows 8 XAML and Windows 8 HTML controls. I would have liked some Android and iOS controls, but I guess you can’t have everything. I haven’t done a lot of Windows Phone or Windows 8 development myself, but I played around with some of the controls and I was really impressed. Again, polished top-notch controls that were really easy to get working.
Also, on the mobile side I found I could combine Kendo UI with PhoneGap to create some pretty nice mobile applications. (Although, I knew Telerik has their AppBuilder platform, which basically does this for you–it used to be called Icenium)
Telerik doesn’t just have UI controls, they have everything else as well. They have an NUnit-like testing framework–which is actually free.
But, they also have JustCode, which is a Visual Studio plugin that makes you more productive and adds all kinds of automatic refactorings to Visual Studio. (Think Resharper, but faster.)
And, I really like the JustMock tools that is part of Devcraft. I found this mocking engine very easy to use and I liked how it had the power to mock non-virtual methods, non-public members, sealed classes and even static methods. (Although, I’d suggest using that power with care.)
There were even tools on the debugging side. JustTrace turned out to be a very robust .NET memory and performance profiling tools–with a very nice and easy to use UI. I finally felt like I could actually us a profiling tool and understand what it was doing.
I’m also pretty well acquainted with JustDecompile. I’ve been using that .NET decompiler ever since that whole Redgate fiasco over .NET reflector. Telerik has done a pretty good job of making this decompiler easy to use.
I’ll also include the reporting and data access tool in this grouping–although I suppose you could argue that they aren’t really developer tools. Devcraft also has a reporting solution that is pretty lightweight and seems to be nice for generating reports and they also have a data access component that is basically a visual object-relational mapper. (The data access component is free.)
I’m not too much into reporting or data access these days, so I didn’t really use these parts very much–but they looked pretty nice to me.
So, what do I think?
Well, I have to say, many of the tools in Devcraft I was already using. I have been familiar with Telerik’s products for quite a while, but I never really had a chance to dig into many of their controls until now.
I was always very impressed with how the controls looked, but I now I am equally impressed with how easy they are to use and especially with the documentation available.
It was obvious that controls for desktop apps and ASP.NET AJAX would be fairly easy to use, but I am most impressed with how easy Telerik made it to use their ASP.NET MVC controls and the Kendo-UI bits.
Without knowing anything about how the ASP.NET MVC controls worked–and without reading any documentation ahead of time–I decided to just pick a few controls and see if I could get them working.
I found that for each control there was a live demo on Telerik’s site. I could simply go to the control, see how it worked, and see the source code below. This made using any control I wanted extremely easy. I didn’t have to memorize how to use each control, since I could just learn how to use a control when I needed to use it.
The big problem I have now is that I don’t see how I can go on using regular controls or trying to create my own UIs for ASP.NET MVC apps anymore. I know that sounds a little lame, but I am actually a bit worried. I have to figure how to convince clients I do work for that they need to invest in these controls, because I can’t see recreating some of this stuff, like I did before, now that I know it exists and how easy it is to use.
It’s also crazy how well all this stuff fits in together. The ASP.NET MVC controls are actually wrappers around the Kendo UI stuff, so you can actually utilize the same Kendo UI controls in your ASP.NET MVC applications very easily.
There also seems to be controls for just about everything you can imagine. I spent hours just looking through the controls and trying them out. I was getting great ideas for applications I could build, just from looking at the controls. I’m really excited now to use some of these controls on my next project.
All together though, the biggest thing for me about Devcraft was the productivity enhancements. I am all about developer productivity, so that is one of the main reasons why I like Devcraft.
I know what it is like to spend days trying to make a custom grid control or customize a grid control to do what I want. I know how much time can be wasted looking for that perfect jQuery plugin to use for your app. I think there is a huge value in having all of that in one big package.
It’s also pretty nice to not have to hunt for different solutions for testing, mocking, refactoring, tracing and more. Having everything together without me having to think about it, and knowing the quality is high, makes things much more simple and allows me to focus on what is really important.
So, overall I would have to say I am very impressed with Devcraft. I’ve been using bits and pieces of Telerik’s software here and there over the years, but until I did this review, I didn’t realize how well it all integrated together and just how much stuff there was available.
Now, the price is a bit high. At the time of this writing, there are three editions:
- The UI Edition at $1,299
- The Complete edition at $1,499
- The Ultimate edition at $1,999
But, with the value in these collections, I still think it is a pretty good bargain. I’ve purchases–or been responsible for the purchase–of many of the individual components in the past, and it seems like a no-brainer to me to get everything all together than trying to buy them piecemeal.
Also, Telerik has kindly offered to give away a license for Kendo UI Professional. To enter the contest, just leave a comment below. I’ll randomly select a winner in a week.
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.
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.)
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.
Yes, that’s right. I am writing a blog post today about Scrum and Scrum Masters.
No, I haven’t lost my mind.
I just realized that out of everything I’ve written about Agile and Scrum, I never talked about what makes a good Scrum Master.
I’ve both been a Scrum Master and I’ve worked on a team with Scrum Masters and from both of those experiences I can tell you that there is much confusion about this particular role on a Scrum or Agile team.
Even the name Scrum Master has confusion around it, is it ScrumMaster or Scrum Master—you can tell, I prefer the latter.
So, let’s talk about why Scrum Masters exist in a Scrum team and what they actually should be doing.
Scrum Masters! What are they good for?
On some teams, unfortunately, it is absolutely nothing.
But, it doesn’t have to be that way. A Scrum Master actually serves a really important role on a properly functioning Scrum Team. (They bring the donuts or bagels in every morning, so the team can get actual work done.)
Ok, I am just kidding about that last part, but in reality it isn’t all that far from the truth. Let me explain.
A Scrum Master really is supposed to be the person who clears the path for the team so they can run as close to full speed as possible. The Scrum Master is sort of like the pit crew for a race car driver.
Without a Scrum Master, a Scrum team is slowed down by impediments which inevitably come up in any development project. It takes time and distracts the team to deal with these impediments, so the whole cadence of the team slows down unless someone external to the development process is moving the boulders out of the way.
So, really, the most important job of the Scrum Master is to remove impediments which may hamper a Scrum team from progressing on backlogs and getting their work done.
This isn’t the same thing as managing a project, because the Scrum Master isn’t deciding how and when things should be done. Instead, the Scrum Master is part of the team and the team as a whole is taking accountability for managing the project.
The Scrum Master also has the role of being the master of the Scrum process—hence the name. This is a tough spot to be in, but is a very important role that many teams neglect. The rules of Scrum are important to a successful Scrum team. One of the reasons why I started to write off Scrum as a process was simply because it was so difficult to get anyone to actually enforce the rules.
This is the job of the Scrum Master; he carries the big Scrum stick and he beats people over the head with it when they step out of line. He doesn’t do this because he is a big power-hungry bully. No, instead, he does this because he knows that the only way the team is going to produce their best work and not waste time arguing over process is if they all follow the process that was agreed upon from the start.
Scrum is intended to be more than just a way to develop software or organize teams, it is also a process that clearly defines what will happen, when it will happen and who will do what.
The Scrum Master is one of the most important roles on the team
It may seem, based on my previous description, that the role of a Scrum Master isn’t all that important to the overall performance of the team, but that is far from the truth.
In reality, the velocity of a team is more influenced by the Scrum Master than any other member of the team—with the exception of that lazy developer that breaks the build all the time and constantly falls asleep at meetings.
Even though the Scrum Master does not have direct control over the management of the team, the Scrum Master’s ability to both remove impediments and enforce the Scrum framework directly affects the team’s ability to get s!@# done.
A poor Scrum Master will let the team flounder and let outside influence distract the team from their work.
A poor Scrum Master will either be too timid or not care enough to force the team to obey the rules of Scrum, causing the whole platoon to go scampering off whatever direction they choose, rifles firing randomly in all directions.
I like to think of the Scrum Master as a guide who takes the team over rough terrain and shows them how to get water from tree leaves on their journey. Sure, the team could manage to bushwhack their way through the jungle without a guide, but it would take them a whole hell of a lot longer to do so—and they’d be much more likely to get eaten by a lion.
So, what should Scrum Masters actually do?
The answer is whatever needs to be done.
You know those gangster movies where some mob boss has a guy they call “the cleaner?” The guy that comes into a sticky situation and can hide a dead body, bribe the right cops, or just make someone disappear? If mobsters were following Scrum, that guy would be the Scrum Master.
The Scrum Master should be part of the team, but not part of the team. The Scrum Master should attend the standup meetings actively trying to spot impediments—especially the ones that aren’t mentioned by the team members, but exist beneath the surface of a problem.
The Scrum Master should ensure that all the Scrum meetings and processes flow smoothly. He should make sure that standups are being used for their correct purpose. He should encourage the team to hold each other accountable and he, himself, should hold the team accountable to what they promised to deliver.
The Scrum Master should be the guy (or gal), who makes things happen. He should know the right people to talk to and know how to get things done. The team should focus on the work, the Scrum Master should focus on the politics. If the team is dealing with politics the Scrum Master has failed.
Most of all, the Scrum Master should be willing to lay it all on the line—to take the hits for the team. Even though the Scrum Master doesn’t control the team and get to boss them around, they are his team and his alone. A good Scrum Master isn’t afraid to take full responsibility for the actions and performance of the team and step in the way of that bullet and take one in the chest if he has to.
Like this post? Sign up for my weekly email and I’ll make sure posts, like this one, are delivered right to your inbox once a week. Also, you’ll get lots of content that I only share with my email subscribers.
I spend a lot of time doing two things: blogging and telling other developers the benefits of doing things like starting their own blog. (Occasionally I squeeze in a little bit of time to code as well. And my wife says I spend too much time answering emails and checking my phone—she wanted me to add that to this post.)
So, I can tell you that one of the major pains I am well acquainted with is that of writing when you don’t feel like writing or you just don’t have anything to say.
I experience this frustration myself—heck I am experiencing it right now. I decided to write this blog post because I couldn’t come up with anything else to write about. And, to top it off, I don’t feel like writing either.
But, let me jump ahead and give you a little secret: by the time I’m halfway through this post, not only will I know what to write about, but I will feel like writing.
I know this from experience, and it is part of what keeps me going on days like these.
Writing is difficult
Writing isn’t an easy thing to do.
It is hard to spill your brains onto a blank piece of paper and not make it look like spaghetti.
It’s difficult to constantly come up with new ideas, week after week.
But, by far, the hardest part of writing is just sitting down in front of the keyboard and typing. Even now, as I am typing these very words, a million other things are vying for my attention, calling me away from the task at hand.
Most software developers who start a blog, end up abandoning that blog, because they never learned how to grit their teeth, glue their ass to a seat and write.
Sure, it starts out fun. When you first throw up your blog on the internet, you are full of ideas. You could write a blog post each and every day—not because you are more creative when you first start, but because you are more motivated. The whole process is still very new and enjoyable.
But, fast forward a couple of months—or a couple of weeks for those of us with ADHD—and that shiny-newness of blogging wears off. That little fairy that was sitting on you shoulder telling you what to write is gone—it’s just you and the keyboard.
This is exactly when you have to search deep down inside of yourself and find the grit beneath your soft cushy exterior. You have to decide—that’s right, make a decision—that every week you are going to write a blog post and nothing is going to stop you from doing it.
You’ll want to start over and give up
Even as I write this very sentence, I want to go back to the beginning of my post and delete everything. It’s no good. My thoughts are scattered; my analogies are crap; no one cares about what I have to say on this subject.
I’ve been writing blog posts just about every single week for over 4 years, and I am still smacked in the face with the stick of doubt just about every time I sit down to write. So, I can tell you from experience, that part doesn’t get any easier.
But, you can’t let that stop you. Your face might be swollen, some of your teeth might be missing, you might have to squint to see out of one of your eyes, but as soon as you care that what you are writing is no good, you’ll stop writing—permanently. You’ll fall right off the wagon.
By the time you’ve gotten this far into my own essay, it doesn’t matter if it is good. I’ve got your attention already. I can’t embarrass myself any further, because if you didn’t at least sort-of like what I have said so far, you wouldn’t be reading this sentence to begin with.
I’ve come to the realization that you can’t always hit homeruns. Sometimes, you write crap. Sometimes, what you think is your best blog post turns out to be so terrible that no one makes it past the first paragraph.
But, sometimes what you think is terrible, turns out to be the most popular thing you’ve ever written.
The point is, you can’t know until you hit that publish button and even if you could, it doesn’t matter, because you can’t write for other people, you’ve got to write for you.
Not because you are writing something that you’ll someday read later and say “oh, yes, that is how I solved that problem in the past”—although, that does happen from time to time. Instead, you have to write because you made a commitment to yourself and the commitment wasn’t to string marvelous words into sentence on paper, but instead just to write—it doesn’t have to be any good.
The secret is to keep going
I’m sure you’ve noticed by now that I haven’t really told you what to do when you don’t feel like writing and you have nothing to say, so, here it is: write.
Yep, that’s it. It’s that simple.
Take some duct tape, put it over your mouth, shut up, stop whining, pull up a chair, sit down at the keyboard and start moving your fingers.
You can’t sit there and type and have nothing to say. Now, what you have to say, you might think isn’t any good—and it may be utter crap—but there is no reason that has to stop you from writing. Just do it.
There are a million ideas bouncing in your head, but some of those ideas will only come to the surface when you have decided you are going to sit down and do the work.
Don’t believe me?
Try this exercise on. Right now I want you to close your eyes, and think about nothing. That’s right, think about absolutely nothing—I’ll wait.
How’d that go for you? Were you able to think about nothing?
So, don’t tell me you don’t have something to write about. Of course you do. Your problem—and my problem—isn’t writing, it’s typing it out.
P.S. – By the time this post goes live, I’ll be in the middle of launching my How To Market Yourself as a Software Developer program. If you liked this post, go check out the program. It has a whole video course on creating your own developer blog and making it successful.
Software developers usually make pretty decent salaries, but did you know that companies that hire software developers usually make much more money off of a single software developer than they pay that software developer?
I guess, if you think about it, it is common sense. Why hire programmers if those programmers don’t make more money for your company than the salary you are paying them?
But sometimes this disparity between what a software developer actually makes and the value that software developer brings to the table is large—sometimes it’s really large.
In fact, if you are being paid an hourly rate as a contractor, you are probably making about half of what the client is being billed for, if even that.
Being a commodity
One of the big problems many software developers face is that they can be easily treated as a commodity.
This problem is becoming more and more prevalent as basic programming skills become easier to come by and more and more people are becoming programmers all over the world.
If you go onto oDesk or ELance today, you can find software developers willing to write code for less than $10 an hour; you can find really good software developers writing code for $25 an hour.
If you are letting yourself be treated like a commodity and the price of that commodity is dropping, you are in big trouble.
Forget about job security at a single job. You’ve got to worry about your entire career and all the investment you put into your skills.
If you want a long and prosperous future doing what you love to do, you’ve got to be able to justify why someone should hire you and keep paying you at your current rate instead of hiring someone at $10 an hour to do the same work.
What makes something a commodity?
In order to solve this problem, you’ve got to examine what exactly it is that makes something a commodity.
But, before we go any further, let’s take a moment to make sure we are on the same page about what a commodity is.
I like this definition from the Wikipedia entry on Commodity:
“The exact definition of the term commodity is specifically applied to goods . It is used to describe a class of goods for which there is demand, but which is supplied without qualitative differentiation across a market.”
The key thing here is “without qualitative differentiation across a market.”
This means that if the service or product you provide isn’t much different than what everyone else is selling, it can be considered a commodity. And, as such, the price will be determined by the market, not by the actual value you provide.
So, even though you may be providing your employer with $500,000 worth of value per year by writing code, your employer can turn around and pay you whatever the market says a software developer with your years of experience and skill level is worth.
That is unless…
You find a way to be something more than a commodity
That is the key to being paid what you are actually worth instead of what the commodity market for software developers says you are worth.
But, it isn’t easy to stand out. It isn’t easy to be perceived as something more than a commodity if you don’t know how to do it.
I want to show you an example of how some people break out of commodity markets and differentiate themselves to make more money.
Have you ever heard of a voice-over?
A voice over is when you have someone who has good oratory skills or a particular accent, or sounds create a recording for something like an advertisement or a cartoon character’s voice in a cartoon.
There is quite a big market for people who do voice overs. Just about every radio ad, podcast advertisement, and animated film or show needs voice over talent to create voice overs.
But, did you know it is a commodity market?
That’s right; I can actually go onto Fiverr.com and pick from a multitude of skilled voice over actors to do a voice over for me for $5. Not only can I do it—I have done it. I’ve hired two different voice over actors to do voice overs for my podcast for just $5.
But, believe it or not, some voice over actors get paid millions of dollars each year to do basically the same work.
So, what separates the voice over actors who get paid millions from the ones who get paid five bucks?
I’ll give you a hint—and it’s not talent—it’s marketing.
Those voice over actors that are making the big bucks have figured out how to market themselves to land the right gigs, which increases the value of their name and gets them more and higher paying gigs.
If you don’t believe me, go on Fiverr.com yourself and check out the talent level of some of the top people on there that are doing voice overs for just five dollars—you will be impressed.
No one tells software developers how to market themselves
In the entertainment industry self-promotion and marketing is the name of the game.
There are whole companies that do nothing but market talent. I mean, actors have agents, so do musicians, and yes, even people who do voice overs have agents… at least the successful ones do.
But, when it comes to software development, you are not very likely to find the same kind of resources of knowledge about self-promotion and advertising that envelope the entertainment world.
Have you ever heard of a software developer having an agent?
Well, even though it sounds silly, you’ve got to be your own agent if you want to rise above the crowd and stand out. If you want a chance at making the big bucks and setting your own price, you’ve got to figure out how to market yourself.
There are plenty of software developers that are already doing it. You’ve heard them on popular podcasts and read articles written by them in trade magazines or heard them speak at conferences.
But, no one ever talks about how they achieve their success… at least not until now.
Over the past few years, I’ve been talking to developers who have broken away from the herd. I’ve studied their careers and asked them about how they’ve achieved their success. I’ve been able to duplicate their results to a large degree myself, and since no one else is doing it, I want to share that information with you now.
Check out this package I am putting together called “How To Market Yourself As A Software Developer.” I’m going to be launching this this package, on March 27th.
Well, I hope this article has been helpful to you and helped you realized that you’ve got to make a fundamental shift in your thinking if you want to be able to really advance your career and not be treated like a commodity.
If you are a regular reader of my blog, you probably know that for the past few months I’ve been working on a really big project.
I get many emails from developers wanting to know how to boost their career by either finding a new job, starting a consulting business, or even just getting a raise.
I try to help as many of these developers as much as possible through emails and Skype calls, but there is only so much of me and those types of communication don’t easily scale.
I was trying to figure out how to solve this problem
Then, I had an idea…
What if I put together a full program which teaches developers what I think is the most important skill required in boosting their career—marketing themselves?
I don’t mean the cheesy kind of marketing yourself that gives marketing a bad name. I mean the true, down-to-earth, I want to help someone and by helping them I’ll build a reputation for myself, marketing.
I found in my career, this approach to marketing—of providing value to others—was the single most impactful thing I had done to increase the amount of money I make and to open up all kinds of opportunities for me.
So, that is how the idea was born. My Pluralsight courses on all kinds of technologies were very popular, but I feel like the biggest value I could provide—more valuable than any technical course—is to show developers how to get out there and build a name for themselves in the community.
Here is what I created
I didn’t want to just create a normal video tutorial. I feel like the material in this course is better served by a combination of video, books, interviews and more.
I want developers who buy the package to feel like they are getting a huge value for the price. I want to make sure that I am not leaving out any of the advice I would have given my younger self if I had a time machine and could travel back in time.
I started out by writing the flagship book for the course, “Why Marketing Yourself Is Important.” I feel this book is a good starting point for the program and gives readers an understanding of what exactly the value of marketing yourself is and what exactly it entails.
The book is designed to introduce the concepts that are covered in more detail in other parts of the program and to get a reader more familiar with these concepts so that they understand where each piece fits in.
Next up, I created the “Building a Brand” video course. The goal of this course is to talk about the importance of building a brand and show viewers exactly how to do it. I want to cover more than just the surface level understanding of what a brand is and really dive deep into what makes a great personal brand and the value having a great personal brand can bring.
I wanted this course to be structured like you are having a real conversation with me. So, I shot a majority of the course in full HD video with me talking into the camera. In this course I take you from the basics of understanding what makes up a brand all the way to the creation of your own brand and I answer the most common questions related to personal branding that I have received from talking about this topic at code camps and conferences.
Since having a blog is a central part of the strategy I recommend, I created a full step-by-step course that shows you how to build a blog from scratch and gives you the tools and advice I’ve learned over the years for making your blog successful.
In this course I go over all the options for setting up a blog, including free hosting, shared hosting and using a full blown virtual private server. But, I don’t want to just talk about building blogs, so I took the extra steps and actually show you how to create a blog using each possible option.
I end the course by giving you all the tips and tricks I’ve used to build this blog up to a blog that gets over 100,000 visitors each month—around 3 thousand per day on average.
I feel that learning to use social networks effectively is a very important skill for getting your name out there and spreading the content you create. So, I wrote another book called “The Ultimate Developer’s Guide to Social Networks.”
In this book, I lay out my overall strategy for gaining traction on social networks. I talk about concepts like building an audience and connecting with people. I cover my strategies for each of the major social networks. I also give a run down of all the tools I use to manage my social networks effectively and not spend hours each week keeping up my presence in them.
One area that I feel is sorely lacking for most developers is the area of creating a good resume. So, I decided to write a “Resume Advice That Will Make Or Break You” in the form of: do this, don’t do that. I included all the best resume advice I’ve gotten from recruiters and hiring managers over the years along with tips that I’ve used myself to land good jobs and negotiate higher salaries.
Next, comes the big topic of getting your name out there. I decided to write “The Complete Guide to Getting Your Name Out There” to cover this topic in detail. In this book I talk about all the different mediums you can use to get your name and brand out there where people can see it.
I start out by talking about how to get people coming to your blog. Then, I give you some advice on getting published in magazines or other blogs. I cover writing your own book and either self-publishing it or getting it published by a traditional publisher. I even talk about all the tips and tricks I use to create video tutorials and screencasts or shoot high quality YouTube videos. I also cover the topic of getting on developer podcasts or creating your own podcast—it isn’t that hard. And finally, I give you some practical advice on getting out there in the community either by speaking or through open source. There is a ton of information packed into this book.
I really want to make this package valuable, so I didn’t stop there. I created a list of networking do’s and don’ts and I hired a graphic designer to create a beautiful inforgraphic out of it. I am really happy with how this thing came out. In this infographic I reveal all the networking secrets I’ve learned over the years from countless books, articles and just plain old trial and error.
Finally, I reached out and contacted the most prominent and well know software developers I could think of. I was able to get Bob Martin, Jeff Atwood, Jon Skeet, Rob Conery and a bunch of other developers to let me interview them. I feel like these interviews alone are worth the price of the course—Mark Freedman, even agrees with me.
— Mark Freedman (@MarkFreedman) March 9, 2014
In these interviews I dig deep into what made these famous software developers so successful. They share plenty of secrets I haven’t heard anywhere else. One interview in particular that I think you’ll find extremely valuable is the one I did with Pinal Dave. Pinal is the creator of SQLAuthority, an extremely successful blog that gets over 1.8 million views per month. That’s right 1.8 million! For the first time, he shares his secrets to success.
I’ll also be updating the package with more interviews and other content as I get feedback about the content. I want to make this package as dynamic as possible.
When does it go live?
So, you might be wondering when this course goes live. Well, if you preordered the package, you’ve already gotten most of the content I’ll be launching with.
But, if you didn’t preorder, you can get the full finished package on March 27th. If you are a subscriber to my email list, you’ll get a nice hefty discount code in your email on the day of the launch.
Man, am I tired
I do have to say, I am exhausted from working on this package. I’ve never put so much effort into a single project in such a relatively short time-frame. I spent countless hours up late at night working on parts of the package. But, I think it was all worth it, because I am extremely happy with the way everything turned out. I am 100% confident this course will help developers learn the skills they need to market themselves and boost their careers.
In the last year, I:
- Created and produced 30 full length video courses for Pluralsight
- Wrote 56 blog posts
- Produced 40 episodes of the Get Up and CODE podcast
- Created 50 YouTube videos
- Published a book
- Spoke at 4 events
- Billed over 100 hours of contract work
- Created a full product, that I am about ready to launch
- Ran 5 kilometers 3 times a week, every week
- Lifted weights 3 times a week, every week
I’m not saying this to brag–although I am certainly proud of these accomplishments. I am saying these things to prove that I know what I am talking about when it comes to productivity.
Being super productive
Right now–as I type–I have a timer ticking down. The clock shows approximately 14 minutes before I’ll take my next break. I live and die by this clock.
You may have guessed it, but the clock is a Pomodoro timer. For the last year, I’ve been religiously using the Pomodoro technique to not only stay on task, but to plan out my days and weeks.
If you aren’t familiar with the Pomodoro technique, the concept is remarkably simple. So simple, that I first dismissed it as ridiculous. But, thanks to my good friend Josh Earl’s success with it, I decided to give it another try.
You basically set a timer for 25 minutes. During that time you pick a single task to accomplish and work on that task, uninterrupted. After 25 minutes you take a break for 5 minutes and then begin again. After 4 cycles, you take a longer 15 minute break. (There are some variations on this, but that is the basic idea.)
Like I said, it seems pretty simple and unremarkable, but I can’t even begin to express how powerful this technique is for getting things done.
I’m lazy by nature. I have to constantly fight against the side of me that wants to procrastinate and slough off my work. The Pomodoro technique helps keep me focused by forcing me to work uninterrupted for a period of time. It also gives me a measure to compare myself against and realistic targets to aspire to achieve.
My week beings on Monday. On Monday morning I wake up and go to the gym to lift weights. When I get back, I have a protein shake and get to work.
The first thing I do when I get to my desk on Monday is start my Pomodoro timer and open up my “Weekly Plan” Trello board. I use this board to organize my week. It has nine columns. Seven columns for the days of the week, one column for today, and one column for done.
My first task of the day is to create the rest of the tasks that I think I can get done that week. I start off with a checklist of things that I know I need to do every week:
- Blog post
- Podcast episode
- YouTube video
- Newsletter email
- Buffer social network posts
Then, I add cards for the current projects I am working on for that week.
Once I’ve got all the cards I can think of on the board, I start tagging each card with a color that represents how many Pomodoros I think that task will take. I have three categories:
- Green: 1 Pomodoro
- Yellow: 2 Pomodoros
- Orange: 3 Pomodoros
If something is going to take up more than three Pomodoros worth of time, it needs to be split into multiple tasks.
Next up is planning the week. For each day of the week–unless there is something that will take up most of my time–I figure I can get about 10 Pomodoros done. This may not seem like a lot, but believe me, it is. I drag cards into the columns until I have filled up each weekday with 10 Pomodoros worth of cards. For weekends, I usually just drag in about three or four.
My estimates are always on the high side, but they are pretty accurate, because it is fairly easy to estimate based on half hour intervals–especially when many of your tasks are repeated each week. (For example, a blog post is estimated at three Pomodoros.)
I have a similar ritual every single day. The first thing I do, after exercising each day, is to open up my Trello board again and this time plan the day.
New things come up and other things need to get shifted around, so planning for the week alone is not sufficient. Often, I’ll have different tasks that I had vaguely identified at the beginning of the week which I’ll give more clarity to later on.
I first drag things over from the appropriate day into my “Today” column until that column is filled with about 10 Pomodoros worth of work. After that, I’ll take a look at the today columns and think about anything I might have missed that needs to get done that day. Finally, I’ll sort the “Today” column based on priority–I want to make sure I am always working on the most important things first.
Once I’ve got the day sorted out, I go back to the rest of the days in the week and move around cards until everything is balanced again. If I find that I’ve got some empty slots, I’ll create new cards and start filling those slots until I am back at full capacity again.
Once all the prep-work is done, it’s time to actually start working on tasks. I grab the first task off the list, start a timer and get to work. At about 5:00, I stop for the day and add up my Pomodoros. If I didn’t hit at least 10, I count on working a little bit that evening. If I did hit 10, it’s optional.
Why this works
So, you may be wondering why this works–why it is worth even writing about such a simple workflow. Well, even though this workflow seems really simple, there are a few key things going on here that aren’t immediately obvious.
First of all, I am using quotas to make sure that I accomplish the volume of work that I want to produce each week. I have quotas for how many blog posts, podcasts, YouTube videos, and other content that I need to produce each week. The things that are being measured by a quota get dropped onto my board first.
I’m also using a daily and weekly quota when it comes to Pomodoros. Pomodoros are little measurable units of work for me. I know that I should be able to get 10 done each day and that I should be able to get roughly 50 done in a week without killing myself. I know from experience that hitting 60-70 will cause a measurable dip in performance the next week and that if I am doing less than 50, I am slacking off.
Because I have those quotas in place, I know what is expected of me each and every week. I have the power to hold myself accountable to a real measurable standard. I can’t emphasize enough how important this point is. If you don’t have a way to hold yourself accountable to a standard that you want to achieve, human nature will cause you to fall way below the bar.
Another major component that makes this technique successful is the awareness of my capacity within a given amount of time. It is really easy to over or under estimate what you can get done in week, because you don’t normally have a ruler that you can use to measure task duration versus your actual capacity. When I start the week, I know that my capacity is about 50–I’ve got that much gas in my car. I get to choose where I want to drive that car that week–I can only go so far. I have to make a realistic prediction of what I can actually get done. From that prediction I have to prioritize my tasks so that the most important things get done first.
Without this understanding of my capacity, it is easy to fall into the trap of overestimating my ability to get work done and underestimating the take it will take to get the work done. With this system, I have a real metric to compare to. I know that I am not going to get 80 Pomodoros done in a week. I know that in an 8 hour day, I will not get 8 hours of work done. I am eliminating my biases by replacing them with real statistics.
Finally, the dedicated focus of the Pomodoro technique makes me more efficient at the work I am doing. When I am solely focused on one task at a time–without checking Facebook or Twitter–I work much more efficiently. Several studies have shown that multitasking causes a drop in efficiency. When I stay focused on a single task, I get much more done. I’ve written about this before, when I talked about quitting your job, but you can easily lose hours of time in a day to small distractions. Over the period of a year’s worth of time, all those wasted minutes can end up equaling weeks of lost productivity.
One huge benefit of this technique is that I am able to do most of this work without stress or guilt. Normally, when I am working, I always feel guilty about how much time I am wasting during the day. I also feel stressed about not getting as much done as I should be getting done. This situation of stress and guilt actually ends up being the perfect breeding ground for procrastination and burnout.
When I am using the Pomodoro technique, I don’t feel the guilt of wasting time, because I know that as long as I get done 10 Pomodoros in a day I have reached my productivity goal for the day. If I get more done, great.
I also don’t feel stressed about getting as much done as I should have, because how much I get done is no longer what is being measured–I’ve taken the burden off of my shoulders. My focus has shifted from results to process. I can’t control the results. Work takes as long as work takes. But, I can control the process. If I put in my 10 Pomodoros for the day and I have sufficiently prioritized my work, then I have done the best that I can do–no need for guilt, shame or stress.
Time for a break
If you are interested in getting started with the Pomodoro technique, I’d recommend checking out Pomodoro Technique Illustrated. And if you have any questions about my process and how it works, feel free to ask and I am happy to answer them in the comments below.
Also, if you liked this post and are interested in more of what I have to say about being productive and boosting your career, sign up for my weekly newsletter here. You also might want to check out the course I am putting together called “How To Market Yourself as a Software Developer.”