I moved from Boise, Idaho to Wesley Chapel, Florida.  One of the main reasons I have been quiet lately has to do with the subject of this post.

About goals

I have heard many people talk about settings goals.  Setting goals is very important, but goals themselves do not ensure success.

Goals give us a way to measure and define success, but not to actually achieve it.

We do have to start with good goals, so let’s talk about what a good goal is.

A good goal is like good done criteria for a backlog.  A good goal is one that is:

• Measurable
• Has a time constraint
• Achievable without being overwhelming
• Sufficiently broken down, (it is a single thing, not a collection of things.)

If you don’t define a good goal, the chances of achieving it go down drastically.  If your goal is not clear cut enough, you may not even be able to tell when it is achieved.

In my world, good goals are things like:

• By Dec 10th I will lose 20 pounds.
• I will read one technical book each month.
• I will create and launch an iPhone application by Nov 15th.

Bad goals are things like:

• I will improve my diet
• I will start lifting weights
• I will improve my SQL skills

Goals aren’t enough

Once you have good goals, you should be good to go right?

Wrong!

How many times have you set good goals that you never achieved?  Always something seems to come up, or the timing isn’t right, etc.

The problem is, life happens.  You have to deal with all kinds of issues you can’t predict, so you don’t end up having the time to achieve your goals.

You usually don’t have anything on the line, so nothing is forcing you to complete the goals.

First let’s talk about the issue of life happening and disrupting you from achieving your goals.

There is a simple solution for this problem…

Make your goals part of your life.  Rarely does life happen to me in such a way that it prevents me from doing things like showering, eating, brushing my teeth or going to work.  (I suppose now that I am down in Florida, a hurricane could happen and cause all that.)  In general though, we operate as humans best on routines.

I have found time and time again that the key to achieving goals is to build them into your daily routine.  Having a routine is critical to being successful.

Don’t believe me?  Think about the biggest losers you know in your life.  You know who I am talking about, that friend from high school that still doesn’t have a real job, sometimes sleeps on your couch, wakes up at noon, etc.

Routine or no routine?

Now think about the most successful people you know.

Routine or no routine?

Routine disruption

Part of the reason my posts stopped for the last few weeks is that I had my routine disrupted.  Back in Idaho before I moved, I had a pretty solid routine, it went something like this:

Every week day: Egg white + Spinach breakfast, Spinach + light soup lunch, Steamed Chicken + vegetable dinner, read 15-30 minutes technical book.

Monday: Lift chest and biceps, do prep work for Pluralsight, cook up chicken for the rest of the week

Tuesday: Run 5k, record for Pluralsight

Wednesday: Lift back and legs, do Android or iPhone app work

Thursday: Run 5k, prep work for Pluralsight

Friday: Lift shoulders and triceps

Saturday: Run 5k, record for Pluralsight and or do Android or iPhone work

Sunday: Write blog post for the week

That was my basic routine.  You can probably figure out my goals just by looking at my routine.

When I moved, this got disrupted, but I am getting back into a routine similar to this one again.  Once a good routine is established, life happens around your routine.

I usually stick with this basic routine and modify it based on the priorities of my goals.  At different points, blogging was a higher priority, so it took up a few more slots.  When I was really focused on getting my Android app done, that took more slots.

When you have a routine, you are making small steps on a regular basis towards your goals.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

• They can’t learn a lesson from someone else
• They can’t take orders from someone else
• They can’t take criticism from someone else

There three qualities together I classify as the “yielding” qualities.

The truth is people don’t like to yield.

We just don’t seem to be built that way.  Often ego tends to get in the way and it causes us to miss opportunities to grow and thrive.

I’ve been pretty guilty of it myself from time to time, especially early in my career. 

It has cost me friendships. 

It has cost me opportunities to grow. 

Most of all it has cost me time.  Because the lessons we need to learn, we will learn, life makes sure of that.  It is up to us how long it takes to learn them.

These three lessons are all similar in that they are all about learning something.  We could quibble over whether or not being teachable and being critique-able are separate things or not, or even whether or not I can make up words like critique-able.

But, regardless here are my 3 lessons, not to say I am totally done learning them yet.

Lesson 1: Be teachable

Of all the ways this lesson applies, there is one that really sticks out in my head…

It is a bit of a strange scenario.

I was watching a live commentary on a Starcraft 2 match.  (Starcraft 2 is one of those hugely popular real time strategy games.  It has a unbelievable depth to strategy.  It is also unbelievably competitive.)

The commentator for the match was commenting on the play of one of the players, we’ll call him our hero.  Well, our hero was quite an experienced player.  His skill level was probably as high or higher than the person who was commenting on his play.

The commentator would say some very basic things that were fundamental to the strategy of the game.  He would make some point about how our hero should be doing this or that in this situation.  He would make even some basic points about what button our hero should be pressing and how he should be holding his mouse or hands.  Some very basic stuff that obviously our hero already knew.  As a matter of fact, some of the comments he was making sounded so simplified and almost demeaning to make to a player of that caliber.

