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?

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?

By most standards, that's young.

And I know a thing or two about being set in your ways. We can all see the laugh I have at myself with the title here being "My Secret Life as a Spaghetti Coder" and some of the stories I've told as well.

In fact, let me add to the wealth of stodginess, idiocy, and all around opposite-of-good-developerness here:

I once said I preferred Windows to Linux. While that's not a completely shocking statement, the reason behind it was: I said I preferred Windows because 14 year olds work on Linux. Not because of any experience I'd had with it, but because of my fear of learning it.

Like with operating systems, your ignorance does not make a programming language suck. Although I've been tempted to say .NET sucks because of my early troubles with it, I've refrained, admitted my ignorance, and asked for help removing it.

Because of my prior experience being unwilling to learn, I was quite interested when I read this:

When you are young, you don't have that sense of self to protect. You're driven by a need to find out who you are, to turn the pages of your biography and see how the story turns out. If people around you are doing something you don't understand, you assume the problem is your inexperience and you go to work trying to understand it.

But when you are old, when you know who you are, everything is different. When people around you are doing something you don't understand, you have no trouble at all explaining why they are assholes mistaken.

. . .

If you want a new idea, you have to silence your inner critic. Your sense of right and wrong, of smart and stupid works by comparing new ideas to what you already know. Your sense of what would be a good fit for you works by comparing new things to who you already are. To learn and grow, you must let go of you, you must be young again, you must accept that you don't understand and seek to understand rather than explaining why it doesn't make any sense.

In a couple of paragraphs, Reg sums up almost precisely some of what I've been thinking and writing about for the last several months. He's so close, but misses a fundamental point: the old and young parts are incidental.

My hypothesis is that the level of learning and idea absorption you can attain has little to do with age. Instead, it is influenced more by your perceived level of experience. Normally, age is highly correlated to experience - but it doesn't have to be. In my case, when I was younger I thought I knew everything. Now that I've aged, I came to the realization I know very little.

My conclusion is not that different from Reg's, and this is not some scientific experimental contest, so let me explain why I feel the difference is worth noting: If we blame our reluctance to try new things on age, we are dooming ourselves to think of it as some unchangeable, deterministic process. By thinking of it in terms of perception of experience, we admit to being able to control it with more ease. (My belief is that we have control over what and how we perceive things.)

In other words, we lose our ability to blame anyone but ourselves. That's a powerful motivator sometimes.

Thoughts? Disagreements? Please be kind enough to let me know.

Chad Fowler, My Job Went to India (page 121)

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.



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.

"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.)



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)?

At this stage, if you've heard of Rails and you haven't converted, it's entirely possible that you never will. It's also entirely possible that anybody who still isn't even taking Rails seriously by this point might just be some kind of idiot.
...
Every programmer should also read Chad Fowler's "My Job Went To India" book, where he explains that as larger and larger numbers of programmers adopt a particular skill, that skill becomes more and more a commodity. Rails development becoming a commodity is really not in the economic interest of any Rails developer. This is especially the case because programming skill is very difficult to measure, which - according to the same economics which govern lemons and used-car markets - means that the average price of programmers in any given market is more a reflection of the worst programmers in that market than the best. An influx of programmers drives your rates down, and an influx of incompetent programmers drives your rates way the fuck down.

Instead, I want to talk about my first attempt at solving the puzzle, which was an utter failure. A glorious, spectacular failure. Perhaps the single most impressive failure of my career. Failures are often much more interesting than successes, but for some unfathomable reason, people are often reluctant to discuss them.

And this is just the beginning of the ceremony:

Me: read file blah.txt and display it on system output
Java: How should I name the class?
Me: Test
Java: How should I handle errors?
Me: I don't care right now, I just need to display that data to system output
Java: But I need to know this, what if something unexpected happens?!
Me: I just want to make a prototype damn it!
Java: Sorry, can't do it.
Me: Ok, do nothing on error.
Java: And which implementation of Stream class should I use for reading?

Everyone knows that diversification is the key to managing financial risk, but few people seem to apply this principal to their professional careers. Most developer shops are relatively limited when it comes to the number of technologies and problem domains they deal with. If you want to diversify your resume without job hopping every year, then it makes sense to actively seek out technology experiences that are different from the ones you use in your day job.

