If you recall, I quit my job and struck out on my own. But I still have a few more days before my last. Four days, to be more precise. You see, the thing is, I had already prepared a smooth exit even before I gave notice. So everything’s all set for me to go. Except now they’ve got me hacking a new feature into another impossibly low-quality module. I’m somewhere inbetween demoralized and just plain exhausted.

Alistair Cooke said, “A professional is someone who can do his best work when he doesn’t feel like it.” This quote is sometimes used by the more pointy-haired to brow-beat their underlings into a sense of pride. And that’s complete B.S. Each of us, professional or otherwise, does his best work when he’s engaged and happy. A professional is someone who can do a competent job when he’s disengaged or unhappy. But he’s not going to do his best work.

(Note: My manager is not quoting me Alistair Cooke. But bear with me.)

Ever since I started here, I’ve billed myself as the guy who can help them improve their codebase. I know how to turn it around, change it from a time-wasting, bug-ridden disaster into an architecturally sound, maintainable work of art. And I still sell myself as the good-code guy.

But I ran out of energy a long time ago. I’m tired of being the only one on the team who is actively improving the codebase. Fixing this system is a gargantuan task, one I can’t do on my own. I mean really: I physically and mentally can’t do it on my own.

What makes me good at what I do is that I’m both innately artistic and fundamentally lazy. On the lazy side, something deep inside me can’t stand to waste hours wrestling with problems we ourselves keep causing. But more than that, it physically pains me to churn out ugly code. I intuitively know high-quality code from almost 20 years of programming. And what I’ve got here goes against my nature. It’s frustrating and stressful. It makes me angry, and it gives me headaches. Literally. I have to pop a few ibuprofin.

This is an unhealthy situation. But they said the bad design was the product of contractors who are no longer with the company. And they said they wanted to redesign the system. I can help with that, whether it’s a rewrite from scratch or whether it’s a systematic refactoring. But what actually happened was I led cheers for improving the design and the process. Meanwhile, everyone else went on doing what they always had.

I discovered a great truth. A capable team will make great software with very little help. A mediocre team will make poor software, no matter what you do.

I’m still willing to do contract work here, but on my terms. In particular, what I’m working on now is not a feature I would have contracted to deliver under these conditions, because the code is impossible. I don’t understand how this code works, or even what it does. I talked to the guy who wrote the module. I walked over to his cubicle and asked him, and he doesn’t understand it, either. There is no way I could possibly deliver any new features against this module without first refactoring it or rewriting it. And that will take a long time and involve a lot of risk. As a consultant, I would refuse this job under these conditions.

I actually considered refusing, even as an employee. Why should the two be any different? The worst they could do is to fire me, ask me to go home 4 days early. That can’t be as bad as losing my temper and wanting to put my fist through the computer monitor. Or feeling like I’m going to cry, for all the grief this mess is causing me. Or going home every day with a headache and taking a nap to avoid snapping at my wife and kids.

But I think I’ve discovered a mantra that can get me through. I drew it on my dry-erase board. I wrote “4 days left,” and under that “IDCAM,” which stands for “I Don’t Care Any-More.”

• I don’t care whether the code I leave is maintainable. The code I’m hacking on reads like the result of a chemical-factory explosion. (It’s a mess.) I can’t stand messy, unmaintainable code. It’s a waste of time, and it frustrates me. Except today, I’m not going to fix it. I won’t make it any messier. But I’m not going to clean it up. I just don’t care anymore.

• I don’t care that the manager jokes that he came in early to make sure K. was at work on time. K. works an earlier schedule than the rest of us. She laughed. She and the manager are pals, and she knows he’s just joking. The manager actually came in for a customer meeting. It had nothing to do with K. That doesn’t make it funny to the rest of us. But I don’t care anymore.

• I don’t care that the one thing I thought I made progress on is completely wrong. It’s wrong because I needed to enter the data in two completely separate places. One is a configuration file. The other is hard-coded in the software. If these two don’t match, the software will silently behave in strange ways, and you won’t find out about it until you try to use the software’s higher functions. Yes, that’s a fundamental design problem. There’s no good reason for having the same information entered in two places, and it’s not documented, and it would take me 10 minutes to fix it. And no, I’m not going to fix it, just as no one else who’s ever worked on this part of the system has ever fixed it. I’m not going to be the one to take the initiative, because I don’t care anymore.