What amazed me though, is how our hero responded.  He did not defend his actions or himself even once.  He completely absorbed and acknowledged everything the commentator was saying about his game.  He wasted no energy, no time, not a breath saying words either in his defense or confirming his prior knowledge of what he was being told.  He just let every word the commentator was saying soak in knowing that some of it might not have been useful, but being appreciative of all of it.

Immediately I thought to myself, “why can I not be as teachable as this guy.”  I thought if I could be that teachable, if I could be that egoless, I could really learn from anyone that had something to offer, not just those people who I perceived higher or more experienced than myself.

And that is the key to being teachable: learning from not just people who we think can teach us something, but recognizing that anyone can teach us a lesson if we can unbiasedly, undefendingly, uninterruptingly listen.

Lesson 2: Be command-able

It’s easy to be commendable, but difficult to be commandable.

Seems like no one wants to have someone else telling them what to do.  It is very unfortunate though, because there is a huge value when we can teach ourselves to march to someone else’s drum beat.

I’ll use another gaming analogy to illustrate my point here.  Those of you familiar with MMOs might be familiar with the concepts of raids.  As difficult as it is for me to admit, I was at one point pretty involved in an online game called Lord of the Rings Online.

If you are not familiar with MMOs and raids, the basic concept is fairly simple.  In these games they put some really nasty bosses for you to kill that have nice rewards.  The trouble is you can’t kill this boss by yourself.  You have to team up, and not with just 1 or two people.  For some of these raids you might have to team up with 20 to 30 other players.

I raided with a few different groups of players in this game, and there was a clear distinction between the successful groups the the unsuccessful groups.  There was one thing in common that the successful groups all had and the unsuccessful groups all lacked… the ability to be commanded.

You would think that skill level of the players, or the equipment they had, or even the number of players would make the biggest difference in the success or the failure of the raid, but you would be wrong.

Every single time I went out for a raid, I found the single biggest factor, more important than skill, equipment or any other factor, was the ability for the players in the group to be commanded.

The really strange thing is that sometimes the groups with too many skilled players would fare the worst.  Sometimes in those groups no one wanted to be told what to do and each person wanted to act independently.  In those cases we all became dragon snacks.

I know there are many of you out there reading this thinking that what I am saying only applies in wars and online battle games, but I would challenge you by saying every company, every business, every software project you are on is a war.

You might not be fighting against a army of invaders or an online dragon, but you are fighting competition, deadlines, internal and external politics and a whole host of things worse than undead dragons!

The bottom line is this: sometimes you just need to shut up, let someone else run the show and do what you’re told.

Often the ability to do this is the single greatest asset you can bring to any team.

Lesson 3: Be critique-able

Being critique-able and being teachable are pretty similar, but in my mind I think of being critique-able as more of taking your lumps like a champ while being teachable is about trying to gather knowledge out of a situation.  While you certainly can do either of these things in both situations, I make the distinction on where you put the focus.

We all screw up.  Heck, I screw up at least once a day.  If I make it a day without screwing up about 50 times, it’s probably because I spent all day sleeping, and that in itself represents at least 1 screw up.

A person who benefits from their screw ups though is someone who not only can recognize when they do screw up, but is willing to take the lumps for it that they deserve and even the ones they don’t deserve.

I do a bit of real estate investment on the side.  It’s my retirement plan.  One thing I can tell you about owning rental properties is that you need a good property management company.  I can also tell you about some bad property management companies; I have fired plenty of them.

I’ve finally found a property management company here in Boise, Idaho that I have no intention of firing and it is not because they don’t screw up.  They screw up, sometimes they screw up bad, but the thing about this management company that makes them different than the ones I have fired in the past is that when they screw up they admit it.

They don’t try and fight for their rights.  They don’t try and claim how they did the best they could.

I called up the manager of the company one day when I had an issue with one of the bills I was sent on one of my statements, and do you know what he said?  He said “John, I can see we messed up here.  What can I do to make this right?”

He has said these very words on several occasions when there was some kind of issue or dispute, and I am absolutely sure at lease a couple of those times that he believed his company had done exactly right and made no mistake at all.

Sometimes I have to remind myself to shut up, nod my head, apologize and move on.

Sometimes I really have to force myself to consider that perhaps I am wrong.  Perhaps I did do something wrong and I have something to learn from it.

Sometimes I really have to remind myself that nobody ever likes excuses.  No one ever wants to hear “I am sorry, but.”  Justifications nullify apologies.  Not just for them, but for you.

As soon as you start to make an excuse for yourself, you take yourself off the hook.  You lose all possibility of learning from your mistake, because it ceases to become a mistake in your mind.  Instead it becomes an unfortunate circumstance.

My best advice: when someone critiques you, shut up, listen to what they have to say, acknowledge it, apologize and say you have no excuse.  It takes a bit of courage.  It stings a bit, but you’ll be a better person for it and you might actually learn something.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

The symptoms of this disease are many:

• Frantically saying “It’ll work this time”
• Randomly adding +1 and –1 to integers
• Inability to see the forest
• Irritability
• Irrational paradoxical statements like “I am sure this is impossible, but I don’t know how it is happening.”
• Screaming
• Spitting at hamsters
• The list goes on…

