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.”
The best way to guarantee success in almost any pursuit is to be prolific. Not all successful people are prolific, but almost all prolific people–regardless of vocation–are successful.
When you take so many swings at the ball, it is hard to not eventually hit a home run.
Rewards are unfairly skewed towards the top.
I used to be addicted to playing poker tournaments online. I would spend countless hours in the evenings with multiple poker tables open, happily clicking away as I could hear the mechanical chk chk chk of the computerized dealer dealing me out hand after hand.
A typical breakdown of a poker tournament prize pool goes something like this:
- 1st place = 25%
- 2nd place = 15%
- 3rd place = 10%
- 4th and lower = remaining 50%
Half of all the money goes to the top 3 places. A quarter of it goes to 1st place.
In a poker tournament, you want to win first place.
This same kind of payout structure exists in many areas of life. You see it everywhere you look. 1st place gets the big bucks, the endorsement deals, and a unfair share of the glory. 2nd place and lower get much less.
As Ricky Bobby says, “If you ain’t first you’re last.”
Because so much of life is weighted to give those who end up on top a lion’s share of the bounty, it makes much more sense to take a lot of big swings than it does to take a few little swings.
Keep swinging that bat as hard as you can, and even if you have your eyes closed, you are bound to eventually connect with the ball, and when you do you are going to knock it right out of the park.
Rarely when you find someone who is wildly successful, do you find them taking small carefully calculated conservative steps, instead you find them wildly flailing in every direction until success just walks right into one of their haymakers.
One of the most famous examples of prolific people who produce amazing results is Thomas Edison. (By the way, if you don’t know what prolific means, it basically means producing a lot.)
Thomas Edison had 1,093 US patents in his name. That means he basically invented a new thing every single day for the equivalent of 3 years. Imagine waking up every morning and filing a patent for 3 years–talk about being productive.
Here is another example. You’ve probably heard of the famous romance and fiction novelist Nora Roberts. Any guesses to how many books she has written?
She has written over 208 novels. Not blog posts, not eBooks–novels.
She doesn’t use a ghostwriter. She doesn’t have a research assistant. She does it all herself and she publishes about 5 complete novels a year. I can’t even imagine writing that much.
Want to know how many blind swings Nora Roberts took before she knocked one out of the park?
Well, she got rejection letters for her first 6 books and got her first book published in 1981. From 1982 till 1984 she wrote 23 novels which were published and she didn’t make the New York Times Best Seller List until 1991 when she had already produced close to 100 novels–that is a whole lot of swinging.
Now, every single novel she has published since 1999 has been a New York Times bestseller.
I want you to stop and think for a minute about how many authors or would-be-authors write one book or two books or even 10 books and give up. Think about it. If it took Nora Roberts almost a hundred tries to hit a home-run, why do so many people think they can do it in one?
I used to be lazy
I used to produce almost nothing. Weeks would go by and I would have no real tangible asset which I produced. During those times in my life, I wasn’t a failure, but I wasn’t going anywhere. I was just sort of floating in the pond.
But, one day something changed. I can’t quite tell you what it was, but something lit a fire under my ass. I started being productive. I turned off the TV, put the XBox controller down and started producing instead of just consuming.
I went to work and I tried to see how many backlogs I could get done in a day. I got home and wrote blog posts and created Android apps. Everyday I was doing something. Everyday I was taking big swings and stepping into them–hard.
Then one day, crack–my bat connected with something.
I got a chance to do some developer training videos for Pluralsight.
I took a bunch more swings, producing courses as rapidly as I could. 3 years went by and somehow 54 courses manifested themselves out of nights and weekends of sitting in front of my computer recording. crack! crack! crack!
It started to become harder to miss the ball than it was to hit it.
Lazy me had become… prolific?
By the way, one of the first books that helped me become more productive was Getting Things Done by David Allen, I highly recommend reading this book if you’ve never read it before.
Also, if you are having trouble staying on task and actually producing the work you know you should be producing, read one of my all time favorite books, The War of Art by Stephen Pressfield. This book will kick your ass.
Quantity breeds quality
Many software developers focus on quality. And while quality is important, it can’t be manufactured on its own. You can’t force quality to appear. It takes practice; it takes quantity to produce quality.
If you want to become a better developer, write more code. Produce some applications. There has never been an easier time for a developer to publish their own application, whether it be a web application, mobile app or even a standalone desktop one.
If you want to write good code, you need to write a lot of it. No matter how hard you try, you aren’t going to write better code by gritting your teeth and concentrating really hard. You’ve got to be actively producing code and solving problems if you want to produce better code and solve harder problems.
It’s not that quantity beats quality, so much as it breed quality. The more you produce the better you become at producing.
Back to you
If you want to guarantee success, more than anything else, you need quantity. You can’t just assume that your first try is going to be successful, you’ve got to assume it is going to take 5 tries or 10 tries or maybe even 100 tries to hit a big success.
Far too many people give up early and far too many people aren’t willing to put in the hard work that is required to be prolific.
If you are having trouble hitting your stride it may be because you just haven’t stuck with it long enough.
Your first application might not be a success. Your first attempt at solving a difficult problem may be a dismal failure. But, the question is, are you going to keep trying?
If you want to be successful, you have to learn how to produce. You’ve got to learn how to put a crank in your back and wind that thing up until you can’t turn it any more.
Are you going to be the kind of person who takes a few halfhearted whiffs at the ball and gives up? Or are you going to be the kind of person that is there day after day, swinging that bat, knowing the outcome will come if you only are willing to put in the time?
Prolific people generate prolific results.
What is it that you could be doing, but you’re not?
If you like what you’ve read, please take a moment to sign up here and become part of the Simple Programmer community.
I write quite often on this blog about starting a side business or becoming self-employed, but one of the biggest struggles in getting something new started is finding time.
The same goes for getting fit and getting in shape.
So, if you want to be successful in your career, or in life in general, it is really beneficial to find out where you are wasting your time—so you can stop wasting your time.
I’ve found there is one major time-waster out there that many of us indulge in. One that can easily be cut out, or at least reduced significantly, to give you back much of that time you are wasting each day.
I’m not going to give away the answer here, but you can probably guess what it is already.
Check out my video for this week below and let me know what you think.