Big Swinging Developer

Don't Do What You Should

"What should I do?" is another question I hear a lot, especially from the people I manage.  It gets phrased differently sometimes:

• What would you like me to do?
• How would you like this done?
• How should this be done?
• How should it work?
• Etc.

This may be the most value-robbing question ever.  It essentially turns an opportunity to show who you are and what you can do into nothing more than a task to be completed.  Asking what should be done is, essentially, asking someone to design the solution to the problem that you've been assigned.  When I run a team, I want my team members to design (and implement) the solution.  One of my management mantras is, "Bring me options and ask for a decision".

I can hear the naysayers now: "But Jay, not everyone who reports to me can design the solutions to the problems we have."

Oy.

I'm not suggesting that your only options are what your team brings you, I'm suggesting that before they ask for help they demonstrate an attempt at solving the problem.  This is how you build design skills: You practice and you find out where you're wrong.  Eventually you get to the point that your designs are accepted by your manager consistently and you get to move up a notch.  Without that practice, though, you'll remain stuck where you are.

So instead of finding out (and doing) what you should do, do what you can.  Present options to whoever needs to make the decision and if the options are unacceptable, then ask for help.  Look for the growth opportunity in everything you do and you'll be amazed at how quickly you grow.

Working Hard Isn't Smart

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.

Walking The Walk

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.

The Interview Questions I Ask

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!

The Developer & The Toy Store - Part 1

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.

3 Words That Guarantee Success

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.

What To Do When You F Up Big Time

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.

Brownfield Development: How To Peel The Onion Without The Tears

In the Spring of 2008, I decided to become a brownfield development specialist.  Greenfield development is when you're starting a project from scratch and get to design everything with only minimal constraints.  Brownfield development is the opposite of that: it's when a project is n months into development and most of the constraints have been cast in stone.  My guess is that if you were to ask every developer you know whether they'd prefer to work on a greenfield project or a brownfield project that they'd all say greenfield.  Heck, I'd bet that a quarter of them would laugh so hard that Red Bull shot out of their nose just at being asked the question.  Therein lies one of the secrets of becoming a Big Swinging Developer:

You can make money being good at things that other people hate to do.  A lot of money.

When people hate to do something, they don't do it very much.  Since they don't do much of it, they never get particularly good at it.  This makes it harder for them to do it and the cycle starts all over again.  Some common values of "it" for development include: writing tests, documentation, and creating installers.  You can safely add brownfield development to the list since a job description of "Support the big ball of mess that runs our business while adding features and fixing bugs" doesn't usually have folks banging down your door. Throw in the fact that you'll have no relevant documentation and few, if any, tests to guide your way and you can picture weeks of pestering your co-workers with questions just to get to the point where you can fix a simple defect.

But what if brownfield was easy for you? What if, rather than pestering your co-workers with basic questions, you could understand what the code was doing and then ask why it was doing things that way rather than asking what it actually does?  That's what my secret weapon, Visustin, gives you.  You paste in your source code and it'll generate a flowchart for you:

It supports 31 languages including the popular .NET, open source, and SQL variants.  I spent last week throwing hundreds of lines of Python into the tool and tracing through an incredibly complex financial trading system to learn how portfolio valuation is calculated.  I was able to correctly describe the process to my team lead, including a couple gotchas buried in the code even though I don't know Python.  Since I know how the system works, though, I can find the path the code will take and identify where problems are likely to occur while coming up to speed on the language at night.

If you're a developer, I'd highly recommend Visustin.  It's great for code reviews, documentation, and for diving into existing systems.  Developer or not, look around your industry and find the important things that no one wants to do because there's a real opportunity there.  You can become better (or more tolerant) than anyone else simply by identifying the key aspects to the unpleasantness and solving that problem first.

First-Rate Companies Have First-Rate Systems