What I am talking about is the debugger mind set and…

It is a mental disorder

So what is this debugger mindset I am talking about?

It is more than just overusing the debugger, it is thinking and acting in a way that is the same way one tends to think and act when they are stepping through code in the debugger.

I am guilty of it as I imagine many of you are.

And it is a disease.

A debugging tale all too familiar

Picture this… You are just about to check in the final piece of code that you have been working on all week for this awesome feature you are developing and something is wrong.

It is just not working.  You can’t figure out why.  The behavior of the code seems to defy all logic.

You set a few break points and start stepping through code.  (By the way it is 4:00 on a Friday and you were about to check in this code and go home a little early, you deserve it.)

Step… step… step…  Check this variable… Check that variable… Evaluate this expression.

Nothing, no clue as to what is going on.  You are beginning to sweat.  The release is going out on Sunday.  You need to get this fixed or the code can’t release.

You look at the clock.  It is now 5:03.  You glance at your phone and see you have a text from your wife.  No time to look at what it says.  You are intensely focused.  You must solve this bug.

Step… step… step… Check this variable… Check that variable… Evaluate this expression.  You begin to sweat more.

You can’t understand why this one little thing isn’t working.  It is driving you nuts, it doesn’t make any sense… You start scratching at your head in frustration.

Time ticks by, it’s now 6:30.  Your phone rings, it’s your wife.

“Did you get my text?  When are you coming home?  It’s Friday.  It’s the weekend.”

You fumble to get to your SMS program on your phone.  You don’t have time for this, you must SOLVE this bug, now!  Grrr, you are getting angry and irritated.  You try and hide it, but it comes through in your voice.

You’re thirsty, you’re hungry, your eyes hurt from not blinking.  You’re tapping your foot like a madman intently focused on the keyboard.  It’s now 7:40.

You start frantically changing variables.  You’ve lost track of what the code is doing now, instead you’re just watching values in your watch window.  It’s getting hard to think, minutes turn to hours.

You finally solve your bug at 11:03 PM, but your nerves are shot.  The taste of victory is soured like milk left too long in the fridge.  You can taste the chunky curds in your mouth as you think about how even though you fixed the problem, you still don’t understand why your solution worked or what was causing it.

It is very important to avoid this pattern of behavior

And it can destroy your productivity like nothing else.

You don’t actually have to be in the debugger to have this mindset, even though it often occurs when you are.

All developers are susceptible to it.  I know I have spent my share of time thrashing around with it.  It takes a fairly simple 1-hour-to-solve-problem and makes it take 8 hours to solve because we try to solve it in 5 minutes.

Very few things in life have a 5 minute solution.

When we start thinking this way, we lose all ability to think rationally and actually solve a problem.  Instead we start zooming into symptoms and using frustration instead of wit.

This kind of mindset can put us into a downward spiral of burnout and insatiability.  We end up wasting time and losing focus.  It is the most frequent time in my career when I have made stupid mistakes.

How to avoid the debugger mindset

The is a perfect storm of conditions which tend to cause this kind of a mindset, mix and match these as you will:

• A looming deadline (self-imposed or otherwise)
• Large chunks of almost complete work that can’t stand on its own
• Being in a hurry and looking for a shortcut
• Believing a problem is probably simple
• Believing a problem is probably hard
• Jumping to the debugger too soon
• Being at the end of a marathon session
• Not taking enough breaks

There are many other conditions of course which can contribute to this mindset, but these are some of the ones I find most common.  It can only take a few of these in combination to really push you over the edge into no man’s land.

Avoiding the debugger mindset can be as simple as trying to eliminate as many of these precursors as possible.

Here are a few tips I have found to directly counter this list above:

• Don’t impose deadlines on yourself and try to ignore unrealistic ones that are imposed on you.  Instead try to focus on doing a good job and being productive.  You are much more likely to get fired for being in the debugger mindset and making a stupid brainless mistake than for taking a bit longer to accomplish a task or having to tell your boss that you cannot in good conscious commit to a deadline.  Never forget that software development is always going to have a huge “unknowable” factor to it.  No one can blame you for that and it is not your fault.
• Try to commit as frequently as possible and divide your work into very small tasks.  Smaller is better.  Also try to split work vertically rather than horizontally.  This means trying to implement a feature in terms of small working pieces that work end to end, rather than trying to implement all the functionality in a single layer at a time.
• There are no shorcuts in programming.  When you need time take it.  Don’t forget to take time to quietly think about a problem.  Quiet contemplation is work.  It is not slacking off.  Take a walk if you need to.  Ask for a second set of eyes before you get into panic mode.
• Do not make an assumption about a problem until you understand fully what the problem is.  Don’t tell yourself it is easy, don’t tell yourself it is difficult, instead refrain from making a judgment call until you have enough information to do so.
• Don’t prematurely go to the debugger.  Always try to solve problems without the debugger first.  Once you have gone to the debugger, you are much more likely to get sucked into the debugger mindset.  If you do need to use the debugger, always have a hypothesis of what the problem is and use the debugger to confirm or deny it. 
• Do not use the debugger to help you understand what the code is doing.  Instead use unit tests for that or refactor to make the code clearer.  Divide and conquer the problem into a series of branching hypothesizes.  Use the debugger only when necessary to confirm or disprove a hypotheses and then form a new one and repeat all the while remaining calm and understanding that you don’t know how deep a rabbit hole is until you go down it.  (This StackOverflow question points out a fairly extreme view of what I am saying here, but I tend to agree with it more than I disagree with it.  I won’t say never use the debugger, but I will say that I myself use it too much and jump to it too quickly.)
• Take breaks and don’t work on the same piece of code for too long a period of time.  As stated above, break your tasks into smaller tasks so that you are always near a checkpoint.  If you are feeling frustrated, take a 5 minute break to clear your head and regain your focus.

