Of Rockstars and Bricklayers

Today we're going to start with a thought experiment.  You are one of the better coders in your company.  All the proof I need is that you're reading this.  Ok, that may be a little self-serving but it is true that the better coders I know are always reading something about coding.  It might be a new language, or a new technique, a programming question and answer site, or even a site that likes to rag on bad code. 

Based on how many Code Monkeys you know, it's easy to figure yourself in the top half of programmers, a 'good' coder if you will. An assumption that is easy to make is that the higher your productivity the higher your pay.  Is this true?  If you base it on simple experience, the answer is no.  It's too easy to get a job right out of college and get mediocre raises and then find yourself interveriewing candidates for openings in your own group where you have to offer 'market rates' to attract anybody.  If you've been there for 5+ years, given a company desperate to hire warm bodies, it doesn't take much for the new guy to be making 15-25% more than you even if he is a two-finger typist and can't spell SQL if you spotted him the 'S' and the 'Q'. 


Now, I'm happy where I am but it didn't take much to trigger my bad habit of thinking up 'what-ifs'.  The Stackoverflow podcast has been a good one for this sort of pondering.  Jeff and Joel have enough real-world experience to bring a ton of wisdom to the discussion on programming as it's own topic and in episode #42 discuss underperforming programmers.  I'd been reading about how star actors can command huge salaries based on their past work and the expected effect on the box-office if their name appeared on the marquee.  That major-league sports can have individuals who make 10-times what the lowest paid athlete makes on a single team, it doesn't take much to ask why programming doesn't see the same effect. 

I submitted this as a question to the Stackoverflow podcast which they spent a good 10 minutes on in episode 77. It didn't fit so well as a question on Stackoverflow itself, I suspect the culprit is the lack of code snippets. Interestingly enough I discovered the podcast when they were at episode 65 and decided to start listening back at #1 and was up to around #42 when I decided to contribute my question.  So anyway, when I saw the summary for #77, I didn't have the audio handy so jumped over to the transcript wiki for #77 and read the transcript.  It was a pleasant surprise at how engaged they were and that the question wasn't dismissed out-of-hand.  When I downloaded the audio, to hear their discussion it only reinforced my reaction.

The range of talent can be mighty wide even if there is some disagreement on the empirical numbers.  Joel Spolsky talks about the difficulty in finding great programmers, and uses similiar metaphores in a comparison with opera singers. Jeff has a similar take on Coding Horror.  Finding great talent is hard because there are only so many people who can do what you need done.

There have been some good discussions that has surfaced.  John Cook has a good argument based on lack of meaningful metrics.  It's a question that has been around for awhile.  Frank Wiles makes the claim that hiring average (or below) programmers actually costs your company money (followup post). Obviously when a company says they only hire the to 10%, they are deluding themselves or at least paying lip-service to wanting good programmers.  Joel does a great job of shattering that particular illusion. 

What about sales? In some fields top salesmen can bring home seven-figure incomes so we know that the wide range of incomes aren't limited to Hollywood and the big leagues.  James Kwak picks up on John's post and supports Joel and Jeff contention that paying the top performers much more than the average, outside of easily measured areas like sales and movies, has a corrosive effect on the group and the best coders end up leaving for greener pastures while the dregs hang on for dear life or are eventually pushed out.  I can't disagree.  It seems that if you are underpaid you have to ask yourself Ann Lander's question, "Am I better off leaving or staying put?"  Just realize that it's no use complaining to the company, the status quo works for them.

The Myth of the Aging Developer

I question that I've heard throughout my career is, "What happens to older software developers?" The danger with this question is when the discussion turns to the implied version which is "The lack of older developers means that it is a young persons game." Nothing could be further from the truth..

My wife and I are both developers. We have both been working as developers for 15+ years. One thing we noticed was that there were a lot of people working as developers who really shouldn't be, they didn't have the aptitude, interest or sometimes even the background. It would be easy to dismiss the problem as a lack of proper education but that doesn't explain the developers who lack a CS degree but who can code circles around veteran devs. Those folks usually decide that programming is not for them and move on to different job. Some go into management, some become analysts, while others change careers completely.

