My first job primarily used Cold Fusion. When I joined AOL Time Warner I gave up Cold Fusion for PHP. When I joined IAG I gave up PHP for C#. And so on. As you can see, I've never been too tied to a language. I've always been most interested in learning and growing. I love jobs that help me improve my skills.
...
I prefer jobs that allow me to learn new things. Think of it as job security -- I shouldn't ever be out-of-date when it comes to technology experience. Think of it as an investment -- everything I learn creates a broader range of experience that I can leverage for future projects or jobs. Think of it as experimenting -- by trying many different solutions I may find ways to combine them and innovate.

Programming in C for the first time seems to be a chore. There are many details about your Code you need to keep track of. And C doesn't even lend you much of a hand when programming. There are no iterators, memory management is done manually, and handling strings correctly is akin to walking through a minefield with a hood over your head. While on fire. And being chased by a pack of wild dogs.

But then the question still stays: "what should one learn next?". Algorithms, data structures, complexity, math... Learn the core abstracts, ideas, and skills that are language independent, and that transfer from one syntax to another. Learn the ability to learn. When a new opportunity with new technology comes along, you should be able to get over the learning curve fairly quickly.
...
So lets drop this obsession with learning to say "hello world" (or some more complicated version of essentially the same) in every programming language one can name. Lets also drop the idea of finding "one language to rule them all; and retire". Once we put the Science back in Computer Science, it wouldn't matter which language you'll end up using.

(A disclaimer for you: I read this book as a reviewer and haven't yet made the time to go through the finished product, so some of what I'm about to say may change. That said, I can only imagine that it got better before going to publication, so I don't expect anyone would be disappointed.)

The Passionate Programmer retains that status of being a must-read. It adds a few new chapters and removes a couple of others, but more importantly it changes the framing from the negative view of "save your job" to what My Job Went to India was always really about anyway: "creating a remarkable career in software development."

Here's what I had to say about it for the blurb:

Six short months before I read Chad's book, I was on the verge of changing careers. Through a series of accidents from November to May, I decided not only to stick with software development but to be passionate about it while striving to be great. With a healthy dose of inspiration, the book you're now holding served as a road map for achieving those goals.

It truly is an excellent map that helped me find my way from Quit Town to making the decision to be passionate about hacking and life in general, starting this blog, and striving to leave the realm of the unclean masses in our profession whose exploits we read about so often.

If you read MJWTI and understood the positive aspects of it, this book isn't that important since you know most of it already. I'd have purchased it anyway, but you may feel differently. That's Okay.

However, if you felt you'd be embarrassed if someone saw you holding the first version - or just haven't read it before - I strongly recommend picking up a copy of this version and going through it. Don't just read it though - apply it. At the end of every chunk of advice there is a list of activities that you can perform. Don't just gloss over them; make it a point to actually do some of them.

It's short enough to read through in one or two sittings. But there's enough content in there to keep you busy for a couple of years.

If you've read this book or the 1^st edition, what did you think about it? Am I overenthusiastic?

I look forward to covering the new chapters as time allows over the next few weeks. I hope you'll join me in the discussion.

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 are heavily influenced by (when not directly part of) Scrum and Extreme Programming. I wouldn't call what we're doing by either of their names. If you're not familiar with the ideas and they interest you, now you know where to look.

Where would we like to go from here?
One thing that sticks out immediately is client-driven automated testing with Selenium or FIT. I'd also like to work for several months on a team that does it all and does it right, mostly to learn how I might better apply things I've learned, heard of, or yet to be exposed to. What else? That will have to be the subject of another post, as this one's turned into a book.

Thoughts, questions, comments, and criticisms are always welcome below.

1. JetBrains' IntelliJ IDEA: An awesome IDE for Java. So great, I don't mind spending the $249 (US) and using it over the free Eclipse. The Ruby plugin is not too shabby either, the license for your copy is good for your OSX and Windows installations, and you can try it free for 30 days. Martin Fowler thinks IntelliJ changed the IDE landscape. If you work in .NET, they also have ReSharper, which I plan to purchase very soon. Now if only we could get a ColdFusion plugin for IntelliJ, I'd love it even more.
   
   
2. Programming Ruby, Second Edition: What many in the Ruby community consider to be Ruby's Bible. You can lower the barrier of entry for your favorite programmer to using Ruby, certainly one of the funner languages a lot of people are loving to program in lately. Sometimes, I sit and think about things to program just so I can do it in Ruby.
   
   If they've already got that, I always like books as gifts. Some of my favorites from this year have been: Code Complete 2, Agile Software Development: Principles, Patterns, and Practices which has a great section on object oriented design principles, and of course, My Job Went to India. I have a slew of books I've yet to read this year that I got from last Christmas (and birthday), so I'll have to list those next year.
   
   
3. Xbox 360 and a subscription to XNA Creator's Club (through Xbox Live Marketplace - $99 anually) so they can deploy their games to their new Xbox. This is without a doubt the thing I'd want most, since I got into this whole programming thing because I was interested in making games. You can point them to the getting started page, and they could make games for the PC for free, using XNA (they'll need that page to get started anyway, even if you get them the 360 and Creator's Club membership to deploy to the Xbox).
   
   
4. MacBook Pro and pay for the extra pixels. I love mine - so much so, that I intend to marry it. (Ok, not that much, but I have been enjoying it.) The extra pixels make the screen almost as wide as two, and if you can get them an extra monitor I'd do that too. I've moved over to using this as my sole computer for development, and don't bother with the desktops at work or home anymore, except on rare occasions. You can run Windows on it, and the virtual machines are getting really good so that you ought not have to even reboot to use either operating system.
   
   Even if you don't want to get them the MacBook, a second or third monitor should be met with enthusiasm.
   
   
5. A Vacation: Programmers are notoriously working long hours and suffering burnout, so we often need to take a little break from the computer screen. I like SkyAuction because all the vacations are package deals, there's often a good variety to choose from (many different countries), most of the time you can find a very good price, and usually the dates are flexible within a certain time frame, so you don't have to commit right away to a certain date.

Happy Thanksgiving to those celebrating it, and thanks to all you who read and comment and set me straight when I'm wrong - not just here but in the community at large. I do appreciate it.

Do you have any ideas you'd like to share (or ones you'd like to strike from this list)?