What do you think?  Have you ever been in the debugger mindset?  What are some ways you avoid it?

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

I don’t like to admit it, but I have spent countless hours trying to solve problems I didn’t fully understand.

When you sit there trying to fix a defect or solve a programming problem without first reproducing it you are like a bicycle thief hopelessly spinning the dials of a combination bike lock hoping to stumble upon that magical combination.

It is a common ailment after all

Don’t worry you and I are not alone, many programmers share the same kindred spirit of overeager rambunctiousness of trying to solve problems before they know what they fully are.

It is perhaps ones of the greatest killers of productivity and conflagration of the nerves of programmers both experienced and in-experienced.

I’ve learned this lesson a dozen times, but I learned it again this week as I was working with Jesse Taber.  We recently instituted a remote pair programming program at my work, and I had the opportunity to pair up with Jesse this week.

See Jesse is the kind of programmer that pretty much always reproduces a problem before working on it.  I thought I was pretty good at doing this and insisting it be done, but after working with Jesse I found that I tend to be a little more lazy in this area than I should.

It seems pretty basic, but most of us don’t do it

Most of us tend to jump right into a problem.  Dive right into the code without completely understanding what we are up against.

I don’t know how many times I have attempted to solve a problem only to find that the actual problem was not reproducible at all.

A decent majority of problems that we try to solve either are not problems at all or are not anywhere close to the description of the problem we had been given.

I’ve definitely learned that taking that hour of time upfront to properly set up your environment and actually reproduce the problem shaves many hours off the time it takes to solve the problem and verify your solution actually works.

Sometimes problems can solve themselves

It is amazing how when you follow this simple advice problems have the seeming ability to solve themselves.

I’ve found many times in working on a difficult problem that the very act of the reproduction of the problem points to the actual cause.

When you think about it, it makes perfect sense.  In order to reproduce a problem, you must cause the problem.  If you have caused the problem, you may be able to identify the particular thing you did that caused it.

Sometimes it isn’t that easy, but reproducing the problem is still a great place to start.  After I have reproduced a problem, I often find that I can divide and conquer that problem by breaking it into sub-problems.

This technique is very similar to basic troubleshooting.  We follow steps that go something like this:

1. Reproduce the original problem
2. Break apart the problem by determining if any aspects or symptoms of the problem that was recreated can be recreated in isolation
3. Once we have a small enough problem to solve, start taking away steps and elements of the recreation of the problem until we have the minimum set of of criteria required to create the problem
4. Come up with a hypothesis of the cause of the problem (not the solution), change the cause in the simplest way possible to prove or disprove the hypothesis (many times this will not involve changing any code yet)

Let us make a pact

Let’s hold ourselves to a solemn vow of never again trying to solve a problem before we can reproduce it.

Don’t just take someone’s word for it anymore.  Stick your head in the sand like an ostrich and refuse to believe there is a problem until you can see it for yourself.

What do you think?  Have you ever tried to solve a problem only to find it does exist?  Have you wasted hours of time trying to solve the wrong problem or randomly twiddling bits?

Oh, and if you are in QA or ever write up a defect.  This pertains to you also, because you should realize that the most important part of a defect is always the steps to reproduce.  A defect that cannot be reproduced is only noise, it cannot be solved, because the solution cannot be verified.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

I just got my first course published on Pluralsight!

The course is called Android Development for .NET Developers and it covers most of the basic knowledge you would need to go from knowing nothing about Android development to being able to create a fairly simple application and publish that application to the Android Market.

If you haven’t checked out Pluralsight, it is a really good site for a wide variety of developer training videos.  They really managed to get some very good content on the site and there are videos on just about every .NET topic you can think of.

I have also really enjoyed working with the guys that run Pluralsight, they are all very friendly and very knowledgeable.  Thanks to David Starr and Fritz Onion for all their help getting my course ready and published.

You never really learn something till you teach it

This simple truth became more apparent to me than ever during the process of making this course.

I thought I had a pretty good understanding of the Android fundamentals, having published a fairly complex application, PaceMaker.

What I became quickly aware of is that there is a huge difference between having knowledge and having understanding.

I equate knowledge as possessing a formula to be able to do something, but lacking knowing why or how to make modifications to the process.

Cooking provides an excellent example of this.  There are many people in the world who know how to cook a large number of dishes.  But many of these people only have the knowledge of cooking.  They have a large collection of recipes which they can follow to produce the desired result.