What's left? The ones who are passionate about development and are interested in doing it right. They love learning new stuff and don't gripe about how things used to be in "The good ole' days." They might be grumpy but they usually know their stuff.

The main problem would be in finding management who doesn't have a pre-conceived notion about what makes a good developer. If they feel that only the younger ones have the stamina to keep up with the pace, I'd wonder whether those same employers were the same ones who believe that the 'Deathmarch' style of project management is standard operating procedure. They'd rather grind through fresh-meat developers (Code-Monkeys anyone?) than listen to the experienced ones and change their development process much less change their management style.

Lastly, I've noticed that doing nothing but coding holds less business value than being able to communicate with customers, users, management, and vendors. One reason you start coding less is because finding answers to ambiguous requirements takes more experience and provides more payback to the business.

My advice, to those who worry about their coding future, would be to find a place where they need experienced developers to help with the overall task of creating or maintaining software, that also gives you the opportunity to code regularly. That way you can have the time to keep up with industry changes while taking advantage of your understanding of software development.

What Did You Say?

This says it all. Most of the time research focuses on if new stuff is possible. The real 'Silver Bullet' would be to find a way to solve the communication problem. Click on the image to embiggen.

The Myth of Code Construction

Ever work with a developer who avoided letting anyone see their code, refused to program in pairs or participate in a code review? They say "This is my code" as if they have sole right of refusal on the final product regardless of who else may be paying the bill.

Great writers still have editors. No matter how great a writer you are, you still have to submit your work to an editor before it will be published. Let's examine the idea of putting code into production as a form of publication.

Before we jump into a new analogy, we should look at the current state of affairs. If engineering were a family construction would be the successful older brother leaving software as the immature younger brother, never quite living up to the accolades of the elder sibling yet endlessly compared nonetheless.

In general, the phases in software are: analysis, design, construction, test, deployment, and training. When you want to build a building of any size, let's use a downtown skyscraper as an example. If we continue the comparison we'd start with analysis which includes many factors like the target location or how many square feet are required. The location can impose limitations to the footprint which then dictates how many floors would be needed to achieve the required square footage. Such trade-offs are examined and decided upon during the design phase. Construction is all about execution with limited opportunity for design changes. How do you test a building, what does that even mean? You might might test the subsystems, like elevators, fire alarms, etc. but how do you test the entire building? The closest we can come in scale might be the opening and closing the retractable roof of an almost complete stadium like the new Cowboy's stadium (this being written in May of 2009). How do you deploy a building? You don't, you open it for business. There is no pull of the lever where what did not exist suddenly does. As for iterations, the closest construction can come is building a new wing on an existing building, adding a room to the house at hand. The cost and effort of remodeling can end up being a significant ratio to the original price of the house.

Now let's discuss a comparison of software development with writing a book. A publisher decides the market is ready for a new book on ant farming. They either have recent submissions by authors interested in writing such a book or they solicit existing authors who have experience in the subject matter. In any event, they request an outline of the book with maybe a sample of one chapter to gauge the material matches what the publish wants. The author or authors work at creating the manuscript all the while knowing that editors will read the book and suggest changes. Editors who are not experts in the content but are experts in the publishing of books. Even the highest-paid authors - Mary Higgins-Clark, Stephen King, or J. K. Rowlings to name a few - will all submit their work to the editors pen.