• I don’t care that I’m wasting the company’s resources. There are other developers here who have proven they can hack with code they don’t understand and sign off on it. I can’t do that. That’s why I usually deliver what I say I will, when I say I’ll deliver it, and it actually works. There may be other things I could help with that would utilize my strengths, and everyone could be happy. But in order to get there, I’d need to sell my manager on it, because it is his responsibility, one way or the other. And that’s just too much work, and for the sake of a few days, I just don’t care anymore.

• I don’t care whether I accomplish anything. Because that would require that I take the initiative and take the leadership role. And it would require an emotional investment. And that would stress me out. I know, becoming emotionally invested in my work is my natural tendency. It even gets me into trouble sometimes. And I’m willing to live with that, because it’s also what makes me a professional. Except that today, this would turn me into a basket case. So instead, I simply take a deep breath and chant my new mantra. “Just four more days. That’s all. I can make it. IDCAM: I don’t care anymore.”

But what concerns me is professionalism. Is it okay for a professional not to care? Maybe. Because I didn’t promise to care. All I promised to do was to stay for 4 more days. And in my weekly status, I even told my manager that it was unlikely I’d work all the bugs out of the stuff he left me with.

I wonder what he’s thinking about this. Does he realize how dissatisfied I am with the task he gave me? Does he know I’m just wasting the company’s money? Sitting here, bashing my head against the cubicle wall. Is he disappointed in me? Does he want better “performance” out of my last four days of hell? I could ask him. But that would require that I take the initiative (again) to open up the lines of communication between us. And I just don’t care anymore.

-TimK

I’ve been meaning for some time to write this. It took Lidor Wyssocky’s latest blog post to push me into it. And just in case someone out there couldn’t tell you were joking… (You were joking, right?) The sad truth is that “quick and dirty” may be dirty, but it’s never quick, at least not if you actually want to deliver a usable product.

“Quick and dirty” never has all the features the customer expected. And it rarely will. Because when you try to support all those edge conditions, the complexity quickly overwhelms you. It takes you twice as long to add the code to support the edge conditions, and in doing so you introduce innumerable new bugs.

“Quick and dirty” is what the A-Team did to build a tank out of a truck or a jeep. Yeah, maybe it got them out of their current predicament. But 5 minutes later, the whole landscape was in ruins (including the tankified vehicle). Is that what you want to deliver to your customers? I’m going to guess “Not.”

Pam Slim in an interview in this very blog talked about her some of her early consulting clients:

As your readers know, “doing the right thing” in corporations is not often supported, especially by senior management. But I felt really passionate about spending their money and my time on things that were most likely to make a real difference. I turned away many clients who insisted that I do things that I felt would be counter-productive to their business goals…

… and in what situations should we as professionals allow ourselves to adopt quick-and-dirty? (You are a professional, right?)

The general rule I use is that if it’s a spike solution for proof-of-concept or one-time demo, it’s okay to do quick and dirty. Because these things do not get delivered to customers. Before I deliver proof-of-concept or demo code to a customer, I clean it up. Or I rewrite it. Because I know that doing it right the first time is going to be both better and faster than any other way.

Deep in the recesses of my memory, there’s a story about a software development workshop. (I wish I could remember the citation.) The developers who attended the workshop were given some programming problem to solve and a limited amount of time in which to solve it. Those developers that took a little time first to think about the problem and how they might solve it generated more reliable solutions in less time than their counterparts who just started coding.

(By the way, the opposite of “doing it right” is not “doing it quick.” The opposite is “doing it wrong.”)

This is a running theme on Mythbusters. Host Jamie Hyneman, faced with a challenge, thinks first before constructing a solution, always looking for the simplest, most elegant design. Co-host Adam Savage, on the other hand, plunges forward impulsively, with cool, clever gizmos and gadgets. They frequently do episodes where the two Mythbusters compete to construct a device that will do such-and-such. Guess who more often achieves the goal within the allotted time, usually with a solution that makes you go “Wow.”

All software designs have some necessary complexity. Good design manages this necessary complexity, dividing it into smaller, simpler parts. I had a manager, a practicing software developer, who occasionally would criticize me for always doing grandly architected software designs. This puzzled me. When I pressed him on the issue, he told me that I had introduced unnecessary complexity. But every design feature he complained about was something that would be there anyway. So I told him so. Then he hit me with what I believe was the real issue. He said, sometimes we have to get the software out there, and we don’t have time for grand architecture.

