InformationWeek's IT Salary Survey

InformationWeek and ComputerWorld both run annual salary surveys for IT. InformationWeek's was just published in the 28-Apr-08 issue. I like to read these because they have some interesting things to say, but you have to be careful about treating them as the truth. There was a famous thread a year ago at the JoelOnSoftware.com forums titled "How much do you make?" and it ran for weeks and got cross-linked by lots of sites. It's interesting to see how different it was from the InformationWeek survey.

Statistics
First, you have to be careful about the demographics of the survey. InformationWeek says there are 3.8 million IT workers, but less then 10,000 responded to the survey. Not exactly a confidence-inspiring sample size.

The gist of the InformationWeek survey was that salaries were down a bit, as were bonuses. There were some interesting trends noted, that hiring is actually up in the lower salary ranges for positions like help desk work.

The JoelOnSoftware.com thread was filled with people saying they were making a healthy six figures, but that forum is going to be skewed toward experienced developers rather than a mix of all IT professions from infrastructure roles to management. Interestingly, many of the more well-off programmers at the JoS forums hail from New York banking shops.

Unsettling but Perhaps not Surprising News
Hot on the heels of my training class, the thing I really didn't like to read in the InformationWeek survey was that training continues to be a second-class citizen in the realm of IT benefits. I've said it before, if you don't invest in your people it will come back to haunt you.

But then again, maybe that random sampling of 10 thousand people just had it bad. In ComputerWorld's annual rankings of the top 100 companies to work for, education is still a serious benefit for those employers. Good luck getting into one of those companies if you're not already there though.

We don't have Time to do it Right the First Time and We have even less Time for Training
Why doesn't corporate America want to pay for training? One of my theories says it isn't about cheapness, though that is a factor. I still think it's impatience. It takes a long time to get a person trained and productive in a completely new technology stack. It's not impossible, but it certainly seems slower than signing a contractor on that already has the needed skills.

If what the InformationWeek survey says is a real trend though, then perhaps Nicholas Carr was only half right: it's not just that IT doesn't matter - people don't either. Companies can apply the software as a service model to people too. Just pick up some free agent off the waiver wire and dump him when you're done; no training or benefit expense headaches necessary.

But we have this already don't we, between onshore and offshore contracting? And people as a service doesn't work often. It never works as advertised. How many Oracle or SAP ERP implementations have incurred cost overruns? How many have left people happy? That generic out-of-the-box approach leaves a lot to be desired, doesn't it?

Your best bet is to get good people, train them in your business and also help upkeep their skills. It's like the difference between washing your car yourself versus paying someone else to do it. Will that contractor put as much time into detailing your vehicle as you would? Would he or she know the quirks about not using abrasive polishing agents on your custom chrome wheels? Maybe, but if you did it yourself, you'd go the extra mile and you'd also know what parts of the car to be careful around, like that loose handle or that spot that needs rust protection. There will always be differences between companies and how they operate. Who would understand your business better than people that have a stake in its survival and who support it every day?

Amid these salary survey discussions, something to remember is that paying for good people isn't just a cost; it's the cost of doing business.

Course review: Business Analyst Boot Camp (ASPE Tech)

Training Day
Computerworld's editor, Don Tennant, wrote a couple of interesting editorials last month. In one, he took IT workers to task for not being more active in developing their skills to stay competitive with the global marketplace. Actually, he's done that several times in the last few years. However, he was also good to follow up that editorial with some of the feedback he got, and agreed that companies that are quick to outsource ought to also be fair enough to also assist in-house resources with training. This article dovetailed nicely with some of the things I'd been saying earlier in the blog about companies not investing in internal staff, and how some of this might be due more to impatience than to cost. More on that in a future rant.

Provider
The subject at hand is the Business Analyst Boot Camp offered by ASPE Technology. ASPE sent me a brochure about the class and I was pleased with the breadth of subjects it covered. I was especially pleased with the course materials; more on that in a moment. The company offers courses across the spectrum of software development and project management. I won't go into further details on the offerings, you can visit the web site for a course list and pricing.