When the manuscript is complete and the editors happy, there are still other contributors to the final product, researchers, artists, designers, and the like who do things like create illustrations, populate an index, check facts, or plan the visual layout of the chapters. All these activities are coordinated by the publisher who has a target date for when the book will be printed, planning a marketing blitz to coincide with the publish date. Getting the manuscript done is important but still is a small part of the whole effort and if an author cannot produce on time, a lot of investment by the publisher goes to waste; a good way to dissuade the publishing company to find an author who can deliver. The key is that it doesn't have to be perfect but does have to be complete. If there is enough demand, it is easier to publish a new edition rather than hold off on the initial printing. Testing is as easy as a small test run where the final product can be validated by all contributors before scaling up into production-sized runs; images replaced, a new cover chosen, typos fixed. Printing becomes like running the build with a target of production. This means that "build" isn't a phase, it's an activity; unlike any in construction. Deployment becomes a straightforward, if not simple matter, of distributing copies of the book to various retail book-sellers or their distributors.

My suggestion is for the software developers of the world realize that allowing our craft to be constantly compared to the construction industry is to remain the little boy, wanting to live up to the expectations of those who came before, never earning the respect or acceptance they so long for. Look instead to the world of publishing, where writing is still an art and yet the businesspeople have found a way to make money without rejecting the fundamental nature of writing, be that a novel, the latest tech book, why not the latest edition of your favorite word processor?

p.s. Kudos to the wife for the idea.

In My Estimation

There I was at my first real programming job and my team lead comes by and drops a bomb. "How long will it take to make the change?", he asks. I hope I kept the panic from my face. "Wait a minute!", I was thinking, "Did I miss the class on estimation in college?" No, I didn't. They didn't have one. Hmmm, what do I tell my boss, "sorry, can't help you!", "I have no idea", or even better "they didn't teach that in school"? If I close my eyes and pull a number out of my estimation orifice I could look like a ill-trained idiot programmer by guessing too high or try to please by low-balling it which could easily backfire. Why did I want to be a programmer again, someone remind me. It surely wasn't to look incompetent to a guy that hasn't coded in over 20 years.

Why is estimation still so hard and what are we doing about it?

Does Anyone Know What Testing Is?

(With apologies to Chicago for the title) I'm a big fan of good design which should be no surprise to those who know me. It can irritate my wife when I analyze a building and then start describing all the different ways in which you can tell it was poorly designed. I do rant when I see great design but those are much more rare in these "I don't care if it's a half-baked piece of crap, we need it ready now!" times. I apologize for any management flashbacks that caused.

In any event, I'm also a big fan of testing. I see testing scenarios around me during the day. This story just happens to be one that is easy to tell. The mens room where I work has three sinks, each with a soap dispenser. There was one sink that more heavily used than the others based on the fact that there was never any soap in the dispenser. You'd push on the plunger a couple of times and when nothing came out you'd shrug and move to another sink. I always figured that it was running out quickly since I would see the buildings cleaning crew in the bathroom a couple times a week. Surely they were refilling the dispensers right? After a few weeks of the "soapless sink shuffle" I mentioned the problem to the cleaning guy. I got his attention and showed him how no soap came out. He looked confused and said something to the effect of "it should work because it has plenty of soap". As I looked under the counter where he was examining the half-full bottle of soap it was clear that lack of soap wasn't the problem. I left him to his work, figuring that maybe the tube from the plunger was disconnected; plus, he didn't need me looking over his shoulder.

Upon reflection, I realized that his 'test' for being out of soap was looking under the counter to see if any of the containers were empty. Our 'test' for being out of soap was trying to get soap from the dispenser. So even though his test passed, it still was failing the end user because he wasn't verifying the expected result; the assumption being that the only reason you wouldn't get soap was if the container was empty.

The bottom line is to always be aware of what your tests are testing. Just because you're tests all pass does not guarantee everything is working as long as you aren't testing the way the system/device is used in real life. So, when you look at your test plan ask yourself, am I checking that we are out of soap, or am I checking whether I can get soap out of the dispenser? It might seem like a small difference but it can be difference between a cleanly running system and one that leaves you all wet.

The Management Delusion

A good friend of mine sent me this:

Subject: New Stroustrup quote

"The companies are complaining because they are hurting. They can't
produce quality products as cheaply, as reliably, and as quickly as they
would like. They correctly see a shortage of good developers as a part
of the problem. What they generally don't see is that inserting a good
developer into a culture designed to constrain semi-skilled programmers
from doing harm is pointless because the rules/culture will constrain
the new developer from doing anything significantly new and better."

