wandercoding.com

A couple of days ago, I was working on some code. I had created a few temporary files on disk and needed to delete them. I was going to work out a scheme for recording the file names and hooking into an exit routine to delete them. I went to look for the delete file command in Java and found something brilliant: File.deleteOnExit.

I was thrilled and stunned to be confronted with the answer to my problem. All I had to do was call this function and Java would take care of the rest. It doesn’t get any easier than that. This is just one reason that I don’t agree with Jeff Atwood on his assertion that you must be a good typist to write code. If I had blindly started writing this utility, I would have added a few dozen lines of unneeded code. However, that’s not really the point here, just a corollary point.

My real point is that including deleteOnExit was brilliant. It’s just one example of why I love Java for writing an application. I’ve written loads of C++, and a little C# (but, not enough to know all of the hidden functionality). What amazes me is that I’ve been able to make incredible progress on my application than I would have considered possible in C++ in more than twice the time. Part of it is due to Java’s integrated UI, graphics, and table functionality. In C++, there’s an object oriented language, some utility classes, and the Microsoft windowing and graphics stuff that’s really old and poorly designed. In C#, at least there’s some integration of these things as an environment. But, that’s still not the point.

Getting back to the point - including useful functionality as part of the package saves people time. It’s part of picking the right tool for the job. It’s why you should write a script for repetetive programming tasks. It’s why you should refactor your code to create as many utility functions for other programmers to use. It’s why the Extreme Programming mantra you’re not going to need it is only partially on the mark. It’s why you should always think about how to make your code reusable. It’s why you should try to write as little code as you can to do the job correctly, creating and using the tools available to make coding easier.

The next time you’re writing some code, think about whether there’s a way that you can make it easier to use. Including deleteOnExit is just one example of saving thousands of users time because one programmer thought to add it to the toolkit.

Today’s world of software development is decidedly more global. Outsourcing and offshoring is common because every knows “it’s more economical.” While I won’t debate that last statement (I’m not really convinced it’s more economical), it is simply a fact of life and not really the point of this particular post anyway.

Currently, I work from home. I’m doing some contract programming work for a local company. I’m developing an application that they had had an intern start. The intern had spent several months working on it and it was allegedly nearing the stage where it might be considered sellable. As it was used mainly internally, the requirements for style, bug-proofedness (is that a word?), and functional completeness were a little lax.  And so I come to inherit a piece of code written a couple of years ago by an intern.  Most of the code was unusable due to a complete lack of comments, usefully named variables, and code that wasn’t full of bugs.  Nonetheless, I was able to lift some ideas and one piece of code that undoubtedly will save me some time, but is nearly unreadable.

But, that’s not the point of today’s post either; it’s just some background.  The real point of this post is maintaining contact with your employer, colleagues, manager, etc. (I’m going to group these people into a term called “work folks” for future ease of reference.)  In other words, being there.  If you work remotely, getting face time with your work folks is difficult, but not impossible.  There are several options for increasing your visibility.

• Take a trip.  There’s really no better way to increase your visibility than actually being visible.  Take your laptop and find a desk in the middle of the place if possible (rather than a secluded conference room.  Become “one of the guys” for a week or two.  Have lunch with everyone that you can and get to know them a bit more personally.
• Make a phone call.  If you can’t be there, at least pick up the phone occasionally rather than relying totally on email, which is far less personal.  Conversations have more range of direction that they can flow in due to their interactive nature.  The scope and types of things you can find out in a conversation are far greater than what you’ll get in an email response.  There’s also a far lower likelihood of being misunderstood or having to ask for more clarification in a followup email and the turnaround time in a conversation can’t be beat.
• Communicate regularly.  Trips are expensive (depending on distance), phone calls aren’t always easy due to time zone issues and meeting schedules.  If nothing else, a regular email update will keep you in the minds of your work folks.

Whichever mode you pick, keep up a regular pace of communication so you stay on the radar of your work folks.  It will make you feel like you’re a part of the team and make the team feel like you’re one of them as well.

Have you noticed that chipotle is the new baking soda. Back in the 90’s, you couldn’t turn on the TV without seeing a commercial talking about how they added baking soda to make the product better. Crest toothpaste - now with baking soda. Try our laundry detergent - now with baking soda. Goodyear tires - now with baking soda. Arm & Hammer Baking Soda - now with even more baking soda!

Well, today, chipotle is the new baking soda. You can’t turn on the TV without seeing a commercial talking about how they added chipotle to their chicken/steak/hamburgers/barbecue/broccoli. Although I haven’t eaten out much recently, the idea is that chipotle will give the food an extra kick of flavor that will delight you.

When I was writing software in the 90’s, I used to talk about advertising our next version of software as “Version 2 - now with baking soda”. But, since we’re living in the year 2008 where chipotle is the next big thing, I’m recommending that you add it instead. That begs the question, “How?”

Now that I’m doing some private contract work, my work attitude has changed considerably. I’m no longer working for a large, bloated, cash-laden company. It’s not like I didn’t give every company my best ideas and effort, it’s just that an environment like that tends to have long development cycles, lots of waiting for specs and testing, etc. In other words, it often lacks a sense of urgency and a sense of true ownership and responsibility. Now that I’m working for a friend, I have a renewed sense of all of these. One thing that this is leading me to do is add chipotle to my software.

When I first sat down to talk about the application I’d be working on, I had tons of ideas, but wanted to make sure that I could continuously send software updates to keep my client aware of my progress. I also knew that this was a first release and that my client didn’t want to spend a fortune on it. On the other hand, a first impression is a lasting one, whether it’s your software in front of a customer, or your work for your client. So, I regularly send updates and when I do this, I outline a list of the new functionality I’ve added and ensure that everything works well. In addition, I try to add a little chipotle with every update. Sure, it’s supposed to show something on the screen when this happens, but isn’t that dialog sharp looking? Sure, it’s going to have standard printing functionality, but how about this special option that automatically does some setup that will save you tons of time?

When you’re working on someone else’s dime, it adds pressure to stay focused on task. It means not wasting time (or at least not charging the customer for it). It means adding some chipotle, especially if it doesn’t cost the customer anything extra.