As a professional, how can I see eye-to-eye with such a man? I was not sorry for my architectural decisions. These choices even allowed us to deliver features we previously could not even consider. And I will always be proud of his negative review. Because I knew and still know, it’s faster to do things right the first time, rather than to do it wrong.

Or to put it another way: I’d rather be known as someone who actually delivers what he says he will when he says he’ll deliver it, rather than someone who does “whatever it takes” and then delivers something that doesn’t actually work.

-TimK

He’s right. We should say something. The worst they can do is fire us. You don’t need to be offensive. It doesn’t need to be a big deal. They may not listen. But the worst they can do is fire us.

This reminds me of a talk Tim Lister gave in April at Boston SPIN (Software Process Improvement Network), a talk called “Dead Fish and Other Things Nobody Wants To Talk About.” “For starters,” Tim says, “We all need to declare the smell as soon as it is wafting in the project area. We need to all discuss the damage the Dead Fish does. Is it too much to ask that 50% of our projects
should be outright winners?” This is an excellent talk, and I highly recommend catching it if Tim gives it again.

-TimK

Many software developers become very attached to their favorite programming languages, methodologies, practices, and so forth. Checking the link-backs for my post “Twelve Benefits of Writing Unit Tests First” demonstrates this. One commenter on another blog even said he saw no value in reading the whole post, since it was specious and had no redeeming value. I took great joy in that comment, because it means I must be doing something right to push someone’s righteous buttons so accurately. Regardless, would test-first be the right tool for that programmer?

If you want to choose the best tool for the job, it’s not just about finding the tool with features that match up with the problem you’re trying to solve. You also have to take into account the people who will be using the tool. How well do they know it? How much do they like it. This latter may seem a silly parameter. But it does play into the equation. Any effective leader knows that it’s not enough to be right; you also have to get your people on-board. This is even one of the guiding principles of Alistair Cockburn’s Crystal Clear, that whatever practices you choose must be culturally relevent to the developers.

Here’s where Kathy stops. But we don’t have to stop here. Indeed, effective software teams never stop here. Witness Alistair’s second property of successful teams: reflective improvement. That is, we’re always looking to try new things and to validate them. If something doesn’t work, we know we don’t have to use it. We look for excuses to try new languages, new technologies, new practices. We shun excuses to avoid them. We are a growing team, not growing in numbers, but growing in maturity. Speaking of test-first, one commenter said you can’t try every new practice that comes down the pike. But a growing team can try almost every practice, one at a time. If you could try just one new practice a month, how many new practices could you try in a year? A growing team would never use this excuse to rule out any practice. They might decide to try something other than test-first to address the challenges they’re facing. But they wouldn’t just rule it out.

Similarly, a growing team would not write off the benefits of test-first, even if they did think the person touting those beneifts was high on drugs. Instead, they would ask whether test-first might address their situation. If so, they’d look for a way to try it. Maybe with a single module. Maybe with a sample project. If the experiment goes awry, how much effort would they lose? A few days? A week? Surely it’s worth that risk to find out whether this practice delivers on its promise and helps them do their job. Of course, before you can take that risk, you need to have slack in your schedule. You need to be able to burn time in order to try new things. Slack is where you grow.

But how does passion work into this? If we’re not passionate about a certain practice or programming language or framework, how can we use it? Even if we try it, won’t we sabotage our own efforts? After all, we can’t control what we’re passionate about, can we? To some extent, we can indeed control what we’re passionate about. Look at the passion of a growing team. A growing team is passionate about growth. And that means they will give new tools a fair chance. They might be skeptical. But because of their passion for growth, they will be able to set aside their skepticism. But they must choose to do so. They must choose to consider that maybe they’re wrong. They must choose to list what would need to happen to prove to them that they’re wrong. They must choose to test this list. They must choose to embrace the results and be excited to discover a new truth, to open up a new righteousness.

Growth is part of professionalism. Realistically, the members of a team will differ in their professionalism. Some will be more professional. Others will be less professional. After all, professionalism takes practice. Only some of them will be growing professionals. This may make it difficult—or impossible—to inject growth into a stagnant team. Reflective improvement itself may never be culturally appropriate, and the team may always be mediocre. Many growing professionals decide to go on to a new team that offers new challenges, rather than waiting for a stagnant team to catch up to them. For many people, this is the right course to take. For others, it’s more important to stick it out, take the leadership, and make a difference. And in a stagnant team, this will probably only happen over the long haul. It depends on your goals, your passions, and your strengths. And there we are back to choices.