Those companies are in a bed of their own making. They want software written on a schedule which means hiring warm bodies who have the minimum training, enough to run a compiler, and can crank out code on a consistent basis; consistently low quality and in a consistently long time. When the pain of low quality software finally registers through their management-induced fog, they look for answers. What keeps these "Leaders" from admitting their own contribution to the problem?

Leadership sometimes means making hard choices, almost guaranteed to make someone unhappy. Leadership sometimes means suspending self-doubt to enable making those hard choices without the burden of guilt. Consider car company executives contemplating closing a factory - let all the employees down through bankruptcy or let a smaller set of employees down through a layoff? The best example of this would be President Truman's decision to use the A-bomb on Japan. Good luck trying get them to second-guess themselves - to do so would mean letting self-doubt out of the tiny box in which they hide it. Now, for the leader of the free world, we can understand why self-doubt is a luxury they can't afford.

What about the corporate world? Well, the upper-level executives may catch a break when they have to make truly gut-wrenching decisions like the car company example above. Middle and line-level managers do not have those reasons to hide behind so what's their story? Even without earth-shattering, bet-the-company decisions to make, a manager faces the same dilemma, how to isolate their own sense of self-worth from being damaged by potentially bad decisions. One way of doing this is by never looking back, never re-examining prior decisions, not entertaining the idea that they made a bad choice which is, by the way, popular with leaders at any level.

This may keep them from being paralyzed with self-doubt or wracked with guilt but is also makes them oblivious to their own short-comings. It takes a strong leader to learn from their mistakes, to emerge from self-examination stronger because they own up to their mistakes and learn from them.

Here then is the key. Allow me to extend the quote to the next logical step. Companies that are complaining about the lack of good developers are in a state of denial. What they are really complaining about is how few good developers want to work for them. There can be many reasons from an environment that accepts mediocrity to the unwillingness to pay the good ones what they're worth. In the first case it could be the red-tape just to get their development workstation setup, "What do you mean I have to get each Eclipse plugin on the approved software list!?!?" In the second case it could be failing to attract good talent; after all its only fair for a programmer that is 10x better than average to get paid 10x the average, right? Describing your workplace as "We have reasonable development policies and reasonably good salaries" you should not be surprised that you have reasonably talented programmers. To deny this is effectively admitting to self-delusion.

So, when your boss complains about the lack of good developers, they are really trying to deny their own reality and shift the blame away from themselves.

This reminds me of a story about 10 hiring managers who all insist they hire only the top 10% but I'll save that for next time.

The Tale of Two Managers

Is the company you work for serious about software development? How can you tell whether your manager is susceptible to the "Death March" management style you ask? Let's discuss a negative case and go from there.

I have a new definition of 'Chaos Theory'. Those who don't understand how to develop software will never free themselves from the chaos caused by operating in constant crisis mode.

Have you ever worked for a boss who liked to give direction and expected their group to start running around doing anything because action == progress regardless of direction? Did we do stuff we didn't need to? So what, at least we're doing _something_. is their mantra. Imagine what would happen if we let modern skyscrapers be built this way. The financial backers would revolt because they'd have to write the check for all the re-work; the engineering team would go AWOL because their carefully evaluated design wasn't being followed; the workers would go on strike because of the unsafe work environment caused by the activity-for-activities-sake. If your manager never wants to discuss process (current or future) they might be trying to manage the chaos by dictating constant activity. My theory is those managers feel like they are having to flail like the dickens just to keep their heads above water because they don't want their team to know just how out of control they feel.
Let's call this manager "Suzy Spur" for her penchant for 'spurring' her team to action; her idea of effective management is making sure her cattle-prod has freshly charged batteries.

Now, let's switch gears to a large development project that has it's head on straight. While Eclipse is also a tool that Java developers use to create applications, it also has sprouted a mature project management template for coordinating large-scale (in number of apps involved) software releases.