ASPE appears to work like most third-party training providers I've seen, meaning that they don't staff a set of full-time employees as instructors that continuously learn and teach a specific product. My impression is that ASPE handles the administrative overhead of developing the course syllabus, selecting the materials, and organizing the marketing and scheduling. The instructors are more like contractors that plug into areas of demand depending on their qualifications, locations, and course demand.

Logistics

• The course is four days long, 8:30am to 4:30pm. Due to some of the class leaving early to catch flights we finished in just under four and sped up the last day's subjects.
• My course had ten students and was in a dedicated training facility.
• Students came from various parts of the US and 80% were from the energy industry. Seven were business analysts, one was an IT manager, and two were developers.
• The course is recognized by both the International Institute of Business Analysts (IIBA) and the Project Management Institute (PMI) and is worth 28 development units toward certification in either of those organizations.

Instructor: Mini Kirtane

Kirtane is a former developer that moved to the business analyst (BA) role and now teaches both project management and BA courses. She still does contract BA work for various clients. She's quite personable and entertaining, but I really appreciated that she was able to speak to both the theory and practice of the materials. She has her Certified Business Analyst Professional (CBAP) qualification. She often quoted from her experiences with both public and private institutions. She also teaches other courses for ASPE.

She communicated well and did a good job of fielding questions. She's comfortable with the course materials. We could occasionally get off track but she kept pretty close to the course guide and schedule. I liked that she did not get into heated debates about classic vs. agile approaches and recommended that students use what works for them.

Course
There was a lot to cover in the four days. Key subjects:

• Foundations of Requirements Development - BA skill set, term definitions
• Project Initiation - Identifying project scope and stakeholders and goals, using a context diagram to identify actors and goals and high-level data flows
• Eliciting Functional and Non-functional Requirements - Using various process analysis tools, interviewing techniques, data definition, taking into account the need to process CRUD functions (Create, Retrieve, Update, Delete)
• Documenting Requirements with Use Cases - Information and exercises on writing and refining Use Cases
• Creating and Presenting the Requirements Specification - Sample formats of requirements documents, some discussion of thorny issues like traceability, discussion of communication

Each day contained several topics, generally presented in the format of theory followed by exercise. Students worked individually and also in groups.

I liked that the first day did a nice job of identifying the responsibilities of a typical BA and Kirtane made sure one of the themes of the course was that BAs are not "order takers." When a party presents an idea for a system ("We'd like a new system that runs on gold-plated portable devices because that would really be cool") she was very clear on the point that a BA's first job is identifying the business needs and goals because the idea may not be salient given business risks and resource limitations.

Another excellent point that I appreciated as a developer was the identification of how a good BA delivering good requirements can save maintenance hassles down the road. This slide from the class says it all.

Another benefit is the course's awareness of the PMI and IIBA. There is information in the course relating the BA work to specific phases of the PMI's project management process.

Time is spent also studying the sources of requirements data BAs must work with and how to use techniques and tools to give the requirements shape. Everything from interviewing to using various diagrams. The class discussed ways to disarm reluctant subject matter experts and how to channel the ideas of more enthusiastic ones without without letting them compromise the bounds of their role.

New for me was the work on things like context diagrams and Use Cases. There were several tools presented for identifying requirements; no one tool is the answer and often a combination is needed. I was looking forward to putting together the requirements document, but unfortunately our rushing a bit at the end meant we only reviewed this information. However, I still have the course materials to refer to. The exercises were also helpful in reinforcing ideas and showing that getting requirements isn't any easier for a BA than it is for a developer.

I also liked the course concepts of functional versus non-functional requirements. Strangely, when I went back to the course guide to look up this section there was little to identify it in the section where it is named. We did discuss it in class, but in the guide I had to go to the sample requirements document in the course guide to get some details on what a non-functional requirement is.