A professional chef on the other hand, has a true understanding of cooking.  This person might have knowledge of many recipes, but they also understand why the particular ingredients are used and can make modifications to those ingredients and steps.  They may even create something without preset steps because they understand what they are doing, not just have knowledge about it.

It was great to have the experience of creating these videos because I was able to acquire an in-depth understanding of Android development, not just a knowledge of what to do.

If you ever have the opportunity to teach, I definitely recommend you take that opportunity.  Even if you don’t think you are qualified to teach a subject, by the time you have prepared what you are going to teach, you will be qualified.  Trial by fire perhaps, but well worth the outcome.  Plus you’ll be helping others in the process.

Much harder than I thought

I do have to admit though, recording training videos is definitely much harder than I had originally anticipated.

In order to get 40 minutes of video, it might take 6 hours worth of work or even more depending on the prep work involved and how much editing after getting the raw footage.

I really expected that it would take about as much time as it takes to record something to produce that something, but I definitely learned that is not the case.

I often found that I had to draw a line and stop trying to refine a video because you can literally spend an unlimited amount of time editing and tweaking a video.

Another revelation that might be apparent to everyone else, but was quite an epiphany to me was that you can edit “umms” out of video very easily.  You can’t even notice where they are cut out!  My first video, I didn’t even realize I could edit anything, and I ended up taking like 50 cuts until I could get it right.

Overall though, great experience, lots of fun

I felt like I’ve been stretched in a different direction, as I had never done any video or audio recording before and had never really spent much time in a room talking to myself pretending to talk to other people, but it was a good kind of stretching.

I really actually enjoyed the process and I will definitely be doing more of this kind of work in the future.  Probably going to take a bit of a break before I start my next course though.  I want to make sure I take some time to get a good retrospective of the process and sharpen my saw a bit so my next videos can be even better.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

But, I think it is worth taking a moment to talk about one of the biggest blunders professional programmers make in their job search, careers.

The mistake is not having a resume that is of the same caliber in both presentation and content as the set of skills you are trying to sell.

I’m no marketing whiz

But, over the years I have come to understand the value of marketing.  As a professional, you should always be trying to sell yourself.

I’ll be honest, part of the reason I write this blog is because I know it is a valuable tool for marketing myself.

For most professional programmers your resume is your only real marketing method. When it looks worse than a 3rd grade book report and I see it, I immediately think you suck.

Sorry for the boldness, but no need to mince words here. 

Unless you have some awesome open source project you built, or a blog, or some other kind of flashy marketing tool, your resume IS your ONLY marketing and if that sucks, people are going to assume you do also. 

To be completely honest again, in some part you have to admit that you do suck. Perhaps you are a great programmer, but you suck at common sense.  I mean going through all the hard work of becoming a great programmer and not having the common sense to do the easy thing that will make it all worth it…

Trent: You know what you are? You’re like a big bear with claws and with fangs…
Sue: …big &!%* teeth, man.
Trent: Yeah… big &!%*teeth on ya’. And she’s just like this little bunny, who’s just kinda cowering in the corner.
Sue: Shivering.
Trent: Yeah, man just kinda… you know, you got these claws and you’re staring at these claws and you’re thinking to yourself, and with these claws you’re thinking, "How am I supposed to kill this bunny, how am I supposed to kill this bunny?"
Sue: And you’re poking at it, you’re poking at it…
Trent: Yeah, you’re not hurting it. You’re just kinda gently batting the bunny around, you know what I mean? And the bunny’s scared Mike, the bunny’s scared of you, shivering.
Sue: And you got these &!%* claws and these fangs…
Trent: And you got these &!%* claws and these fangs, man! And you’re looking at your claws and you’re looking at your fangs. And you’re thinking to yourself, you don’t know what to do, man. "I don’t know how to kill the bunny." With *this* you don’t know how to kill the bunny, do you know what I mean?
Sue: You’re like a big bear, man.
Mike: So you’re not just like &!%* with me?
Trent: No I’m not &!%* with you.
Sue: Honestly, man.

I know you might be thinking I am being harsh here, but really it is for your own good.

Let me give you an example.

Lets pretend that Pepsi let me design their new logo and ad copy for a magazine ad.

PEPSI!  It eez so freakin good it will nock you’re socks off!

I drink it all the time.  I have spearheaded drinking it at parties with 100-1000 people.

PEPSI! YES!  TOTALLY AWESOME AND QUITE DRINKABLE!

Next time you are at the store and you see a 12 pack of Pepsi with my hand drawn logo on it, and a big white board with no color that says "DRINK PEPSI! TOTALLY AWESOME AND QUITE DRINKABLE" are you going to buy it or are you going to think whoever made that piece of crap is a doofus?

The situation is far worse than what I described.  Pepsi has many marketing venues and advertising campaigns.  If all you have is your resume, then you just have one. There is nothing wrong with that, but it better be damn good!

Your resume is like a Superbowl ad for you and your programming skills.

I would love to make a nice resume, but I do suck at writing and design

