As you look to 2017, you can pretty easily add $10,000 to your income. Here’s the math:
Salaried Employess
$10,000 = $5/hr more than your current hourly rate. (divide your salary by 2,000 for a quick hourly rate)
Entry-Level Freelance
If you’re making $20 – $25 per hour, then you need between 400 and 500 extra hours next year. This is 8 to 10 extra hours per week. An extra hour per day, plus 3 – 5 hours on Saturday morning will do it. Not only that, but the extra time you put in should move you up to a mid-level freelancer.
Mid-Level Freelance
If you’re making $30 – $50 per hour, then you need between 200 and 350 extra hours next year. This is 4 to 7 extra hours per week. An extra hour per day Monday -Thursday and a few hours on Saturday will do it.
Senior Freelance
If you’re making $50 – $100 per hour, then you need between 100 and 170 extra hours next year. This is 2 to 4 extra hours per week.
Above $100/hour
If you’re making more than $100 per hour, chances are that you’ve built a system of work where adding more time isn’t going to move your income needle enough to offset the loss of free time and big thoughts.
The lesson here is twofold: first, the extra money is easily within grasp if you spread out the effort through the whole year. Secondly, working on your value (aka your rate) will give you more leverage than simply throwing additional hours into work. If you’re early in your career then put in the time, collect the extra money, invest in yourself, and learn as much as you can. By accelerating your experience with the extra time, you’ll hit mid and senior levels earlier and find compounded returns later in your career.
This blog is all about going from being a good programmer to a highly paid developer. I spend a lot of time talking about the techniques I've used in my career, but I haven't said anything about the effects. This seems like a good time fill the gap since I'm changing jobs on Monday. The change represents the positive outcome of a lot of what I've done and gives me a chance to talk about some aspects of managing your career.
Managing Your Career Is Your Responsibility
I can't emphasize this enough. I've seen so many people fall short of their potential and feel victimized when their manager didn't move them along their desired path. Hear me now and believe me later: nobody will ever be more motivated than you to advance your career. Which means that if you're not particularly motivated to advance your career then you'll probably fall far short of your potential. If you've never given much thought to career management, then there's only one word you really need to know: Alignment. Figure out where you want to be and what you want to do, map a path, and then constantly align your goals with those of your manager.
Leave On Your Own Schedule, But Always On Good Terms
My career is a little more actively managed than others. I'm continuously measuring where I am and what I'm doing against other opportunities. I try to keep what I'm working on clean enough that I could finish in a couple of weeks, if need be. This has several benefits. For example, I tend to work in small, defined chunks that are easy to manage and measure. I avoid going down the deep rabbit holes that trap so many other developers — if a developer ever tells you that they want to "rip out the entire persistence layer and rewrite it" on their 3rd day (or even their 3rd month), then chances are you've got a rabbit hunter. This also allows my manager to easily rearrange my priorities as his change. Something big pops up and who is he going to redirect to it, the guy who is a month in to a 3 month coding odyssey or the guy who can wrap things up in a day or two? This is really important, because it's critical that your manager does not feel like you've left him hanging when you leave. It's great if they are disappointed that you won't be around any more, but if they are angry then you've probably done something wrong. Also note that you should be leaving for an understandable reason. This means that simply going somewhere else for more money is a bad idea. If you feel underpaid then you should be able to negotiate an increase where you are. If that fails and you presented your case well, then your manager will not be surprised when you leave for more money. A couple of good reasons to leave are: You're in the wrong place (i.e. alignment is impossible), or you've gotten an opportunity that simply doesn't exist in your current environment (i.e. a jump in leadership that would only happen somewhere else). If done well, your manager will be glad you were there for the time you were and you've just added a person to the list of people who may call you with one of those aforementioned great opportunities sometime in the future.
So How Did This Happen To Me?
My story is combination of all of the above. The number one reason why I'm changing jobs is that I'm in the wrong place. The job I'm in was about to require far more Python work than I could stomach. NOTE: This has nothing to do with Python, it's a fine language but it's not the one I want to work in. This meant that alignment was going to be impossible. At the same time, a former manager had started in a new job and since we'd kept in touch he told me that there could be a great opportunity there. Since I was in the process of winding down my current cycle of work and getting ready to start the next one, then everything cam together such that I could hash out a deal, give my notice, wrap up my work, and roll to the next big thing. Believe me when I say that great opportunities like this don't come along every day so it's critical to be ready or you won't be able to capitalize on them.
In closing, I'm really happy that I had this job and it's great to be leaving while I still feel that way. I firmly believe that managing my career advancement (and personal happiness) is nobody's job but mine and I'm fortunate to be able to share my experience. As always, feel free to post similar experiences, advice, or questions in the comments.
This post will probably strike you as either common sense or absolute crazy talk. It is especially written for those in the latter group.
I write a lot about working safely. After lots of posts on branching, test environments, kitchen analogies, etc. I'm here to recommend some behaviors for those times when you totally screw up. After all, you may very likely find yourself in an environment without all of the safety nets you want because you were specifically brought in to build the safety nets. I'm going to assume that you messed up while doing the right thing in the wrong way rather than something criminally stupid like, say, encoding your DVD collection to Divx on the production database server because "it has those really fast drives and all that RAM".
First, and foremost, as soon as you realize that you've screwed up, let someone know. Do not be tempted to keep things quiet and fix it before anyone notices. I have yet to see a production issue that didn't get worse with time (and quickly). Keeping things quiet is outright selfish because you're putting your own comfort ahead of the good of the group.
Secondly, fixing your mistake needs to become your top priority. Fixing means not only getting things working again, but getting them back to the way they would have been. Does data need to be re-keyed? It's now your job to re-key it. Do numbers need to be verified? If you're not the one who can do it, be prepared to generate special reports or data dumps to make the job as easy as possible.
Next, take responsibility for your mistakes. Full responsibility. You don't get to say, "I deleted the production website, but the slow restore process is what caused the outage to be so long." Being up the creek without a paddle means that you own the upstream and downstream problems as well.
After things are back to normal, do your own private After Action Review (note: there's a good chance you'll be asked for either a public one or one with your manager). Take this opportunity to learn from what just happened while it's still fresh. For a big enough mistake, you'll probably also reflect on it for a day or two. Having said that, hear me now and believe me later: do not utter the words, "Well it's kind of lucky it happened because…". Even if there's some fantastically beneficial outcome, you don't get to celebrate the effect, you are still responsible for the action.
Lastly, get over it. If you've made the kind of mistake that I'm writing about, it will almost certainly affect you emotionally, mentally, and physically. That's to be understood and will actually help with internalizing the "Don't do that again" lesson. But don't let it affect you too much for too long or you'll kill your productivity. If making a huge mistake makes you skittish to the point that you are no longer a high performing contributor, then things aren't back to normal are they?
As a final thought, while things are at their worst you may start wondering, "Are they going to fire me for this?" I can't answer for certain, but I can tell you this: When I had headcount, I never fired someone for making a mistake . . . and they pulled some doozies. If you do get fired for a blunder that you feel comfortable defending (i.e. Doing the right thing the wrong way), then chances are it wasn't the place for you anyway. The only way you can do truly incredible work is by being willing to take some risks and if your employer squashes any chance of that happening by firing people for mistakes, then you're better off elsewhere. Just don't make a habit of it: it's easy to explain a one-off, but the second time you get fired for f'ing up big time it starts to look like a trend.
The secret to being a Big Swinging Developer is to be a force multiplier; make other people more valuable and you become incredibly valuable. Don't believe me? Which do you think is worth more: improving your own effectiveness by 50%, or improving 10 people's effectiveness by 10%?
There are several ways to improve others' effectiveness: tools, techniques, processes, infrastructure, the list goes on. The most direct way, however, is if you're the manager or team lead. If you've never lead a team before, or are afraid that you're bad at it, here is a dead simple guide to get you started or turn things around.
Step 1: Find out what success looks like for you & your team.
Your team exists for a reason. It's there to build features, or test stuff, or support a system that's in production. Whoever signs your check has a vision for what makes you and your team valuable and what success looks like for you. And if they don't? Easy, you find out elsewhere. There are only 3 ways to provide value to an organization: increase sales/revenue/demand, decrease costs (aka increase efficiency and output), or decrease risks. Your team is responsible for one of these, guaranteed.
Step 2: Determine how each team member can be valuable.
Remember in step one where I said, "Whoever signs your check has a vision for what you valuable"? Well, you're that "whoever" for each of your team members. Even if you don't actually sign their check, you are responsible for knowing what each person can do to be valuable and then communicating that clearly. NOTE: This is the hardest part of management. If you know what someone can do to help out and can communicate that clearly, you have it made.
Step 3: Monitor.
Lack of monitoring is the Heart Disease of management: It kills more teams more quietly than anything else. Even worse, lack of monitoring can look like so many other things. You see, one of the problems with organizations is that they're dynamic. If you're not monitoring what they need, you may find yourself doing what you've always done and unemployed because that's not what's needed anymore. Or you may do what you think is a great job of communicating to your team what you want them to do, but if you don't monitor them and provide course corrections then they could end up working really hard on something that you don't need.
If you put those 3 steps in an infinite loop, you can successfully manage teams for the rest of your career. If you need more supporting evidence, look around where you work for teams who are struggling and you'll probably see lack of monitoring, poor communication, or lack of vision.
That covers the basics of running just about any team. Next time I'll talk about how to build a really kick-ass team.