I'd done some requirements as a developer before and one of my goals coming into the class was to learn how to use a mixture of graphics and text to more concisely capture requirements detail without creating a huge document and without losing the speed of just typing text. I don't know that I met this goal because we discovered in the class that with requirements you could keep going into more and more details. My experience has been that the more detailed the requirements document can be, the better the information is for the developer. Yet, time constraints often limit the detail, and I'm still trying to reconcile how to be both detailed and agile. The Use Cases may help as they use text in a semi-structured way and with brevity as a goal. But as you expand a Use Case to handle exceptions, it can grow to be as complicated as pseudo-code. Cockburn advises against getting too detailed because the document then becomes unwieldy, a point he doesn't have to make twice to anyone.

This issue of being able to determine the appropriate level of requirement detail is one I struggled with in the class and will continue to work on. However, the context diagrams and activity diagrams and Use Case diagrams may all serve me well in my work.

Traceability, the concept of being able to reference the requirements at a later date and keep them updated for changes, fascinated me. Sadly, this is almost as hard as keeping code updated. There are expensive professional traceability solutions out there, but it appears that with regard to conventional documents the best traceability tool is still a human being.

Materials
This is an area where I felt ASPE distinguished itself. All the third-party courses I've taken include a custom course guide that is essentially a collection of the slides used to navigate the course and may include some additional worksheets for the in-course exercises. This is provided in the BA Boot Camp and still works as a useful way for the student to follow along and take notes.

The BA Boot Camp also came with some additional texts for students to take home.

• More About Software Requirements by Karl Weigers
• Writing Effective Use Cases by Alistair Cockburn
• The Software Requirements Memory Jogger by Ellen Gottsdiener

For what it's worth, all of the books are rated 4 stars or above in the user ratings on Amazon.com. Even if they weren't, Cockburn's name is a respected in the world of agile development.

Each of these provided detail and reference for future use. This is especially important because BA Boot Camp covered the gamut of BA work from the project initiation all the way to the delivery of a requirements document. A four day class isn't long enough to delve into all the details, so the inclusion of critically regarded books is a big plus. There are clear links in the course guide back to the external texts. This is very handy for future reference.

Finally, all necessary peripherals were included: binder, worksheets, pens and pencils.

Facility
The Texas Training and Conference Center was great and is well designed for courses. There's an antechamber for each classroom that contains a set of phone cubicles and a serving area. The antechamber and classroom are separated by a door so when it's closed students can make calls and the TXTACC staff can work in the serving area with minimal disturbance to the class. Each class has ample seating space, desk space, and accouterments such as a projector, easels, and whiteboards. The staff is accommodating and responsive. If we ever had technical issues, someone quickly addressed them. Each day the staff kept the serving area stocked with beverages, a continental breakfast, and an afternoon snack.

Summary
I learned much but still had some questions at the end. I definitely gained knowledge of Use Cases, gained a better definition of the BA role, learned several new tools to help illustrate issues and derive requirements, and I have some fine books to continue my education with.

I enjoyed the class and found Kirtane's insights and tips that weren't in the course materials good to have.

The Vanguard

Giving Props to the Business Analysts
I am taking a slight change in direction and will be reviewing a recent class I took. I'm fortunate to be working for a company that is willing to invest some funding into developing its people. I attended a Business Analyst Boot Camp offered by ASPE Technology. To preface that, this entry is to pay some respects to the business analyst (BA) world and explain why I feel developers can benefit from learning BA skills.

In the class, I received exposure to several aspects of business analyst work. I've been primarily a developer most of my professional life, but I will give my first employer, EDS, some credit for trying to teach us budding systems engineers BA skills. I've since worked with several companies and many different BAs. BAs are like developers: there are many out there, but only a minorty are outstanding. And when you find a good one, he or she is worth keeping.

At the Starting Blocks
Business analysis is where it all starts when it comes to a software application. It's the tip of the sword and while good work at this stage can be compromised by deficiencies in development, testing, and change management issues, bad work here will almost certainly lead to problems in the overall effort. Only the presence of experienced developers and project managers might be able to still guide such a project to a successful end, and they would do this by willfully partaking of some of the BA duties. In fact, this has happened on many of my past projects and it was when the developer was willing to hash out the business issues and processes rather than make assumptions that downstream pitfalls were avoided.