Yes, it’s about passion. Inciting passion is one of the most powerful tools in the leader’s bag of tricks. Passion matters. It matters more than most managers want to admit. But decide whether you want to be a growing professional. Decide whether you want to be passionate about the tools or about the results. And if you choose the latter, know that you can indeed use the best tool for the job.

I’m a Linux user. That is to say, all of my home computers run Linux. The one at work doesn’t, but that’s a long story, which only serves to convince me that I want no Windows box at home. To say that I “hate” Microsoft may be a little hyperbole. But sometimes it does describe the way I feel. But not because Bill Gates is rich, as Bill Hilf is quoted as implying. On the contrary, the story of Bill Gates and MS-DOS and IBM is one of the most inspiring tales I’ve ever encountered. I dream of being a Bill Gates.

The reasons I hate Microsoft are more basic. Here are the top three that come to mind:

Tux, my penguin friend

1. Windows is one of my last bastions of angry insanity. As a developer, Windows gets in my way more often than it does what I want. When it really pisses me off, I stop my work, walk over to my white board, and write “Windows sucks!” in big red letters. Were it not for Cygwin, I’d be carrying on conversations with my stuffed penguin.

2. I would think twice about going into business with Microsoft. I’ve felt this way ever since I read Startup: A Silicon Valley Adventure by Jerry Kaplan, the story of GO Corporation. Now, GO had more problems than just Microsoft, I’m sure. That doesn’t ease my fear. My fear is that Microsoft would renege on their agreement with me and then sick their team of lawyers on me to make up for the fact. The legal system is a funny thing. If you have enough money, you can buy your own justice.

3. Windows XP activation, and now the Orwellian “Windows Genuine Advantage” service. Like the Internal Revenue Service: No thanks! Please! You’ve served me enough already!

Basically, Microsoft no longer oozes professionalism and trust. They don’t trust me, and I don’t trust them. And once lost, trust is almost impossible to regain.

-TimK

In our company, I as an employee am expected to fill out a self-evaluation, my manager is also to fill out an evaluation, and then we discuss the differences and file the forms with HR. The first thing I noticed is that I didn’t know how to fill out my copy of the form. Each line item I could rate as “strong point,” “satisfactory,” or “needs improvement.” I knew what each line item meant, but I didn’t know what my manager actually expected of me, so I didn’t know how well or how poorly I had achieved it.

Now, I could have just evaluated myself against my own personal yardstick, in which case I would have had a dozen strong points. Isn’t that a little disingenuous? Well, no, actually. Because I achieved measurable progress in all areas I had set goals for, and I was happy with my performance in all the other areas.

But it would impact my manager more if I were to drive home that he and I need to talk more. So, for all line items, I marked down “satisfactory,” neither good nor bad. The only further comment I left was that I thought better communication with management would make my job easier.

But then came the meeting with my manager and his evaluation. In almost 20 years as a software developer, I have never had less than a stellar performance review. Now, one year with one manager, and I finally understand. Well, I understood before, but I had not internalized it. Now I can internalize it: Performance evaluations are not about actual performance. They are about the relationship with the guy filling out the evaluation form.

I don’t want to make it sound as though the evaluation was all bad. For example, my manager thought I had strong organization skills. He particularly like my “system of breaking down a project and organizing the individual tasks.” Ah yes, I am proud of my system. It’s a system I began using years ago in a prior job, to track features and tasks and to estimate how long new features would take to develop. As a result of this system, I actually know how much I can safely commit to, and I actually deliver when I say I will. It’s a marvellous system, one we should all try. Those of us in the know call them story cards.

Then there was the fact that my code has fewer bugs than anyone else’s. I produce high-quality code. I was actually surprised to hear this, because I didn’t think we counted bugs. Well, as it turns out, we don’t. I still believe I probably introduce fewer bugs, because I’m the only one of our little team that uses unit tests, at least on new code. I hate bugs, both the software kind and the multi-legged kind. And as far as I know, the few I have introduced into our system have all been in non-unit-tested code.

(As you can probably see, I’ve been reading Extreme Programming Explained and Crystal Clear. Actually, I read them both long ago. But I also have them both on my shelf at work, and they are my plumb line.)