The Eclipse organization has created a process that is rational, consistent, and repeatable. By thinking through the process beforehand, they do not have to make things up as they go. They release on-time and with high-quality even if that means leaving features behind. Here is a quote from the site

Ganymede is about improving the productivity of the developers working on top of Eclipse frameworks by providing a more transparent and predictable development cycle; Ganymede is about developers helping developers serve the whole Eclipse community

When the executives are clamoring for results, what they really are asking for is predictability. They want to know when they can plan on the next version of their application will be ready for release so they can plan their trip to Jackson Hole (for those without spouses) or Orlando (for those with families). What they don't want is a make-it-up-as-you-go process, of which Suzy Spur is so fond, that will send them to Las Vegas in August with no AC.

In comes "Craig Calm". He acts deliberately, instead of by reflex. He surveys the road ahead and lays out a route which will get him to his destination with a minimum of fuss instead of bouncing over each hill unable to see over the next rise. He prepares the project foundation so the flurry of change means asking different interior designers for their ideas on the finishing touches instead of tearing out walls because they were put up before the wiring and pumbing were installed. He is respected because his team can plan time off because his projects are always on-time or any delays are expiditiously relayed to the proper governance group; instead of reviled due to the ever-cracking whip and constantly worrying about being fired right before a family vacation because the project is always behind the eight ball -- the deadline never moving regardless of the increased workload.

When a deadline doesn't move even though the work increases, that is a classic sign of inadequate risk management. If you (project) manager is not insane, a sliding schedules would be a simple result of project math: Workload divided by resources = timeline. Of course I'm over simplifying but let me use an analogy here. You are in charge of building a dam and one of the project assumptions is the area will get no more rain than the largest amount in the last 100 years. If halfway through the site gets deluged with twice the 100-year-record amount, you do not go to your team, at the waterlogged site, and say "Guys, just work harder" or my favorite "Work Smarter". What the sane project manager does is go to the sponser and say, "We didn't plan on this, we're going to have to start over." It is not the fault of the team or of the project plan when the sponser approved the assumptions and then came up short. The book "Waltzing With Bears" is a fantastic resource on the subject of proper risk management and how it can restore sanity to your project.

So, for whom would you rather work? The insane activity-for-its-own-sake pile-driver or the methodical, consisent, and goes-home-by-five software development veteran?

Stalking a Serial Thinker

Some people think using groups of lists (1 dimensional) , others can think in grids (2 dimensional). I ran across this phenomenon when I was in a requirements gathering session for a complex revenue accounting system. Many of the components of the system had several attributes in common. The example I'll use is a family of four (Mom, Dad, little Gary, little Jan) and their bicycles. One way to describe the bikes is list each of the separately by the owner and then their attributes. For a serial thinker (let's call them Serial Sue), it looks like this:

Bike1
Owner: Mom
Type: Touring
Gears: 15
Size: 26-inch
Color: blue
Make: Trek
Model: Super-Safe Sidewalk
Wheels: street
Accessories: water bottle

Bike2
Owner: Dad
Type: Hybrid
Gears: 18
Size: 28-inch
Color: black
Make: Specialized
Model: Trail-aways
Wheels: knobby
Accessories: speedometer

Bike3
Owner: Gary
Type: Mountain
Gears: 24
Size: 26-inch
Color: red
Make: Specialized
Model: Porche
Wheels: knobby
Accessories: rear view mirror

Bike4
Owner: Jan
Type: learning
Gears: 0
Size: 16-inch
Color: yellow
Make: Murray
Model: Princess
Wheels: street
Accessories: handlebar tassels


Notice how each bike repeated all the attribute names? No big deal right? What if you now need to add 2 more attributes to each bike, or 4, or 10? You would have a lot of editing in your future.

Don't get ahead of me here but another way to organize this data is with a grid (aka a spreadsheet) which could look like this:

	Bike4	Bike3	Bike2	Bike1