That leads me to describe my past experience with BAs. Some had decent domain knowledge and were good communicators and had helpful attitudes. Some even had technical skills and that could be a boon. But I've worked with more than my share of people that probably shouldn't have been in IT, much less BAs. I've met a few that simply were non-factors; they didn't participate, they didn't provide timely answers for developer questions, weren't too hot on requirements documentation, didn't get involved in testing or user training, and didn't forge relationships with stakeholders. In effect, if they at least had a helpful attitude, they were glorified secretaries that organized meetings.

That is why I as a developer took this course. The BA skillset includes things like requirements definition, interviewing, conflict resolution, project initiation and elaboration, meeting management, and a whole host of both written and verbal communication skills. All of those things are valuable skills even if you're not formally a BA. A developer, even with the assistance of a good BA, will still have to be able to elicit requirements. There are always going to be missed gaps and unforseen issues, especially on complicated systems. Remember, making software is easy, but making it right is hard. Being able to perform these duties just makes a developer more rounded. In the agile development methodologies, this is even more important because there might not be a BA; the developers and functional owners are co-located and work together in real-time.

Quality is Everybody's Responsibility
Not to belittle a good BA, but most of the BA skills are ones that can be harnessed by anyone that wants to participate in the role (in fairness, I earlier wrote that anyone can become a programmer too). So I took the class because my experience has proven that when a developer is materially involved in the requirements research, it leads to less risk that the software will fail to meet those requirements. This is one of the points that defines software quality.

Some developers would not like this. They would say, "I don't want to document the requirements, I'm a developer." What they really mean is that they'd prefer not to document anything and they would rather just hack away.

For the developers that get outstanding requirements handed to them by either a BA or a developer willing to do BA duties, fine. But at least in the US, conventional wisdom is that code-only developers will become rarer as companies look at offshoring models. And the reality is that most of the time, there isn't a tight requirements document handed over. So, to uphold some measure of quality, good business analysis must be done and it doesn't really matter if it's done by a BA, a project manager, a developer, a functional owner, or a raccoon. If it's done, and done well, it makes a difference. Quality is everybody's responsibility.

In the next entry, I'll write about the class.

Code is Shit

Please forgive what appears to be a regression in my language usage. But I'm working with more code written by an expensive contractor and I've just got to say this because bad code is definitely a source of more overtime. It's hard to manage and hard to decipher and suffers higher risk for defects. I'd told this individual several times to try and reduce the complexity of the code and several times this advice fell on deaf ears. This individual is smart, and that's part of the problem. Code that doesn't seem complicated to her is in fact very ugly to the rest of us on the team; not necessarily because the rest of us are stupid but because we will live with this code far longer than the person writing it and well past the point when this person is no longer around.

How can I do a better job of explaining the difference between using introductory versus advanced techniques? Maybe I have to start with changing the attitude about code. Instead of treating code as something beautiful, which it rarely is, perhaps I should start calling it shit. Oh my, a four letter word!

However, there is precedent for my approach. J. van Mannen is a criminologist who has published books on his studies of police work. He has a term he uses to describe any difficult individual law enforcement must deal with: "The Asshole." I'm not kidding, you can look this up. I learned of this when I took a criminology class at UC Irvine taught by James Dombrink.

Just as van Mannen could find no more concise or accurate a term as "the asshole" to describe this element of the population, "shit" is a fine way to describe code. Think about it: would you rather manage a cup of rabbit turds or shovelfuls of horse manure? This also ties in nicely with what expert developers will tell you about the difference between novice and advanced developers. New or thoughtless developers are usually all about hacking away and adding what they can. Increasing the amount of code is considered good programming and even fun. But an experienced developer understands that the best practice is not about adding code but reducing it.

Code is shit. Improving it is not about what you can keep piling on, but about what you can take away.

How Developers Learn

I took a sarcastic look at developer motivation to learn in the last post, but let's take a look at how developers learn. First, let's detour briefly to the realm of behavioral science, where David A. Kolb created a chart categorizing learning styles.