• Physical/coordination: Visiting "the dusty corners of your primary programming language," such as deep exploration of regular expressions, tools, and APIs you rarely (or never) get a chance to use at your day job. I'd put learning other languages here, and experimenting with new constructs and paradigms, like you can win an iPod Nano for doing. You may not use it often, but when you need to, you'll be prepared. On the other hand, you may find something that used to take you hours can be done in one line of code - it's built right into the language.
  
  
• Sight reading: If you can sight-read code, how much faster would you be at finding and diagnosing problems, or adding new features, just by having the ability to understand the structure of an application instantly? Chad recommends going to the to-do list of an open source application, deciding on a feature to implement or bug to fix, and then going through the source to find out where it needs to go. Impose time constraints on yourself, and rotate through many different projects (and languages), and you'll get faster at "sight reading" code. You don't even need to implement it - just finding the place to put it would be enough (but it would be even better if you did!).
  
  
• Improvisation: Chad defines improvisation as "taking some structure or constraint and creating something new, on the fly, on top of that structure." One such example he described was

  recovering lost data by manually replaying packets over a wireless network from a binary log file. No body meant for you to do these things, especially not in the heat of the moment. [But] that kind of sharp and quick programming ability can be like a magical power when wielded at the right time.

Of the three, I really like his ideas on practicing improvisation: "Pick a simple program, and try to write it with [self-imposed] constraints." One example is printing the lyrics to 99 Bottles of Beer on the Wall "without doing any variable assignments." Or golfing. I'm sure you can think of others (and I plan to).

