This is the 3rd post in a three part series about quitting your job and working for yourself. Check out the first post about why you should want to quit your job, and the second post about the fantasies and realities of quitting your job.
I want to start off by saying that I, myself, have had several false starts and I’ve witnessed countless others who think that they are going to quit their job and live their dream only to wash up, shipwrecked on the shores of reality.
I’ve already talked about the harsh realities of working for yourself. If that part didn’t scare you at least a little bit, or you think that what I said doesn’t apply to you, there isn’t much point reading any further, because this advice won’t help you either.
But, if what I said earlier made you sweat just a little bit; made you just a little bit more unsure of your brilliant plan, then you’ll probably find the advice I offer here immensely useful (I wish I would have had this, advice when I started out.)
Transition into working for yourself
Now, for some people this ends up working out. These are the people you hear of that quit their job to follow their dream and then they created some startup company that got purchased for millions of dollars. Some people also win the lottery and others, unfortunately, get hit by lightning.
But, what you don’t hear about is all the people who quit their jobs to follow their dreams and end up wasting a year or two of their life eating up all the savings they have accumulated from the past 10 years while they suffer from a bout of writer’s block that never ends up being cured.
The truth is, working for the man is quite a bit like slavery or prison. You can’t just be set free and expect that you’ll adapt comfortably to your new life and start fulfilling your dreams. It is a bit like when you get off that 6 week diet you were on and say “ok, I’m just going to pig out a little as a reward, then I’ll get back to ‘normal eating.’” What ends up happening is this instant transformation from the shackles of a restrictive diet to “free eater” doesn’t land us in the comfortable norm of “normal healthy eater” like we’d expect. Nope, instead we take a 1 way ticket to pig-out land until we eventually come crawling back to the comfortable diet prison that we hated, yet required.
The same happens to software developers, and other professionals who go from working for the man to being the man– they can’t handle it! They go nuts, and waste lots of time being unproductive without the structure of a workplace and someone cracking the whip on their back. Eventually, they crawl back to their cruel masters and begrudgingly reenter the rat race.
The problem is that working for yourself requires self-discipline. More than you’ve got right now. Yes, I know that your parents and friends have commented on how self-disciplined you are because you have excelled at your job by actually showing up to work each day and doing your job, but there is a huge difference between doing what you are supposed to do because you are supposed to do it and doing what you are supposed to do, because there are immediate and dire consequences if you don’t.
Stop shaking your head for a moment and listen to me. I know you think you are better than that, but you aren’t. Take a deep breath, dig deep and realize what I am saying is true. If you really want to succeed on your own, you are going to have to learn this skill as well; seeing an unfiltered view of reality.
In order to be ready to be successful on your own, without a boss, without a formalized structure and system of consequences, you are going to have to exorcise a few demons.
The best place to perform this religious rite is at your current workplace, in your current job. You will use this as a transition period and training ground to prove yourself, before you cut loose your chains.
The first demon: productivity
In my last post, I talked about the fantasy and reality of working for yourself and really what it focused on was the most critical component: productivity.
These days, productivity is like a drug; lots of people are peddling productivity hacks and productivity tools as if productivity means more than just working hard on what you are supposed to.
The trick is that it is much easier said than done. As I highlighted in the last post, most of us are spending very little time actually working productively at work. And, you will probably be in for quite a shock when you lose your shackles and find out that you aren’t getting nearly as much done as you thought you were– oh, and now you aren’t getting paid for goofing off.
So, my advice is: before you quit your job, you need to actually be able to put in a 6 hour day of hard work. No better place to practice doing that than in a paid learning environment.
How do we get there?
It isn’t going to be easy. But, nothing ever is, right?
I use a productivity technique called the Pomodoro technique to both measure and help me achieve a high level of productivity. The idea behind this technique is pretty simple. So simple that I actually overlooked it the first time I had been introduced to it and only later came back to it when a friend of mine, Josh Earl, mentioned how much success he was having using it.
The idea is that you set a timer for 25 minutes. During this time, you work on one focused task without interruption. After you are done, you take a 5 minute break and repeat. Nothing magic here. The magic is actually in the measurement. You see how many of these you can get done in a day and you track them. You can actually then plan out your work and estimate your work in terms of Pomodoros, which it turns outs, is extremely useful.
I’d recommend getting this book, Pomodoro Technique Illustrated (Pragmatic Life), to learn more about this deceptively simple seeming productivity tool.
I’d recommend starting to put this into practice at your regular job. Try to achieve 8 Pomodoros a day. This would represent close to 6 hours of productivity. And only count time that you are actually being productive. This means producing something of tangible value. You are going to end up not replying back to lots of emails and dismissing yourself from a bunch of meetings.
The second demon: gold-plating
On someone else’s dime it is pretty easy to forgo pragmatism. But, something I had to learn really quickly when I struck out on my own is that good enough really is good enough.
Don’t get me wrong. I’m not saying do shoddy work. And you already know that I’m not advocating not working so hard. What I am saying is, if you want to be super productive, you can’t make every piece of work you do a masterpiece. You have to find the right balance of time and effort.
Take this blog post, for example. I’m putting quite a bit of work into this post and the series of blog posts it belongs to, but I could actually spend weeks or months writing and rewriting parts of this post. If I did this, I might end up with a true work of art at the end of the process, but I’m not going to do that. Instead, I’m going to ship it when it gets to the 80-90% effectiveness mark and not worry about squeezing out that extra 10% of quality for another 300% cost of time and effort.
Don’t take this as an excuse to do s!*# work and ship a bunch of crap. That is easy, anyone can do that. Instead focus on being pragmatic. Get to the point where the work is good enough and let it go, then move onto the next thing. This is much harder than you might think– it is a delicate balance.
The third demon: consistency
Success is usually not the result of a glorious fight with a single dragon which you vanquish in a fierce battle, instead the road to success looks much more like running around Midgaard naked, killing rats over and over again.
Working hard and being pragmatic is completely worthless if you can’t do these things consistently week after week month after month. It is like starving yourself for a day and thinking you are going to lose weight, or running a marathon and sitting on the couch for the rest of the year.
So, how do you learn consistency? Simple, you cut out all the excuses. Make being consistent a matter of life and death. Don’t act like failure is an option. Pretend like just missing a single day or skipping a beat is the end of the world.
Eventually, you’ll be able to use your judgment to decide what you should do and when to make exceptions, but for now make rules for yourself. Rules that you will not break under any circumstances. Learning to live by rules like this will be a huge benefit to you. Everyone is weak-willed, no one can resist temptation; if you want to be successful, avoid judgment calls and decision making. Make your decisions ahead of time and codify them as rules that you follow every day.
I’ll give you an example, before I wrap up this post, because it is already getting quite long. Right now I am learning Spanish. I am using an app on my iPad called Doulingo to do this. I have a rule that I do this app at least 30 minutes a day, every day– no excuses. What do you think will happen if I obey this rule every single day for a year? I think I am going to be pretty good at Spanish. Unless I stick my finger in an electrical socket and fry my brains, it will be pretty hard for me not to succeed, so long as I follow my rule.
The hard part
If I haven’t lost you yet, you must really be serious. Good. You are going to need to be serious to stomach what I am going to tell you next.
At this point, if you start right now, you are probably still at least two years out from the point where you are going to be able to quit your job and not end up coming crawling back to the rat race battered and beaten.
I see far too many people come up with the ill-conceived plan of saving up perhaps 6 months to a year’s worth of living expenses and then quitting their job to pursue their dreams of starting their own business. (I’ve entertained this idea myself several times in my career.)
But, let me tell you why this is a very bad idea and then give you a much better one– a plan that will actually work and isn’t likely to leave you homeless or broke.
The reason why saving up a bunch of money and quitting is a bad idea is, because if you do this, you will be constantly racing against time. Instead of time working for you, you will have time working against you. You’ll make bad choices, you’ll feel panicked, you will not be operating under ideal conditions and you won’t be giving yourself room to fail– which you will inevitably do.
Here is a better plan. Instead, of thinking in terms of saving up X amount of dollars, think in terms of earning X amount of monthly income from a side business. Whatever business you plan on creating once you quit your job, start doing it now. Start building you future business while you are still working for the man. If you can’t get something going on the side without the stress and pressure of potential financial ruin, you aren’t going to succeed when you go it alone and add all the extra pressure and stress that comes with being self-employed and not getting a pay check.
Sure, it will take you longer. Sure, it is going to be hard to essentially work two jobs, but the question is, how bad do you want it? If you don’t want it that bad, fine, I’m not going to try and convince you otherwise– to each his own. But, if you really want it, and you are willing to both work and wait for it, then do it the smart way; build your business on the side while you are still getting a regular paycheck.
Well, I hope this series was helpful to you. I’m not an expert by any means on the subject, but I can speak from personal experience, and I’ve talked with enough other people who have made the transition to know that what I am telling you here is not my advice alone.
When I first quit my job, I was shocked at how different life was from how I had imagined it would be. I had to make some big adjustments really fast, because I wasn’t prepared. Hopefully, after this advice, you won’t find yourself in the same situation, or at least you’ll have a rough idea of what to expect and how to deal with it.
Update: check out what Loren (the guy I mention in this post) actually is creating. Pretty awesome. The things I say in this post are still true, but I apparently either had Loren pegged wrong or this post may have influenced him in some way. He’s definitely building something cool right now and he’s putting a great deal of hard work into it.
I read the saddest most uninformed blog post on hacker news yesterday which somehow made it near the top of the front page.
It is basically the all too common story of “I quit my job because I got bored and I’m just going to do what I want and I’m so excited, please give me self encouragement in the form of follow your dream, live your passion, etc, so I can feel better about myself and not realize that I am just lazy.”
Unfortunately this kind of thinking and mentality seems to accurately embody much of the general ignorance and blatant stupidity of the next generation of software developers.
The best and the brightest
Hacker news is full of plenty of smart and talented young people. There are, of course, experienced veterans of the industry there as well, but there sure seem to be a lot of really smart people that, like brightly burning stars, will soon fade into nothingness.
It is really sad to see someone peak at 22 or 23 years of age and then go down the crapper from there.
It doesn’t happen because they work really hard and burn out. It doesn’t happen because, as they like to imagine, the world wasn’t ready for their genius. It happens because they don’t know how to work.
The sad thing is, we are to blame for this. We have painted the wrong picture for youth. We have glamorized the world of software development and programming and told them that they will be carried through life on their abilities and brain matter. We have somehow imbued within them the misconception that being smarter than someone or possessing more knowledge than another makes a person not only superior to that person in every way, but gives them the right to publically efface and hurl all manner of insults at that person in the name of science.
What we haven’t told them is that nothing of any worth is obtained by any means except for good old honest hard work.
You see, these young and bright minds are being mistakenly fed the tasty meal of McDonald’s french fries and double whoppers that says work should be fun.
Hard, boring work
The big problem is that “kids today” don’t understand the value of hard, boring work. They think that they can just fly through life choosing only things that interest them and as soon as the thing stops interesting them, then they can move onto something else.
And it is fine, you can live your life this way. And if you do, you may start out ahead of the pack. Your passion may at first carry you further than your peers. But, overtime you’ll find those peers of yours that were willing to put in the hard work and stick to one thing, as boring as it might have been for them, will overtake you.
“The race is to the driven, not to the swift” – North and South
This is an extremely sad day, because it is a day in which you realize that while others have been carefully storing away nuts for the winter and fortifying their fortresses against all attack, you yourself have lived the vapid life of a vagabond merrily traveling from pleasure to pleasure in life ever thirsting, but never being quenched, every tasting, but never consuming.
It is really easy to sit at your desk when you are supposed to be working and browse hacker news, injecting in your sarcastic wit and sly comments, believing them to be of value, believing that somehow that in this false self-affirming reality that you are actually creating something of value, when indeed all you are doing is destroying and marring the work of others to your own detriment.
It is easy from the cushy back of your Aeron chair, provided to you by the fancy startup you’ve managed to secure a job at, based on sheer intelligence alone and no other human quality of any worth, to indiscriminately write-off the thought of lesser mortals and set them in their place as you spout off your hard earned knowledge of the industry and of how the very world works which was granted to you as a gift to mankind—your divine providence.
The sad truth of reality though is that while you are providing your service and value to humanity in the form of your irrefutable and distinguished wisdom, others are hard at work ever so humbly providing real value through their—at times—loveless toil.
They are building bridges a carefully laid stone at a time. You are crossing those bridges without a thought about how they got there and upholding your position as the great explorer and master of bridge building even though you just traversed a path that was already laid out for you.
The easy path
So, to those of you who want the easy path; for each of you that can’t stand boredom and despise work without pleasure, enjoy your brilliance while it lasts.
As you take flight from project to project seeking out only what it is that entertains your for the moment, you will be receiving your reward as you have earned it. You are like the man without a dollar in his bank account until payday comes who then quickly and excitedly cashes his check and spends it in its entirety that very weekend.
Check out this quote from Nietzsche which sums it up nicely:
But there are rarer men who would rather die than work without enjoyment in their work: the fastidious people, difficult to satisfy, whose object is not served by an abundant profit, unless the work itself be the reward of all rewards.
It doesn’t matter how brilliant you started out or how much faster you exited the gates than everyone else, those who consistently get up every morning and direct their energies along a single path, no matter how boring it may be, will eventually pass you on each of the many roads you haphazardly travel.
It may seem that I am suggesting that a software developer pick a single path, a single technology and stick with it for the rest of their life. But, this is not at all what I am suggesting.
Instead, what I am really saying is that to have long term success at whatever endeavor you are currently pursuing—and it can change drastically and many times throughout your life—you must have the wherewithal, the grit, to hunker down and work hard well past the point where the work is enjoyable.
It doesn’t matter what passion you pursue, the passion will fade, and you will be left with cold hard work in its place. At this point many people will mistakenly make the choice to leave that work and assume that it is time to move on, but any person who has ever produced any great work or achievement knows that it is only by pushing through the pain, by continually showing up every day and “paying your dues” that anything of value is ever really achieved.
The myth of burn out
I’ve written about this wall or barrier before, that many developers and like to attribute to burn out.
Burn out is just a rationalization for giving up early.
It is just a way to make an excuse for yourself to say that since everyone experiences this phenomenon, there is nothing wrong with me and no shame in my giving into it.
As I’ve grown over the years, I’ve come to realize that it is more than just a barrier. I recently read the excellent book “The War of Art,” and in that book Steven Pressfield describes this avoidance of work as resistance. He give resistance all kinds of diabolical characteristics that paint it as the true enemy that it is.
Even as I type these very words, I feel the force rising up in me. I created this blog originally because I thought it would be fun to write about what I thought about software development; to share my wisdom and knowledge about the profession. But, like all things, that feeling soon faded. What I was left with was the choice to continue blogging, even though it now at times hurt, or give up and move on to the next direction my heart led me to go.
And I could have given up and instead perhaps started a novel that I would never finish, or maybe a web application that I would someday sell as a service, or… and the list goes on.
The point is, no matter what avenue I would choose to pursue, the passion would eventually die, and I would be again faced with the same choice.
The same goes for the work I do at Pluralsight. Just last week I finished the 20th course I created this year alone, my 46th course overall. Do you think I wake up every morning and say “hey, I can’t wait to painstakingly produce and record hours of content?”
When I first started creating my first course, I had that feeling and felt that energy, but to be honest, it didn’t even last through the creation of that first course. By the end of it, I was ready to give up. This online video course production is for someone else, not me, instead I want to… eh, but I stopped myself. I started my next course, and when I was done with that one, I moved onto the next one and so on.
Now have I been miserable this whole time? Do I hate creating courses and writing blog posts with all my energy and inner being? Some days, yes, but most days it is not that black and white.
There are things I like and things I despise and it varies from day to day. I am, for example, having quite a bit of fun with this post. But, for the most part the rewarding part of what I do comes at the end—the finished product.
There is not quite any feeling like that of success that was achieved from long hours and hard work and toil. Work that is constantly pleasurable most often lacks this quality.
I’ve got much more to say on this topic including how I’ve been able to overcome burnout and learn to hunker down and do hard work even when I don’t feel like it.
I’m currently working on a top secret product that will combine what I have learned about this topic and more over the years with wisdom and knowledge from many successful developers much smarter than I am. Sign up here, and you’ll be the first to know when it is launched.
I discovered something about myself—I have an amazing gift to always make the very best technology choice.
No really, it is quite amazing.
When I look back at my development career, it seems to me that every programming language I was using at any given time was clearly the best one.
The same goes for frameworks and even operating systems.
Yes, I have this amazing ability to pick from the vast ocean of technologies, without even trying them all out, the very best one, and to vehemently defend my choice.
Perhaps as you’ve been reading this, you’ve discovered you have this uncanny ability as well?
Most developers are religious about technology
Don’t be ashamed, you are not alone. Myself, and just about everyone else, is with you.
Some of use are recovering from our self-imposed brain washing. Others of us are blissfully unaware of our predicament. But most of us have at least one religion we’ve managed to craft ourselves.
It is perfectly natural because most programmers got into the field of software development because they were passionate about it. Anything you are passionate about is likely to cause you to develop some highly charged opinions.
Take sports fans for instance. I’m not really much of a sports fan myself, but I know many fans of all different kinds of sports that religiously believe their team is the best despite all the evidence to the contrary.
This defense of our own choices and ideas is core to human nature. It is easy for us to adopt a new idea but we religiously defend the ones we have without needing much evidence to back it up. The problem is we tend to tie up our ideas about things with our identity and even our value as human beings.
It takes some deep soul searching, but it you look within yourself you’ll probably find that you can make a list of the best operating systems, programming languages, frameworks and so on.
Ignorance is not bliss
The problem with this self-imposed religion is that our technological religion blinds us from the truth.
I spent countless hours arguing about why Macs sucked so much before I had even really used one. Ironically, I am writing this post on a Mac right now, but I am using Windows Live Writer which I am accessing through remote desktop. Oh, and this blog post, well, it is actually hosted on an Ubuntu Linux server in the cloud on a PHP application you may have heard of called WordPress.
My point is, most of us vehemently will argue that our technology choice is the best without even having really tried the alternatives.
It seems ludicrous when you think about it clearly, but I still catch myself doing it even today.
When I look within myself to honestly ask the question “why,” I find that most of my motivations come from a combination of pride in what I have learned and accomplished and a fear of what I don’t know.
I find that it is much easier to dismiss a technology that I don’t know as “garbage” or “worthless” than it is to take the time to learn about it and see why others like it so much. As they say, one man’s garbage is another man’s treasure.
The problem with thoughtless religion
I don’t need to tell you that mindless religious zealotry is a destructive force in our world. You only need to go to your favorite national news web site or look in any history book to see that is the case.
So, while we may think our ignorance isn’t harming anyone and that they deserve it anyway because they are clearly wrong, the truth is, there is quite a wake of destruction that our ignorance can leave behind us.
I look back on my own past and I am embarrassed that I harassed Perl developers to the degree that I did, completely discrediting their work and ignorantly pushing my holy statically typed C-based languages as their one and only savior who could cleanse them of their filth.
But more than anything, I realize that I hurt myself.
Stop hitting yourself, idiot!
The biggest growth in my career came when I was looking for a job doing C# development and found a really good opportunity to act as a technical architect for a project written in Java.
I was quite torn by the decision. In my heart I knew that Java was bad and evil. I knew that because Java lacked properties like C# and required the use of manually created getters and setters that everyone writing Java code was clearly an idiot.
I almost didn’t take the job, but I decided that the pay was too good to pass up and that I would suffer through this awful experience like a prisoner of war until one day my Microsoft would rescue me. I thought I would at least get to apostatize some filthy Java writing scoundrels.
Well, it turned out that after a couple of years of mentoring developers on writing good Java code and unit testing, I realized that not only was Java not so bad, but there were some actual merits of the language and Java frameworks that could be appreciated.
More importantly though, I began to realize that my past code bigotry had closed quite a few doors on my face. It began to occur to me that perhaps all of my technology choices in the past were not necessarily the best. I began to start thinking that there wasn’t actually all the much difference between many of the most popular technologies.
I began to realize that understanding a wide range of technologies and programming languages made me much more valuable than ignorantly subscribing to my own religion about a particular technology that I happened to choose.
I found that my own understanding of individual technologies increased rapidly, because instead of just “eating what I was fed,” I could use my brain to compare and contrast differences between programming languages and technologies which left me with a deeper understanding of all of then.
I was rudely reminded of my own shortcomings that still exist in this area when I recently converted my blogs over to a Linux server in the cloud from Digital Ocean.
I was predisposed to choose Windows technologies for deploying web applications, but it was pretty hard to argue that a complete Linux server in the cloud that performed extremely well for $10 a month was not a good choice.
My point in all this is to say that being closed-minded about technology choices only hurts yourself in the end and severely limits your personal growth as a developer.
There is no “best”
I’ll finish up this post by imploring you to believe me when I say “there is no best technology or programming language.”
I’m not going to insult your intelligence by saying that each language has a purpose for a different situation because the truth is much deeper than that.
After creating over 40 Pluralsight courses on a very wide range of technologies and programming languages, I’ve discovered a few truths.
The truth is that there are multiple great ways to do the same thing using different tools and different technologies.
The truth is that all programming languages and technologies have big mistakes and weaknesses in them.
The truth is the more you learn about different technologies, the more you will find that at the core most things are pretty similar. What I mean by this is that most of the core concepts about writing software apply regardless of technology choice or programming language syntax.
You’ll also find, as I have, that if you are accepting about others technology choices and are able to admit your own ignorance and learn from it, you’ll find helpful friendly people willing to teach you what they know, everywhere you go.
If you found this post useful–or at the very least entertaining–sign up here and join the thousands of other Simple Programmers out there. Also, I’m still preselling my complete package on How To Market Yourself as a Software Developer for a limited time.
Do you consider yourself a good salesman?
If you are like most programmers, you probably don’t.
But have you ever stopped to consider what “selling” and “sales” really are?
Have you ever taken the time to dissect the process of marketing and making a sale and tried to see how it applies to your own life and career?
It’s OK if you haven’t—most people haven’t.
I’m selling you right now
If you’ve made it this far, it is going well for me. You probably decided to read this article because of the headline I created for it, “The One Thing You Don’t Know How To Do That You Do Every Day.” Then, the questions I asked in the paragraphs above must have held your interest long enough for you to get to my sub-heading telling you that I am selling you right now.
You see, unless I am actively selling you with my words, you aren’t going to be reading this blog. And, if you aren’t reading this blog, there really isn’t a point in me writing it.
This may not seem important, but the effects of a good sale are profound; especially when you magnify them by a huge number.
Imagine for a moment that this article lands in mainstream media and is featured on national media outlets—yes, a pipedream, I know, but bear with me for a moment.
What would happen to those ads over there on the right or at the bottom of this article? How valuable would they suddenly become?
How many people would subscribe to this blog? How many people would follow me on Twitter or check out the other things I am doing?
The difference between a thousand page views and a million page views is huge!
If I had the ability to “sell” these free words to millions of people each day, even my $0 priced product would have immense value.
When I am writing this blog post, it doesn’t “feel” like I am selling anything, but it is a mistake to think I am not.
I am selling you my ideas, my brand, my name and more. You are paying me with the single most valuable asset you have… your time. CHA-CHING!
You’re selling too
You may not think so, but everything you do in your life, every interaction, every word you speak, and even the clothes you wear are all part of one big sale.
It doesn’t even matter what your profession is, even if you are a programmer, you are selling something each and every day.
Take for instance the last conversation you had with your boss or your coworkers about what technology to use or what direction you should take to solve a certain problem. If you had an opinion at all on what to do, you were in the process of negotiating a sale. In this case you were selling your ideas.
Even the code you write is selling something. The code you write should be conveying something about what it does and how it works. If you can write the code elegantly, the reader of the code might not even be aware of the “selling” taking place. Great code sells itself, it seems apparent, like there was no other way to write it. Just like certain tech companies sell their products in a way that seems like they are obvious and your life wouldn’t be complete without them.
(If you lack the elegance of selling your code naturally, you may have to resort to hard sale tactics and add some comments to the code to describe in detail to the user what the code is doing and what its intent is.)
Your sale might not even be successful at all, as your reader may simply delete your code and replace it or ignore it completely.
Your code is also selling something besides meaning and understanding, it is selling your programming skills. When someone reads code they know you have written, they are making certain judgments about you as a programmer, and even you as a person, believe it or not.
Now, you may not think this amounts to much or is very important—and it may not be—but most sales calls aren’t. Professional salesman face a lot more “no”s than “yes”es, but for some salesman it only takes a couple of “yes”es to pay their whole years salary.
But it goes far beyond this as well. Even the subtle things like the clothes you put on in the morning and how you sit in your chair, are influencing people around you and shaping their acceptance of everything you are selling.
What you post on Twitter, even what you like on Facebook, are all either working for or against the image you are trying to sell.
Why selling matters
So, you may be thinking, “ok that’s nice and all, and I kind of agree, but seriously, why should I even care? So what if I am selling my “ideas” or my “personality” or something else, it doesn’t make a difference to my daily life.”
Do you know those kinds of people which seem to have everything go right for them?
Those people in which opportunity just seems to open its floodgates and rain on them pelting their heads with hailstones of success?
Guess what, most of those kinds of people happen to be excellent salesmen.
You see all those hundreds of sales calls that happen unconsciously every day of your life add up big over time.
If you are consistently “knocking it out of the park,” you are going to make a big impact and have huge amounts of influence.
This “influence,” which is really what sales is all about, will permeate all areas of your life.
If you have a large amount of influence, people will tend to like your ideas and agree with what you say. They will want to follow you and they’ll be buying into your personal brand and your message, whether it be “save the whales” or “give me a promotion.” (Which is exactly why so many companies hire celebrities to represent their brand or product.)
If you lack influence, you can actually have the opposite effect and create a repulsion. Think about the worst salesman you ever met. Did he make you want to buy the products he was selling or did he actually turn you off from them and make you never want to buy those products?
It is the same with us, we can actually become repulsive to the point that we are working completely against ourselves. We can get in situations where the more we try to promote our ideas or our vision of reality, the further away we actually push others from it.
Even if you are not trying to sell, you have to be good at it
So the bottom line is that we all need to learn how to sell and be better salesman, because even if we aren’t actively trying to sell something, we are still participating in the process of hundreds of sales transactions or more each day.
If we aren’t doing something to help make those sales transactions a positive influence for our interests, we may be inadvertently making them a negative influence.
You can be doing everything else right, but if you are selling wrong, you could be spinning your wheels or even going in reverse.
Now obviously, I’m not the best salesman I could possibly be, otherwise you’d probably be reading this post on the New York Times or CNN.com and not on simpleprogrammer.com, so you shouldn’t turn to me for sales advice. (I’m just telling you that you need to develop the skill.)
But, I do have a few suggestions of where to get started.
First of all, a book that I always recommend over and over again that doesn’t seem to have anything to do with sales, but in actuality has a lot to do with sales is “How To Win Friends And Influence People” by Dale Carnegie.
And second, the place that makes sense to me to look next is Amazon’s Best Sellers in the Sales and Selling category. (If you can’t figure out why to check this list, you may need more help than I can provide.)
By the way, I am working on a top secret specifically to help programmers and IT people learn to promote and sell themselves to help them increase their opportunities.
YouTube video for the week
And before I let you go, let me sell you on my YouTube video for the week about getting “punched in the stomach.”
Get Up and CODE: Episode 5, How to get 6-pack abs
And I’ve got one more free thing to sell, my latest podcast episode here:
What do you do when you make a mistake?
Not just in your job, but in life in general?
I’ve made some pretty big mistakes in my career
Just last month I was giving a talk at the Orlando Code Camp and I forgot to bring an adapter to go from DVI to VGA for my MacBook.
That was a huge mistake! I spent most of the presentation trying to get someone else’s laptop to work with my setup. Finally, in the last 5 minutes I managed to actually get my demo started. (Luckily the talk was about how to create a web service using Service Stack in 5 minutes.)
I’ve made huge career mistakes, like quitting a job with a certain company that got sold a year or two later, which would have resulted in a pretty big payday for me.
I’ve made dumb coding mistakes that have caused bugs to go into production and resulted in some embarrassing moments for myself.
I could take up this whole post just listing all the mistakes I have made.
The point is…
Everybody makes mistakes
It doesn’t matter who you are or how good you are at development or whatever else you are doing, you’ve made mistakes in the past and at some point in the future you’ll make them again.
The fact of the matter is that mistakes are just part of life.
We can try to avoid them. We can try to deny them. But, regardless of what we do, mistakes will happen, so it’s best to learn how to deal with them.
Own up to it
The most important thing to do when making a mistake is to own up to that mistake.
Chances are everyone else already knows that you made the mistake, and no amount of excuses or finger pointing will change anyone’s opinion of it. Trying to avoid the ownership of a mistake is more likely to make you look even worse and damage your credibility.
Sometimes the mistakes truly are only visible to you. In those cases it can be even more difficult to own up to the mistakes.
I have a tendency to try and pretend like somehow the mistake I made was not a mistake at all, but rather the wisest choice I could make given the set of circumstances I faced, regardless of how bad the outcome was.
This is called justification. Not only is it not healthy, but it is a complete waste of time and energy. When you justify your mistakes instead of acknowledging them, you completely void any possible benefit you may have gotten from making that mistake.
Justifying mistakes is tantamount to throwing your hands up in the air and saying “what comes, comes.” It is taking away your power and control over your life and career and giving it to everyone else. It is becoming a victim of your circumstances instead of a master of your destiny.
Long story short, when this !@#$ hits the fan in your life, it’s probably your fault, so own up to it.
Fix it (if possible)
You can’t always fix your mistakes.
Once I deleted my backup folder and emptied the recycle bin, BEFORE I had copied that folder to my new backup drive.
That was it, it was done. There was no fixing it at that point. Oops.
Fortunately though, in many cases mistakes are fixable if they can be identified and you are willing to own up to them.
There is a wise old Turkish saying that goes something like this:
“No matter how far you’ve gone down the wrong road, turn back.”
I always try to remember this saying, because the first tendency I seem to have when caught in a mistake is to try and ride it out with the foolish thought that I’ll save what I invested so far by continuing to go down the wrong road. As if somehow the wrong road will magically become the right road.
If you have made a mistake and you know what that mistake is and that mistake is fixable—fix it!
Don’t try and “ride it out” or build on top of it. Tear down the building to the foundation and fix the mistake, before it can get any worse.
Little mistakes become big mistakes when we let them fester. Big mistakes become tragically life altering mistakes when we ignore them.
Guard against future mistakes of the same kind
Now, like I said before, we can’t always fix all of our mistakes, (although you’d be surprised how many mistakes you can actually fix if you are willing to eat a little humble pie,) but we can guard against future mistakes.
The first thing that I try to do after I have made a mistake that I have identified, owned up to and have tried to fix, is to figure out why the mistake happened and how I can prevent it from happening again.
Far too many people make the same mistakes over and over again, because they don’t take careful steps to prevent the mistake from happening again.
It is very easy to move on from a mistake or dwell on the mistake without making any effort to analyze why the mistake happened in the first place and how it could be prevented in the future.
Many times in a rush to move on to the next thing, I’ve been guilty of this meta-mistake myself.
It is very important to examine a mistake with a clear head and honestly evaluate what brought about the mistake and why exactly it was a mistake.
Once you know what caused the mistake, it is important to put in place a procedure or some other sort of guard that will ensure that mistake doesn’t happen again.
In code, I’ll often add a new unit test or some other type of automated test to ensure that a bug I fixed can never happen again.
In life, I often don’t find it that easy. Many times the mistakes and the consequences of those mistakes are quite far apart, so it can require a very careful and honest analysis to determine the connection and find a future remedy.
I have a high tolerance for people making mistakes, because I know we all make mistakes. But, my tolerance wanes for people who continually make the same mistakes again and again.
Single mistakes are expected and accepted, repeated mistakes indicate incompetence and carelessness.
Move on… quickly
It is to easy to get hung up on a mistake and become paralyzed by it in such a way that it prevents you from having future success.
I seem to have an instinctual desire to throw away what I am doing or try to completely wipe the board clean, whenever I make a mistake.
I remember as a child playing Nintendo and hitting the reset button over and over again every time I died on a level or messed up in the slightest, instead of continuing on and doing my best from that point forward.
I’ve embarked on projects and ventures where I have made mistakes and instead of plowing forward to learn from them, have simply given up.
Giving up isn’t the same as moving on.
Sometimes it’s the same and you need to know when changing directions is the right course of action, but often we are so caught up in our mistakes that the continual focus on those mistakes shifts focus from what we should be working on and derails us completely from our track.
I’ve learned that is it important to quickly acknowledge the mistake, take corrective action, guard against it in the future and then move on.
This means letting go of it and accepting mistakes as the only way to move forward.
Fail, but when you do, just be sure you are leaning in the direction of success. Then when you fall it will be forward.
I’ve had many situations in my career where I know I’ve screwed up and I know what I did wrong, but the process and consequences of my mistake have drained the enthusiasm and spirit out of me to press on.
In those situations I’ve had to tell myself that I was not going to give up and I was going to make the best of my current situation, regardless of what it is, instead of making the worst of it.
What about you? What kinds of mistakes have you made and how did you recover from them?
I’ve been seeing quite a few posts on Hacker News lately about why you should not work too hard and even saying you should work less than 35 hours a week.
(Now, don’t get me wrong. I think the authors of these articles are awesome people who have accomplished huge things. I don’t mean to disrespect anyone of these great entrepreneurs. I just think some of them have confused where they are now, with how they got there.)
Would we ever want to live in a world where working harder didn’t amount to anything more, but rather ended up returning you less?
I know plenty of people who work less than 35 hours a week, and I wouldn’t say they are doing the best work of their life.
In contrast, I know plenty of people who are working 50 to 60 hours per week and they are doing some amazing things.
You have to work hard now to reap the benefits later
At the beginning of every episode of Pat Flynn’s podcast he says
“Welcome to the smart passive income podcast where it’s all about working hard now so you can sit back and reap the benefits later.”
There is no way around this. It is the principal of sowing and reaping at work.
While many well intentioned bloggers have urged you to not put in those extra hours at night, but rather to take time to do what you want and live a life outside of your work, they have forgotten the very path they took to get to where they are today.
If you are in that season of your life, then please take their advice. They are 100% right. There is this point of diminishing returns where you don’t gain much more benefit by spinning the wheel harder.
Ever rode a bike down hill really fast?
You know how at first you can start pedaling and it will actually make you go down the hill faster, but at some point the pedals just start spinning themselves?
You reach that point where you can’t actually move your legs fast enough to make much of a difference. Every couple of seconds, your foot will hit that tiny bit of resistance which tells you that you actually did something, but most of the time you are just spinning your loose pedals, not actually adding any speed.
It’s a pretty good feeling zooming down that hill with minimal effort on your part. There is no need to pedal furiously like you did to get up the hill. If you are pedaling furiously at that point, not only are you wasting your effort, but you are missing out on taking time to enjoy the best part of the ride.
You have to climb the hill before you can sail down it
Altitude change down, requires previous altitude change up. No way around it.
Pedaling a bike up a hill is hard work.
Not only do you have to keep working to move the bike up the hill, but every time you stop pedaling, you run the risk of rolling backwards.
The faster you want to get up the hill, the harder you have to pedal and the more you risk tiring out and rolling down the hill.
There is no rest, there are no breaks when pedaling up the hill. The best you can do is get off the bike for a while and walk it up the hill, but that will surely slow you down.
And so it is with life in general.
My personal hill
I’d like to buy into the story that we can just take it easy and good things will come, but the reality of the situation is that you’ve got to put in work first—hard work.
I started buying real estate when I was 18 years old. I bought my first house, which is a rental I still have today.
Since then, I’ve been buying properties at a rate of about 1 every couple of years.
It hasn’t been easy. Huge sacrifices to be able to do it, but from when I started I knew that I was pedaling my bike up the hill.
I also had been working as a developer full time for about the past 15 years. During that time, I was working nights and weekends to handle my real estate, building apps, and most recently creating online courses for Pluralsight.
Only at the beginning of this year was I able to finally quit my regular job working for someone else and start working completely for myself.
It took a lot of extra hours on nights and weekends, week after week for over 2 years to get there.
Just within the last year have all the real estate investments that I have been making for the last 15 years started to actually put some money in my pocket.
I’m still at the point where I am working 60 hour weeks just about every week. I am still climbing up the hill.
But, the good news is I can see the crest and I know that if I keep pushing down on those pedals, I’ll reach the peak from where I can coast down.
Don’t buy into the idea that there is someway to get around hard work.
Stop running away from hard work and start embracing it. I’ve learned from experience that it takes much more effort overall to avoid hard work than it does to do it, and avoiding hard work engenders no benefits long term or short.
Make the right sacrifices.
Don’t sacrifice your marriage or family in order to get ahead. In the end, it will put you behind. Remember, there is no more costly pursuit than divorce.
Make time to be with your spouse, set aside time to play with the kids every day, if you have them. Take a day off to have a family day.
Instead, sacrifice from this list:
- Watching TV
- Hanging out with friends
- Playing games
- Goofing around
- Browsing the web
Yeah, it might suck for awhile, but if you want to climb that hill now, so that you can cruise down it later, you are going to have to make some sacrifices.
Don’t waste your time.
Here is a list of things I don’t do:
- Cut my own lawn
- Wash my car
- Clean my house
- Any kind of home improvement work
I pay for these things and instead spend that time—not sitting on the couch watching TV—but working hard at what I do best. Working at doing things that will generate me more money than it will cost me to pay someone else to do the other things I mentioned in this list.
I use a service called Fancy Hands to handle many of the time consuming tasks I can delegate out. I have saved tons of time and money by using that service. (Disclosure: that link is my referral link to that site.)
Every time I am doing something, I ask myself if I should be paying someone else to do this. And if your time is escaping you completely, start tracking it.
Lighten your load.
Want to make it easier to pedal a bike up a hill?
Good, all you have to do is carry less stuff with you.
This means, get your expenses down. Start being smart with your money.
Pay off debts, don’t go into debt. Don’t be pennywise and pound foolish, but at the same time learn to live on less.
If you learn to live on 2k a month, guess how much you need to live? That’s right 2k.
If you have saddled yourself with debt and expenses that make it so you need 10k a month to live, you are going to have to pedal a lot harder… just saying.
(If you want to read a good book that helps you learn this mindset, read Rich Dad Poor Dad by Robert T. Kiyosaki.)
It all comes down to this
Be willing to work hard now in order to have a better, more relaxed tomorrow.
Don’t try to take shortcuts or get rich quick, those roads lead to disaster and wasted time.
Instead, if you are working a full time job now for someone else, give yourself 10 hours a week of “your time,” where you work for yourself.
Put in the time now to build that business on the side. Make that sacrifice for 2 years or 5 years or however long it takes to get your bike pushed up that hill.
Don’t give up, don’t be afraid to work hard, and don’t be sucked in by any preacher that preaches a fast way to riches and leisure by doing less.
Remember, those who show up everyday eventually beat out both the faster and the smarter.
I always hear the advice that we should tackle hard problems first.
It seems like pretty legitimate advice, and many of the reasons for saying so make sense, at least at a surface level.
The reasoning usually revolves around the idea that by tackling the hard problems first you can eliminate your biggest risk early and everything will be smooth sailing from there.
When you really think about the reasoning for solving hard problems first though, most of it is not actually reasoning, but based of off one emotion… fear.
We tend to think it is best to solve hard problems first, because we are thinking about eliminating our fear, not because we are thinking about what approach has the highest chance of success or is the most optimal.
I call this FDD, or Fear Driven Development.
And when I think about it that way, I find myself hard pressed to find a real good reason for tackling hard problems first besides being able to abort early. Which, in some cases might be good, but I’d rather focus on success.
Here are 7 reasons why it might be a good idea to tackle the hard problems last instead of first.
1. Solving easy problems first gives you momentum
When a large ball starts rolling down a hill, it picks up speed rapidly and that large ball can bust through many barriers that it couldn’t before, simply because of one thing it has after rolling down a hill that it didn’t have before—momentum.
On the converse, trying to push a heavy ball up a hill is pretty hard. And if there are barriers on the way to the top of the hill, not only do you have to fight gravity, but you have to be able to push extra hard to get through those barriers.
Life is hard enough, why make it harder?
I recently received an email from a developer that was concerned that his team wasn’t gelling and that they didn’t have the expertise in the technology needed to solve the complicated problem ahead of them.
They were going to start the project by trying to integrate this fairly complex technology and he was afraid that it would cause them a large delay before they would be able to get version 1 out.
Start with your simple problems; get working software out there as soon as possible. Not only will the team gel much more easily as they are having success and making real progress, but that momentum will help them when it is time to solve the more difficult problem.
Even if they have to throw the first version away, when they get to the hard problem, the momentum alone will make them much more likely to reach success in the end.
I could give 100 examples of how solving easy problems to gain momentum can benefit you, but you probably already know intrinsically that this is true.
Long story short, get a running start before taking a big leap.
2. Avoid solving the wrong problem
The big problem with solving the hard problems first is that the hard problems usually require a large amount of context in order to fully understand them.
It is very hard to get the right context for a hard problem when we take it out of its natural order of progression and artificially cut it to the front of the line.
You’d probably like to start a college class by taking the final exam first, so you don’t have to worry about it, but the problem with doing so is that you’ll lack the context and information to understand the questions and to know the answers.
When we try to tackle problems out of order to avoid leaving the hard problems to the end, we end up losing all of the learning and context that would help us to solve the hard problems at the end and we are much much more likely to end up solving the wrong problem, which is a complete waste of time.
3. Someone else may solve the problem for you
Sometimes procrastination is a good thing.
Sometimes, when you purposely push off solving a hard problem till the end, you end up finding that someone else already solved your problem.
I spent a few minutes trying to troubleshoot it, but nothing I was trying was working, so I had to make a decision.
I had 3 choices:
- Keep trying to solve this hard problem before moving on.
- Go on and do other videos and send off a support request to see if they could handle it.
- Make a new project and re-edit all the clips.
Choices 1 and 3 involved tackling a hard problem right then and there.
Choice 2 was to tackle easy problems and see if support could solve my hard problem for me, and if not, I would solve it at the end.
I ended up choosing option 2 and it paid off. It turned out Camtasia support was able to solve my problem. By the time I needed the project to complete my course, they had solved my hard problem for me and I didn’t waste any time upfront trying to tackle it myself.
Now it could have worked out differently; I might have had to solve the problem myself at the end, but instead of assuming I would have to and wasting perhaps a day or 2, trying to solve the problem myself, I pushed it off and kept working on easy problems and I gave someone else a chance to solve my hard problem for me.
It doesn’t happen all the time, but many times if we push off the hard problems we face, we find that by the time we get to them, someone else has already solved the problem for us.
4. Your own subconscious mind may solve the problem
When I said someone else might solve the problem for you, that someone else might actually by you—at least your subconscious mind.
Have you ever had the experience of thinking about a problem and not being able to figure it out, but then you wake up the next morning and suddenly have the answer?
It seems that our subconscious mind is more powerful than we are aware of.
In many cases, if we know of the hard problem we need to solve and have thought about it a little bit, our subconscious mind will start working on the solution, even though we are not aware.
Obviously this isn’t going to work all the time, and your subconscious mind isn’t going to write a bunch of code for you, but in many cases there is at least some benefit to throwing the problem off to our internal “worker thread.”
5. You are more committed to solving the hard problem when you risk everything you do so far
One benefit to saving the hard problem for last is that you have some extra motivation in the form of loss aversion.
We can use this knowledge to our advantage by doing the easy work first and letting our loss aversion help motivate us to solve the harder problems, because we don’t want to lose all the work we put into a project so far.
By starting with easy problem, we put some “skin in the game.”
If we try to solve the hard problems first, we have nothing to lose, so we are much more likely to give up.
6. Hard problems are often easy problems bundled together
And it turns out that many hard problems (not all) are decomposable into many small easy problems.
If you strive to never solve hard problems and to always push them off, you may actually find out that you never have to solve hard problems.
Many times we can chip away at hard problems, by taking bits of them off a little at a time and solving those easier problems. Eventually, you may find that you’ve reached the tootsie roll center of your hard problem lollipop and it is filled with chocolate candy!
Now, some problems aren’t very easily decomposable, but a good majority of problems are. Once you develop the skills to chip off bits of hard problems into smaller easy problems, the world looks like a much more conquerable place.
So, saving hard problems for last and breaking off little pieces of them as you go, can be a good strategy to help you to wear down your opponent before you have to face him.
7. Some hard problems are never truly solved
One of the big problems with tackling the hard problems first is that they tend to fill up as much time as you’ll give them.
If I give you an easy problem, like write a function to reverse a string, there isn’t much to think about. You can solve it a number of different ways and there isn’t a huge difference in the efficiency of the different methods of solving it. It is pretty unlikely you’ll spend weeks revamping your solution and thinking that it’s not quite right.
But, if I give you a problem like, create an in-memory database, not only is it a hard problem, but it has a huge number of possible solutions and can be optimized from now until the end of time. You could spend 2 weeks working on that task or 2 years.
The problem is that many hard problems don’t have a good scope to them when they are solved in isolation.
If you design an engine for a car that isn’t built yet, you won’t know when you are done.
But if you design an engine for a car and you know how much it weighs and know what kind of transmission it will use and what kind of fuel efficiency it needs to have, you can have a much clearer understanding of when your engine design is done.
If you save the hard problems for last, the scope of those hard problems will be much more defined, which will keep you from wasting valuable time over solving a problem or, like I mentioned earlier, solving the wrong problem altogether.
With the vast array of technology, language and platform choices available today, it can be very difficult to figure out where to best invest time in training your skills as a software developer.
I’m often asked advice on how to be a better programmer.
Most often the question someone asks is based on whether or not they should invest their time in a particular programming language or technology versus another.
I’ve been giving this quite a bit of thought lately and I’ve come up with what I think are the most important and timeless skills that a software developer can attain which will give them the best career opportunities and make them the most effective.
Skill 1: Solving Problems
I’ve talked about the need to learn how to solve problems before and I’ve even given some steps of how to learn to solve problems, because I believe this skill is critical to any software developer.
Software development is 100% about solving problems.
Without problems there wouldn’t be a need for software.
All software is designed to solve some user problem and within that general solution is a wide array of smaller problems that make it up.
It really doesn’t matter what programming language or technology you use, if you can’t solve problems, you won’t be very good at developing software.
It is amazing how bad most developers are at solving problems.
I constantly hear complaints about job interviews that are too hard because they ask the developer to solve some difficult problem.
I’ve talked about why hard interviews are good and part of the reason is because they test a developer’s ability to solve problems.
I know that many developers still disagree with me about this point and don’t see why a site like TopCoder would improve their development skills so much, but I know from personal experience that it was the practice of solving problems on TopCoder that was the turning point in my career.
Think about a carpenter. If you want be a successful carpenter, you should probably be good at cutting wood. You should probably have practiced doing all kinds of cuts and using many different tools to cut wood.
It doesn’t matter how many years experience in carpentry you have had or how well you can design furniture or cabinetry if every time you try to cut wood you struggle with making the cuts.
Cutting wood is a base skill of carpentry, just like problem solving is the base skill of software development.
Skill 2: Teaching Yourself
There is probably no more important skill in life than learning to learn.
This skill is especially important in software development, because no field I know of changes more rapidly than software development.
You can’t know everything about everything. You can’t even really invest the time it takes to be a master of one particular framework or technology—things are moving way too fast!
Instead you need the ability to quickly acquire the knowledge you need for the task at hand.
If you truly want to have a skill that will propel you through your software development career, learn how to teach yourself.
The only way to develop this skill is to put it into use. Go out and learn a new programming language or technology, even if you think you’ll never use it. You’ll be surprised how quickly you may be able to pick it up because of the foundation you will already have in what you know.
If you can quickly adapt to the rapidly changing software development market and technologies and platforms associated with it, you will have skills that will always be in demand.
Although I am a bit skeptical of some of Tim Ferris’s claims, he has an excellent book called the 4-Hour Chef which has some great techniques about how to learn things rapidly. (I was wanting to write a book about this very subject.)
Skill 3: Naming
When people ask me what I do all day, I mostly say “read things other people name and name things.”
Ok, no one really asks me that and I wouldn’t really answer it that way, but I certainly could.
Software development is all about describing the metaphysical. Most of what we are building can’t be seen.
We have to construct in our minds an entire world with authorization managers taking authorization requests and spitting out authorization response alongside user repositories using user factories to assemble new users.
Every time you are writing code you are naming things. When you read code that you or someone else has written, you are gaining most of your understanding about that code from the names of things in that code.
Most of the time I can accurately predict a developer’s skill level by looking at how they have named methods, variables and classes in code they have written.
A developer who lacks the ability to give good names to concepts and data in their code is like a mute translator. It doesn’t matter if you can understand something, if you can’t adequately explain it, the moment it leaves your head it is gone.
The best way to improve this skill is to always put it into practice. I’ll often rename things in code I am just reading to get an understanding. As I start to understand what a method is doing, I’ll change the name to match that understanding. I’ll do this while I am reading the code, not even making any logic changes to it.
The more you focus on giving good names to things, the better at it you will become.
This is also the most visible thing about your code. It is hard to know if your code is correct or efficient by looking at it, but if I read it and can understand it, I am going to assume you know what you are doing.
Skill 4: Dealing with People
I list this as last, but in many cases you could say it is the first or most important skill.
Everywhere you go there are people.
Unless you work alone and develop software just for yourself, other people are going to influence your career as a software developer.
I’ve talked about why you might not want to criticize someone else before, but there is much more to dealing with people than not pissing them off.
I always go back to the famous book by Dale Carnegie, “How to Win Friends and Influence People,” because this book is so important in learning how to be a successful human being.
I’ve said it before, but if you want to develop people skills, read this book!
The basic problem is that humans are not logical creatures, we are emotional ones. Sure, we like to pride ourselves on our ability to reason, but the reality is that most decisions we make are more influenced by emotion than reason.
What this means for you as a software developer is that unless you can effectively deal with other developers, managers, and even customers, you will constantly face trouble despite how good your ideas are or how valuable your skills are.
Being active and involved in the software development community in general can also help you immensely in your career. It is not just about networking, but getting your name out there and building good Karma.
Doing this successfully hinges directly on your ability to deal with people. (Want to take a big shortcut in learning how to deal with people? It’s simple. Be nice!)
What about practical skills?
Notice I didn’t include anything in my list about a particular technology or even as broad a skill as web development or mobile development?
It is certainly important to have a solid foundation in a couple of technology areas, but what those areas are is not nearly as important as the 4 skills I mention above.
If you can solve problems, learn things quickly, name things well and deal with people, you will have a much greater level of success in the long run than you will in specializing in any particular technology.
With that said, of course it is important to thoroughly learn a programming language or two and to have a general area of specialization, but as long as you don’t go too far off the beaten path with those choices and you focus on these 4 important skills, you will be ok. (You could even learn C++ )
Quick side note: if you are stopping here reading this post, you are probably the kind of developer that cares about your career. I’m putting together a complete package full of information on how to really boost you software development career and increase your earning potential. It is only available for preorder right now. I’m only going to be selling it at this heavily discounted price for a short time. I’ll also have some exclusive interview with famous software developers like Bob Martin, Jon Skeet, and Jeff Atwood sharing their secrets to their success.
I was reading an interesting study last week about how willpower seems to grow like a muscle. In the study they had found that subjects that had successfully stuck to a diet program performed better in many other areas of their life as well.
This study seemed to indicate that by having success in one area of life requiring willpower that a person would gain benefits in other willpower related areas of life such as working out, controlling temper, studying and/or working.
Basically as people trained their willpower it grew in capacity.
This study got me thinking about how all kinds of seemingly unrelated skills tend to aid us in tasks that don’t directly use them.
Digging a little deeper
So what do I mean by this?
I mean that if you learn C#, you will be able to learn Java faster. Essentially you’ll never have to be a beginner at Java.
Now that might not be any big revelation to you. The languages are pretty close already in syntax, but I have found this principal extends much further than that.
In the years that I have been doing software development I’ve had the opportunity to work with many developers who started out their careers in totally unrelated fields.
I found that many of those developers who had significant experience in another field, but then switched to software development, very quickly acquired the skills required to become successful in software development.
I found that within about 3 years, many of those developers had the skill and knowledge equivalence of a developer that might have been in the field for 10 or more years.
Everything is the same
I’ve always been surprised by this phenomenon, but never really thought about why this was true.
I’ve worked with many different programming languages, technologies and platforms and I’ve made a pretty good study of other fields like real estate investment and options trading. I’m constantly finding skills and knowledge I acquired in one area of interest are boosting my abilities in other areas and I finally think I know why.
There really isn’t that much variation in the very basic principles of reality. Essentially everything fits into a handful of molds at a very fundamental level.
The same kind of basic principles that define the pricing of options contracts on securities like stocks are the same basic principles that define the trade-off between time, scope and quality in software development.
At a deeper even more fundamental level you could say that a person that has learned how to work within and understand the relationships between constraints will find that skill is unconsciously applied to a thousand other areas of life which also have defined and real constraints.
Of course in software development itself we recognize many of these similarities as patterns. What most developers don’t realize though is that patterns are natural emergences of ways to solve problems that organically occur in some form or other. The book on patterns just formalizes these patterns.
If you’ve ever heard the term Polymath before (basically a master of multiple skills or areas of study), this tends to explain why Polymaths like Leonardo da Vinci and Michelangelo were able to accomplish so much in so many areas.
Knowing what you don’t know
Another major reason why you are only a beginner once is because once you’ve been a beginner you have a better idea of what you don’t know.
When you start out as a beginner in something one of the biggest hurdles to success is finding out what you need to learn. (Which is why I often recommend starting off by scoping a subject.)
If you were just starting out in programming and had no prior experience in with any type of related skill, you wouldn’t know to ask what kind of looping structures are available in C#, because you wouldn’t even know to ask that question.
On the other hand, if you have experience in just one programming language, you will have a whole array of questions which you can ask about that language, because you can relate it to concepts you already understand. Often when I teach, I try to do exactly that. I try to find something that I think you are already familiar with and relate the new concept to a well understood domain.
If you’ve learned quite a few different technologies and programming platforms, when you try to learn a new one, you’ll know what you don’t know and that will make the whole learning process much quicker.
What this means to you and me
As software developers this is great news, because the world of technology just keeps getting bigger and bigger.
It is very difficult to keep up with all the different technologies that are constantly coming out every year—it is an almost impossible task.
But fortunately we can apply this principle to our craft and realize that skills we acquire in one area of software development will help us to never have to be a beginner in other technologies and development platforms.
The key to unlocking this potential is twofold.
- Push through the surface to see the similarities. Often starting out with a new technology everything seems new, but I’ve found that if you don’t give up, and you push a little further you end up in familiar territory.
- Constantly make the shift between technologies in order to maximize the benefit. I’ve also found that shifting between technologies and even development languages tends to help us to unlock the ability to see things at a more fundamental level. Think about the inductive reasoning where you might start out with 1 instance of a thing, then 2, then 3, then you generalize to n.
This is why it is so important to learn how to learn. The more you learn, the easier to becomes to learn and the more synergistic the skills you acquire become.
So if you’ve been afraid to dive into a new technology because you are either afraid that you won’t be able to learn it quickly enough or that it will be a waste of time because it is unrelated to technologies you actually use, don’t be. Instead try to remember that even though something new might be intimidating at first, you’ll most likely have a head start, because you are only a beginner once.
Let me ask you a question.
How would you develop your next software project if I told you that if you “succeeded” you would be given $1 million dollars, but if you failed you would get nothing?
Success of course is a very fuzzy term, but let’s assume that success means:
- You built a working functional product
- Your customers are happy with it, content enough to call it done
- You delivered it on time
- You delivered it within budget
- It can be fairly easily modified and maintained with its current design for the next 5 years.
This is an all or nothing proposition. Everything is on the line. If you were to succeed, you would be rewarded handsomely, but if you fail, your effort would be entirely wasted.
Oh, also, you can’t work more than 8 hours a day 5 days a week—no winning by heroics alone.
Why ask this question?
Simple, because after thinking about “how to build software” for the last 10 or so years, (in my beginning years, I didn’t really ponder this question) I have decided the answer to this question is the way that software should be built.
I don’t mean that developers should be given an all or nothing proposition. What I mean is that we should be building and designing software as if I proposed the above situation.
This might sound a bit crazy, but think about it for a bit.
Most developers today are paid a salary. Some salaries have bonuses attached for performance, but rarely are we put in a situation where making mistakes or not being as efficient as possible results in dire consequences. The worst that can happen in most cases is that we would get paid for the work we did and then be looking for a new job at the end of the project.
Losing all the time we put into the project and losing out on an opportunity to make a million dollars would be some consequence.
We’d think about software development quite differently
It’s really hard for me to answer the question of whether or not practices like TDD are worth it. I mean sure, I tell my manager it is. I emphasize quality over speed. I say we need to do this or that, but honestly I don’t really know.
I’ve never been put to the test.
No one has ever said to me, “succeed or die.”
No one has ever put the consequences of my choices directly in my own hands.
Never have I actually had to weigh the weight of extra time spent refactoring code, writing unit tests or using an ORM instead of writing SQL directly in my source code.
I choose technologies because they seem good to me or it seems like they’ll help me get things done faster, but I am never really staking much on that choice.
Sure, I may be staking my reputation, or I might lose my job, but chances are I’ll just blame some failure on some other reason or worse yet, I won’t even recognize my failure, because it will be disguised by “good enough.”
“Man, John, you are a big fraudulent a-hole! I can’t believe you go around touting to know stuff, leading people down paths that you yourself don’t even know are correct. Burning up other people’s money in your test lab of software development.”
Maybe it’s true. Maybe I am a big ignorant and arrogant jerk, but somehow I feel that I am not alone.
I’m not saying we don’t or shouldn’t have strong convictions.
I’m not saying that we don’t have good reason to believe the development methodologies and practices we suggest and follow are correct.
What I am saying is…
Our beliefs about software development are mostly theoretical
8 years ago I would have told you that you needed to create UML diagrams before you write any code.
5 years ago I would have probably emphasized the importance of always having an XML schema. I would have told you data without schema is meaningless.
I don’t hold either of those views today.
Perhaps you’ve changed your views in the past few years as well?
The point is that even though we may be down in the trenches doing software development and to some degree finding out what works and what doesn’t, we are basing the results on OUR motivations not the motivations of our customers or our employers.
So, we may eventually get good at making things easier for ourselves, but unless your feet are held to the fire, you’ll never really optimize for building the best software as efficiently as possible.
If you think you already are focusing on building the best software as efficiently as possible and I am just full of crap and you don’t operate that way, I would strongly suggest doing a thorough self-check and also please tell me the secret of the most efficient way to build software, because I definitely want to know.
What about startups or open source projects?
You might be tempted to think that working for yourself or not for money at all would change things, but I’m really not sure that is the case.
I’ve worked on plenty of my own software projects where my fate was directly in my hands.
I’ve built applications like PaceMaker where my financial success with the endeavor was directly tied my own efforts and my efforts alone.
But, do I think I built PaceMaker as efficiently as possible?
No, definitely not!
The problem with PaceMaker and other projects where there is a big potential upside, is that the upside potential is not guaranteed.
I can assure you that if someone said to me that I have 6 months to build PaceMaker and if I succeeded (according to the rules I stated above) that I would be given $1 million dollars, but if I failed I would be given nothing, I would have probably gone about the whole process an entirely different way.
I’m not saying I would have built it with perfect efficiency, but my motivations would have entirely matched up with the footprint of building software as perfectly as possible.
What I mean by this is that I would be trying as hard as I could to do what I absolutely believed was mostly likely to benefit me, and by doing so I would be trying as hard as possible to completely optimize the process of building that software.
What can we do about this?
Now I can’t tell you how I would have built PaceMaker had I been given the million dollar challenge.
There is no way that I could objectively put myself into that situation and give you an answer.
Would I have bothered with unit tests? Would I have have created backlogs and written UATs to make sure they pass? Would I have used an IoC container?
The plain and honest answer is, I don’t know. All I know is that I would have done things differently and on any software project you’ve worked on, you probably would also.
There are a few things we can gather from thinking about this hypothetical proposition.
- Don’t think you know the answer, but at the same time have convictions about what you currently believe. Just hold on to those convictions loosely.
- Even though you can’t realistically be completely objective and build software as if someone was going to pay you 1 million dollars (just like you can’t tickle yourself) you can still try to think as much as possible with this mindset. It is a worthwhile exercise to imagine as if the decisions you are making and the convictions you are holding onto are based on idealism or reality. We could also all examine and at least understand our own motivations.
- Recognize others are in the exact same boat you are. Don’t believe everything an expert says or even believe there are experts. Experience and wisdom count for something, but no one has anywhere close to all the answers.
I’d love to see this experiment actually played out. I’d really be curious to see what the outcome was, especially in a team situation.
Perhaps someday, someone will actually conduct this experiment and share the results.
What about you? How do you think being given the million dollar challenge would change the way you develop software?