I'm leery of the categorizations that social science tries to put on humans. You can't stick people in boxes because some parts of them won't fit and the ones that do might be trying to climb out. But I agree they are useful for identifying general traits and tendencies. You've seen these things before, possibly in your management or project management classes. Similar charts for categorizing personality types are used to help you empathize with teammates and understand better how to communicate with them.

David A. Kolb
Kolb wrote Learning Style Inventory in 1984. There's a nice summary of his theories of human learning at Don Clark's Performance, Learning, Leadership, & Knowledge site. Essentially, Kolb's theory is illustrated on a two dimensional grid.

One dimension represents a continuum that rates a person's tendency to be task oriented (doers versus watchers). The other represents a person's emotional state in learning (expressive versus detached). The extremes of each continuum yield four types of learning style:

1. Concrete Experience: People that like this learning style learn best from the experience of others and information they receive hands-on. They favor anecdotal lessons, peer feedback, and direct experience with a situation over theoretical study.
   


2. Reflective Observation: This learning style represents those that learn by watching others work and can ponder how it affects their life. Learners of this style appreciate having a mentor to learn from or an advancement structure where they can serve in apprenticeships and see how others perform a task.


3. Abstract Generalization: This is learning via deep analyses of published theory and case studies. Learners preferring this style tend to reflect heavily on hypotheses and compare and contrast the theoretical against their own personal experience.
   


4. Active Experimentation: Learning here is achieved through the "school of hard knocks." People using this method to learn like to jump right in right away. They probably don't have the patience to absorb large amounts of theory or to poll peers for advice. But hey, some situations call for Dick Marcinko and some call for Robert Gormly.
   

The intersection of the dimensions creates four quadrants that generalize the types of people based on their learning preferences.

1. Theorists: These people are readers and thinkers. They prefer book study and tend to think in abstract theory rather than practical application. They might be what Joel Spolsky calls Architecture Astronauts.



2. Pragmatists: Like the Theorists, Pragmatists will use abstract learning to study theories, but they are more interested in ultimately how they'll apply that theory to practice.
   


3. Activists: Activists like to learn by just diving into something and learning as they go. They like to experiment and may be too impatient for the books the Theorists would use, instead relying on immediate feedback.
   


4. Reflectors: Reflectors, like Theorists, need time to ponder and come to grips with a subject. But like Activists, they depend on concrete experience to help them make sense of things and determine how they'll apply them. Theorists use observations and studies to develop and challenge a theoretical model; the Reflectors use their observations and intuition to learn and apply themselves.
   

It sounds interesting and I do find Kolb's work fascinating, but then again maybe it's all a bunch of moldy elephant crap. As I said before, you can't categorize human beings with cookie cutters. Not all criminals are, as the liberals would have us believe, simply lonesome, misguided kids that can't help themselves and therefore shouldn't be locked up. Yeah, whatever. Maybe that's true for Dostoevsky's Raskolnikov, whose guilt drove him to turn himself in, but how many times does that happen in real life? I digress. The reality is that a person can use any of those learning styles and belong to several of those categories.

Learning Through Code
How can you help improve your company's applications and reduce time spent fighting fires if your developers don't have time to learn or advance their skills? If they're not motivated to do it themselves? After years fixing other people's code, and realizing that mine at times has been even worse, I think there are a couple of tactics that can help.

• Document, Dummy!
  I know. I harp on this all the time. And I may be one of less than 20 developers in the world that actually care about it. But would you work on an engine without a Chilton guide? Would you build a house without a blueprint? Even a LEGO model without the instructions?
  
  Then why, with something as complicated as software, would you jump into 100,000+ lines of code without a map? I know the answer already: because the knuckleheads that cooked up that pile of spaghetti didn't leave a recipe behind! Forget it. I'm done talking about user documentation, technical documentation, and training. If you don't value it, that's your problem, and good luck with that as your application grows in complexity and your users start spreading across time zones.
  