I haven't done as good a job at practicing as I'd like to, so I'm going to resolve to sit down weekly and just have some practice time, stressing the points above. I won't be too ambitious though - I've already over-committed myself for the rest of this year. But as my early New Year's Resolution, I'll plan on blogging my weekly experience in regularly scheduled practice, like Scott Hanselman does in his series, The Weekly Source Code.

Anyone want to lend some moral support and start practicing too? We could be like virtual workout partners, flexing our coding muscles.

Note: I didn't do a good job of showing it in the article itself, but all the quotes there are from Chad Fowler.

Unfortunately, I quickly found out that the one professor I wanted as an advisor would be leaving soon and was not taking any new students. But I didn't let that stop me. Sure, a formal relationship with a mentor is nice, but as Chad mentions in the book, you can have mentors who don't even know they are filling that role for you.

So 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.

Notice that, excepting the Code Dojo, where our aims to be a mentor and be mentored are explicit, nothing in the previous paragraph requires those people to know they are filling that role for me (until they read this, I suppose).

If anyone wants to be my mentor, I can pay you with a heartfelt "Thanks!" And if you need a mentor, don't hesitate to contact me. I'm always glad to help when that precious combination of time and knowledge allows for it.

Do you have mentoring relationships with anyone, or any group? How does it work for you?

*: I'm starting to think everything I say is correct because I haven't had many disagreements lately. Perhaps I need to start saying stupid things I know are wrong just to see if you all are paying attention. I'll be a troll on my own blog.

Being a good developer means not relying on your "server guy" to set everything up for you. Be a master of source control, testing, and of setting up your own development tools: the IDE, outside references or the build path, and the virtual machine (or whatever runs your code).

Learn how to make ColdFusion work with your database. Figure out how to install and run Rails - don't rely on it being preinstalled on Leopard.

For quite some time in college I was afraid of using the command line to compile my programs - I just wrote them in Windows using Dev C++ and turned them in, blindly hoping they would compile and work correctly for the person grading my program on Unix.

For God's sake, learn how to compile your own programs, even if modern IDEs do it onSave().

I hate to say it, but you're in the wrong line-of-work if you are constantly asking for fish. Technologies change too quickly to ask for help every time you run into a roadblock. The problem is magnified tenfold if you have to ask several times to accomplish the same task.

On another note, Chad mentions code-by-wizardry as being particularly painful:

A[n] ... easy way to get lazy is to use a lot of wizards that generate code for you. This is particularly prevalent in the world of Windows development where, to Microsoft's credit, the development tools make a lot of tasks really easy. The downside is that many Windows developers have no idea how their code really works. (page 50, emphasis mine)

I can attest to that. You know that main class that processes all the callbacks in a typical Windows program? I didn't either. Consequently, my first several forays into programming for Windows resulted in disaster. If I could find that code, I'd love to post it for inspection, so you could marvel at how Button1 did something for TextField2 and all of it somehow worked in one GodClass. The magnificence of the horror led to nightmares for me recently as I discovered the XNA framework. The wizards are there to make your life easy - not to be a replacement for knowledge and thought. You still need to understand what they are doing for you.

The point is that you have to learn. Don't be afraid to ask, but when you ask, make sure there is a purpose behind it. If you teach yourself to learn, and you learn everything you need to know, you'll be in good shape. But, to end with some advice from an old professor of mine, be honest about what you know. Don't be afraid to admit your shortcomings - instead, use it as a chance to learn, not as a chance to have someone else do it for you.

Don't do it that way is the advice from MJWTI this week.

In particular, I want to share one passage that resonated with me:

Somehow, as an industry, we fool ourselves into thinking market leader is the same thing as standard. So, to some people, it seems rational to make another company's product a part of their identities. Even worse, some base their entire careers around non-market-leading products -- at least until their careers fail so miserably that they have no choice but to rethink this losing strategy.