It is good that you admit that, because if you are a programmer and your name isn’t Hugo, you probably do suck at writing and design and that is Ok. 

You should not be the person writing your resume or designing it.  You should provide the information, you should review the design, you should even proof-read and edit it, but you should be letting someone else do most of the work.

Why?  Because there are professionals that know how to write and design a resume. Perhaps with many hours of work and research you could create a resume as good or better than a professional resume writer, but chances are you can’t.

Just like a professional resume writer shouldn’t try and write their own software, they should hire you to do it, you shouldn’t try and write your own resume.

This might seem like strange advice.  Perhaps it seems like a cop-out or uber-lame. You are welcome to think that if you want.

Perhaps you think, well if everyone did that then all resumes would be nicely formatted, not contain spelling errors and typos and be full of marketing hype. 

That is true, but the good news for you is that HARDLY ANYONE IS DOING IT and by being one of the few who do, your resume will stand out and make the others look like something your cat puked up.

If you can get an edge, take the edge!

People should judge my skills not my design and formatting on my resume

I completely disagree.  Having an ugly resume tells me a large amount about you… shall I list a few prejudice things I assume about you when I see your double spaced 6 page monstrosity?

1. Doesn’t care about appearances – hmm too bad my customers do.
2. Doesn’t have self-respect – those who don’t respect themselves don’t respect others usually.
3. No sense of pride – if you can’t take pride in your own work, why do I expect you to take pride in the software you are building for me?
4. Doesn’t value the opinion of others.
5. Is limited by own abilities – if you can’t reach out to others for help in your area of weakness, I expect when you can’t figure something out, you’ll just flounder.
6. Doesn’t care about quality.
7. Is not detail oriented.
8. Lacks ambition, will settle for less.
9. Your code reflects all the above statements.

Unfair?  Perhaps.  Untrue?  Perhaps, but given no other information and a stack of 100 more resumes to go through, I’m going to go ahead and be prejudice.

But it costs too much money

It is called an investment. If you are not willing to put some money into your career, then why should someone else be willing to take a chance and make an investment in you?

A good professional resume writer might charge around $500.  That is chump change compared to the potential earnings increase of having a professionally written and designed resume.  You may increase your negotiating power by a huge margin by appearing to be more professional and you will certainly increase the number of possible opportunities that are available to you.

Let’s use some real fake numbers like I always like to do.

Suppose that you have skills that on average would be worth about 60k a year in the market and your resume is getting around a 10% response rate from jobs you submit to.

Now of the jobs you submit to, most of the 10% responses you are getting are for jobs that pay right at your market rate, some are above, very few are way above, and some are below.

If you invest $500 in getting a really well done professional resume, you could reasonably expect to increase the base value of your market rate to say 65k and improve your response rate to 20%.

That is a pretty modest improvement, which only requires an investment of money to achieve.  The immediate return on that investment is HUGE, and the lifelong return on that investment could be literally 10s of 1000s of percent.

Think about it.  If you increase your starting wage at a company by just 5k, for a $500 investment, and you work for that company for 10 years, if you got no raises at all, you would make 50k return on your $500 investment.

Raises, by the way, are usually based on percentages of base pay, so it is realistically going to be even more.

Two more points, then I promise to stop beating this horse.

• It is likely that someone who had a very bad resume and expected to find jobs making 60k, could get a very good resume and find that one company willing to pay them 80k for that same set of skills.
• It is very much more likely that the dream job you are after will have a much wider pool of candidates to choose from, even if they are paying the same market rate.  So by having the better resume, you are more likely to get seen and get that dream job.

Final advice

• Don’t hire some cheap resume writing service. You get what you pay for.  Spend the money to get it done by a real professional who will do it right.  This is the only hard part you have to do, you need to do a large amount of research here.  I have hired several resume writers for myself and my wife, and I have had to fire a few, because they were basically just rip-offs.  If you try to be cheap and you end up getting ripped off, don’t come crying to me.
• Review the resume.  You will need to go through more than 1 revision, probably at least 5.  If you want something changed, ask for it.  They will do it, you are paying for it.
• You are still going to do most of the work of gathering the information.  Figure out all the things you want to have on your resume and put it all in a mind-map to give to the resume writer.  Garbage in, garbage out.
• Whether you take this advice or not, before you ever send your resume to an employer, send it to your mom, your girlfriend, your English major buddy, anyone who will look at it and tell you why it is ugly and what you need to do to fix it.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

There is a part in the movie where Greg goes to the breakfast table to be greeted by his girlfriend’s sister’s fiancé, Dr. Bob, and his father who is also a doctor.

They ask him what he does, and he says he is a nurse.  They think he is joking at first, but then they realize he is serious.  They assume the MCATs were too hard, but he tells them he prefers nursing, because he can work in several areas of medicine and not have to deal with the bureaucracy that doctors do.

“You are a programmer?”

“Yes”

“Didn’t you want to move on to become an architect or manager?”

“No, I like writing code and solving hard problems.  And I don’t want to deal with the bureaucracy that architects or managers have to deal with.  I just want to write code and keep getting better at it.”

What exactly is a “career developer?”