Neal Ford and others have been talking about the distinction between dynamic and static typing as being incorrect. The real question is between essence and ceremony. Java is a ceremonious language because it needs you to do several dances to the rain gods to declare even the simplest form of method. In an essential language you will say what you need to say, but nothing else. This is one of the reasons dynamic languages and type inferenced static languages sometimes look quite alike - it's the absence of ceremony that people react to.

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.

Update: Coincidentally, Reg Braithwaite related The Battle of Britain to software development telling us about Marshall Dowding and his refusals to be pressured into saying "yes" yesterday as well (along with personal stories).

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.

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.



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?

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.

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.

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!

He thinks many tasks are beneath him. He avoids them when possible and does them begrudgingly (and slowly) when not. He cherry-picks work that he thinks, even if subconciously, is in tune with his level and might get him closer to his goal of the next promotion.

That's the paragraph that hit home with me, because I used to be that developer. However, I never looked at it as a way to get ahead (being in such a small company and all). But, I did justify it by saying things to myself like "this is beneath my skill level - I don't want to waste money they are paying me by wasting time on these mundane tasks that could be done by a monkey."

Even until recently, I took this attitude in some regard. So much so, that during our recent SWOT analysis, I brought it up as a weakness against myself, and resolved to take the opposite approach. Now, I find ways to automate many of those menial tasks, and in general just do what the job requires, without regard to the prestige of task at hand.

If you want me to follow an elephant around with a shovel, I'll do it, and I'll try to be the best damn shit-shoveler you've ever seen.

Know anyone like the horror-story? Anyone who has overcome that superiority complex?

To remedy this, Chad says it's easy to ask your manager how you can help. When you help your manager, he helps his, and so on, all the way up the food chain. In doing that, you can be sure that your work is aligned with the goals of the business, and it doesn't hurt to keep the man happy "who holds the keys to your career (in your present company, at least)."

Of all the chapters thus far in the book, this was the least inspirational for me. That's not any fault of Chad's but more because of the fact that I've always worked at small companies. Therefore, I've always been fortunate enough to have close relationships with the people in power positions, and I've been much more of a mind reader because of it.

However, that doesn't mean I still can't ask what I can do to help us reach our goals, and what those goals are. So earlier this week, after reading the chapter, I was inspired to do just that. Try it out and see if it works for you, especially if you're at a larger company. Perhaps you can discuss longer term objectives over lunch.

You've got a related story? I'd love to hear about it in the comments below.

I think you just have to make the decision to be passionate. Wake up in the morning and think about how lucky you are. Decide to enjoy the day, and to enjoy what you do. But you can do better.

Think about what drew you to the profession in the first place, and try to get a job doing that. If you can't get one in a timely fashion, try to get a job doing something similar and spend your free time working on side projects that interest you. That's a lot of what I'm doing.

For me, it is learning new things and gaming that I enjoy most. So, I spend a lot of time doing that. I still have to do grunt work, but I get equal doses of fun stuff too - all the while I am expanding my skill set and enjoying most of it.

As far as the job search goes, I'd recommend networking with people. Visit the local User Groups, get involved in forums and mailing lists. Learn things and share them, and people will eventually come to you with jobs. Even though I like the computers, I've found that I really enjoy the relationships with people who also like computers. Before, I stayed locked in a room thinking and working by myself. Now, I venture out from time to time, and in addition, I have the online relationships I enjoy immensely.

Since you probably can't afford to live that long without a job, perhaps in the mean time you can go to a career fair at a local university or just use the search term "programming" and browse jobs until you find one that interests you.

I'd also read many different weblogs about programming to stay up to date on trends in the industry, as well as to receive solid advice that stands the test of time.

Just as importantly, take a look back at your own situation. Can you identify anything that may be causing your malaise? If so, can you remove it? It may be as simple as that.

To the rest of you: how do you maintain and find passion in your work when you seem to have lost it?

I work in an environment where it wouldn't benefit me to "tell the manager" about my daily hits. They know already. But you might want to make yours known. Obviously you don't want to be braggadocious about it, but don't keep it to yourself either.