• Get a Decent Lead or Architect
  If you can't get a decent road map for a project, at least get a decent foreman. There's a reason young lieutenants are told to defer to the platoon's senior non-commissioned officers: experience and proven competence. This is especially important when the team is navigating the minefield of a new paradigm such as when adding substantially new chunks of functionality, porting the application to a different technology, or even retraining en masse to a new language. A good lead can help the team make good decisions and bypass common pitfalls. But leads aren't perfect; if the team is making the jump to something really different, get a consultant in that has proven expertise to work with the team. This is especially important because of the next point.
  


• Make Version 1 as Clean as Possible
  You want to know how developers learn? Some will read books, some will listen to advice from the lead or architect. And some won't do either of the above. Maybe they're not interested in the time it takes outside of work to read books or take classes. Maybe they're self-conscious and feel that asking for help makes them look stupid.
  
  But every developer eventually has to dig into the code. Every one. Has to, at some time or another. It doesn't matter if they're supporting an old app or just looking for ways to write a new one, they'll likely try to cut-and-paste to save time. And this is where you can do good things for them if you've got good people leading the way. Regardless of their preferred learning methods, all developers learn from existing code. That means that if the bulk of the code is fugly, average developers are going to propagate those techniques forward.
  
  Good developers will try to improve things; they too cut-and-paste to make deadlines, but bad code smells will trigger a reflexive action and they'll at least try to clean it up a bit.
  
  Average or less experienced ones may not introduce worse techniques, but cut-and-paste still deteriorates the code because it expands the existing technique's use. That hardcoded routine that was already a maintenance hassle is now a maintenance hassle in two or more places.
  
  Poor developers will make it worse, by cobbling on even more hacks on top of the copied code.
  
  If you don't have strong developers maintaining an application, it's going to stay about the same or get worse. Everything from data access and variable naming standards to GUI techniques and script formatting will likely be carried forward from the original foundation. That means the application is well served by a decent version 1, assuming the software is going to live long enough to need continued maintenance.

Still, making Version 1 as clean as possible is no guarantee of a happy, extensible application. I've seen apps that had a decent first cut, but poor follow-on developers compromised it over time. And sometimes, the first cut is necessarily rushed and you could make a case that a good lead developer/architect is as valuable in the first several refactorings of the code as he/she is in the original design. Writers have an adage that applies here: The best kind of writing is re-writing. Perhaps the best kind of programming is refactoring.

Knowledge is Power
Software is hard. It almost always grows in complexity as it evolves, sometimes by design and sometimes by misstep. You can't do everything, but do everything you can to give your developers an edge against chaos. Lobby for thorough requirements, demand proper resources and tools, and get a good project manager to enforce scope control. And educate them, knowing that each person has a different blend of learning styles. Institutionalize the team's knowledge through documentation and impress on them the importance of keeping it updated, hold technical sessions, live training for both business and technical topics, give them a book budget, and for crying out loud, don't always say "No" when they ask to take external classes or attend technical conferences.

What Motivates Developers to Learn?

What Kind of Learning Developer are You?

Getting to a place where a person calls himself a developer is just part of the story. The other half is really about how he develops himself once he's in his career.

Ultimately, it depends on the kind of person the developer is. I've seen a couple scenarios in my experience:

The Renaissance Man
You know the character that is always the nemesis of the everyman hero in romantic comedies?He's the guy that looks like he's going to get the girl the hero wants because he's a double PhD in law and medicine, inherited more money than you'll find in the Denver mint, plays guitar, can charm cats, is an award-winning chef in his spare time, owns stocks that only go up in value, and looks like he walked off the cover of some glossy magazine. Oh yeah, he also knows every language O'Reilly has ever published a book on and can work at a high level of mastery.

Yeah, that guy. Not many exist, thank God, but these guys aren't just lucky, they're also deeply talented. They are the Mozart to your Salieri, and you can't do anything about it. Programming is well served by people capable of blending outstanding memories with quick minds, an ability to manage complex concepts, and organizational skills. Most of us have some of those things but not all of them. What does that mean? It means the Renaissance guy can study less and learn more because it comes naturally. So for him education doesn't require quite the investment of time it does everyone else. It also doesn't hurt that these guys make the effort to learn and can apply what they learn in their craft and their lives. That's what makes them Renaissance guys; learning isn't some uphill battle they do to try to get ahead, it's just a part of who they are. And it isn't just programming crap. These guys seem to learn everything.