Owner	Jan	Gary	Dad	Mom
Type	learning	Mountain	Hybrid	Touring
Gears	0	24	18	15
Size	16-inch	26-inch	28-inch	26-inch
Color	yellow	black	red	blue
Make	Murray	Specialized	Specialized	Trek
Model	Princess	Peaks-r-us	Trail-aways	Super-Safe Sidewalk
Wheels	street	knobby	knobby	street
Accessories	handlebar tassels	none	speedometer	water bottle

In this form it becomes easy to add categories and/or bikes; thus maintaining the list in an efficient manner. The problem? Describing this method to a Serial-Sue will confuse them. They'll ask, "Why go to the trouble of creating a grid, all I want is a list?" You might think that it is a simple matter of just do it they way your boss wants. That is fair but there is more to the story. When dealing with a large list of semi-related things, using categories to subdivide the items can be an enormous help in simplifying the organization and can help bring order out of the chaos.

Another clue you are dealing with a serial thinker is if you show her a grid and then have to explain it. It takes a different sort of brain. Much like how some people can't read maps well, go figure. Watch for symptoms of frustration when showing or explaining a grid of data to someone, it could be that you've botched your data, but it could also be a sign of serial thinking.

So, do you work for/with a Serial-Sue?

Intolerance of Vision

I've always been the type who likes to look far ahead on whatever trail I find myself. When I can see some obstacle, it only seems logical to report back to whomever is in command so they can make appropriate plans. What I've discovered is that some commanders are allergic to news portraying events beyond their mental horizon. "It's not going to happen for a week/month/year, why do you want me to worry about it?" That's a fair argument when you're in the heat of battle but rings empty when you're safe at home, eating dinner in front of the fireplace or when the battle-stations alarm is constantly clanging in your ear because everything is a crisis.

To ignore what lies ahead takes one of two types of people. The first is constantly in battle-mode and never feels like the have the luxury of looking down the road. There are managers who take this to the extreme by operating in this mode all the time and make management-by-crisis their modus operandi. If it doesn't get immediate results, they're not interested. It doesn't matter if doing things the easy way now will create 10 times more work later, the mantra is "why is it taking so long and when can we be done?" Quality, safety, sanity, all take a back seat to expediancy. The second type of person has a devil-may-care attitude and lives with their head in the sand. Worring about what might happen is for those wet-blanket types who keep telling me what to do like "wear your seatbelt" or "quit smoking". Nag nag nag, that's all they do. Can't they stop whining and live a little? While the latter is a case of simple denial, the former is clearly one of short-sightedness.

This brings me to tolerance. Imagine if General Custer had had a scout who kept him informed on the location of the belligerent Indian tribes but Custer got so annoyed by the constant reminders of upcoming trouble that he fired the scout. Having such a low tolerance for long-range vision (of both good and bad news) becomes a grim mistake. Having kept said scout and charging ahead anyway is completely within a commanders decision-making authority. It would not prevent the upcoming catastrophe but puts the mantle of blame solely on the commander. The scout's responsibility is to report what he sees and would be derelict in his duty to stay silent. The commander will be responsible for whatever happens regardless but ignoring information snatches from his grip the haven of excuses and tightens the noose of history around the neck of his legacy.

The deluded commanders ignore harbingers of bad news while deranged commander shoots them. The pragmatic one listens but takes his own counsel. At the very least, having another warm body around means one more person you can hand a weapon when you've circled the wagons and are faced with a relentless oncoming horde.

Do you know someone with a low tolerance of Vision? It'll take more than a visit to the eye-doctor to take off the blinders and open their eyes. Let me know if you discover an effective vaccine for this particularly nasty disease.

Fred Brooks meets Mozart

For some reason, as I started to read this blog entry I thought that a better analogy would be that writing software is like writing music for hire.

Music has well established connections with mathematics. That doesn't mean I'm going to hold my breath waiting for my computer to compose 'The Magic Flute'.

I started to describe the idea to my friend Craig and the more I talked the more apt the comparison became. It's partly ephemeral yet can be reproduced in the real world and its acceptance is controlled by someone other than the writer.