I like to do more than one hit per day. One is the absolute minimum. I try to get an overview of what needs to be done during the week, and create a high level plan in my mind over the weekend. I'll set each day's tasks and the time I'll be working on them on the day before. Then, I stick to the plan.

Even when I don't finish a task in the time allotted, I can reschedule and finish it the next day. In this way, I'm always having small successes which keeps me motivated and moving along towards my goals.

We're not talking about just what has to be done - it's about going above and beyond that. Chad ends the chapter with the advice to make a list of the "nitpicky problems" you and your team face that waste a little time each day, and starting to do some work on those things. I've done some of that, but there's plenty left to do, and re-reading this chapter reminded me that I need to start scheduling those things as well.

Do you do anything similar?

The experiences discussed herein were valuable in their own right, but the challenge itself is rewarding as well. How often do we pause to reflect on what we've learned, and more importantly, how it has changed us? Because of that, I recommend you perform the exercise as well.

I freely admit that some of this isn't necessarily caused by my experiences with the language alone - but instead shaped by the languages and my experiences surrounding the times.

One last bit of administrata: Some of these memories are over a decade old, and therefore may bleed together and/or be unfactual. Please forgive the minor errors due to memory loss.


How QBASIC Made Me A Programmer

As I've said before, from the time I was very young, I had an interest in making games. I was enamored with my Atari 2600, and then later the NES. I also enjoyed a playground game with Donald Duck and Spelunker.

Before I was 10, I had a notepad with designs for my as-yet-unreleased blockbuster of a side-scrolling game that would run on my very own Super Sanola game console (I had the shell designed, not the electronics).

It was that intense interest in how to make a game that led me to inspect some of the source code Microsoft provided with QBASIC. After learning PRINT, INPUT, IF..THEN, and GOTO (and of course SomeLabel: to go to) I was ready to take a shot at my first text-based adventure game.

The game wasn't all that big - consisting of a few rooms, the NEWS directions, swinging of a sword against a few monsters, and keeping track of treasure and stats for everything - but it was a complete mess.

The experience with QBASIC taught me that, for any given program of sufficient complexity, you really only need three to four language constructs:

1. Input
2. Output
3. Conditional statements
4. Control structures

Even the control structures may not be necessary there. Why? Suppose you know a set of operations will be performed an unknown but arbitrary amount of times. Suppose also that it will be performed less than X number of times, where X is a known quantity smaller than infinity. Then you can simply write out X number of conditionals to cover all the cases. Not efficient, but not a requirement either.

Unfortunately, that experience and its lesson stuck with me for a while. (Hence, the title of this weblog.)

Side Note: The number of language constructs I mentioned that are necessary is not from a scientific source - just from the top of my head at the time I wrote it. If I'm wrong on the amount (be it too high or too low), I always appreciate corrections in the comments.


What ANSI Art taught me about programming

When I started making ANSI art, I was unaware of TheDraw. Instead, I opened up those .ans files I enjoyed looking at so much in MS-DOS Editor to see how it was done. A bunch of escape codes and blocks came together to produce a thing of visual beauty.



Since all I knew about were the escape codes and the blocks (alt-177, 178, 219-223 mostly), naturally I used the MS-DOS Editor to create my own art. The limitations of the medium were strangling, but that was what made it fun.

And I'm sure you can imagine the pain - worse than programming in an assembly language (at least for relatively small programs). Nevertheless, the experience taught me some valuable lessons:

• Even though we value people over tools, don't underestimate the value of a good tool. In fact, when attempting anything new to you, see if there's a tool that can help you. Back then, I was on local BBSs, and not the 1337 ones when I first started out. Now, the Internet is ubiquitous. We don't have an excuse anymore.
  
  
• I can now navigate through really bad code (and code that is limited by the language) a bit easier than I might otherwise have been able to do. I might have to do some experimenting to see what the symbols mean, but I imagine everyone would. And to be fair, I'm sure years of personally producing such crapcode also has something to do with my navigation abilities.
  
  
• Perhaps most importantly, it taught me the value of working in small chunks and taking baby steps. When you can't see the result of what you're doing, you've got to constantly check the results of the latest change, and most software systems are like that. Moreover, when you encounter something unexpected, an effective approach is to isolate the problem by isolating the code. In doing so, you can reproduce the problem and problem area, making the fix much easier.