The closest thing we have to this title is a Software Craftsman, but that seems a bit presumptuous.  I am OK with being called a “career developer.”

It means that I don’t consider advancement to be something beyond writing code.  Becoming a manager or a high level architect is not something I consider to be career advancement for me.

Even becoming a technical lead is not something I strive for in my personal advancement.  Leadership is something that can never be assigned, but is always earned by reputation and willingness to help others.

It means that I consider advancement to be becoming better at writing code, learning more about best practices and implementing them.  I measure advancement in terms of breadth and depth of knowledge in the field of software development and the ability to get things done.

A career developer is someone who values the process of learning and advancing their skills at programming and software development in general over a title, and, unfortunately in a large number of cases, pay.

Although, it does not mean that "career developers” will not be paid well, it just means you have a harder time finding the right company that will recognize the value that you can bring and pay you accordingly.

Why?

I can’t speak for everyone, but for me it is about staying true to the reason I got into programming in the first place.  It is the feeling of pure amazement and excitement, as you realize you can make the computer do what you want.

It is hard to match the satisfaction of seeing all your unit tests turn green, knowing that you wrote those tests before writing the code.

There is no novel that compares to the joy of reading through well written code clearly revealing its intent.  Just as real as a character in a book.  The greatest joy is when it is your own code.

There are not many things more exhilarating then facing that really hard problem that seems impossible to solve, not knowing if you actually will be able to solve it, until you finally break it down to small bite-sized pieces, and when you look down at your plate, you see the problem is suddenly gone, and you have emerged victorious!

What else can stimulate the mind in so many ways?  What other activity can challenge you mentally to the same degree that programming can?  What other act of creation allows you take take virtually nothing and make it into something real?

Where can you exaggerate so much, but in a blog?

Yes, perhaps I go a bit far, but at times what I say above is completely true, at least it seems that way to me.  And that is precisely why I choose to keep slinging code.  I’m looking for my next programming high.

Don’t let the man get you down

There is nothing wrong with striving to go into management or into higher level architecture instead, but you have to make the choice yourself, and you should not make the choice lightly.

One problem in the real world is that not many companies realize that there even is such a thing as a “career developer.”  There is not really a job title for it.  Senior Software Engineer doesn’t quite cut it.  There are plenty of those out there.

Don’t be discouraged though, if you choose to go the route of the “career developer.”  There are companies out there that do recognize the value of a developer with 10 years experience versus a developer with 1 year experience 10 times.  There are many companies that want to hire exactly the kind of programmer that only want to be programmers, and will pay them well.

I’m fortunate enough to have found such a company.  And I can’t be happier that I did.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

I wish I could take a time machine back to the year 2000 and read it then.

So much of the information in the book seems to be concepts that many software developers understand and take for granted as general knowledge now, that wasn’t at the time of its writing.

The book is very much a collection of knowledge from years of practical experience writing code.  It is very specific in stating what kind of specific coding practices should be carried out and which ones should be avoided.

The content of the book lays somewhere between the low level software construction in a book like Code Complete and a book targeting a higher level methodology or project management.

Good:

• Years of experience packed into a small package.
• Most of the advice in this book is timeless.
• Practical real world truth instead of theoretical talk.
• Excellent focus on automation for everything you can automate.
• Technology independent advice.

Bad:

• There were definitely some dated pieces of advice that I wouldn’t recommend following today.
• If you are already familiar with many of the software craftsmanship or general agile principles, much of this book will echo what you already know.  (Can’t fault the authors for that since this book is probably the origin of much of that information getting out, yet if you haven’t read the book, you should know what to expect.)

What I learned:

I really liked the section of the book that talked about using “tracer bullets” in software development.  Basically the idea is that you can either prototype the software or build what you know and then adjust your aim to reach the user’s real requirements instead of trying to specify up front.

I think many times in development we get hung up on knowing all the details, but sometimes we need to fire “tracer bullets” first to see if we are hitting the target.

I also realized that I am guilty often of programming by coincidence.  Sometimes I will have put a magic incantation into the code and not really understood why it worked.  It is very important to understand why something works, not just make it work.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

Some of your coworkers probably don’t struggle with the issue because they really just don’t think about it that much.

But, if you are reading this blog, you probably have encountered the problem I am about to talk about.  It may be for you, like it is for me, the single greatest thing holding you back.

What am I talking about?

The struggle with perfection

We want to build perfect software, we want to build perfect code, but it is just not possible.

Like Tyler Duren’s alter ego, we want to put everything in a nice little box.

I had mentioned earlier that not all software developers struggle with this problem.  I think it arises when you start to actively seek to improve your development skills.  It is natural to look for the “right” way to do something you want to get better at.

• There is a right way to swing a baseball bat.
• There is a right way to do mathematical calculations.
• You can play a piece of music perfectly on a piano.

But there isn’t a right way to build software.

There are lots of wrong ways, and then there are many better ways that all have trade-offs against each other.

It is vey hard to come to grips with this reality.  At least for me it is.  I want to know how am I supposed to do it, and I don’t want to hear “any way you like”, or “however seems right to you.”

Software development is part craft

There is some science to it.  Don’t get me wrong.