Management advice: Don't worry about these guys, they'll take care of themselves. They're probably already making more money from their side businesses than what you pay them.

The Nerd
Nerds are en rapt by the whole world of software and computers. Unlike the Renaissance Man, for whom learning is natural, the Nerd has to work at it. The Nerd tells himself he enjoys it, but that's just a defense mechanism to deal with the fact that again unlike the Renaissance Man, the Nerd is socially estranged and isn't doing much else on Saturday nights. Learning about new techniques and technologies is above rejection on the entertainment scale. Fortunate Nerds work for companies that pay for the cost of education. But most are like the other 80% of the world's tech workers, where IT is considered a cost center, and they'll have to learn on their own resources. But either way the drive to learn is self initiated and they seek knowledge of their own volition.

Management advice: Nerds make great employees if you can handle their eccentricities. They won't make a jump to sales anytime soon, but they'll do good work and they're reliable. Do what you can to support their interests in learning. It'll boost their morale and benefit the organization.

The Resume Builder
This developer's strength is that she is always looking forward and cognizant of industry trends. The weakness is a desire to always be at that cutting edge and a fear that working on the old stuff is death in the marketplace. While there is some validity to that fear, I'm still seeing systems that run on COBOL, so its death, for those that are proficient in the language and willing to work with it, has been highly exaggerated. The same could be said for FoxPro, pre-.Net Visual Basic, PowerBuilder, and C++.

The Resume Builder is always learning, but unlike the Nerd and the Renaissance Man, the Resume Builder never develops deep proficiency. The Resume Builder, currently using language X, will be satisfied with a year or less of experience with it, and even at the day job, will be stealing time from work to study language Y. When an opportunity to use language Y appears, at the same company or elsewhere, the Resume Builder will move on. Once entrenched in her new position, the Resume Builder will begin studying hot new language Z, and will be ready to move on again in a year.

The Resume Builder's resume is indeed impressive, with every programming language conceivable on it. But what the resume doesn't tell you is that the code the Resume Builder wrote wasn't very high quality. It might have been Visual Basic, or PL/SQL, or Java, or C#, but it tended to solve problems the same way in each language, rather than using the language's strengths. It would include T-SQL that used lots of cursors instead of set theory or it might be an OO language where the methods were each 500+ lines of spaghetti code instead of smaller, logically partitioned components. The resume also doesn't mention that the Resume Builder, busy moving between languages, tends to repeat the same mistakes in each new language.

Finally, the resume also doesn't tell the story of the Resume Builder's poor motivation while working with language X. Any assignments in language X were done quickly and with a band-aid approach. Sometimes a band-aid approach is the correct tactical response when the preferences of a developer and a project manager clash but everyone wants to stay employed. The actions of the Resume Builder aren't of that type; they don't leave behind a rushed solution with useful documentation for those who must follow; they leave behind a train wreck caused by neglect for maintenance.

Perhaps I shouldn't be so hard on the Resume Builders. At least their learning is still self motivated, even if the motivation is for the next job and not necessarily for building quality solutions. Frankly, the Resume Builders probably don't care what I think. They're too busy counting their money.

Management advice: Nope. I know you wouldn't listen to me anyway because you keep hiring these guys.

The Anchor
Sometimes developers don't care to learn. It's not that they won't or that they don't enjoy it. They might even like it, but they're not motivated to do it regularly on their own. This is because learning involves substantive effort outside of work. And that's an important distinction I haven't mentioned: learning job-related skills on the job versus learning them as an extracurricular activity.

The Renaissance Man learns with ease anytime, anywhere. The Nerd has to work on it but typically doesn't have a problem committing personal time. The Resume Builder might also do it at work and at home, but prefers to bootleg time from work (and I don't mean bootleg in the nice 3M way, where bootlegging led to the creation of the now ubiquitous Post-It Note). The Anchor will plod along at work, primarily doing work, and when the bell rings at 5pm, he's only doing work at home if it's for a production emergency. The Anchors will learn if someone is forcibly hauling them through the water or holding their hands through a software learning exercise. But it had better be on company time. Left to their own devices outside of work, they'll opt to do something else they find more palatable.

