My Secret Life as a Spaghetti Coder
home | about | contact | privacy statement
I'm going to keep this week's post about My Job Went To India short, because the two quotes I want to pass on from Chad pretty much sum it up:
You work for a business, and unless you provide some kind of real value, you are a waste of money.
So you need to consider what you cost the company - not just your salary, but include your benefits and anything else as well. Compare that with the value you provide. Are you worth it?

You don't need to just meet your cost - Chad mentions that's like putting all of your savings in a 0% interest account. The value you provide needs to exceed your liability.

To get there, ask yourself about it regularly:
A month would pass and I would think, "What did I deliver this month?" Then, I started getting as granular as weeks an days. "Was I worth it today?"

Hey! Why don't you make your life easier and subscribe to the full post or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!

I want to share some words of wisdom with you again that I've shared in the past from notes I took in Dr. Ricardo Vilalta's course on Machine Learning:
  1. If you claim to know something, you will be seen as the expert
  2. Therefore, be honest about what you really know
  3. Be willing to learn and admit your lack of knowledge on certain areas
  4. Don't claim you are superior to others
  5. Don't give in to the pressure of winning over others
This week, I'm diverging from the advice found in My Job Went To India, and offering some advice based on personal experience, with the above caveat.

Most people don't talk. You might be one of them. But why don't you talk? You have an opinion don't you? Questions at least?

I think a lot of it has to do with item 1 on the list above. If you claim to know something, you open yourself up to criticism of your opinion and being proven wrong. So, you have to be honest about what you know. But you're not confident enough in your knowledge, so you pretend to know more than you really do. Doing that, you have to keep state in your head, whereas, if you were "willing to learn and admit your lack of knowledge," you could essentially be speaking functionally (paraphrasing Paul Graham, Interview with Jessica Livingston in Founders at Work).

So instead of saying something, you sit silently, hoping no one will ask you anything significant.

The problem with that approach, of course, is that you don't ever get to shine. Rarely ever will anyone who occupies a position of importance see your brilliance, your modesty, or your sense of humor. In fact, you might be lucky if they remember your name. (Unless you do something boneheaded.)

You don't have to be the smartest person in the room. You'll be wrong sometimes -- maybe a lot. But if follow the list above, you'll be miles ahead of the wallflowers - even those who have more skill and knowledge than you.

So how do I know speaking up works?

I've been trying it.

And what kind of results have I had? Outside of relationships cultivated through this blog and my other online activity, in the past six months I've been offered three jobs, none of which I initiated. (And even though you might say the blog is an example of "speaking up", I'm excluding that to show you don't need one to get the same effect, though it may amplify it.)

They aren't "work for free until we make it" jobs either - in fact, two have been from people I know and respect (the other one was from a relative stranger, so I didn't consider it very seriously). Both of those have been from people I already admire for their skill, knowledge, and accomplishments. Both are from people I'd love to work with and in both positions I'd be doing work I'd enjoy.

Can job offers translate to saving your job? I think so. If other people want you, surely someone wants to keep you. (And if not, you've got other sources from which to pull income!)

Thoughts? Oh come on, speak up!

You might not want to hear it, but you can be replaced. Indeed, you should strive to be replaceable - or at least tell yourself you are. That's the subject in this week's advice from My Job Went to India.

This is an eye-opening, scary, yet inspiring chapter - all rolled into one. In it, Chad explains why we should strive to be replaceable parts in the machine (or "a pebble in a bucket of water"), and he mentions the old job insurance via crapcode line:
I've heard lots of programmers half-joking about creating "job security" with unmaintainable code. And, I've seen actual programmers attempt to do it. In every case, these people have become targets. Sure, it was scary for the company to finally let go of them. Ultimately, though, fear is the worst that ever came of it. Attempting to be irreplaceable is a defensive maneuver that creates a hostile relationship with your employer...
By contrast, being "replaceable should create an unhostile working relationship," Chad says. He also notes that if you're not replaceable in your current position, you can't move up the ladder.

You might like to imagine yourself as a supercoder, keeping your company safe from disaster, and that if you were gone, they'd be helpless. To combat this delusion, Chad suggests imagining the average impact of one of your co-workers leaving.

I'll wait while you imagine it.

Got it? Good. That's probably about the same impact you'd have. If your entire company's truck number is a 1, and you're one of the ones, then clearly that's not the case for you. If you are in that position, you should be doing something to reverse it. It's unlikely you're "so peerless that [you] in fact should be irreplaceable" (quoting Chad Fowler).

The best part of this chapter, though, is the story Chad tells about a powerful CIO in a powerful company:
He and his team (of which I was a part) were winning every award and setting every IT standard in the company.
[Yet] he professed to waking up every day and intentionally and explicitly reminding himself that he could be knocked off his pedestal any day. Today could be it, he'd say.
[Chad explains,] humility is not just something we develop so we can claim to be more spiritual. It also allows you to see your own actions more clearly... [The] more successful you are, the more likely you are to make a fatal mistake. When you've got everything going for you, you're less likely to question your own judgment. When the way you've always done it has always worked, you're less likely to recognize a new way that might work better. You become arrogant, and with arrogance you develop blind spots.
Deep words.

In my case, our truck number is a one. But we have so few employees, it's hard to get it much higher than that. Still, we're making moves in the right direction to increase our truck number so that we all share more knowledge about more of each others' positions. Our hope is that while one of us might not be able to take over for another (if for no other reason than lack of available time), we might have enough shared knowledge to train someone else to do it, without it being more difficult than it needs to be.

All that spaghetti code I wrote is slowing being shoveled into the dumpster. And we're skipping the recycle bin.

We're all going to fail at some point. I've failed, you've failed. We'll both do it again. And who cares anyway? It's a good thing to fail.

Failing is how we learn - if you're not failing, how likely is it that you're doing something new? You probably don't think of it as failure though. But it is - it's just that we prefer to fail early and often with small mistakes, as opposed to late and rarely, with collossal mistakes.

Failure, and how to react properly to it, is the subject of this week's chapter in Chad Fowler's MJWTI.

Chad notes that since failure is a given, "within reason, we don't judge each other on the mistakes we make." Instead, we tend to focus on how we react to that failure.

For me, Chad best summed it up by comparing it to failure in the food service industry:
Think about the last time you experienced a customer service issue at a restaurant. Perhaps you waited way too long for the wrong dish to ultimately reach your table. Think about how the waiter reacted to your complaint.

The wrong reaction is for the waiter to make excuses or blame the cooks. The wrong reaction would be for the waiter to walk off to resubmit the order and stay out of sight while you site there starving and wondering when the hell your food is going to arrive. Of course, the really wrong reaction would be for the waiter to arrive with a dish that he already knows is wrong, hoping you would either not notice or not complain.
In each of those cases, it may even seem like the wrong thing to do is the natural thing we want to do. But put yourself in the customer's position (in whose shoes, no doubt, you've been). How would you like him to react?