Let me repeat that: some people base their entire careers around non-market-leading products.

That sounds just about where I was 18 months ago. Today, I cannot imagine basing my career around a product, much less insignificant ones. I try to relate everything to myself in terms of ideas, and I try to regularly experiment with the unfamiliar. Even if I were not able to do some of it at work, it would be well worth the effort of spending a little time at home to do that.

Moving around at the whim of others. You assert no control over your own safety. If you were dropped, what would you do?

Have you felt that way? Do you still?

Chad mentions a measure he used to assess a job candidate's depth of knowledge in Java: a question of how to make the JVM crash.

I'm definitely lacking in this regard. I've got a pretty good handle on Java, Ruby, and ColdFusion. I've done a small amount of work in .NET and have been adding to that recently. I can certainly write a program that will crash - but can I write one to crash the virtual machine (or CLR)?

I can relunctantly write small programs in C/C++, but I'm unlikely to have the patience to trace through a large program for fun. I might even still be able to figure out some assembly language if you gave me enough time. Certainly in these lower level items it's not hard to find a way to crash. It's probably harder to avoid it, in fact.

In ColdFusion, I've crashed the CF Server by simply writing recursive templates (those that cfinclude themselves). (However, I don't know if that still works.) In Java and .NET, I wouldn't know where to start. What about crashing a browser with JavaScript?

So Chad mentions that you should know the internals of JVM and CLR. I should know how JavaScript works in the browser and not just how to getElementById(). With that in mind, these things are going on the to-learn list - the goal being to find a way to crash each of them.

Ideas?

Towards the end of the chapter, Chad tells us about his early days in IT:

What first amazed me most when I entered the information technology field was that many well-educated programmers (maybe most) didn't know the first thing about how to set up the systems they used for development and deployment. I worked with developers who couldn't even install an operating system on a PC if you asked them to, much less set up and application server on which to deploy their applications.

After reading that, I thought to myself, "That's me." Rather than wallow in self-pity, I decided to do something about it.