It also depends on those who perform the instructions. Maybe coding is like writing a symphony. You can write as grandly as Bach or Mozart but if the players are terrible, so will the performance. The same goes for good players using poor instruments, or good players using good instruments but having a poor conductor, or having all the players and conductor as first rate but the audience is completely tone-deaf.

Maybe we have Code-Cowboys instead of Virtuosos or Divas.

Ok, instead of a symphony, it would be an opera. In addition to the symphony (for the music) you have a company of actors with which to contend.

My friend Craig chimes in with: and a director

Now you're getting it.

Think about estimating how long it would take to put on a production of an opera that had never been done?

The estimate would be pretty worthless because it depends on how long it takes to do the casting, figure the lighting, blocking the scenes, creating the scenery and all that is dependent upon the budget.

Craig:Yes - building the stage is like erecting the infrastructure for a platform not currently used. You have to set up sound, seating, temperature, etc

Talented individuals can create great performances, they can make it seem effortless. We even have terms for these people in the arts. An singer can be a 'diva' and a musician can be a 'virtuoso'. When we limit the scope to the talent of a single individual we can get good material but what marks transcendent art is when the creator inspires the performer using the sheer force of ideas alone.


Music expresses that which cannot be said and on which it is impossible to be silent. ~Victor Hugo

Can this be the equivalent driving force behind the open source movement? There is an idea that needs expressed, the code, compiler, and CPU serving as the artist's paints, brushes and canvas. The Software Craftsmanship movement has much in common with the artistic temperament.

The Codewright Mentality revisited

In my last post about the Codewright Mentality I had some fun at the expense of consultants. When my friend Paul, whom I met while he was a consultant, pointed out my over-generalized stereotyping of consultants, I felt that I needed to clarify my point. Being a consultant does not imply lacking drive to improve. I was going for humor but instead stepped on some toes. Don't get me wrong, if there are toes that need stepped-on I'm all for it, but this time he had me dead-to-rights.

Maybe I should have said contractors instead of consultants but that would have traded one set of toes for another. The truth is nobody has a monopoly on the lack of drive; this means contractors; as well as consultants; as well as full-time employees. I'm not sure there is a consistently used differentiation between consulting and contracting. The behavior in question is, for contractors they either did what we asked but no more or for consultants they gave us the answer to our question but no more. You would hope that if there was a better way to do something or a better question to ask, the contractor / consultant would mention it. Both assume the client being open-minded enough to listen. What we're describing is being optimistic about the intentions of those involved.

Paul's observation:

I also have noticed a tendency to blur the distinction between a consultant and a contractor in the IT world. I tend to perceive "contractors" as being hired for very specific skills (C++, Oracle, whatever) and as being mostly just complements to a team, rather than a facilitator/leader. The "contractee" often doesn't make the distinction because "consultants" are, like "contractors", just "not full time employees but being paid by us, directly or indirectly". Doesn't much matter, I suppose, so long as both parties agree on expectations.

I give Paul a lot of credit for helping me start thinking about programming as a craft and worthy of study in it's own right.

Here is what Paul had to say about what it means to be a Codewright:

For me, codewright-ship is...

• About not settling for intention-obscuring code
• About not settling for inarticulate requirements
• About seeking out other codewrights to learn from
• About seeking out codewright apprentices to teach
• About not settling for code without tests
• About believing there is something noble about programming
• About tuning out the voices of developers past who want you to think that coding is monkey business, or that quality is the testers' job, or that you have to figure it all out ahead of time before you write even one line of code.
  
• About realizing that simplicity is beautiful; and that the simplest things that could possibly work probably isn't the first thing you think of.
• About building systems people are passionate about using.
• About realizing that developing such software is difficult-- that maybe it shouldn't be easy -- that maybe gains in software productivity needn't or can't keep pace with such gains in hardware performance
• About creating sustainable solutions -- software that future maintenance programmers don't mind maintaining (as opposed to the mind-bogglingly putrid legacy code much software is).