There's nothing wrong with the Anchor's philosophy. It's rather laudable in a work-life balance approach. However, learning isn't really about work even if it's about work-related skills. It's about self development and furthering one's ability as a developer. If someone is too busy at work to learn new things that help both himself and his employer, they'll both be endlessly mired in the same approaches with the same problems. Any improvements from this camp will be rare and of incremental value. Having lots of these guys means that instead of building a staff of Renaissance Man wannabes, you'll have a staff of guys that do as little as possible. They'll never sufficiently refactor the software so that they can spend more time furthering the company's strategic goals and less time fighting fires in overtime (see, I worked the overtime angle into the post after all).

Management advice: Anchors aren't going to lead the way in evolutionary improvements for the organization. They can be reliable in some roles, but be careful about putting them in positions where they are going to make decisions for software projects of considerable risk and complexity.

Keeping it Real
Despite some grains of truth, the above was a largely humorous look at different learning motivations for developers. The truth is that you can't cleanly and completely categorize any person. I myself could have fit into any of those categories (except for that Renaissance thing) at different times in my career depending on my level of maturation, experience, and the environment.

That's enough about intrinsic motivation. Next time, I've got some thoughts on how developers learn.

The Difference a Year Makes

I've done the very thing a blogger isn't supposed to do. I went nearly a year before posting. What happened?

IT and Happiness
A job change can always be a time sink. I made a decision last year to trade a little money for some intangibles. I've been busy as blazes trying to wrench a big project into order. Was the change worth it? I think so; as I tell my friends, you're not supposed to be able to buy happiness. But I sort of did that, not by buying it direcly but by giving up purchasing power in trade (a fancy way of saying I took a pay cut to make the move).

A theme I was supposed to pontificate on last year was what happiness means in IT. What a pretentious bastard to assume I could know such a thing, huh? I'll take a stab at it anyway, because if nothing else, writing is cheap therapy.

On that note, and given my recent experience, let's talk about money. Everyone needs it even if they don't love it. And you know what? I think everyone loves it even if they say they don't. Not everyone loves it equally, but it means a lot in a world where things tend to get more expensive, not less. But it's an important part of any worker's life, so here's the truth about it from my perspective.

How Much is Enough?
That's what employees and employers want to know, right?

Employers, you don't have to be a top compensator, but do keep abreast of the salary surveys and make sure you're not too far out of the loop. Seriously. And be willing to boost your long time loyal veterans if they're not up to the market standard, or they'll leave and do it themselves. If they're not smart enough to keep up with what's going on, do you even want them working for you?

Employees, keep an eye on those salary surveys but keep a decent perspective on reality too. Are you really delivering the quality a 15 year senior person is supposed to be delivering? Are you being honest in your assessment of yourself? In the end of course, your network may have more to do with your career success than your ability. How much is enough? That's ultimately up to each individual, but I believe most are reasonably happy if they are enough above breaking even to live comfortably. They're even happier if they can get far enough above that to have a savings account and live with some minor luxuries. For most developers, that's a good spot to be in. Money above that point is gravy, but isn't worth having if you have to give up having a decent supervisor, good working conditions, and challenging work that engages you.

The Intangibles
When you get older, you realize that money is important, especially in a society where it is the main bartering tool. But there are indeed things money cannot buy that developers do appreciate:

• Decent work environment
• Quality peers
• Decent tools
• Access to training
• Book budget
• Flexible hours
• Mangement that understands quality is not always free, swift, or easy
• A work environment with minimal interruptions
• Career path (including a non-management path)
• Management that values its full-time employees more than contractors (and pays for it with more than lip service)
• Decent equipment (reasonably current PC and dual monitors)
• Management that says Yes as often as it says No
• Opportunities to work with advanced or new technology in productive and meaningful ways