The Middle Years (included for completeness' sake)

The middle years included exposure to Turbo Pascal, MASM, C, and C++, and some small experiences in other places as well. Although I learned many lessons, there are far too many to list here, and most are so small as to not be significant on their own. Therefore, they are uninteresting for the purposes of this post.

However, there were two lessons I learned from this time (but not during) that are significant:

1. Learn to compile your own $&*@%# programs (or, learn to fish instead of asking for them).
2. Stop being an arrogant know-it-all prick and admit you know nothing.

As you can tell, I was quite the cowboy coding young buck. I've tried to change that in recent years.


How ColdFusion made me a better programmer when I use Java

Although I've written a ton of bad code in ColdFusion, I've also written a couple of good lines here and there. I came into ColdFusion with the experiences I've related above this, and my early times with it definitely illustrate that fact. I cared nothing for small files, knew nothing of abstraction, and horrendous god-files were created as a result.

If you're a fan of Italian food, looking through my code would make your mouth water.

DRY principle? Forget about it. I still thought code reuse meant copy and paste.

Still, ColdFusion taught me one important aspect that got me started on the path to Object Oriented Enlightenment: Database access shouldn't require several lines of boilerplate code to execute one line of SQL.

Because of my experience with ColdFusion, I wrote my first reusable class in Java that took the boilerplating away, let me instantiate a single object, and use it for queries.


How Java taught me to write better programs in Ruby, C#, CF and others

It was around the time I started using Java quite a bit that I discovered Uncle Bob's Principles of OOD, so much of the improvement here is only indirectly related to Java.

Sure, I had heard about object oriented programming, but either I shrugged it off ("who needs that?") or didn't "get" it (or more likely, a combination of both).

Whatever it was, it took a couple of years of revisiting my own crapcode in ColdFusion and Java as a "professional" to tip me over the edge. I had to find a better way: Grad school here I come!

The better way was to find a new career. I was going to enter as a Political Scientist and drop programming altogether. I had seemingly lost all passion for the subject.

Fortunately for me now, the political science department wasn't accepting Spring entrance, so I decide to at least get started in computer science. Even more luckily, that first semester Venkat introduced me to the solution to many my problems, and got me excited about programming again.

I was using Java fairly heavily during all this time, so learning the principles behind OO in depth and in Java allowed me to extrapolate that for use in other languages. I focused on principles, not recipes.

On top of it all, Java taught me about unit testing with JUnit. Now, the first thing I look for when evaluating a language is a unit testing framework.


What Ruby taught me that the others didn't

My experience with Ruby over the last year or so has been invaluable. In particular, there are four lessons I've taken (or am in the process of taking):

• The importance of code as data, or higher-order functions, or first-order functions, or blocks or closures: After learning how to appropriately use yield, I really miss it when I'm using a language where it's lacking.
  
  
• There is value in viewing programming as the construction of lanugages, and DSLs are useful tools to have in your toolbox.
  
  
• Metaprogramming is OK. Before Ruby, I used metaprogramming very sparingly. Part of that is because I didn't understand it, and the other part is I didn't take the time to understand it because I had heard how slow it can make your programs.
  
  Needless to say, after seeing it in action in Ruby, I started using those features more extensively everywhere else. After seeing Rails, I very rarely write queries in ColdFusion - instead, I've got a component that takes care of it for me.
  
  
• Because of my interests in Java and Ruby, I've recently started browsing JRuby's source code and issue tracker. I'm not yet able to put into words what I'm learning, but that time will come with some more experience. In any case, I can't imagine that I'll learn nothing from the likes of Charlie Nutter, Ola Bini, Thomas Enebo, and others. Can you?

What's next?

Missing from my experience has been a functional language. Sure, I had a tiny bit of Lisp in college, but not enough to say I got anything out of it. So this year, I'm going to do something useful and not useful in Erlang. Perhaps next I'll go for Lisp. We'll see where time takes me after that.

That's been my journey. What's yours been like?

Now that I've written that post, I have a request for a post I'd like to see:

What have you learned from a non-programming-related discipline that's made you a better programmer?

We might be standing around waiting for a pot of coffee to brew, and I would talk about how great it would be if we had some new flexibility in our code that didn't exist before. If I said it often enough or with enough conviction, even though I hadn't really put it on the team's TO-DO list, Rao might fill the gaps between "real work" looking at the feasibility of implementing one of these things. If it was easy (and cheap) to implement, he'd whip it out and check it in.

(emphasis mine) Chad also mentions the potential pitfalls in such an approach:

• You waste time and money if the functionality was not needed
• You increase complexity of the code base and make "it less resilient to change" if your code forces "the system down a particular architectural path."
• You could unintentionally make the application "less functional or desirable to the customer."

Honestly, I'd caution against using this advice unless you are in one of the following situations:

1. You've known the feature-requester long enough that you can pick up on things he's asking for, but hasn't yet asked for. I think you should be really close in this situation. How can you predict otherwise?
2. There is obviously something missing from the spec, and you have enough experience with similar systems to know it is missing. This might be something like "We need a login system." You can probably safely assume they'll need a way to log out as well, and perhaps even "I forgot my password" functionality.
   
   The logout functionality I'd almost always toss in (unless requested otherwise). However, even on the "forgot password" feature, I'd consider a couple of things. First, do I know the customer well enough that we've done another application for them and they wanted it? Second, is the budget big enough to where I know they won't be upset if I implement it?

There could be more, but that's what my brain thought of this morning. Of course, in many cases it's just better to ask first.

What do you think?

How is it that an application of similar scope to those we spend weeks working on in the office is going to get finished in a single weekend?

We've all seen projects take weeks when they could be measured in days. So what gives? The answer, of course, is that we aren't accustomed to doing it right now. Stop putting off tasks. Just do them.

To help meet that goal and create race conditions, I like to timebox my daily tasks. From 5:30 to 6:15 I read my email do my morning blog reading. Then I take 15 minutes and enjoy a cold Red Bull. After that, I might work on Project A for 3 hours, then read email for 15 minutes. I've got half a days work done before most people get to the office. After that, I might switch to Project B for three more hours, and so on.

To keep track of what I should be working on and give myself pop-up reminders that it's time to change tasks, I've been using Apple's iCal, and it works pretty well. My only problem is that as I need to work more often in Windows, I'm not using it as much, and particularly this week my productivity has been way down. (I admit, the impending holiday may have something to do with that as well.) However, FedEx just dropped off VMWare Fusion, so hopefully I won't need to boot into Windows anymore and the problem will be solved. My only complaint against iCal itself is that I wish I didn't have to set up an email address in the mail client for it to send me an email - that's just annoying.

If you're not on a Mac, Google Calendar would work (except you're not getting the popup reminders). Even just spending 15 minutes before you leave work to plan the next day, and writing it on the whiteboard or some sticky-notes would likely be a major improvement for your work-day, and might even be better than a technology-based solution.