Just Flailing Away

You're back? I'd better be careful. If more people start showing up to these group therapy sessions, they might start charging admission. That would clear out this place and I'd be able to go back to tilting at windmills. Tempting...

I was just thinking (I know I know, *slaps hand*, stop that!) about training someone to be a good developer. The accepted mantra is always, "Send them to training". But even when training is available, it always seems to be too early or too late. Have I ever told you about my friend Jack? I have? I'll act like I didn't hear that. Jack is a developer at a large company. They embrace new technology the way someone lost in a desert for days embraces a cactus; so thirsty it is easy to rationalize, "It won't hurt that much and I'm really thirsty and want a drink right now!" They can quench their thirst but its a prickly proposition. Anyway, Jack was telling me about getting training at work. Ok, he was ranting to beat the band but I don't want you to think he's crazy, that's reserved for me. Jack gets put on this cutting-edge project using new technology on a new platform developed with new tools. So Jack gets sent to training and then doesn't get to use it for months.

[From the back row]:*boo!*, *hiss!*
What are you griping about, you get what you paid for. If you want good comedy, go somewhere that'll demand some lucre. I'm just here to hear myself talk. The jokes are free, just like admission.

So back to Jack. Jack's training showed him all the bells and whistles. You know the drill. How to save a file: "If you want to save a file, hit the [Save] button!" or how to color your text, "This button will turn all your text blue!" More 'how's than a tribe of Native Americans in a marathon of bad spaghetti westerns. I've always preferred my learning to be more about 'why' (Pardon my French) than 'how'. A book or on-line tutorial and show me 'how'. My search for ones that can tell me 'why' (Sorry, about that) sometimes makes me feel like I'm panning for gold and only finding fools-gold. Finding such a rare breed "Look, she can clearly explain why I would want my text blue!" (Excuse me! I must have a rude tic or something.) can feel like finding that one gold nugget that makes it all worthwhile.

Even when Jack came back from training, whenever he'd try to apply what he learned, if it slowed anyone down or required them to change how they worked, he'd be met with "We don't have time to learn how to use that fancy new tool! Just do it the way we've always done it."
Hearing that story, I couldn't help but imagine how that would work in real-life. Imagine your hometown city pool (Hey, we're imagining here! I don't care if your city was too poor to have a pool.) where you went to high school, complete with life-guards, deep end, diving board and lots of squealing kids among other things. You get a job there as a life-guard even though you can't swim. They tell you they'll provide the training. When you show up to work, no training. Your boss tells you not to worry, no one every drowns anyway. You take him at his word until the day the Senior Class President "Johnnie" shows his true colors and throws the class geek's kid brother, who also can't swim, into the pool. Jane, the head cheerleader, screams, "Johnnie! Don't you care that he can't swim?!?" To which Johnnie replies with a shrug and a disaffected scowl, "Nah! That's what life-guards are for." Ignoring his bad grammar, you realize that he means *you*! Jumping in, you flail your arms to keep afloat and manage to make your way over to the little geek where he grabs onto you with a death-grip. You keep from getting water-logged long enough to get back to the edge of the pool where everybody's safe and all is right with the world; until you run into your boss later. "What do you mean you want to go to swimming class?" with a tone that implies that it's your fault people need lifeguards that can swim. "We don't have time for you to learn how to swim." Blithely deflecting your eloquent recounting of the days incident, "It was a fluke, a million-to-one. Go back to work. What are you worried about anyway, everything worked out ok, right?" That night, when you go to bed your dreams are filled with flailing arms and water being flung everywhere and you wake up in a cold sweat. You feel thirsty but don't know why.

Wake up out there! The snoring is so loud someone might come and wonder what the commotion is all about. And no, the concession stand did not bribe me to tell that story.

So, what does that leave? The next time you want training (or want to apply training to real-work), remember Jack and his developer cohorts, struggling to keep their heads above water, their cubes like mini-pools, and they're all just flailing away.