Where I used to ask "our server guy" (that's his official name) to do something, I started asking him how to do it. ButI didn't immediately start there - I started trying to figure it out on my own before going to him for help (à la Mr. Raymond's famous guide). Now I don't need help in setting up virtual directories or web sites or my development environment (yes, I was that bad).

Instead of being helpless, I set up Rails, installed Linux and fixed up dual widescreen monitors, set up Subversion, set up my own development environments in general, and played with ANTLR, among a slew of other things past, present, and planned for the future (on my TO-LEARN list).

Doing things like I mention above is not impressive. Certainly things like that aren't hard to do. But doing them helps you get over your fear of new technology and take responsibility for your own improvement.

The chapter ends with advice to "list the dimensions on which you may or may not be generalizing your knowledge and abilities" and to do something about it. There are an "infinite number" of aspects for which you could do it, but Chad limits his discussion to five: "Rung on the career ladder, Platform/OS, Code vs. data, Systems vs. applications, [and] Business vs. IT."

I've got a long way to go, but I'm slowly getting to where I want to be. Are you doing anything?

As I said in the last post about this book, I used to be that developer. Since then, I've improved myself considerably in Java and learned a great deal about Ruby, among other things.

But asking "what's your new language this year?" misses the point. The big shift comes when you accept responsibility for your own improvement. Once you've done that, instead of feeling threatened by new (to you) technologies, you start to embrace them.

Now, instead of avoiding projects in unfamiliar territory, I'm asking for them. Instead of laying down to be steamrolled by something I've yet to try, I take at least a few minutes to familiarize myself with it, like I did recently with ANTLR. When I've got a bit of extra time on my hands, I'll go all out and even do something useful with it.

Go explore. Now.

That sounds incredibly unlike me now. Although the change was occurring before I read his book (as evidenced by the fact that I was reading it in the first place), it certainly helped accelerate things.

(Let me also say I feel weird posting a link to the book each time I write one of these, but I don't want someone new to come along and think "WTF's he on about?" So for all you regulars, please ignore what must seem like link spam for the greater good of improving oneself: I'm not a PragProg salesman or affiliated with them in any way. Though I am an affiliate with Amazon, I don't get any special consideration for promoting this book out of all the other things I could be writing about.)

Anyway, Chad suggests making "a list of early, middle, and late adoption technologies" (page 23). Then, note the one's you're strong in, ones you have some experience in, and some you have no experience in. Try to notice any pattern there. And finally, "are there any technologies around the far edges that you have some special interest in?" Those are the high risk/high reward type cases where there is more money to be made. The middle has many more jobs, but also much more competition from other programmers.

So here's a small list I made (from early adoption to late adoption). A + marks technologies I'm fairly strong in while a - is just some experience. I 'm trying to be honest with myself, so call me out if you think I've got something wrong:

Early adoption: Lisp(-), Haskell, Erlang, Ruby(+), JavaScript(+)

Middle adoption: SQL(+), Python, Perl, ColdFusion(+), PHP(-), ASP.NET(-), C#(-), Java(+), .NET(in general)(-)

Late adoption: ASP(-), JSP(+), ASM, Visual C++(-), COBOL

I put Lisp in early adoption because I could foresee it becoming big at some point. Probably not, but I don't think its mainstream or in its sunset years either. Similarly, I think JavaScript while abundantly adopted is only done for simple web scripting. I see its importance rising.

I'm not sure where CF belongs, honestly. Certainly not early adoption. It's in the middle somewhere, but I don't know how early in the middle or how late. I'm tending later. For Java, I put it near late adoption because I think its importance as a language is diminishing, though its importance as a platform will remain steady.

I'm not sure where to put PHP either honestly. I almost went with late adoption because I can't foresee myself ever looking for a job doing PHP. But that's just me. I certainly don't think its importance is on the rise, however. Of course, I don't think that about CF either, given prevailing attitudes.

That's just a few large things- a lot related to web development (since that's what I'm most familiar with). I'm also having trouble thinking of technologies I have no experience in whatsoever. There are tons, to be sure, I'm just not finding any when it comes to the language level of granularity. What important languages have I missed? I know I missed SmallTalk, but I don't know whether to put that in early or late adoption. At the moment it belongs in late, but will its importance rise?

Anyway, what does your list look like? What technologies are missing from mine and where would you put them on the curve?

Working for a tiny consulting company, I get the benefit of being close to all the business decisions, but not in many specialized domains. However, since I made the decision to stop being a "code robot" (Chad's term), I've always taken the opportunity to talk with clients or meet them for lunch to discuss their domains. Even more recently, a couple of us here have taken to reading trade publications related to a product we're building.

Doing so helps you understand why some of those "crazy" requests are made, and what you can do to make them work in the system while still accomplishing the client's goals. And things just seem to work better that way. Nowadays, I'm no longer getting any "that's a nice system, but it's not what I wanted" comments due to keeping myself stuck in a walled garden. Instead, I'm building software customers want and will use. And the purely selfish benefit: I'm adding to my value as an employee or contractor in those domains.

As an aside, last week I was on vacation, so that's why you didn't see this then. I'll try to make up for it and post two this week.

So are you a code monkey? Are you trying to evolve into a code human?

In the first nine chapters, Chad tells us how to choose the right market. So for my first week, he addresses supply and demand: first we want to search jobs in our home country, as well as those available offshore. Compare the results and highlight skills in demand in your home country that nobody (or very few people) offshore is offering.

Then, you just need to become good at those technologies that are in demand but aren't yet available offshore (or in high supply). This is simple economics.

To get a head start, you might want to watch the alpha geeks and see what they're doing, but you can probably afford to start a little farther along on the curve.

Sounds easy enough. So, start googling. Better yet, why doesn't someone create a service that performs this search and analysis for us?