How have you made it easier on yourself to do it right now?

What can we do to help them get over this irrational behavior? If they continuously request those trivial changes and never go live, the project has failed. Do you think they will blame themselves, their ideas, and their actions? No, they will blame you, and find someone else to work with next time. So you may have been paid for your time, but it still impacts you negatively.

Don't get me wrong - sometimes there are good reasons to wait to release a product or service. Sometimes, you don't need to DIFN. However, the fear that your customers won't know to look under "output devices" to find a subcategory of "printers" is probably not on that list of reasons. Someone has been using a product to great advantage for many years and you want to "wait until you finish the last bit" to sell it as a whole to others - also probably not on that list. You want the login on the left hand side instead of the right?

After a week of such changes, it's one thing. Six months? GMAFB.

Perhaps you'd have been better off letting your customer's use it to see if they got confused, preferred blue links to red ones, or even happened upon an idea to make the application flow better.

So what does make the "OK to wait"-list? The fear of underwhelming an audience with your unfinished product would, especially if you're get to show them exactly one time. I can't think of much else that does. Can you?

So the point is that you need to get over the fear of success. Stop snatching defeat from the jaws of victory. Let a good thing or two happen. Help your customer's get past their fears.

Changing ourselves to recognize that fear and ignore it is something we can all do. Looking at our customer's excuses to keep the product in the warehouse from a fear-of-success angle might provide a way to relate to them instead of scoffing at their incessant requests for frivolity.