The biggest problem in software development is not people struggling with perfection, but rather developers believing that there are no wrong ways to develop software.

You can learn what is right to some degree, up to a point.  But, after you steer away from the obviously wrong, you end up drifting into the true craft of software development.

When you only have one tool, software development is easy.  You just hack on things with your one tool.  You might not be very effective, or very efficient, and you may make a pretty big mess, but you generally can get things done and you know what to do.

When you have a toolbox full of tools, the world stops being so black and white.  Software development truly becomes an art or craft at this point, as you are forced to make trade-offs and choose architectures and technologies based on experience and intuition combined.

Our minds fight against this concept of unrule.  It is like playing monopoly with generalizations or ideas of how the game should be played, but no explicit rules.  Sometimes life is just easier within preset boundaries that clearly tell us what is right and what is wrong.

It is a strange twist of fate that the act of building something that is absolutely structured and governed by rules is such a rule-less and judgment based pursuit.

Dealing with perfection in an imperfect world

So why is striving for perfection bad anyway?

Well, it can be a major roadblock that prevents us from getting things done.

I’ll often find myself at the 90% better than I started solution, and pushing to get to 95%.  That push to 95% can take the same amount of time it took to get to 90%.

Sometimes when we are looking for the perfect architecture, or trying to apply patterns, because we believe they are right, we end up making things more complicated than they need to be, or we miss a better “less perfect” solution, because we have deemed it so.

One thing I have tried to do to curb my insatiable desire for perfection is to strive to always improve rather than for perfection itself.

It is important for us to recognize when we are at that 90% mark and move on.

Next time we encounter a similar situation, we’ll hit the 91% mark, because we will have more experience and will have built better intuition.

Here are some tips and strategies I have picked up for dealing with the problem of perfection.

• Try to get rid of the all or nothing mentality.  Don’t do things just good enough to get by, but don’t try to do them perfectly either.  Do an excellent job, and know what that is.
• Start working on things in a rough draft form.  Fill in details later.  This especially helpful with web pages or anything that requires design work.
• Don’t get stuck on a problem that is mainly just polish.  If the elegant way to do something is causing you 10 hours of debugging, but you can do it in a less elegant way and hide the mess in a nice package, opt for the second.  You can always come back later, when you don’t feel pressured to find a solution.
• Get a second opinion.  If you are struggling with a design issue and going back and forth in your head about the best way to do something, ask someone else and it might make one way or another perfectly clear.
• Make yourself a research note.  Move on for now, and make a note to come back later or to research a technology or design.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

There is one coming soon, but I wanted to talk about why it has been so long.

Simple answer… I stopped reading.

What happened?  Well, I got caught up with switching jobs twice.  Lots of different things going on.  I started a running program, etc… etc… excuse… excuse.

I wasn’t following my own advice.

It is really important to take a moment every once in a while, when you feel like you are off track or not reaching your goals, to reassess your priorities and goals and figure out what you need to get back on track.

You have to set a schedule

That is primarily where I failed, and that is how I am succeeding now again.  At one point I was reading through books about 2 a month, but pretty soon a few months passed by without one book read.

When I was successful at reading, it was because I had set up a schedule or reading every day for so much time.

The simple matter of it is, as humans we are not good at making good choices about priorities without explicitly planning them out.

Now that I have set up a schedule of reading a minimum of 30 minutes each day, I am making progress again, and much faster than I thought.

Aren’t you being a little strict?

You may think that just reading blogs is enough to keep up with the information stream, and it may be, but it probably isn’t going to really expand your mind like a book will.

Why I recommend reading technical books (although, I would argue a book on people skills and other self-improvement books should also be mixed in.)

Breadth of knowledge will increase.

You will learn more about things and understand more of what is available to you even if you do not employ all the practices and technologies in the books you read.

Depth of knowledge.

Sometimes drilling down into an API or deep into a technique can help you truly master a technology or practice way more than hacking out code or consulting APIs to just find what you need to know.

Motivation.

This one is a surprise to most people, but what you read is what you are excited about, not the other way around.

Try it if you don’t believe me.  Pick any topic and start reading about it.  You will become passionate about that topic.

If you want to be a better software developer, read about software development.

Reputable source of authority when influencing decisions.

You can have the best idea in the world, but if your only authority is yourself, it doesn’t hold much credibility.  It is much more effective to say, “I think we should do it this way.  In Code Complete, Steve McConnell says…”

Unconscious knowledge absorption.

I have always been amazed by how much information I picked up from reading than what I was conscious of knowing.

Many of my blog posts will echo things I have read in Code Complete, or Clean Code, or any number of other books I have read, which I do not even consciously recall.

Sometimes when I write code, I intrinsically know it is the right way to do it, because of an unconscious conditioning.  (Make sure you read good books, or you will have the negative aspect of this effect.)

My little tip

One great way to get your reading done, and to stay in shape at the same time, is to do it on a treadmill.

I have been doing this for awhile now, and it really makes me feel like I am using my time wisely.

You can just walk on the treadmill, set a little incline to burn some extra calories, and after awhile you’ll forget you are walking.

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.