Exactly the way you should react (quoting Chad):
  1. Raise the issue as early as you know about it...
  2. Take the blame [even if it's not all your fault]...
  3. Offer a solution ... [or] a plan of attack for finding [one]...
  4. Ask for help.
It's a hard thing to do to put your ego aside like that - but offering solutions instead of excuses goes a long way. Lately, I've been trying that - and for me it's an extra hard thing to do. I like to argue. So when I'm wrong, it used to be near impossible to admit it and move on.

But having used the technique, I can say it's much nicer to own up to it instead of squirming around trying to find excuses. I'd even go so far as to jump in if you notice someone else playing the blame game. It's not useful at all to assign blame. Fixing problems, however, is useful.

So instead of saying "I didn't have time," or "I had a problem with such and such," I've been trying to use the following key phrases (These are some recent examples, boiled down to their essense):
  • I didn't get that done. I don't have a good excuse. I'll get it to you this evening.
  • I should have done that. Let's fix it now.
  • I was mistaken in my original thought. Here's a more accurate one. Can we work something out?
That reminds me - I blamed something on my battery going out yesterday. It was the truth, but I probably could have offered something better. I probably should have said the first thing on my list.

When you make excuses for your mistakes - especially when they just keep piling on and they're all out of your control - it sounds ridiculous to the other people listening. It's incredibly more useful to offer solutions. And even if your battery did die, or something out your control did prevent you from meeting your responsibilities - don't pause after saying so. Don't let them have a chance to respond before you say "I'll fix it" in a tangible and timely way.

Aside from the learning aspects involved in failure, reacting in the the right way provides a chance to shine. I conclude as Chad does: "Stressful times offer the best opportunities to build loyalty." Use them to your advantage.

I do say it quite a bit - but this is still something I've got to learn to do more often. Even though I try to say "no" when I know I can't do something, I have still been feeling over-committed lately. So it's time to start saying it more often.

But the fact that I feel over-committed is just a symptom that I'm saying "yes" too often - the real problem is that I'm lying to whomever I'm making promises that I can't keep. In this week's chapter from My Job Went To India, Chad Fowler sums it up:
Saying "yes" is an addictive and destructive habit. It's a bad habit masquerading as a good one. But there's a big difference between a can-do attitude and the misrepresentation of one's capabilities (extra emphasis mine). The latter causes problems not only for you but for the people to whom you are making your promises. If I am your manager and I ask you if you can rewrite the way we track shipments ... by the end of the month, someone probably asked me if it could be done by then... So, armed with your assurance that you can make the date, I run off and commit to my customers that it will be done.
When you lie about your capabilities (even though it's not malicious), that spreads itself throughout an organization, and harms everyone. Most importantly for you, it damages your reputation. Whereas the man who says "yes" only when he is truly capable may feel bad about having to say "no" more often than you, he will come to be known for his honesty and accuracy in prediction while no one will trust anything you have to say about such matters.

The point is that you need to have the courage to speak up on the job. You need to say yes when you can do something. You need to say no when you can't do something. And as Chad notes at the end, you need to speak out against bad decisions:
As a manager, I make decisions or strong suggestions all the time. However, I don't hire my employees to be robots. It's the ones who speak up and offer a better suggestion that become my trusted lieutenants.
How guilty are you of over-committal and non-committal? I may have learned to not keep quiet, but I still have some work to do regarding the scheduling of -- and commitment to -- tasks in general.

There are plenty of times when you should just say no, refusing to be pressured into telling people what they want to here. That doesn't mean you don't ever want to commit to anything. You want to avoid being a Jasager, not to avoid being effective.

Planning helps make you effective. I've said it many times - I like to spend a few minutes each evening planning what I'll do the next day. I may get in trouble when I'm in Windows because I've yet to port my time-boxing routine over there, but for the most part, it really helps: I always have a specific direction, and I get to think about it in my dreams.

"Say it, Do it, Show it" - That's the advice this week from Chad Fowler in My Job Went To India. This chapter came at a perfect time for me - my planning is slipping, things to do are piling up, too many people want too many things from me, and I can't seem to decide what to do because there's too much to choose from. (Let me whine some more.)

War Plans

Chad offers a lot of good advice in this chapter. The first illustrates why planning is so effective:
As you complete each item on the list, mark it DONE. Use capital letters. Say the word, done. At the end of the day look at your list of DONE stuff and feel like you've accomplished something...

It's a stimulating process. It's rhythmic. It allows you to divide your days and weeks into a series of small victories, each one propelling you to the next. You'll find that not only does it give you visibility into what you're accomplishing but you'll actually get more done than if you weren't watching things so closely.
(Link and emphasis are mine.)

Even though my daily plans help me stay focused and get things done, they are only tactical in nature - which means that although I consistently have a direction, there is no coherent strategy to it. That's why coming across this chapter again was so fortunate: once you've "established a rhythm of plan and attack," you should start working on a more strategic level of weeks and months. It's something I've not done: I may have an item on my to-do list that doesn't need to be completed until 90 days from now, but that doesn't add up to coherence.

I've recently been trying some organization practices from GTD (without having read the book), so we'll see if that also helps.

Other than planning and executing, there is a third practice that Chad identifies as useful at work: telling your manager.
You should start communicating your plans to management. The best time to start communicating the plans is after you have gotten through at least one cycle of the plan through execution. And -- this is an important point -- start doing it before they ask you to do it. No manage in his or her right mind would be unhappy to receive a succinct e-mail from an employee stating what was accomplished in the past week and what they plan to do in the next.
I'll think I'll try that.

To summarize the last two weeks, I'd say that the ability to say no and the ability to commit (and execute), while opposites, are still both required skills. However, you should commit only to the right sorts of tasks for the right reasons, and refuse to give in to pressure to candy-coat your answers in the affirmative when you really think the opposite.

Anyway, I'm interested in what you have to say. Got any planning tips, or stories (good or bad)?

It's comfortable to play the idealist and pretend you don't care what other people think about you. But, that's a game. You can't let yourself believe it. You should care what other people think about you. Perception is reality. Get over it.
Chad Fowler, My Job Went to India (page 121)

Let me put that another way: Perception is reality. Get over it.

Last week, we finished the section of MJWTI that dealt with executing when we discussed the importance of commitment, and executing on that commitment. This week, we begin adventuring into the world many of us have absolutely no clue about: marketing.

The main thing I want to do here is dispel this myth that marketing is evil, or that it's "just for suits" (quoting Fowler). There's no sense in persisting these illusions that say your super-modesty is an ethical choice in reaction to evil, or that it's not your job.

MC Escher's Relativity used to illustrate illusion.

I cast dispel magic in your general area. I rolled a 17 on a d20. It's enough to pass the check. Therefore, the illusion from which you now suffer will disappear on your next turn.

I agree that it is possible to go overboard, being a braggart. But let's worry about that when you get close to it - you're most likely on the other end of the scale:
Most programmer types were the last kids picked for every team when they were in school. They probably avoided social situations where possible and failed miserable where not possible. It's no surprise that these people are afraid to stick their necks out by trying to show someone their capabilities.
The fact of the matter is that there's no reliable way to objectively measure knowledge-workers. What are they going to do? Count the lines of code you write? LoC as a measure of productivity is a stupid idea. Even if you were to have objective measures of "goodness" and "badness" as it relates to developers, perception would still matter: Someone has to decide if he likes you enough to promote you, or to keep you on the team in times of cutting back, or hire you in the first place.

If people are going to rely on their perceptions to form judgments of you, you might as well be the one to decide what they experience to form that perception.

One way to do that is to Speak Up! In doing so, Chad suggests making a list of groups you interact with and their associated perception drivers. His example looks like this:

Group Perception Drivers
Teammates: Technical skills, social skills, teamwork
Manager: Leadership ability, customer focus, communication skills, follow through, teamwork
Customers: Customer focus, communication skills, follow through
Project Manager: Communication skills, follow through, productivity, technical skills

He also suggests making your own list, and trying to change your behavior to emphasize those points which resonate well depending on which group you're around. Critique yourself as you go along. By simply making conversation along the lines defined by perception drivers in each group, you don't need to brag to be seen in a positive light.

It sounds quite technical, but I think it's probably a bit more natural than it seems by writing it down and reading it.

I know I need to give it a try. Yesterday, one of my classmates made a "he talks too much" motion with the duck-quacking of his hands when he thought I wasn't looking. I know it was probably something to do with the way he was feeling, but I could obviously be better perceived at least by that member of my peer group.

What do you think? Baloney? Hogwash? Or might there be something to this perception thing? My vote's with the last one. Don't agree? Change my mind in the comments.

To market yourself effectively, and thus, improve your career prospects, you need to know how to communicate effectively. It's not just that communication "gets the word out" about you - it has value in and of itself.

At the risk of this becoming a regular feature here on Fridays, Raganwald covered the same topic as the chapter from MJWTI that I'm covering this week. (This also happened a few weeks ago, when we discussed not overcommitting yourself).

There are many ways to communicate - and you should practice them all. In the post linked to Raganwald above, Reg talks about physical communication (as opposed to virtual) and suggests volunteering to present in front of a group as a means to improve your communication skill. It's something I get some small practice with at school, and something which I'd like to eventually do more of in a professional capacity - but I've yet to take the time or show the cojones and actually do it, outside of what's been required of me.

Anyway, he covered it better than I will, so I'd suggest reading it over at his blog. I'll continue with the real point of this one, about not being a "grumpy old code ogre [whom] everyone fears" (Quoting Fowler, pg 125).

Managers and customers are
responsible for something gravely important which they ultimately have to trust to some scary IT guys for implementations... In this situation, what's the most important attribute they're looking for in a team member? ... It's not whether they've memorized the latest design patterns or how many programming languages they know.

They're going to be looking for someone who can make them comfortable about the project they're working on... They're afraid of you.
Recognizing this deficiency in the relationship, you can bridge the gap by reversing the polarity: try looking at your customer or manager as the one on whom you depend for information about it and without whom you could not do your job (that's the case anyway).

I try to do this, but it's hard to tell how effective I've been. Chad suggests finding some email you've written to a manager or client, telling your mom it was written by a colleague, and asking her how it could be improved. That may work, but I don't know if I'm willing to try it. He also says going through old mail yourself will help give you a more objective perspective into your own mail.

Of course, this type of thing isn't for everyone. As one commenter over at Reg's post points out:
Rag, see, we don't want to improve our careers, exactly because an improved career would mean more communication and less code. And we became programmers exactly because we wanted to be spared of that "Hey, how are you, is everything fine?" kind noise most biped animals call "communication", and rather talk to a computer which does not expect any more information than it actually needs to do it's job.
That's the kind of programmer I used to be. Obviously, I've tried to move away from that in recent years. However, it's certainly not a view about your job to be ashamed of: I think an overwhelming majority of us got into this because we were socially awkward. But, I'm not sure the types of jobs where you can do that are going to be around forever. I hesitate to say, "much longer," because I have no idea, to be honest.

The point of it all: This goes beyond simply speaking up. You want to be the "adventure tour guide:" hold hands when you need to, help them navigate the treacherous landscape. Being helpful and somewhat outgoing puts people at ease, where terse messages loaded with talk about details they know nothing about does the opposite.

You want to be open, not shut off.

Do you have any tips for communicating well with non-technical people?

When people talk about keeping communication concise and to the point, they aren't insisting you write as if you were code-golfing. After all, Vg'f abg sha gelvat gb haeniry fbzrguvat gung ybbxf yvxr frperg pbqr.

Using acronyms and abbreviations that come from the online subculture is acceptable in certain situations: IM with friends, twitter (where space is limited), and texting are three of them. An email to your boss, coworker, or a client is generally not.

Most people (but if my experience is worth anything, not even close to everyone) are fine in the area of not deliberately writing like that when communicating in some official capacity. So, in the "Me Rite Reel Nice" chapter of My Job Went To India, Chad Fowler focuses more on unintentional mistakes. He relates research that found
more than half of companies consider writing skills when making both hiring and promotion decisions. Forty percent of surveyed companies in the services sector said that a third or fewer of their new hires had the writing skills they desired.
Furthermore, Chad describes the necessity of knowing how to write well: As companies and teams move to a more distributed global model, much of your communication will be with the written word.

Unintentionally riting bad - fillng ur txt w/ speling and gramer mistakes can make you look sloppy, [im|a]mature, or even ignorant.

Sound like an easy way to stand out? See that red underline on the screen? That often indicates a spelling error. See if you can fix it. You wouldn't let that stand in your code would you? So why let it stand in your writing?

I like email. It has so many advantages: The asynchronous nature means I can respond when I have time and you can do the same. I don't have to face you, so its easier to relate unpleasantries. I can take as much time to carefully craft my words as I need. I can say just the right thing. The list could get longer.

A lot of us really like computers more than we like people. We prefer IM or IRC to picking up the phone, and we prefer email over face-to-face conversation. Be honest, you'd rather be talking to Johnny 5 than Homo sapiens.

Number 5 is alive! More input!

The problem is that most of the rest of the world doesn't share your distaste for people, and neither would you if you were depending on the person who chose not to communicate on a personal level. To put a similar amount of information in an email as you could get in one RL conversation could take tens of minutes to write (and subsequently read) compared to just a couple of minutes.

Just like Johnny 5, humans need "more input, more input!"

As Chad Fowler notes in the "Being Present" chapter of My Job Went To India, business is personal. The bonds you form (or don't form) with your boss and coworkers affect how they treat and react to you. As he writes on page 131,
The natural work mode of a computer person is to hole up in a cubicle or office, put on a pair of headphones, and get into "the zone" until it's time to eat. Douglas Coupland, in his book Microserfs tells the entertaining story of a team having to buy flat food to slide under the office door of a programmer on a mission. This kind of isolation has become part of the culture and folklore of the software industry.

Unfortunately, speaking for your career, this is bad for business. If you're locked up in an office, accessible only by phone (if you answer) or e-mail, perhaps even working all hours of the night and sleeping late as a result, there's no difference between you being onsite with your bosses and your customers and being offshore. [Bold emphasis mine.]
No difference, except you probably get paid more. So how valuable are you then? You are on-site and that puts you at an advantage. Use it. As I mentioned above, if the tables were turned - if you were depending on someone else - you'd not likely feel like a few short emails will suffice for communication.

From my own recent experience, I can certainly say that's how I've felt. In this case, I'm the customer forking the money over to my home builder. When we first met, he said he preferred communicating mostly through email. I thought to myself, "great, I won't have to call him or meet with him all the time."

That quickly changed as I noticed problems with the house. I wanted vocal reassurances. I wanted face-to-face meetings so I could express my displeasure with the tile not matching without coming across like a jackass in email. I wanted to know when problems would be fixed - not just "I'll fix them" with no progress seen over two months. A simple, "We fix that kind of stuff at the end" would have gone miles. Sadly, I've only met with the builder a couple of times and spoke on the phone even less.

I'm completely uncomfortable with the situation. I feel out of control. I want to know what's going on and how we're going to fix the problems. But I get no reassurance - at least not as quickly as I'd like it.

Now I know how my customers and coworkers and bosses feel when they don't get anything but short emails from me. They have queasy stomachs and feel sick. Hopefully, I won't let them feel like that again.

What do you think?

You wouldn't market a product to American audiences in German. A soft drink company wouldn't try to sell a drink to consumers based on the measured quantity of red dye #8 it contains. Common sense tells you that to sell a product to an audience, you have to speak to that audience in a language they can both understand and relate to.
-Chad Fowler, My Job Went To India, page 133.

In other words, when you market yourself, consider to whom you are doing the marketing. Consider the perception drivers that define what a particular group responds well to, and use language that they understand. As Chad notes, "businesses and those who run them are interested in business results," so it's unlikely your discussion of the latest inversion of control framework is going to move them. Focus on why and how that helps the business.

Of course, that is in general. Clearly there are some companies where management knows quite a bit about the details of technology. Still, the role they are playing dictates they care about how that technology affects the business goals, not the other way around.

If you align your goals and your work with the goals of your business, putting yourself in others' shoes enough to communicate at their level shouldn't be very difficult.

What do you do? What have you done?

According to Chad Fowler in this week's chapter of MJWTI, those are two of the worst questions someone can ask about you. Why? Because it means they don't already know.

You might as well move to the basement and spend your days mumbling about your red Swingline stapler. Get used to the idea that no one will notice you're missing.

You were fired years ago. There was just a glitch in the payroll system that caused your paycheck to get printed anyway. Don't worry, they'll fix it soon.

Instead of being a "no-talent ass clown" that simply does what's expected of you, why not take some initiative and change some things for the better?

Most companies have their fair share of WTFs. Some have it worse than others. Can you help solve some of them?

Can you automate TPS reports? (Can I reference anything else in that movie?)

Can you show them the light and get them to ditch ceremony in favor of essence when it makes sense?

IronRuby now runs unmodified Rails.

IronRuby runs unmodified Rails

And JRuby's been on Rails for a while. There's Groovy and Grails and IronPython and ColdFusion and Jython and Scala and frameworks in the platform-anointed languages that relieve pain points in Java and .NET (while still running on them and integrating well!). It's true - they make Vicodin for the programmer's broken spirit. Chicken noodle soup for the coder's lost soul.

So why are you still always writing home-brew apps from scratch with all the pomp required by Her Majesty?

Can you sell essence to your boss and coworkers?

You can start unit testing. You can set up source control. You can tell people when you think their ideas are wrong, and fix other WTFs as you encounter them.

Then no one will need to ask what you do. They'll know.

Ruffled any feathers lately? Been a force for Good? Let's hear about it!

In the past, we talked about how networking with good coders can help you become one. We've also noted how speaking up can differentiate you from the herd.

This week we take a look at the other side of networking: not how you can become a good coder, but how you can get gigs easier than other people can. "Let your voice be heard" is what Chad Fowler titled this chapter in My Job Went to India, and looking back on it, this must have been one of the most inspiring chapters in the book. My outward-facing career plans follow his advice quite closely.

It's all about networking with people -- how you might do it and why it works.

Lee LeFever explains the concept in under two minutes:

Although Lee focuses on social networking websites, the concept applies more generally.

Chad explains it using the best words I can think of. In essence, this is what I'm talking about when I say "my outward-facing career plans follow his advice quite closely."
The world is changing. If you want to write your ticket, you've got to think bigger than the IT workers of yesteryear. While moving from level-23 Programmer to level-24 Programmer Analyst might really be your short-term career goal, as a programmer today, you need to think beyond the next promotion or even your current place of employment.

Set your sights higher. Don't think of yourself as a programmer at a specific company -- after all, it's not likely that you'll be at the same place forever -- but as a participating member of an industry. You are a craftsperson or an artist. You have something to share beyond the expense reporting application you're developing for your human resources department or the bugs you've got stacked up in your company's issue tracking system.

Companies want to hire experts. While a resume with a solid list of projects is a good way to demonstrate experience, nothing is better at a job interview than for the interviewer to have already heard of you. It's especially great if they've heard of you because they've read your articles or books or seen you speak at a conference. Wouldn't you want to hire the person who "wrote the book" on the technology or methodology you're attempting to deploy?


Being good is important, but it doesn't get you all the way there. Our industry ... is a big, complex web of people connecting each other. The more places you are attached to the network, the better your chances of connecting with that perfect job or career break. Limiting yourself to the company you work for places serious limits on the number of connections you can form.
It's not like I read this and said, "that's what I'm gonna do!" I didn't even remember it until I reread it this morning. But something there stuck with me. Although I had toyed with the idea of starting a weblog before I read this, it was that text that got me off my ass and made me actually do it.

That's the what and the why. But how do you get there?

I'd start the same way I started finding and being a mentor (same link as above). This is what I wrote back then, and I think it shows the stumbling quite well:
I started becoming involved online - asking and answering questions in topics of interest to me. Answering questions is particularly beneficial, because you get to throw ideas into the arena and see if your expert "mentors" will disagree with you and correct you when you are wrong. In fact, there's nothing on this blog I enjoy more than when someone disagrees with me in a comment* (with substance, anyway). On the other hand, when you are right you learn that you are right and you reinforce that knowledge.

I also made it a point to sit in the front row (or close to it) of every class and ask questions to aid in my understanding of the subject matter. I started visiting conferences and talks and user group meetings to learn from other developers when time permits. Some friends and I organized the UH Code Dojo in an effort to have mentors and be mentors. Another friend or two are helping me progress in .NET faster than I would alone and we're throwing around the idea of forming a game development meet-up group. I started reading blogs and participating in comments on various topics on a regular basis, rather than just when I needed to find information on a particular problem. Several blogs cover languages or topics I rarely use. Some cover things I've yet to use at all. Finally, I'm planning on going deeper into bioinformatics and game development with the advanced courses next semester, where the one-on-one time with the professor is much more like a mentoring relationship.
Read blogs. Comment on them. Start your own. Get involved on the mailing lists. Join a user group. Start one. Speak at one. Submit papers to journals and talks to conferences. Submit articles to other blogs or industry magazines. (Paraphrasing Chad Fowler, pp. 138-139)

I've barely started. I still need to get more involved in the user group scene, to be followed up with some conferences hopefully. I could also stand to publish my writing in places other than this weblog. I'm moving in the right direction, but I've still got a ways to go before I'm satisfied with what I've done.

That's me. Now I'd like to hear about you. In what ways are you building your network, even if unconsciously?

The internet has given us an amazing opportunity to "build [our] brands," as Chad Fowler points out in this week's short chapter from My Job Went To India.

There are two aspects to consider when building your personal brand: recognition and respect. Chad uses the swastika as the prime example of branding for awareness without positive association: almost everyone in the western world would think of Nazis when they see it (recognition), even if they have no respect for it.

On the other hand, you could also be like Minor Threat are to Blink 182, or the Ramones are to the Backstreet Boys - as Chad puts it about Charlie Wood, relatively "no recognition and lots of respect."

Ideally, you'd have lots of recognition and respect.

You can start by making sure you don't have a negative image. Don't be a jerk, especially online. The search engines won't easily forget, which means prospective employers (and dates!) will be able to find out how often you've been an asshole. If you're near the top of those search results, you could soon be singing with Cher.

If I Could Turn Back Time

But you can go further than not being a jerk. You can show that you're taking an interst in self-improvement, that you're passionate about what you do to the point of discussing, learning, or doing it outside of work, and that while you don't know everything, you're actively filling the gaps as you encounter them.

You can gain respect.

It's easier to gain recognition by being negative or catering to the lowest common denominator than by earning the respect of your peers. That's called selling out. If you can do both, with just a modicum of success ... can you imagine the potential you have?

Stand up and tell the class, "what do you want to do with your life?"

Twisted Sister - I Want To Rock

I want to rock.

Linus Torvalds, Yukihiro Matsumoto, David Heinemeier Hansson, and Larry Wall. They're all famous software developers you may have heard of. If you haven't heard of them, surely you know about some of their creations: Linux, Ruby, Rails, and Perl.

Checking the Rails core alumni list, I had heard of half of them before I knew they were ever Rails team members. You know other names as well - many inside what you might consider your core community, and probably several outside of it.

Even if these developers weren't trying to do so, they did a fantastic job of marketing themselves. As Chad Fowler notes in this week's chapter of MJWTI,
Anyone can write Struts or Nant on their résumé. Very few can write Struts committer or Nant committer.
When thinking about marketing yourself as a programmer, keep that in mind. In other words, it's not just about the fame from a hugely successful project you started, or the love from all the sexy kittens who know your name.

Oh my! It's Linus!

Simply having participated in the project shows not only your passion for software development, but also that you're well versed in the technology you intend to use. You helped develop it, after all.

My own experience in this sphere has been limited, but it's something I hope to rectify. I have released a couple of projects, to little fanfare, but since then, I've been wanting to work on projects that someone else started, because being responsible for the life of the project is something I'm just not interested in at the moment.

In pursuit of that goal, at the beginning of the year, I resolved to get more involved in OSS (among other things), and for a couple of weeks I actually stuck to it. But once school started I quickly realized that there just wasn't enough time to do everything I wanted, and open source contributions were some of the first to go.

Another limitation was that while I wanted to work on JRuby, I wasn't using it for any major projects (just many small scripting tasks) - so I couldn't even help in the most obvious way of filing bug reports. However, now I'm working on a Ruby on Rails application that we expect to deploy on .NET using IronRuby, so I may get some good opportunities to help on that project, even if just by a little.

These are all baby steps. I expect to get more involved in the future, even if in small ways to various projects that never lead to "committer" status.

Aside from learning by being the worst and just saving your job by practicing it, you can also market yourself through your involvement in open source projects.

I know a lot of you already have your own projects and collaborate or participate in others. Perhaps you can help answer the concerns of everyone else.

For the rest of you, here are a few questions for discussion:
  • What are you waiting for? Is there a way you can help your favorite project this weekend? It will make you a better developer than reading this blog will, that's for sure. =)
  • Do you feel too intimidated to start, or just don't know how?
  • If you don't participate, why not?

Seriously, be a purple cow.
Not [the] best cow or most milk-giving cow or prettiest cow. A purple cow would stand out in a crowd of best, most milk-giving, and prettiest cows. [Indeed,] It would be the purple one that you would talk about if you saw that group.
-Chad Fowler in My Job Went To India, with the idea from Seth Godin (whose book is linked in the quote)

A Purple Cow


Chad illustrates the entire point in less than ten words:
Remarkable definitely doesn't mean the same thing as good.
Said another way, I want to rock.

I've never believed I'm smart or gifted or otherwise especially endowed with intelligence. To me, working hard and putting in the effort has always been the key to success. Not until many years after I came to that conclusion did I read about how "eastern" educational philosophy outpaces that of the "west" in that way.

This is hard for me to say, given those beliefs, but it's something I've come to realize in the past few weeks: it's not hard to be remarkable. Let me explain how easily not sucking leads to remarkability, from stories I've personally experienced in the last two weeks.

A Tale of Two Types Of Customer Service
Ring... Ring


Hi, I just bought a reel for my garden hose, and there's supposed to be a short 3 foot hose that connects the faucet to the reel which connects to the hose. The reel I picked up didn't have one on it, can I get one?

Sure, is there something I can "steal" and give you from another one?


Ring... Ring


Hi, I just bought a ceiling fan and installed most of it until I realized one of the blades is scratched. Do I have to disassemble the fan and bring it all back in?

No, just bring the blade and the receipt...


Marsha, check out this 61 inch slim DLP TV. Isn't it awesome

Well, the viewing angle sucks. Can't we get a flat screen LCD?

Wow. You're right.

We don't have one. The nearest one in the computer is in Corpus Christie [3.5 hours drive time], but there's also one in the warehouse that will be here Friday.

That's not good enough, I need it by Monday.

[After making some calls to check around for TVs not in the system] I located one for you. It can be here tomorrow at 1 PM.

Great, I'll see you then.


Contrast those short stories with taking Wednesday off to get telephone service, calling AT&T and asking why a technician never showed up to get told they'll be there Thursday, to be taking off all day Thursday and then calling asking why a technician never showed up to get told they'll be there Friday, to be taking off all day Friday and calling to be told there was a problem with your order and no one ever bothered to call to tell you about it, to be taking off and calling ...

Also contrast those short stories with waiting a week for an appointment with Comcast on Monday, to be calling after the time frame ended, to being told to wait up as late as you can because they have flashlights, to being told they'll certainly be there Tuesday, to waiting until Wednesday, and again until Thursday.

Aside from the monopolistic consequences we observe, the difference in customer service is striking. Normal would have been acceptable, but the first three examples were remarkable, especially given the crap that came later.
Tweet on twitter relating the purple cow allegory

The Point
There may be a lot of companies who aren't looking for great hackers, so perhaps being one isn't going to be in your best interests for finding just any job. It may be in your interest for finding an incredible job, however.

I used to think being lazy might be a quality of a good software developer. Instead, I learned that you should be proud, not lazy. It's not the negative side of pride we should strive for, mind you - it's the the limit of not sucking x_amount as not sucking x_amount approaches infinity.

I don't want to be around people who only want to succeed. I want to be around people who want to excel.

It's that easy to be remarkable to most people. It's the difference between being the one who blows the feather that ends up floating in the wind versus being the feather.

Being remarkable is the difference between being the one to flush the toilet as opposed to being the piece of shit that rides the wave down.

Mr. Hankey, the Christmas Poo, in a toilet.

As always, comments, thoughts, and criticism are encouraged and appreciated.

Don't be afraid to make connections with other programmers, even if you might consider them a "rockstar." Those connections can make you a much better software developer. That's the point Chad Fowler makes in this week's chapter of MJWTI.

After relating the concept to the music scene (with which at one time I was also familiar), Chad (not surprisingly) sums up the matter in a few well-chosen words:
The most serious barrier between us mortals and the people we admire is our own fear. Associating with smart, well-connected people who can teach you things or help find you work is possible the best way to improve yourself, but a lot of us are afraid to try. Being part of a tight-knit professional community is how musicians, artists, and other craftspeople have stayed strong and evolved their respective artforms for years. The gurus are the supernodes in the social and professional network. All it takes to make the connection is a little less humility.
One of the reasons I started blogging was to make connections with other programmers. I enjoy it. Before I started reaching out to my fellow code-enthusiasts, I sucked. I still suck (don't we all?), but I suck progressively less each day. Part of the reason I'm on the road to Notsuckington can be attributed to the connections I've made with all of you.

Some of you taught me better design. To argue better. To write clearly, in code and prose. The value of being a wishy-washy flip-flopper.

I'm a wishy-washy flip-flopping programmer

Some of you helped me find flaws in my own work. Some helped correct them. The list could literally continue much further. However, in the interest of not publicly proclaiming myself a leech, I'll stop there.

Boo! Are you scared? Am I a zombie who wants to feed on your brain?

Lucy Liu photoshopped to be a zombie
From a contest @

Ok, so I am a zombie who wants to feed on your brain. Luckily, it's not a zero-sum proposition. You can retain your thoughts, knowledge, and memories while also sharing them with me.

Feel free to drop me a line any time. You might be able to teach me something, even if you're asking a question. I might be able to teach you something too. I won't be offended at you contacting me if you won't be offended if I don't always have the time to respond.

Let's travel to Notsuckington together.

Have you any stories of how connections with other programmers have made you better? Please, share them with the rest of us! (You can leave the names out, if you want.)

I don't remember what I thought the first time saw the title of this chapter ("Learn to Love Maintenance") from My Job Went To India. I felt sick though. The thought process probably went something like this:
Oh no. You mean I'm going to be stuck here so long I better learn to love it?

I've got it really bad - I have to maintain a bunch of the code I wrote. Mere mortals cannot comprehend how bad that is. When do I get to toss my refuse off to some other sorry excuse for a programmer?
Apparently that's a common response programmers have, given the prospect of enjoying an illustrious career as a an elephant dung-slinger.

But Chad Fowler (in the book) turns it around, saying that not much is expected of maintenance programmers. You just need to fix the occasional bug or add a small feature here or there. It really boils down to this:
[In a greenfield project,] when we don't have the constraints of bad legacy code and lack of funding to deal with, our managers and customers rightfully expect more from us. And, in project work, there is an expected business improvement. If we don't deliver it, we have failed. Since our companies are counting on these business improvements, they will often put tight reigns on what gets created, how, and by when. Suddenly, our creative playground starts to feel more like a military operation - our every move dictated from above.

But in maintenance mode, all we're expected to do is keep the software running smoothly and for as little money as possible. Nobody expects anything from the maintenance crew. Typically, if all is going well, customers will stay pretty hands-off with the daily management of the maintainers and their work. Fix bugs, implement small feature requests, and keep it running. That's all you have to do.
Moreover, after enough code is written, that new project isn't much different than your maintenance work. It's just missing the benefits.

Consequently, you've got a lot more freedom in maintenance to do as you will. Get creative. Spruce up the UI a little bit. Since you get to interact with your "customer" more often, "more people will know who you are, and you'll have the chance to build a larger base of advocates in your business."

On top of that, being responsible for the entire application, it's likely that "even without much effort, you will come to understand what the application actually does." In doing so, you're well on your way to becoming a domain expert.

As I've mentioned before in several of the "Save Your Job" series' posts, as of this writing, I'm working with a small company. So, not only am I a maintenance programmer, I'm a greenfield project programmer too. I've been known to wear more than one hat (As I'm sure many of you can say).

Because of that and the push to drive maintenance costs down - I don't get as many opportunities to get creative in maintenance as Chad suggests. That's a bit of a downer for me.

But he ends it on a motivational high note in the "Act on it!" section: Pick the most important aspect of your maintenance work and find a way to measure it. Make it a point to improve your performance in that area, and measure again. Continuously improve. It's more motivating than having the mindset laid out in the introduction to this post, and you'll likely raise a few eyebrows.

When I work in Windows, I don't get as much done as when I'm in MacOS X.

It's not because MacOS is inherently better than Windows productivity-wise. It's because my calendar and time-boxing mechanism resides on MacOS. So when I've got an entire day of work to do in Windows, I don't have anything telling me "it's time to switch tasks."

Why is that a problem? That's the focus of this week's chapter in MJWTI. (Last week, I took a mini-vacation / early bachelor party to go fishing at Lake Calcasieu in Southwest Louisiana, so I didn't get around to posting then in the Save Your Job series.)

The "Eight-Hour Burn" is another of the chapters in Chad's book that really stuck with me after I first read it. The premise is that instead of working overtime, you should limit each day's work to an 8 hour period of intense activity. In doing so, you'll get more done than you otherwise would. Our brains don't function at as high a level as possible when we're tired. And when we're working on our fifth 60-hour week, we're probably tired.

We may love to brag about how productive we are with our all-nighters [paraphrasing Chad], but the reality is we can't be effective working too many hours over a long period of time.

A Brain Scan

And it's more than just our brains being tired that should prevent us from working too long. It's the fact that when we know we've got so much extra time to do something, we end up goofing off anyway:
Think about day 4 of the last 70-hour week you worked. No doubt, you were putting in a valiant effort. But, by day 4, you start to get lax with your time. It's 10:30 AM, and I know I'm going to be here for hours after everyone else goes home. I think I'll check out the latest technology news for a while. When you have too much time to work, your work time reduces significantly in value. If you have 70 hours available, each hour is less precious to you than when you have 40 hours available.
That's why I'm in trouble when I work in Windows all day. I do work 12-16 hours most days between job, school, and personal activity (like this blog). I get burnt out every few weeks and have to take a couple of days off, but when I'm in MacOS X, at least my working days are very productive: I've got each task time-boxed and any time I spend reading blogs or news or just getting lost on the web is always scheduled.

When I'm in Windows with nothing to remind me but myself, I drift off quite a bit more easily. After all, it's only 6:30 in the morning. I've still got eight hours to get everything done (I'm leaving early to go check the progress on the house I'm having built).

The good news is that I've got an item on my longer-term to-do list to remedy the situation. Hopefully after reading this chapter again, I'll be more motivated to get it done. The bad news is, since it means working in Windows all day to get it done, I'll probably be off doing my best to read all of Wikipedia instead.

Anyway, how much do you work? Do you have any tricks for staying fresh and motivated?

Through the last forty-plus weeks, we've explored looking at yourself as a product and service, different ways of positioning yourself in the programming market, ways to invest in yourself, how to execute decisions to be a better programmer, and several options you have for marketing yourself, guided by Chad Fowler's excellent book, My Job Went To India.

Today we'll start looking at the "Maintaining Your Edge" section of the book. More...

Making goals and achieving them - overcoming adversity to gain something you want - is tremendously motivating and often rewarding in life. Still, there are often times you extend so much effort in focusing on the goal that you don't notice the journey, or worse: you make the journey downright unpleasant.

That's the discussion in this week's chapter from Chad Fowler's MJWTI.


Even though the practice of developing a specific piece of software is better enjoyed as a journey than as a goal, the same is not necessarily true when looking at your career as a whole.


The concept is simple economics: supply and demand. Ideally, you'd like to be a developer with skills that are high in demand, where there isn't yet much supply. That gets you jobs, and higher paying ones at that.

Over a year ago, we mentioned how searching for jobs for skills that aren't available offshore can show you the technologies that meet that criterion. That was in relation to "choosing the right market" for yourself, but it's a good strategy for staying sharp too. More...

Some people call them fat pants. Some people call them stretch pants. Others might call them exercise pants or sweat pants. Whatever you call them, they're comfortable to wear. The problem with sweat pants is the reason they're comfortable is because they're big and expandable. And that expandability means they have a lot of room to accommodate growth as well. More...

If you want to trap a monkey, it's not very hard. Hollow out a hole (in a coconut, the ground, or whatever) just large enough for a monkey's hand to fit in when relaxed, but too small to pull out as a fist. Put some food in the hole, and wait. Soon enough, a monkey will come, fall in love with the food, grab at it and refuse to let go.

You see, monkeys value food higher than life or freedom, and their devotion to it will not allow them to let go. Or so the story of the south Indian monkey trap goes. (I am merely relating the parable, I have not actually tried to capture a monkey in this manner.) More...

Outsourcing is not going away. You can delude yourself with myths of poor quality and miscommunication all you want, but the fact remains that people are solving those problems and making outsourcing work.

As Chad Fowler points out in the intro to the section of MJWTI titled "If You Can't Beat 'Em", when a company decides to outsource - it's often a strategic decision after much deliberation. Few companies (at least responsible ones) would choose to outsource by the seat of their pants, and then change their minds later. (It may be the case that we'll see some reversal, and then more, and then less, ... , until an equilibrium is reached - this is still new territory for most people, I would think.)

Graph showing much more growth in IT outsourcing with statistics from 2006.
Chad explains the situation where he was sent to India to help improve the offshore team there:
If [the American team members] were so good, and the Indian team was so "green," why the hell couldn't they make the Indian team better? Why was it that, even with me in India helping, the U.S.-based software architects weren't making a dent in the collective skill level of the software developers in Bangalore?

The answer was obvious. They didn't want to. As much as they professed to want our software development practices to be sound, our code to be great, and our people to be stars, they didn't lift a finger to make it so.

These people's jobs weren't at risk. They were just resentful. They were holding out, waiting for the day they could say "I told you so," then come in and pick up after management's mess-making offshore excursions.

But that day didn't come. And it won't.
The world is becoming more "interconnected," and information and talent crosses borders easier than it has in the past. And it's not something unique to information technologists - though it may be the easiest to pull-off in that realm.

So while you lament that people are losing their jobs to cheap labor and then demand higher minimum wages, also keep in mind that you should be trying to do something about it. You're not going to reverse the outsourcing trend with any more success than record companies and movie studios are going to have stopping peer-to-peer file sharing.

That's right. In the fight over outsourcing, you, the high-paid programmer, are the big bad RIAA and those participating in the outsourcing are the Napsters. They may have succeeded in shutting down Napster, but in the fight against the idea of Napster, they've had as much strategic success as the War on Drugs (that is to say, very little, if any). Instead of fighting it, you need to find a way to accept it and profit from it - or at least work within the new parameters.

How can you work within the new parameters? One way is to "Manage 'Em." Chad describes several characteristics that you need to have to be successful with an offshore development team, which culminates in a "new kind" of PM:
What I've just described is a project manager. But it's a new kind of project manager with a new set of skills. It's a project manager who must act at a different level of intensity than the project managers of the past. This project manager needs to have strong organizational, functional, and technical skills to be successful. This project manager, unlike those on most onsite projects, is an absolutely essential role for the success of an offshore-developed project.

This project manager possesses a set of skills and innate abilities that are hard to come by and are in increasingly high demand.

It could be you.
Will it be?

Chad suggests learning to write "clear, complete functional and technical specifications," and knowing how to write use cases and use UML. These sorts of things aren't flavor-of-the-month with Agile Development, but in this context, Agile is going to be hard to implement "by the book."

Anyway, I'm interested in your thoughts on outsourcing, any insecurities you feel about it, and what you plan to do about them (if anything). (This is open invitation for outsourcers and outsourcees too!) You're of course welcome to say whatever else is on you mind.

So, what do you think?

Side Note: Posted Thursday instead of Friday because I'm off to Lone Star Ruby Conference in the morning. Hit me up on twitter or contact me if you're going to be there.

If we accept the notion that we need to figure out how to work with outsourcing because it's more likely to increase than decrease or stagnate, then it would be beneficial for us to become "Distributed Software Development Experts" (Fowler, pg 169).

To do that, you need to overcome challenges associated with non-colocated teams that exceed those experienced by teams who work in the same geographic location. Chad lists a few of them in this week's advice from My Job Went To India (I'm not quoting): More...

Chad Fowler describes the problem:
What I've noticed since coming back from India is that in America we are so focused on ourselves that we don't even take the time to learn about our teammates from other parts of the United States. What's the special food in Minnesota? What do Arizonans do on the weekends in their nonexistent winters? The United States is a diverse place, and we don't even bother to learn about our own diverse culture, much less the cultures of people on the outside.
I don't want to get into the merits of whether or not Americans are inward-looking and selfish. The important part here is that as the world becomes smaller, nation-states are losing importance as cultural and political boundaries, and we're increasingly exposed (and exposing ourselves to) new people from unfamiliar places. We can choose to embrace this, or fight it.


You might think that "tech support" is a solved problem. You're probably right. Someone has solved it and written down The General Procedures For Troubleshooting and How To Give Good Tech Support. However, surprisingly enough, not everyone has learned these lessons. And if the manual exists, I can't seem to find it so I can RTFthing.

The titles of the two unheard of holy books I mentioned above might seem at first glance to be different tales. After all, troubleshooting is a broad topic applicable to any kind of problem-solving from chemistry to mechanical engineering to computer and biological science. Tech support is the lowliest of Lowly Worms for top-of-the-food-chain programmers.


This is the "z0mg it's Christmastime and have I really left so many of my goals for the year incomplete?!" edition of Programming Quotables.

If you don't know - I don't like to have too many microposts on this blog (me on twitter for that), so save them up as I run across them, and every once in a while I'll post a few of them. The idea is to post quotes about programming that have one or more of the following attributes:
  1. I find funny
  2. I find asinine
  3. I find insightfully true
  4. And stand on their own, with little to no comment needed
It's up to you decide which category they fall in, if you care to. Anyway, here we go: More...

The Pragmatic Bookshelf has recently published The Passionate Programmer: Creating a Remarkable Career in Software Development, (or you can save a few bucks at Amazon). It's the 2nd edition of My Job Went To India, a book I think is a must-read for any programmer.

It was important enough to me that I dedicated an entire category of this blog to discussion about about it, in fact.


This week's advice from MJWTI deals with making the "boring" tasks in software development more exciting (in the chapter, "How Good A Job Can I Do Today?")

Chad notes that although "it's rewarding to do a good job and to be appreciated," most time, "we allow ourselves to be extremely selective about where and when we really go out of our way to excel."

So, if the Pareto principle applies here, how can we make the 80% boring work be more like the exciting 20%, and go all out, doing our best?

Chad suggests making it a competition with yourself:
What if you tried to do the boring stuff perfectly?
Or, if you want to get competitive with your teammates,
Turn those boring tasks into a competition with your co-workers. See who can do them better... Keep a scoreboard for the whole team. Compete for bragging rights (or even prizes). At the end of a project, arrange for the winner to have his or her grunt work done by the rest of the team for a whole week.
Would that help? I've already resolved to do the boring work with a smile, but something like that might help the smile not feel forced.

What do you think?

In this chapter (Be Where You're At) of My Job Went to India Chad Fowler warns us to "be ambitious, but don't wear it on your sleeve."

He tells us about his pet peeve as a manager: the "employee who's always aiming for the next rung on the ladder." Aside from the annoyances of playing office politics, complaining "about the incompetence of The Management," and being a general jackass, there's also the way he looks at his daily duties: More...

This week's advice from Chad Fowler's book, My Job Went To India tells us to "remember who you work for" when doing your job.

Chad acknowledges that saying "make sure your goals and your work align with the goals of your business" is an easy task that's hard to accomplish. It's hard because working in IT for a major corporation, it's not always clear what those goals are and how you and your department fit into the overall scheme of things. More...

This morning, Leila asked how I got my groove back:
I think you have a great concept going. I really would like to find out HOW you became passionate about programming? I just graduated with a BS in CIS and am looking for an entry level IT job, HOWEVER I am not a bit excited about computers anymore. Like you I was just planning on continuing my education -get my MBA. But I know an IT job is what I went to school for. HELP! How do I get excited about an IT job when I can't even figure out what title to put on a job search? just degree in CIS?!
I started to comment, but as it became longer, I decided it might benefit others as a standalone post. More...

You feel, look, and do better when you are accomplishing goals and showing progress. That's one reason you'll find it in this week's advice from MJWTI.

The chapter is called "Daily Hit" and in it Chad recommends "setting a goal (daily, weekly, or whatever you're capable of) and tracking this type of accomplishment." Make sure it's known to your manager as well - don't let the underpants gnomes take credit for your success. Also, the shorter the distance between hits the better, since "if you're supposed to produce a hit per day, you can't spend two weeks tracking the perfect task." More...

This is a story about my journey as a programmer, the major highs and lows I've had along the way, and how this post came to be. It's not about how ecstasy made me a better programmer, so I apologize if that's why you came.

In any case, we'll start at the end, jump to the beginning, and move along back to today. It's long, but I hope the read is as rewarding as the write.

A while back, Reg Braithwaite challenged programing bloggers with three posts he'd love to read (and one that he wouldn't). I loved the idea so much that I've been thinking about all my experiences as a programmer off and on for the last several months, trying to find the links between what I learned from certain languages that made me a better programmer in others, and how they made me better overall. That's how this post came to be. More...

At the beginning of this week's chapter from My Job Went To India, Chad Fowler relates a story about Rao, a "mind-reading" programmer who could pick up on the subtleties in conversations and implement code before you realized you had asked for it.

Both when I first read this, and the second time around, alarms went off in my head: "What about YAGNI?" Why would you implement something that wasn't asked for? If you are wrong, you could be relieved of your position for wasting time and money.

Thankfully, Chad addressed my concerns. It turns out, More...

This seems to be becoming a theme here lately: DIFN. That's the advice in MJWTI for this week, although Chad Fowler doesn't put it so bluntly. In the chapter, Chad describes a race where the first team to complete a project over the weekend wins $100 thousand. Could you do it? More...

This week I return to following the advice in Chad's book. It's something I've been doing now for a while: automation.

I'm really big into automation - one of the things I really like to do is create developer tools, or even just small throwaway scripts that get me through the day.

One paragraph that stuck with me was this one:
So, imagine your company is in the business of creating websites for small businesses. You basically need to create the same site over and over again, with contacts, surveys, shopping carts, the works. You could either hire a small number of really fast programmers to build the sites for you, hire an army of low-cost programmers to do the whole thing manually and repetitively, or create a system for generating the sites.
Sound like anyone you know? (Or any of the other people writing generators, automated testers, and the like?)

It was after reading that paragraph that I decided we needed to change things at work. Forget about code repetition, there was plenty of effort repetition as well. The first part of that process was getting cfrails together, the remaining part is to build a WYSIWYG editor for building sites - if I ever get around to it.

There are other things to automate besides frameworks that generate code. Neal Ford has a pair of talks (both links there are PDFs found via his past conferences page) he gives that illustrate a bunch of tips and "patterns" along these lines. I enjoyed both of them and will eventually get around to reviewing them. He also mentioned that a book covering the topic is coming soon.

Getting back to MJWTI, Chad lists a "simple (minded) formula" to calculate productivity:
productivity = # projects or features or amount of work / (# programmers * average hourly rate)
At the end of the chapter he shows it in action: 5 units of work with 3 fast programmers at $80 per hour would be as productive as 20 programmers at $12 per hour on the same project (obviously ignoring the communication deficiencies and other pitfalls of a group that large). But if you are able to automate enough of your work, you can be the single programmer at $80 per hour on the same 5 units of work.

The exact math isn't what's important - the fact that you are more productive by automating as much as possible is.

In what ways do you automate your workday, no matter how big or small?

When someone starts complaining about customers who are making silly requests, I normally say something like, "I know! If it weren't for those damn customers, we'd have a perfect program!"

There'd be no one using it, but hey - the application would be sweeeeet.

This week I'm going to diverge from Chad's book on how to save your job. That's mostly because I don't have the book with me, but this has been on my mind the last couple of days anyway: the fear of success.

I've noticed it in myself and others from time to time - inexplicably sabotaging opportunities to succeed. I try not to listen to that voice now if I can help it.

More recently, I've started to notice it in companies and customers as well - groups as opposed to individuals. I've started wondering if reluctance to "go live" until the product was a symbol of perfection fits in with this phenomenon. More...

Although computer science is a young field of study, it is rife with examples of good and bad ways to do things. This week's advice from MJWTI instructs us to focus on the past - learn from the successes and failures of those who came before us.

Chad includes a quote from a Jazz musician that illustrates the concept of how we learn to become masters quite well:
Imitate. Assimilate. Innovate.
We saw a longer version of that in a quote from Ron Jeffries in last week's post about getting good at the process of software development: More...

Last week I posted about why software developers should care about process, and how they can improve themselves by doing so. In the comments, I promised to give a review of what I'm doing that seems to be working for me. So here they are - the bits and pieces that work for me. Also included are new things we've decided to try, along with some notes about what I'd like to attempt in the future. More...

Since the gift buying season is officially upon us, I thought I'd pitch in to the rampant consumerism and list some of the toys I've had a chance to play with this year that would mean fun and learning for the programmer in your life. Plus, the thought of it sounded fun. Here they are, in no particular order other than the one in which I thought of them this morning: More...

The chapter this week from My Job Went to India tells us to "Practice, Practice, Practice." It's pretty obvious advice - if you practice something, you will get better at it. Assuming that skill has value, you'll be able to market yourself easier.

What's not so obvious is that we are "paid to perform in public - not to practice." Unfortunately, most of us practice at our jobs (which is another reason we started the Code Dojo).

Perhaps because the advice seems so obvious is why when I reread this chapter, I realized I hadn't done much about it. Sure, I do a lot of learning and coding on any given day, but it's been rare where I've truly stretched the bounds of my knowledge and skill. And as Chad notes in the chapter, that is precisely the point of practice.

Specifically, we might focus on three areas when practicing, which parallel Chad's experience as a musician: More...

I was in a conversation recently about our mission and vision statements, and how it is important to have them as a model of what your company is trying to do, and what it would like to be doing in the future.

It got me to thinking about why, as a programmer, it is important to understand the basics of business.

Without understanding the company mission or vision, how can you support the business goals and aspirations? Without knowing them, how can you understand them?

We're in the process of redefining ours. What are yours? Do you have a personal mission and vision for your career? Can you boil it down into a couple of concise sentences?

That's one I'm going to have to think about. But I'd love to hear your ideas...

This week I've decided to cover my progress in two chapters of Chad Fowler's book, My Job Went to India, because they go hand in hand with the motivation behind much of my career management in the time since I've read the book.

I already had one semester of graduate school under my belt by the time I read the book, so when I got to these two chapters - Find a Mentor and Be a Mentor - I realized I was in a great position, especially for finding a mentor. I hadn't decided whether or not to graduate under the thesis option, or just take extra classes and do the non-thesis option. Choosing the thesis option would be a great way to get into a relationship with a mentor, so I decided to go that route after reading the book. More...

2nd Generation iPod Nano The Contest
For the next month, I'll be running a contest here for programmers to promote learning something new. I've had this spare iPod Nano that I've yet to use (and likely never will), I've been covering how to save your job with Chad Fowler's My Job Went To India, and I'm passionate about learning new things. It seems the best way to combine all three is a contest to help me spread that passion.

In particular, since I think it's useful to learn languages and different programming paradigms, that's what this contest will focus on.

Here are the rules:
  • Write a program in any language you are unfamiliar with.
  • Choose a language or a program that is in a different paradigm than languages (or programs) you already know (how to write).
  • Use at least one idea from that language that you've never (or rarely) used in another language.
  • Make it a useful program, though it needn't be big.
  • Follow good programming practices appropriate to the paradigm you're programming in (as well as universal ones).
  • If you have a blog and want to participate, post the solution there to be scrutinized in comments.
  • If you don't have a blog and want to participate, email the solution to me via my contact page or my email address if you already know it, and let others scrutinize the solution here in the comments.
  • I'll get the prize out the door in time for you to receive it by Christmas, in case you want to give it away as a gift.
  • When you submit your program, be sure to point out all the ways you've done the above items.
But I need your help
  • If you have any ideas for possible programs, list them below. This would give people something to choose from, and make for more participation.
  • If you have an idea that you want to do, but aren't sure if it would work, it probably will. Feel free to ask if it makes you more comfortable though.
  • If you think this is as important as I do, spread the word - even if you don't want to participate.
  • The winner will likely be chosen in a random drawing, but I need people proficient in different paradigms to help me judge what qualifies. I'm not an expert in everything.
Overall, the point is to learn something new, to have fun doing it, and to get people involved in learning new concepts. If you accomplish any two out of those three goals within the next month, let me know about it and we'll enter you in the contest.

You have until December 5. Start coding.

Chad summed this up for me so well in one paragraph of My Job Went To India that I'm just going to let him say it:
Looking back on it, I realize how foolish we were. We worked for a business and our job was to contribute to either making or saving money for that business. Yet we didn't understand the basics of how the business came to profitability. Worse, we didn't think it was our job to know. We were programmers and system administrators. We thought our jobs were strictly about those topics that we had devoted ourselves to. However, how were we supposed to creatively help the business be profitable if we didn't even understand how the business worked?
To combat this, I took a business course that helped me understand competitive advantage, among other things. Also, in the "Act on it!" section of the chapter, Chad mentions a book, The Ten-Day MBA 3rd Ed.: A Step-By-Step Guide To Mastering The Skills Taught In America's Top Business Schools. I've just gone to Amazon to buy it myself.

You need to take responsibility for your own improvement. That's a good part of what Chad Fowler's MJWTI focuses on getting you to realize. This week's advice follows along that same line: "Give a man a fish; feed him for a day. Teach a man to fish; feed him for a lifetime" (quoting Lao Tzu).

As Chad notes however, "education requires both a teacher and a student. Many of us are too often reluctant to be a student." He likens fish to the "process of using a tool, or some facet of a technology, or a specific piece of information from a business domain you're working in." Too many of us take the fish today, and "ask ... for another fish tomorrow." More...

It's such a bit of obvious advice that I almost skipped over it: "love it or leave it." There's no point staying in a job or career that you don't like - your performance will suffer as you sling code listlessly on a daily basis.

The flip side of that is that you'll excel in something you're passionate about. It's not hard to "take a big step away from mediocrity" just by being passionate (quoting Chad Fowler, in MJWTI).

So, if you're not passionate about programming, should you find another career? Perhaps, but why not just become passionate? It's not exceedingly hard. I know - I was there.

When making the decision to go to graduate school, I had originally planned to go for Political Science. I was bored with work, and I just wanted to get away from computers. A lot of that was self-inflicted with my spaghetti-coding ways, but I just didn't feel right programming any more. Someone with one of the coolest jobs in the world dreading to go to work? That was me.

Luckily for me, the Political Science department didn't accept Spring admissions for grad school, and that was when I wanted to enroll. So, I said "what the hell," and went for Computer Science instead. Of course, I have the benefit of having been passionate about this stuff at one point in my life. If you've never felt that way, what brought you here?

Whatever happened, I made the decision to become passionate about programming and computers again before that first semester - and now I'm hooked. My job is not appreciably different from what I was doing before - I've just added a lot of learning and exploration into my days, and figured out the benefits of dealing with crappy code. I think you can do the same.

Those fluent in English know well the phrase "don't put all your eggs in one basket" (kindly linked for those unfamiliar with the idiom). If it is foolish enough to risk dropping the basket and breaking all of your eggs, it is doubly so to put all your eggs in someone else's basket. How could you control your destiny? More...

The last bit of advice from Chad Fowler's 52 ways to save your job was to be a generalist, so this week's version is the obvious opposite: to be a specialist.

The intersection point between the two seemingly disparate pieces of advice is that you shouldn't use your lack of experience in multiple technologies to call yourself a specialist in another. Just because you develop in Java to the exclusion of .NET (or anything else) doesn't make you a Java specialist. To call yourself that, you need to be "the authority" on all things Java. More...

This week's advice from Chad Fowler's gem of a book really resonated with me when I read it, and it continues to do so. It was one of my favorite chapters in the book: Be a Generalist.

Don't be "just a coder" or "just a tester" or just anything. Doing so leaves you useful only in certain contexts, when reality dictates that it would be better to be generally useful. More...

This week's advice from My Job Went to India is easy to follow: invest in yourself. In particular, Chad mentions some advice found in The Pragmatic Programmer. Namely, that you should learn a new language (every year). But don't just learn any language - it should be a paradigm shifting language. In other words, "don't go from Java to C#." Go from ColdFusion to Haskell or Java to Ruby or Visual Basic to Lisp.

To illustrate the point, Chad tells the story of the developer who, when asked about having used a particular technology, replied, "I haven't been given the opportunity to work on that." Unless you don't own a computer (which Chad says probably was the case for that developer), you don't need the opportunity to be given to you. You need to take some time and do it yourself. More...

Before reading Chad's book, I was a one-"stack" kind of programmer. I knew a bit about Java and .NET, and I was fairly competent in C and C++ (though I wouldn't say I knew much about OO). I had done a couple of things in PHP and ASP. But for the most part, I was only using ColdFusion and Microsoft SQL Server on Windows with IIS as the web server. Consequently, I knew HTML and a bit of CSS too. I largely shied away from learning anything new, and tried my hardest to only work with what I knew well. More...

As I've mentioned before, I used to try my hardest to avoid contact with the customer, and as software developers, I think we don't spend enough time concerned about the business aspects of what we do.

In My Job Went to India, Chad Fowler says he thinks so too.

To combat code monkey syndrome, Chad suggests we have lunch with business people and read trade magazines for our business domains as often as we can. More...

For the next 52 weeks, I'll be following (and sometimes dispensing) advice from Chad Fowler's conveniently packaged one-chapter-per-week-in-a-year book, My Job Went to India and how to save your job without writing spaghetti code (like me) so that only you can disentangle the mess. (It's an important book). Anyway, today marks start of the first week. (Let's do 7 plus or minus 2 days)

By coincidence, this goes along well with the "what are you doing to become a better developer in the next six months" meme. So what are you doing?

Anyway, back to what we can learn from Chad... More...


Picture of me

.NET (19)
AI/Machine Learning (14)
Answers To 100 Interview Questions (10)
Bioinformatics (2)
Business (1)
C and Cplusplus (6)
cfrails (22)
ColdFusion (78)
Customer Relations (15)
Databases (3)
DRY (18)
DSLs (11)
Future Tech (5)
Games (5)
Groovy/Grails (8)
Hardware (1)
IDEs (9)
Java (38)
JavaScript (4)
Linux (2)
Lisp (1)
Mac OS (4)
Management (15)
MediaServerX (1)
Miscellany (76)
OOAD (37)
Productivity (11)
Programming (168)
Programming Quotables (9)
Rails (31)
Ruby (67)
Save Your Job (58)
scriptaGulous (4)
Software Development Process (23)
TDD (41)
TDDing xorblog (6)
Tools (5)
Web Development (8)
Windows (1)
With (1)
YAGNI (10)

Agile Manifesto & Principles
Principles Of OOD
Ruby on Rails

RSS 2.0: Full Post | Short Blurb
Subscribe by email:

Delivered by FeedBurner