Success is staring you in the face. All you have to do is stick your hand out and embrace hers. Why do you turn and run away?

I'm exploring this space for the first time. Obviously, I have a lot of questions and very few answers. If you've got either of them, let me know in the comments - it's always appreciated.

My advice is to do it by the book, get good at the practices, then do as you will. Many people want to skip to step three. How do they know?

Similarly, part of code practice involves studying other people's code.

Doing so is good to teach you new tricks and things to avoid. But as Chad also mentions, it also exposes you to projects you might not have otherwise known about - giving you the option in the future to reuse it instead of writing your own version if your application requires it.

Two books I bought a few years ago might have been a good start to doing this type of thing: Mmurtl V1.0: How to Develop Your Own 32 bit OS and Linux Core Kernel Commentary. Sadly, I never did read them, and no telling where they are at now.

But not having those books won't stop me from reading source code - I plan to start that as part of my weekly practice sessions. It fits so well with one of the things I'm most interested in - improving the design of my own applications. You can say you don't run into trouble and therefore, your design is good, but how would you know until you've gone back to it after not looking at it for a year? You need something to compare it to, and I'm not convinced a UML diagram will suffice.

On top of that, if I'm lucky I'll gain some insight into my questions about how people go about designing algorithms. (Do you have answers?)

In the end, Chad gives two action items to follow up on:

1. Pick a project to read, make notes, and "outline the good and the bad." Use that experience to publish a critique of the project and it's code.
2. Start a study group to dissect and learn from code.

I'd like to start reading other source code, but I'm not sure when I'll publish a critique of it. On top of that, one of the things I'd like to do in the code dojo is dissect other people's code, even if I already find it helpful to analyze our own.

When you look at code, do you do it with a critical eye?

Preproject Considerations
Most of our business comes through referrals or new projects from existing customers. Out of those, we try only to accept referrals or repeat business from the "good clients," believing their friends will be similarly low maintenance, high value, and most importantly, great to work with.