This may surprise you, but when I say "First-Rate Systems", I'm not talking about computers.  When you think about it, a company is simply "the way a group of people does things".  The restaurant down the street is just a group of people making burgers and hot dogs in a delicious and unusual way.  Apple is a group of people designing, building, pricing, and selling their wares.
    Sometimes these systems are well defined in manuals, training, and software.  Sometimes the systems are ad-hoc for better or worse.  As consumers, we love to complain about bad systems which usually manifest themselves as the combination of a stupid policy and an inflexible customer service rep.  We also love great systems, but we rarely notice them as such.  Instead, we like shopping at certain stores or eating at certain restaurants or using certain services.
    If you're starting a company, you need to give serious thought to your systems.  You can typically get away with a blanket statement of, "Make the customer happy" and then refine over time.  If you're joining a company, experience your new employer as a customer while you're still new and systems failures will stand out . . . hopefully so that you can fix them.
    The above may sound obvious and/or a regurgitation of the standard "Be outstanding!" marketing advice you see spouted constantly, but it's all a lead up to the main point of this post:

When you find a second-rate system that the company won't fix, you know that you're not dealing with a first-rate company and you need to stop treating them as such.

Not everyone has the fortitude to be great.  Arguably, most settle for "good enough".  That's why you end up with the dry cleaner that smashes your buttons and doesn't notice before you do.  That's why you have the recruiting company that requires you to enter time in the client's accounting system and their own system even though they literally employee 1,000 people who are qualified to build the integration between the two.  That's why you have Comcast.
    As you might imagine, I'm particularly attuned to (and offended by) bad systems since I spend my days getting paid well to help clients build software to support great systems.  These systems are typically great before the software ever exists, they're simply executed through brute force and the client wants to replace that human effort with software so that people can get back to work.  The important aspect is the commitment for the system to be great - that's what leads to a first-rate company.  You'll save yourself a lot of headaches if you learn to identify second-rate companies and accept them as such (or move on to a first-rate replacement) and if you see yourself as first-rate then make sure your company is as well.

Partner is a Verb

At the beginning of the year, I wrote about my career-changing resolution.  It's not the only revelation that's affected my career, however.  One of the other big ones is that partnering is really important, but it takes effort to make it work.

Let's face it, you need help.  In some way, shape, or form, you need others to work with you to accomplish something bigger than you can do by yourself.  One way to accomplish that is to pay them.  Once you make it big (or if you raise money), then you can pay someone to do what you want.  Before you reach that point, though, your best bet is to partner with others.

Designing a partnership is easy: you identify a set of mutual goals and a division of labor and you're ready.  It could be a developer who needs some design work, a consultant that needs some development work, or whatever.  The key to the design is to make the payoff greater than the opportunity cost of the work.  Design is easy because it's pretty objective: If you do x, you get y.

Implementing a partnership is really, really hard because it's very subjective.  The problem is that people don't simply work, they work with other people.  That means that in order to partner, they have to both trust and, to some degree, like you.  Not just like you, but like the way that you work, which means that they need to see how you work, which means: work.  Even if you design what you think is a brilliant partnering arrangement, if the others involved don't like the way you work they might just walk because they don't believe that if they do x then they'll actually get y.

I saw a perfect example this morning.  I had a meeting with a company that I'm partnering with.  We had discussed the project in February and even though I had worked on it a little, there was a chance of it stalling.  That didn't happen, though, because they put forth the effort of scheduling a meeting to keep things moving along.  During the meeting, they asked a few times, "What do we need to do to make this happen?"  This clear indication that they were putting forth the effort necessary to move things along reinforced my belief and enthusiasm in the project and with them.  My plan now is to follow suit and reinforce their belief and enthusiasm in the project and me.

My point in all of this is that it is easy to fall into the trap of identifying and designing partnering opportunities only to see them wither on the vine.  No matter how jazzed you are after your first meeting, it still takes effort to maintain your momentum so you should be ready to put forth that effort if you ever want to capitalize on the opportunities that you've created.