So I do deliver quality code on-time, but my productivity “needs improvement.” Apparently, I often require “more than [the] ‘normal’ amount of time.” Is that true? How do we know? What’s the “normal” amount of time? We don’t actually have a way to measure feature size or velocity. I’m the only one of the team who measures his velocity. (Remember the story cards?) But how do you compare that to other members of the team? And why would you want to?! Gack! Talk about sabotaging teamwork!

Fortunately, no one’s talking about sabotaging teamwork. But I have a sneaking suspicion that because my code actually works the first time (usually), and because I don’t have to spend endless hours after-hours tracking down yet another defect in our legacy system, it looks like I’m getting less work done. I’m not speaking ill of my teammates, mind you, because they really are doing the best they can with a system and process that fights against them at every turn. They are good programmers, each according to his experience level, and I truly vouch for each of them. And if any of them were to ask for a job reference, I’d give it in a heartbeat. This includes my manager, who is also the team-lead. (If a job reference from a wash-out like me is worth anything.)

But I’m a toxic employee. So my “attitude… needs improvement.” Seriously. I “often look distressed and disgruntled.” This in addition to some not-so-stellar properties of my communication and teamwork skills. According to the report, I’m always arguing everything, and this puts off the other team members.

This confused me greatly. Yes, I am always ready to point out alternatives, especially the challenging ones that require us to think outside the box. This could come off as argumentative, but I consider a good thing. It’s called collaboration. Just this past week, one of the other engineers came to me for advice. She wanted to talk to me. I did not ask her. Together, we delved into the engineering problem she was working on.

My manager from his desk he had heard everything we said, and he cited it in my performance review. He noted how I had picked over everything, always giving a contrary viewpoint. Well, yeah. That’s what she had wanted. I had asked her what kind of input she wanted from me, and she had said she just wanted my thoughts on this design problem. So that’s what she got, my thoughts, no matter how challenging they were. I also told her I might be talking out of the back of my head and that I wouldn’t be offended if she ignored everything I said. They were just ideas, and she was doing the actual work.

The next day, she came to me again and discussed the same engineering problem some more. I did not bring up the subject; she did. If I had made her feel so bad, why did she keep coming back for more? I asked her an open ended question: “What did you think of our meeting yesterday?” She said that she thought it was constructive and useful and that she appreciated my spending my time to hash through her design problem. (I later gave her feedback on how constructive it was for her to give me feedback on our interactions, but that’s another story.)

This all actually did tell me something useful. It told me that I have not been smiling enough at my boss.

It also reaffirmed something else I already knew. My manager and I do not talk enough. We talk about my tasks and my status, but about personal and social issues we are in two seperate worlds. I don’t really know what he expects of me, much less whether I can deliver it. I’ve never really asked. I do not know how what I do fits into the broader corporate vision, or how it fits with what my teammates are working on. I’ve never really asked. And he does not know what excites me about my job, what gets me down, or what my aspirations are.

I asked him if we could have a short, weekly meeting to discuss these issues on an ongoing basis. Or at least every other week. He’s very informal and doesn’t need a set time, but I told him it would help me remember. Otherwise, I might forget and put it off, and it would slip through the cracks. And I didn’t want that to happen, because once a year is not frequent enough for a performance review. So I asked him for a weekly meeting.

I had no real choice. The performance review was a disaster, because once a year is not frequent enough for a performance review. (I know I’m repeating myself, but that bears repeating.) In order to be effective, performance reviews must happen every month, every week, and even every day. It’s that darned feedback cycle again. Agile management, anyone? I need feedback frequently and quickly in order to address workplace issues.

So I plan to discuss these things with him, for better or for worse. I’m taking the first step, which may help. Or it may bring to the surface those issues that are more comfortably left submerged.

Hmm. I see here under the “Leadership/Initiative” line item — “Able to take charge and direct and coordinate activities; able to work independently; seeks increased responsibilities” — he marked, simply, “satisfactory,” no specific comments.

Oops. I think I mentioned unit tests to one of the other developers today.

-TimK

Thought-work is like that. You can’t see a thought-worker’s thoughts, so you can’t measure them. You have to measure what you can see, and you have two choices. You can measure results, or can you measure how much time the worker spends sitting in his chair.

But here’s the twist! The act of measuring the time spent sitting in the chair changes what results are achieved. And the act of measuring results changes when and for how long the thought-worker sits in his chair.