We have tried the RFP circuit in the past, and recently considered going at it again. However, after a review of our experiences with it, we felt that unless you are the cause of the RFP being initiated, you have a subatomically small chance of being selected for the project (we've been on both ends of that one). Since it typically takes incredible effort to craft a response, it just seems like a waste of hours to pursue.

On the other hand, we are considering creating a default template and using minimal customization to put out for future RFPs, and even then, only considering ones that have a very detailed scope, to minimize our effort on the proposal even further.

We're also trying to move ourselves into the repeatable solutions space - something that really takes the cheap manufacturing ability we have in software - copying bits from one piece of hardware storage to another - and puts it to good use.

Finally, I'm very interested to hear how some of you in the small software business world bring in business. I know we're technically competitors and all, but really, how can you compete with this?

The Software Development Life Cycle
I won't bother you by giving a "phase" by phase analysis here. Part of that is because I'm not sure if we do all the phases, or if we're just so flexible and have such short iterations the phases seem to bleed together. (Nor do I want to spend the time to figure out which category what each thing belongs in.) Depending on the project, it could be either. Instead, I'll bore you with what we do pretty much every time:

At the start of a project, we sit down with client and take requirements. There's nothing fancy here. I'm the coder and I get involved - we've found that it's a ridiculous waste of time to pass my questions through a mediator and wait two weeks to get an answer. Instead, we take some paper or cards and pen, and dry erase markers for the whiteboard. We talk through of what the system should do at a high level, and make notes of it.

We try to list every feature in terms of the users who will perform it and it's reason for existence. If that's unknown, at least we know the feature, even if we don't know who will get to use it or why it's needed. All of this basically gives us our "use cases," without a lot of the formality.

I should also note that, we also do the formal bit if the need is there, or if the client wants to work that way. But those meetings can easily get boring, and when no one wants to be there, it's not an incredibly productive environment. If we're talking about doing the project in Rails or ColdFusion, it often takes me longer to write a use case than it would to implement the feature and show it to the client for feedback, so you can see why it might be more productive to skip the formality in cases that don't require it.

After we get a list of all the features we can think of, I'll get some rough estimates of points (not hours) of each feature to the client, to give them an idea of the relative costs for each feature. If there is a feature which is something fairly unrelated to anything we've had experience with, we give it the maximum score, or change it to an "investigate point cost," which would be the points we'd need to expend to do some research to get a better estimate of relative effort.

Armed with that knowledge, they can then give me a prioritized list of the features they'd like to see by next Friday when I ask them to pick X number of points for us to work on in the next week. Then we'll discuss in more detail those features they've chosen, to get a better idea of exactly what it is they're asking for.

We repeat that each iteration, adjusting the X number of points the client gets to choose based on what was actually accomplished the previous iteration - if there was spare time, they get a few more points. If we didn't finish, those go on the backlog and the client has fewer points to spend. Normally, we don't have the need for face to face meetings after the initial one, but I prefer to have them if we can. We're just not religious about it.

Whiteboards at this meeting are particularly useful, as most ideas can be illustrated quite quickly, have their picture taken, and be erased when no longer needed. Plus, it lets everyone get involved when we start prioritizing. Notecards are also nice as they swap places with each other with incredible ease.

Within each iteration, we start working immediately. Most of the time, we have one week iterations, unless there are a couple of projects going on - then we'll go on two week iterations, alternating between clients. If the project is relatively stable, we might even do daily releases. On top of that, we'll interface with client daily if they are available that frequently, and if there is something to show.

If the project size warrants it, we (or I) track our progress in consuming points on a burndown chart. This would typically be for anything a month or longer. If you'll be mostly done with a project in a week, I don't see the point in coming up with one of these. You can set up a spreadsheet to do all the calculations and graphing for you, and in doing so you can get a good idea of when the project will actually be finished, not just some random date you pull out of the air.



Another thing I try to be adamant about is insisting the client start using the product as soon as it provides some value. This is better for everyone involved. The client can realize ROI sooner and feedback is richer. Without it, the code is not flexed as much. Nor do you get to see what parts work to ease the workload and which go against it as early in the product's life, and that makes changes more difficult. For us, the typical client has been willing to do this, and projects seem to devolve into disaster more readily when they don't.

Finally, every morning we have our daily stand-up meeting. Our company is small enough so that we can talk about company-wide stuff, not just individual projects. Each attendee answers three questions:

1. What did you do yesterday?
2. What are you going to do today?
3. What is holding you back

The meeting is a time-conscious way (15 minutes - you stand so you don't get comfortable) to keep us communicating. Just as importantly, it keeps us accountable to each other, focused on setting goals and getting things done, and removing obstacles that get in our way.

On the code side of things, I try to have unit tests and integration tests for mostly everything. I don't have automated tests for things like games and user interfaces. I haven't seen much detriment from doing it this way, and the tradeoff for learning how to do it doesn't seem worth it at the moment.

I would like to learn how to do it properly and make a more informed decision though. That will likely come when time is not so rare for me. Perhaps when I'm finished with school I'll spend that free time learning the strategies for testing such elements.

Luckily, when I'm working on a ColdFusion project, cfrails is pretty well tested so I get to skip a lot of tests I might otherwise need to write.

By the same token, I don't normally unit test one-off scripts, unless there are obvious test cases I can meet or before doing a final version that would actually change something.

I don't know how to do it in CF, but when I've use continuous integration tools for Java projects it has been helpful. If you have good tests, the CI server will report when someone checks in code that breaks the tests. This means bad code gets checked in less often. If you don't have the tests to back it up, at least you'll feel comfortable knowing the project builds successfully.

For maintenance, we normally don't worry about using a project management tool to track issue. Bugs are fixed as they are reported - show stoppers immediately, less important within the day, and things deemed slight annoyances might take a couple of days. I'd like to formalize our response into an actual policy, though.

Similarly, new requests are typically handled within a couple of days if they are small and I'm not too busy - otherwise I'll give an estimate as to when I can have it done.

With bugs in particular, they are so rare and few in number that I could probably track them in my head. Nevertheless, I mark an email with my "Action Required" tag, and try my best to keep that folder very small. Right now I've overcommitted myself and the folder isn't empty, but there was a time recently that it remained empty on most nights.

In any event, I normally only use project management tools for very large projects or those I inherited for some reason or another.

Summary
If you're a practitioner, you can tell the ideas above