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.
I've interviewed a few dozen developers in the course of my career and I've finally settled on a few questions that I'm almost certain I'll ask. If I'm going to interview you, consider this a study guide. If you're going to interview someone else, feel free to use the questions as you see fit. If you're going to interview with someone else, you might prep answers to these questions and find a way to slip them in even if the questions aren't asked.
1. Have you ever seen software written well?
I've come to believe that it's difficult to write software well unless you've seen it done well. But be forewarned, this is not a question you can simply answer "yes" to, even though some candidates have tried to do as such. If you tell me "yes", and leave it at that, the follow up will be "What did that look like? What made you feel it was done well?", or any number of variants See, I'm not just looking to find out if you've seen software written well, I'm looking for a sign that you noticed what made it good. People who have noticed good things will also notice the absence of good things. The first time I test drove this question I had a candidate named Khurram whose eyes absolutely lit up as he said, "Oh yes! I was on a project where . . ." and he went on for 5 or 10 minutes about all of the things he'd seen and why they were great and how they helped later. It was an interviewer's dream come true and cemented this as a permanent question on the list.
2. Have you ever been on a bad project?
Once again, you can try to answer "yes", but I'll ask very similar follow up questions: "What were the symptoms? What were the causes? When did you know that things were going South?" and one of my favorites: "What did you do about it?" Chances are you've been on a bad project, but did you pay attention to what was going on around you, or did you mindlessly write code and close tickets? People who have noticed what causes projects to fail are more valuable than those who haven't because they'll recognize the signs of a project that's going in the wrong direction. Even more valuable is having built up a collection of countermeasures, but if you have those then you probably won't be interviewing very often because there'll be a list of people who are trying to hire you.
3. Have you used branches in version control?
I'll admit that I'm a little . . . um . . . hyper-focused on branching and version control. But here's the thing: I can tell so much about where you've worked and how you've worked from this one question. If you say that you have used branches, I'll ask you about your branching strategy and start to learn about how you work by seeing what you protect yourself against. NOTE: Never, ever, try to fake having branched. There are all kinds of problems that are both solved and caused by branching and if you try to fake it, you'll get caught quickly. If you haven't worked in a group that uses branches, then I instantly know that you've never seen a good build process either. I'll know that you either haven't worked on parallel features/fixes or haven't done it safely. Another note: when I get on my branching soap box, it is a prime opportunity to talk about process, but a surprisingly bad time to talk about technology. I'm trying to open the door for you to discuss things being done quickly, safely, and thoughtfully. If you take this opportunity and use it to talk about the latest distributed version control system and how cool it is, you'll hear that door slam closed very quickly.
That's it. Those are the 3 questions I ask in every interview now. Notice that there are no right or wrong answers. There is literally no honest answer that you can give that would cause me to not hire you, although I will use the answers to qualify your experience level. Junior developers can answer "no" to all of the above and still get hired because this may be their first or second gig. Mids need to answer "yes" to at least one, but preferably two of the above. If you call yourself "senior" and can't answer "yes" to all of the above (and preferably have multiple examples) then you're kidding yourself. I don't mind that you're not senior, but I mind a lot that you're kidding yourself. Also note that there are no technical questions on the list. This is for 2 reasons: Technology changes often enough and is specific enough to the project that it doesn't make sense to me to have permanent tech questions. Secondly, and probably most importantly, I tend to work with programmers that are better than me and they usually have the tech portion of the interview covered really well.
As a final thought, keep in mind what an interview is. An interview is a chance to make people want to give you the opportunity to work with them. No one is really going to know what it's like to work with you until you're in the trenches together for a couple of weeks. If you go into an interview with a story to tell and make life easy on the interviewer by answering their questions in long form, with some examples, then they're going to like you. You will give the impression of someone who takes initiative and shares the workload. On the other hand, if information has to be dragged out of you or your answers are unclear then you're going to give the impression of someone who has to be spoon fed tasks and even then not necessarily deliver.
Feel free to add your own favorite interview questions (or the worst ones you've heard) in the comments!
I'm a big fan of analogies. Analogies are the Swiss Army knife of the brain (note: I'm also a fan of recursion). A good analogy gives you a clear mental model of something complicated. This is the first in a series of posts that was inspired by a walk through a toy store where I saw some of my favorite childhood games and for each one thought, "Wow, that game is just like . . . " about some facet of my job.
Jenga
Jenga is a game where you start with a bunch of rectangular blocks stacked in an orderly manner into a tower. The game progresses by each player pulling a block out of the structure and stacking it on top. In this way the tower becomes taller and less stable over time. Sound like any systems you know?
By day I specialize in brownfield development which is like walking into a Jenga game near the end. Actually, it's like walking into a game where most, if not all, of the original players have left because no one wanted to touch the unstable mess in front of them. In Jenga, the one who knocks the tower over loses. There are 2 ways to knock the tower over: by pulling out the wrong piece or by putting the piece in the wrong place. In other words you can lose by removing the wrong thing or adding the wrong thing.
So how do you play well?
To be a good Jenga player you need 2 things: An understanding of the tower's current state and a steady hand. If you ever have the chance to play against a mechanical engineer, civil engineer, or architect (the real kind) then realize that you will most likely be playing on the basis of your steady hand. These folks will look at the structure, see some crazy Beautiful Mind type equations floating around, and pull a piece that you'd never touch. In the same vein, the more you understand about how your current system is built, the better off you'll be when it comes time to remove sections of it.
The steady hand in Jenga is analogous to the work habits of a solid developer. If you're focused, consistent, and just a bit fearful, then you'll probably do better than someone who just adds stuff in willy-nilly.
To take the analogy beyond game play itself, if you do knock the tower over then what you do next is very important. If you quickly reset the game to play again, chances are you get to play again. If you look at the mess, say, "Sucks to be you!", and walk away then it's likely that no one will want to play with you ever again. Also bad: losing a piece.
In short: You can win by taking the time to understand things well, being careful, and cleaning up quickly when things fall apart.
I read a lot about successful people. I also think a lot about people who aren't as successful as they could be. My theory is that if I can determine what makes or breaks success then I can either emulate or eliminate as the case may be. Recently I've become convinced that I've found at least one piece of the puzzle and it has survived back-testing against both the success stories and the group who falls short. The entire concept can be boiled down to 3 words:
Commit and deliver
I originally spent some time thinking that it could be boiled down to 2 words "commit" and "deliver", but it turns out that the "and" is critical. I've worked with lots of people who commit, but then fall short on delivery. These are usually excuse artists who are more adept at explaining away success than they are at pursuing it. The excuse artist won't see non-delivery as failure, they'll just explain how they could never have been expected to deliver . . . despite having committed.
I've also worked with people who deliver, but never commit. I'm sure everyone has worked with folks like this. They're the wafflers, the ones who caveat everything to the point that they cannot be held accountable, they're the ones we often call "slippery". They will, however, sometimes deliver something of value and then never let anyone forget it. These people have entire catalogs of accomplishments in their head, but have never failed and never been wrong. If you think that they have, they'll be quick to point out that in the particular case that you mention they never said they'd deliver, they said they'd try or they'd see what they can do or that it might be possible.
I'm pretty fortunate to have worked with a few people from the final category. The ones who commit and deliver. These folks are great to work with. They say, "I'll do X" and X gets done. Not always as smoothly as originally thought, not always as quickly as originally thought, but it gets done. It gets done without fail. No excuse, no ambiguity about whether or not they're on the hook for delivery, just straightforward "it will be done".
There may be other factors that shape and size your success, but I guarantee that if you simply commit to doing things and then deliver relentlessly that you'll succeed.
which is like walking into a Jenga game near the end. Actually, it's like walking into a game where most, if not all, of the original players have left because no one wanted to touch the unstable mess in front of them. In Jenga, the one who knocks the tower over loses. There are 2 ways to knock the tower over: by pulling out the wrong piece or by putting the piece in the wrong place. In other words you can lose by removing the wrong thing or adding the wrong thing.