If you’re a creative person who has had to work in a manufacturing organization, you probably know I’m talking about. Manufacturing is all about churning out so-many widgets per hour, over so-many hours, producing so-so-many widgets. And you can increase the number of hours almost indiscriminately to increase the number of widgets. I know, this is not completely true, but it’s close enough that execs believe it to be true. They believe it to be true, even for thought-work.

But as a thought-worker, I must be creative. I need to nurse my creativity. Sometimes this means a change of pace in order to stimulate it. Sometimes this means sleeping in or staying late. Sometimes this means taking a walk or nap in the afternoon, or taking a long lunch. If you tell me I must be in the office at 9 o’clock and that I must stay until 5, you have in one stroke removed a whole dimension of my creativity. And you’ve reduced my effectiveness. And unless there’s a good business reason to do that, something more valuable than “That’s the way we do things here,” it’s been a needless waste.

(These organizations also may have the perverse property that a salaried employee is expected to stay late or come in early, when the organization needs it. But this same salaried employee is forbidden from leaving early or coming in late, even if the employee needs it.)

The converse is also true. If I am self-aware enough to nurse my creativity, to be most effective, I am going to adopt a schedule that works for me. This means blocking out periods of time to think. It means adjusting one’s schedule around day-to-day demands. It means staying late when the work demands it and leaving early when the mind demands it. It means not worrying about how warm the chair is, but measuring how much is accomplished.

But this approach is terribly unfocused, isn’t it? Sometimes I must force myself to sit and work, just to get my mind in gear, just to get into a state of flow. Doesn’t that contradict the Thought-Work Uncertainty Principle?

Or does it prove the point? Note: Sometimes I must force myself to sit and work. No one can do it for me. I have to know when I genuinely need a break and when I’m just avoiding an unpleasant task. That’s part of being a professional. If someone else is forcing me or pressuring me, that’s micromanagement.

And since you can’t see the thoughts, micromanagement will also produce less effective results. Think about it, and I think you’ll agree. You can get your developers to sit in the chair more, or you can accomplish more. I think I’ll take the prize behind door number two.

-TimK

This week, I did my first podcast interview. That is, someone interviewed me for her podcast. Anyone who thinks it’s easy to do an interview needs to take a humility pill and then go get a dose of reality. I think I gave her some good material, but I also said some stupid things and missed some things I wish I would have said. And my worst flub was near the end. She gave me the classic opening for my elevator speech, and I missed it.

But that’s okay. It’s the first podcast interview I’ve done. I knew this, and I knew I was going to do stupid things, because I’m learning how to do something I’d never done before, how to interview.

As professionals, we all should make mistakes. If you don’t make mistakes, you aren’t stretching yourself. As professionals, we make different mistakes than we did before. An amateur makes fewer mistakes, because he keeps doing only what he’s used to, and the mistakes he does make are the same mistakes he’s made a hundred times before. Professionals are always trying new things, so they’re always making newbie errors. But they also know how to reduce the risks posed by the mistakes they’ll make. Professionals test first, then they release. And they identify errors and adopt practices that counteract these errors.

So here’s how I’m handling the podcast interview. Firstly, she is a friendly interviewer. Most interviewers are friendly, as they want material that’s going to make them and their guests look good. Still, that was important to me, since I knew I would be making newbie mistakes, and a friendly interview reduced the risk due to these mistakes. Secondly, I asked her for feedback. I asked her to let me know what the best thing I did was, and what was the worst. This will give me a practice to keep and an area to work on. And then I plan on doing more interviews.

It’s okay to make mistakes. In fact, it’s required. If you’re not making mistakes, you’re not growing. So don’t beat yourself up for the mistakes you make, but do be aware of them and work to reduce them. Then go on to a new set of mistakes.

-TimK

Jim Shore’s Change Your Organization Diary ends on an apt note about professionalism, the dark side. He’s not there yet in the current edition of the Change Diary, linked above, but you can read the original edition on wiki.

Here’s the part I’m thinking about:

I had the opportunity to talk with Gerald Weinberg, a personal hero… We talked at length about professionalism and how it applied to the work I was doing at this company. My conclusion from that conversation was that I wasn’t being treated with respect by this company, and it was because I hadn’t behaved professionally in the way I negotiated my contract or in the way I had reacted to an unrealistic schedule. Specifically, I should have renegotiated my contract when my duties changed, and I should have stood up for myself, resigning if necessary, when I first realized that the schedule was wrong.

I came away with the conclusion that I didn’t have the ability to deliver on the schedule my company wanted or the credibility to change the schedule. The professional thing to do would be to resign.

