There are a handful of techniques that I rely on to make clients happy. Of these techniques, the one that requires almost no thought, no training, and no special skills is to work hard.
It's also the most effective technique that I've ever used.
There are people who are just as successful as I am that don't work nearly as hard. These people are better at what they do than I am at what I do. They are smarter, luckier, or something-ier than I am and I applaud them for it. I choose a simpler path and one that is much more repeatable and transferable: I choose to work really hard when the opportunity presents itself. I think too many people misinterpret the phrase "work smarter, not harder" to mean "don't work hard, figure out how to get things done without much effort". My translation is "work hard, and if a better way becomes apparent then do that . . . but also hard, and just get more done". There's a reason why this is called Big Swinging Developer and not Super Comfortable Developer.
To be clear, "hard" doesn't just mean hours. Sure, there'll be times when nothing but brute force will do and you should be ready to plow through when it's time, but there's more to it than that. Hard work is all about doing the things that others won't. The messy, unpleasant, yet valuable tasks that lie around undone because doing them is unattractive. As I alluded to in a post about brownfield development:
There's money to be made in doing things that others don't want to do. A lot of money.
Go ahead and give it shot. There's bound to be a loose end where you work that's been languishing forever. Attack it. Get it done. Do it in addition to whatever else you were going to do that day or that week. Rinse. Repeat.
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.
Have you ever played Battleship? It's a game where 2 players put their ships on a grid and start guessing coordinates. If you guess a coordinate where your opponent's ship is located, that counts as a hit. Each ship takes up 3, 4, or 5 coordinates and once you've guessed all the coordinates of a ship, it's sunk. The commercial when I was kid had the kid on the losing side exclaim, "You sunk my battleship!". Good times, good times.
This is part 2 in a series. If you have no idea why I'm talking about board games from the 1980's, start with Part 1.
Battleship taught me most of what I need for troubleshooting. I have a bounded set of possibilities, I only get a certain number of attempts, and there's an uncomfortable period during each attempt when something bad may happen to me. When playing Battleship, you can simply guess at random, or you can employ a directed strategy. The same is true in troubleshooting. If you're all over the place, sometimes you'll get lucky and sometimes you'll miss for what seems to be an eternity.
As you're implementing your search strategy, it possible to become too focused. In the game, for example, it makes little sense to test a coordinate immediately adjacent to your previous guess since the ships are at least 3 units long. Better to space out the testing and then "walk it in" by focusing in the surrounding area once you get a hit. The same is true in troubleshooting. If each test run is simply a close variation on the previous hypothesis, you're in for a long night. If, however, you take a wider approach and test based on variations that are reasonably separated, you have a much better chance of getting a hit, and then you can hyper-focus on the surrounding areas.
I seem to recall that Battleship was never as much fun as I thought it should be. When you think about it, there isn't all that much excitement and it doesn't have much to do with the Navy. Troubleshooting: same story. It's one of those things that you do that has its ups and downs, but overall you kind of wish you had done something else instead.
The point here is that when you're confronted by a troubleshooting problem, don't just fire at random and hope that you get a hit. Approach it with a plan, execute, and as you get some success then focus on that area for all it's worth.
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!