So on my last day at the conference, I crafted my resignation letter. When I got back to the office last Monday, I handed it in.

Now, I’m not suggesting that anyone resign his job. That’s a highly personal decision, of which there are many aspects to consider. But when it comes to professionalism, these few paragraphs really drove the point home for me. Reading them brought an epiphany.

At the time, I was in a troubled company, working under a great manager, but so depressed I felt I could cry. During that time, I wrote little that didn’t stem from my depression and my work experiences. I wrote more poetry than usual, emotionally charged under the surface. “Living Inside a Top” and “A Tribute to Lorelai,” for example. I drew on these feelings for assigned creative writing projects, like “Things to Make My Life Perfect.” Even some seemingly innocuous sketches had meaning beyond the sketch itself. “Running” was a scene I based heavily on a real experience getting home after an interview.

I was not in the same situation Jim Shore had been, but there were similarities. And when I read through to the last part of the Change Diary, something clicked. I understood that no one was going to make sure I did a professional job, and few would even encourage me to do so. I knew what professionalism meant, and I had to be responsible for it in my own career. And sometimes that means doing the right thing against the grain, even being willing to resign if necessary.

I don’t know if that’s helpful, as it’s only a start. But I still think it’s a good start.

-TimK

I am one of the worship leaders in my church. We take turns on a rotating schedule. On any weekend, whoever is leading also gets to direct the band. One Sunday morning, I was leading. I may have been playing bass, too. Playing the intro, ready to begin, I was having trouble syncing up with the drums. I couldn’t catch the downbeat. The kick was on 2 and 4-and, only a shy little high-hat on the 1 beat. I talked to the drummer to get things straight, asked him where “one” was. Then I realized, I was talking into the microphone.

When you’re playing on-stage, you have to coordinate in real-time with the other musicians. But that day I realized, I want to coordinate without the aid of a 300-watt amplifier. The problem is that during practice, I as director had been using the mic to give directions. So when the pressure was on, live on stage, my subconscious did what it was used to.

As a musician, I learned early the value of practice. Practice does not necessarily mean you do the same boring thing over and over. Rather, it means you stretch yourself, step outside your current abilities. You do this in a safe environment, where making a mistake is okay. Then when the pressure’s on, your subconscious will take over, and you’ll do it like a pro. You’ll make the difficult look easy.

Sometimes a new musician or vocalist will join our little church band. And if they’re young and inexperienced, they usually feel afraid of making mistakes. I always tell them, it’s okay to make mistakes, especially during practice. That’s what practice is for, to learn new songs, to do things we haven’t done before. We all play wrong notes during practice, or we try to sing higher than our voices will go, or we do stupid things like clapping to a slow song. (I did that last weekend.) But the reason we have practice sessions is to try things and see what works. And what does work, we learn. And when Sunday morning rolls around, we sound damn good! (I’m awful proud of our little worship team.)

Back to my embarrassing incident. From that day on, I stopped using the mic to give direction, even during practice. Now I have a different problem, I have to shout sometimes to be heard above the din. But I haven’t embarrassed myself in that way again.

Practice makes perfect. What you practice, you will do. So it’s important to practice the techniques you want to use. Practice them when you’re not under stress, so that when the pressure’s on, you’ll be able to do them naturally.

Steve Pavlina posts that this is true even of getting up in the morning. It makes perfect sense to me, and I’m going to try his suggestion. When you’re just getting up, foggy and half-asleep, your subconscious will kick in and do what it is used to. For many of us, that’s rolling over and going back to sleep. But if you want your body actually to get up when the alarm goes off in the morning, practice doing it during the day while you’re still awake.

I apply this to every technique I want to use. As a software engineer, even when I can’t write automated unit-tests, I use the test-first model of development. First, determine how to test the new change. Then run the test. See that the test fails (or, if I’m refactoring, that it passes). Make the change. Rerun the test to confirm that it now passes. When all tests pass, I’m done!

Another example: Since I have aspirations of being a manager, I’ve been giving feedback wherever I can, to my coworkers, to my band mates, to my daughters, using the feedback model Mike and Mark talk about on Manager Tools. It’s a simple technique that produces immediate results, even if you’re not a manager. But I’m practicing it in easy situations, the easy-going circumstances we encounter day-to-day. By the time a tense situation occurs, it’ll be second nature to me.

So practice, practice, practice. Then you’ll make it look easy.

-TimK