The prevailing wisdom at the time was that it would be easy for us to do a Mac version, “because it’s just UNIX now, and you guys are UNIX already – it’ll just be another port”.  I remember hearing this over and over at trade shows in between requests for Ruby support, and “Do you guys have any free t-shirts?” (Right now, there’s a guy in his basement inventing a new scripting language, convinced his will be the one that will take over the world, obsoleting all other scripting languages.  I really wish somebody would stop him, because it won’t take over and obsolete all other scripting languages, but it will become just popular enough we will have to support it.  When I say “stop him”, I don’t mean hurt him or anything – just take him out to dinner or introduce him to a woman).

It turns out the “It’s just UNIX now” logic is a bit, what’s the word I’m looking for…. wrong.  There is UNIX under there, and obviously that was a good place to start when they revamped MacOS.  Plus, I can get a console window which was always my complaint about Macs “back in the day” (yes, I know you could install something, I maintain it should just be there).  But what the fact that “It’s just UNIX now” got us was the ability to create an X11 application that would run on the Mac.  So we did that – and customers loved it.  Well, that isn’t exactly true.  They acted more like we gave them a new BMW but first used it for one of those things you see at the county fair where you pay a dollar and get to hit a car with a sledgehammer (granted they usually do this with demolition derby cars, not new BMWs).  It was SlickEdit – it worked, but it just didn’t look or feel like people expected it to. Hardcore SlickEdit fans were happy… ish.  They were happy to have SlickEdit, but they missed all the Mac-isms, and were a little perturbed by SlickEdit’s menu being attached right to the top of the application window.

So, starting sometime in 2010 our CTO began the process of exploring how to get us a native version on the Mac – and the GUI overhaul that ensued stayed largely in his office until sometime this past spring when different team members began to have certain controls assigned to them to port to our new GUI framework (I’m not going into which one here, the evidence is “out there”).  I was able to be part of this process, and it was very interesting work.  It is an exciting time to work here at SlickEdit.

We had a nice long beta test – a little longer than we planned. I would like to take a moment to say that our beta testers were some of the best we’ve ever dealt with.  Even when there were problems, the comments almost always went something like “It crashed, but thanks for doing a native Mac version, great work, looking forward to the next version!”.  The beta testers this time were aces – some of them old SlickEdit fans we’ve known for a while, and I believe we made some new friends too.  Thanks guys.

So, our native Mac version is “out there” now.  We hope everybody likes it.  Typically I haven’t been a big Mac fan, but I’m learning to appreciate the things that it does well.  I only wish I could get a few people to join me in an Indiana Jones like quest to track down the eleven remaining single button mice on the planet and then Ctrl+Click could work properly.

If you bought any of our X11 versions on the Mac you can get the new version for free. Here’s the link,or you can give our sales team a call at (919) 473-0070.

Caffeinated Soap
No, we’re not making this up. http://www.thinkgeek.com/interests/giftsunder10/5a65/ 
Between end-of-year project deadlines, gift shopping, and other holiday preparations, a coder can get really squeezed for time. And you don’t want to back a programmer into a corner where they have to choose between sufficient caffeination and personal hygiene. This should avoid any such unpleasantness.

A Blunt Instrument
http://www.harborfreight.com/4-lb-neon-orange-dead-blow-hammer-41800.html
There are situations in which you simply cannot improve upon a large hammer.  This is the reason that the B-52 has had such a long lifespan. This orange beauty will allow your beloved techie to vent frustration upon keyboards, desks, recalcitrant Solaris machines, etc without the risk of forehead or hand injury.

A “Come home for dinner late” card
It’s surprising how many bugs are found just after the “I’ll be home by 6:15 for dinner” phone call. Your programmer is now torn between a promise to loved ones and a dedication to hunting down that crash before calling it a day. Give them a Monopoly-style “Get out of dinner, free” card so that at least once this year week, they can arrive late without guilt.

A USB-chargeable flashlight
http://www.berettausa.com/products/jolt-usb-flash-light-b2c-only-blue/
A USB flashlight is insidious in its irresistible blend of techie-seducing features. First off, it’s a USB device. *Anything* USB (and to a lesser extent FireWire) is worthy of investigation. Secondly, it’s the size and shape of most trade show trinkets, which programmers are wired at birth to hoard. Thirdly, it has a genuinely useful function, which all but ensures your coder will make every effort to rationalize this gadget’s place in the laptop bag for years to come.

Carpal Tunnel Therapy
http://www.amazon.com/Roleo-Therapeutic-Carpal-Therapy-Massager/dp/B005CP4GDA/
Because sometimes you gotta play hurt.
(Not yet verified, but I think this thing can also make homemade ravioli…)

Yoga Gear
http://www.amazon.com/Office-Yoga-Simple-Stretches-People/dp/0811826856
Not only is this great for relieving the tension of long hours frozen at the keyboard, it appears to also be a crafty way of furthering ones career.

Let’s assume you have some file extension which is not already set up accurately in the default SlickEdit Core configuration. It might be something your company only uses internally. Let’s use .data for this example.

I have a workspace created which includes some .data files, and what I first see in the Navigator view is this:

When I go to open one of these files, Eclipse will use the standard Text Editor because it does not know better:

Not terribly useful…clearly the SlickEdit editor has not been opened, and we have no language support whatsoever. These appear to be COBOL files…so we should set up Eclipse to recognize them as such, and also tell SlickEdit that these files should be treated as COBOL code.

The first step is to go to Window > Preferences > Editors > File Associations and add *.data as a “New File Type”. Then select *.data in the list and click the Add button in the “Associated Editors” pane. Now select “SlickEdit Editor”. Make sure you mark “SlickEdit Editor” as the “Default” editor for this file type. Now we have told Eclipse to open all .data files with the SlickEdit Editor.

We are not quite finished yet. Now we need to tell SlickEdit to treat these files as COBOL. So, go to Window > SlickEdit Preferences > Languages > File Extension Manager and create a new extension for data (just data…not *.data), and assign the language to be Cobol 85. Click “OK”, and then click “OK” on the SlickEdit Preferences dialog. Now when you open up one of these .data files, you will see the correct editor opened with the correct language support.

Since the Eclipse IDE has become so popular for mainframe developers, we have been dedicating more and more resources to our mainframe language support. The SlickEdit editor is even now integrated into the Compuware Workbench:

Supports a vast array of programming languages for source code editing, powered by SlickEdit.

PL/I is one of the mainframe languages that got a major support upgrade in the newly released SlickEdit Core v3.7.1. The SlickEdit editor now has full support for parsing structures, includes, and even statement level tagging for PL/I code.

SlickEdit Core also has great support for COBOL, JCL, REXX, and other languages. If you are a mainframe developer coding in an Eclipse-based environment, try out the latest version of the SlickEdit Core plugin for free.

SlickEdit is an MDI application
While there are some very well known applications that support a multiple document interface on the Mac, there is no real standard for how they should look and feel. Each application has a slightly different interpretation. As such we have chosen to keep our MDI implementation very close to what we have used in recent versions.

SlickEdit does a lot
This mostly affects how we present our application configuration options. Most Mac applications have a relatively small Preferences pane, perhaps with half a dozen categories, and a half-page screen of options for each category. But SlickEdit has 20+ years worth of features and configuration settings. Developers come to SlickEdit from a wide variety of editing environments, and our users want to be able to mold the application to their tastes.

SlickEdit is not just for the Mac
Like all multi-platform software, we have to make trade-offs between what might look best for a particular operating system, and what makes the most sense for a feature that needs to work on all of the supported platforms. There is also quite a bit of bias toward keeping functionality and appearance consistent with what long-time customers want and expect. SlickEdit has always placed a premium on letting you work with multiple languages on disparate platforms without having to retrain your brain and fingers. When implementing and tweaking features, we are constantly evaluating what a Mac user would expect, and what a SlickEdit user (regardless of platform) would expect.

SlickEdit will continue to evolve
While we do want to keep our product familiar across platforms, we aren’t going to be sitting stock still. While our immediate focus for the Mac is improvements to Objective-C language support, and better interoperability with Xcode project formats, we are looking forward to changes we can make in the user interface to improve effectiveness and efficiency. Getting this first non-X11 release ready was a big effort. And now that it’s almost done, we’re looking forward to making it the best it can be. We’re excited, and we hope that you will be too.

If you haven’t yet taken a look at SlickEdit 2011 for Mac, we invite you download our most recent beta version.

I didn’t buy your book. There are several reasons I walked out the door without shelling out for your title.

First off, fifty bucks on the sticker price subjects a book to a lot of extra scrutiny. When I think of all I can do with that sum, the bar gets set pretty high. This used to be somewhat ameliorated when Borders was still a going concern. Their frequent 30% and 40% discount coupons made me a little more cavalier in my purchasing decisions. I am now limited to shopping Barnes and Noble. They have a good selection of titles, but they are a bit more stingy with the coupons, and a 10% discount barely covers our state sales tax. I’m still willing to part with two Jacksons or more, but you’ve gotta wow me.

Why does your book have 10 authors, including 9 I’ve never heard of? Unless I’m reading a short story anthology, I’d prefer to see just one or two subject matter experts. I get a little suspicious when the author count goes above 3.

Annotated code samples and snippets are wonderful. And bonus points can be earned for legibility-enhancing color coding. But I really don’t care to pay for the trees you chopped down to provide over 200 pages of mostly boilerplate code. I work with computers for a living, so I’m not afraid to download a zip file with source code. Look into it.

Your book won’t stay open. I know a nice binding, especially a hardback binding is going to cost more. But I don’t have two sets of arms. Most of the time I’m reading a computer book while trying to work on the computer. I’d prefer not to have to pin down a page with empty coffee mugs and my left elbow while trying to type in a code sample.

Your index isn’t helping me find what I need. If I’m in the market for a programming title, it’s often because I am unfamiliar with the language or technology. And since I’m not plugged into the lingo yet, I need all the help I can get finding the relevant passages. An index that is 90% class and function names does me little good.

Before you decry how internet retailers are pushing down your margins, let me assure you that I still buy most of my software titles in a brick and mortar store. I’ve been disappointed too many times buying books online, sight unseen. I need to hold a book in my hands and flip few a couple chapters. I’ll buy that book in the store, but you’re going to have to work a little harder for my money.

Sincerely,

TechBookShopper

The winner will receive an iPad 2 valued at $499 (he/she may opt to receive a visa gift card of equal value instead).

So, what are we looking for? In an attempt to not limit your creativity and critical thinking, we are keeping this as open-ended as possible. The winning submission will stand out from the rest. Maybe it does something really neat and creative, or it solves a widespread problem with just one line of code. Your submission doesn’t have to be long or short, but it has to wow us in order to win the iPad!

You can enter now through October 31, 2011, so there is plenty of time to put your best macro together and submit it for your chance to win! Click here for contest rules and how to enter.

Look at this. It’s worthless – ten dollars from a vendor in the street. But I take it, I bury it in the sand for a thousand years, it becomes priceless. Men will kill for it. Men like you and me.
- René Belloq, Raiders of the Lost Ark

Whether it be changing jobs, moving to a new house or office, or simply cleaning out clutter, every so often I find myself sorting through the bits of technology-related junk I’ve accumulated over the years. There’s a fair amount of trade show goodies, some of them entirely too cool or valuable to part with. The bulk of it is reluctantly thrown away, including stress-relief squeezy things, can coolers, light up pens that no longer light, and the like. But there are items that always survive the cut, ones that have some sentimentality attached to them.

Professional Developers Conference 2000 pen

I cannot believe this thing still writes after 11 years. It has lived in the glove box of the three different cars I’ve owned since 2000. This was the PDC where Microsoft formally introduced the .NET platform to the masses. I vividly recall the stunned looks on thousands of keynote attendees as they realized all their Win32 mastery was just rendered obsolete. The pen has actually outlasted several .NET technologies introduced at the conference. I’ve got one from the 2003 PDC ready to go once this one runs out of ink.

Cyrix x86 processor

A leftover from my system building days. It was the first real ultra-cheap x86 alternative, and prompted Intel to develop the Celeron line. I placed this in a slapped-together spare parts budget computer (running Windows 95) that I assembled for my wife’s grandparents. Cyrix as a company didn’t last long, but this chip powered that system for over a decade. Now that the grandparents are gone, I can’t bear to toss this hunk of silicon junk.

NeXT Step poster

I got this gem in a trade with my wife’s uncle, a sysadmin, for a Windows Server 2000 license. It’s a panorama of the first generation NeXT system, replete with all black computer, keyboard, monitor, and printer. I’ve been meaning to put it up on my office wall, but I can’t bring myself to stick pins through it, and I can’t justify the cash it would take to frame it.

Do you have anything like this that you can’t seem to part with? Please share by leaving a reply!

In order to become a better golfer I decided to start from scratch, beginning with lessons from a PGA pro and purchasing a set of clubs suited to my ‘experienced beginner’ game. And in the process I have found some interesting parallels between learning to golf (again) and learning to use a code editor.

You need solid fundamentals as your foundation
Having been a badly-self-taught golfer for the majority of my life, I now see them all the time at the driving range. And it always starts with the hands. If you have a lousy grip, you’re going to have a lousy swing. The corollary in software development in my mind is basic typing and keyboard navigation skills. You can have a talented mind for software development, but if you’re not touch typing your way through source code, you’re making it way too hard on yourself.

Know and use the tools available to you
I recall a time when my high school golf coach, in a effort to make a point about club selection (or perhaps just to show off), played a few holes with just a 3 wood, a 7 iron, and a putter. This is eleven clubs fewer than you’re allowed to carry. We got the point he was trying to make, but you don’t see good players with fewer than 14 clubs in the bag. And they aren’t using the cheapest off-the-shelf sticks, either.

I also recall a PDC conference session several years ago where the presenter was banging out ASP.NET examples and frequently used Notepad to tweak some of his prepared code snippets. The audience started tuning out about the 5th time he had to repeat the edit-save-compile cycle on a particularly troublesome sample, when the use of any decent code editor would have shown the syntax error at the top of the file right away.

Master the basics so you can focus on the harder tasks
Once you have a solid, reliably repeatable golf swing, your mind is free to focus on all the other details of the game. A software developer that is in command of his or her IDEs, editors, debuggers, etc is likewise free to focus on the real work of designing and coding.

Everybody’s “key move” is different
One night at the driving range I was having a terrible time making clean contact with the ball, even with the deliberate practice of what my golf coach and I had just gone over in the previous lesson. But somewhere in the recesses of my memory I pulled out a tip I had read in Ben Hogan’s Five Lessons where he recommends a wrist waggle as part of the pre-shot routine. So I gave it a try. Lo and behold the waggle made it quite evident that my stance was too close to the ball. After making the adjustment, everything else fell into place. Now I don’t swing a club without this waggle routine.

Most software developers have their favorite features and shortcuts in their editor of choice. These features become an essential part of how they navigate a source base or edit code. My key move in SlickEdit is using the SlickEdit command line. It’s the first place I go when I want to do a quick search, compare the current file with Subversion, look up a keyboard shortcut, and dozens of other operations. Other folks swear by aliases or custom macros. Some will create custom key bindings for every conceivable editor operation.

Demo clubs are awesome
I tried out half a dozen models of clubs before finding the set that I liked the best and felt right for my work-in-progress swing. If you’re not yet carrying SlickEdit in your tour bag, we invite you to download a trial and take it out on the range.

The primary oddity I see is the scheduling of the release. Hot fixes are easy. A problem comes up, you investigate and fix it, then send out the small update. And for us at SlickEdit, major releases are dictated by our annual release cycle. We *will* have a beta in the early spring and we *will* have the major release out late spring/early summer. Lawns go un-mowed, playoff hockey goes unwatched, and “I’ll be home for dinner” promises are broken in order to meet the schedule. For hot fixes and major releases all of the time pressure is one-way: the sooner the better.

A point release is just harder to time as there are forces pulling at both ends of the schedule. An earlier release means customers don’t have to wait as long for the features we had to let slip initially. There is a shorter wait for resolutions to the small bugs that didn’t warrant a hot fix. An earlier release means that the quality of the trial version is better sooner. And the quicker it goes out the door, the sooner we can focus all attention on feature development for the next major release.

But there are also forces that want to delay the service pack. More time means more polish, fewer bugs, and more special requests that can be accommodated.

This release is a little more poignant for me personally. I primarily work on the Mac version of SlickEdit. And we are committed to providing a native version for 2012, meaning that we’re finally getting rid of our X11-based UI. It’s a welcome (admittedly overdue) change, and I’m enjoying the early progress we’re making. But this release of 16.0.1 represents the last chance we have to make the X11 version work as well as it can.

But now the release notes have been finalized, customers have received the update e-mails, and it’s time to call 16.0.1 done.

I think most technology companies understand there are only two real dangers to a market-leading product’s lifespan: self-inflicted wounds or a failure to evolve. The introduction of a new competitor does not foretell an impending winner-take-all contest.

While Apple has been churning out hit after hit for the past five years, Final Cut Pro is in danger of dealing itself a knockout combination of radical UI redesign and reduced functionality. Facebook may indeed need to be wary of Google+ as the most recent barbarian at the gate, but they also need to make sure they don’t turn themselves into MySpace.

The public perception nightmare of Windows Vista did more damage to the Windows brand than any Linux distro could ever hope to inflict. Personally I found Vista to be a fine upgrade from XP, and never understood the reason for such vitriol pointed its way. But nevertheless the criticism was loud and frequent.

Quick! What killed the Palm Pilot? Was it some hot new portable? Plenty of Windows Mobile touchscreen devices certainly wanted to take a swing at the champ. (Like my Viewsonic V35, which I finally got around to recycling last year). But no single device spelled the demise of the Pilot. Rather the entire PDA segment was washed away in a tide of irrelevance and redundancy as cell phones acquired this functionality. At least the 3-pack of replacement styli I bought for the V35 comes in handy when my son misplaces his Nintendo DS stylus.

So while the bloodthirsty tech media may attempt to paint the competitive landscape as a gladiatorial arena, I believe most tech products leave the battle under their own declining power, and not in a body bag.

After years of using a third-party license manager, we decided to write our own License Manager. The old one worked reasonably well, but the company tried to gouge us when we wanted to add two new platforms: 64-bit Windows and 64-bit Linux.

As a product company, it’s never an easy decision to have someone work on something like licensing. It’s not the kind of feature that motivates people to buy your product. But there was just no arguing with the economics of the situation.

As part of finalizing the release, I write up the list of new features. Usually, this is pretty straightforward. This year, it was a little tougher. We had fewer new features due to the amount of time spent updating existing capabilities. And one of my few new features is the License Manager. How do I make that look really interesting on the list?

Maybe if I gave it a clever name like, “License Manager: License to Code”.

Hmm, Roman numerals make things look cool, “License Manager XVI”.

Maybe if I shortened the name it would sound more high tech, “LicMan”. No, not that!

Perhaps, the language of business obfuscation could be used, “Product Enablement System”. That doesn’t work either.

I know! How about an acronym that spells out something awesome, like “SlickEdit License Instance Capture Knowledgebase for Efficient Distribution, Inventory, and Tracking (SLICKEDIT)”. No, that just makes the name of this thing the same as the product.

In the end, there’s just nothing I could do to make this sound like more than it is. It’s a License Manager. We did everything we could to make it fast and convenient. In the end, it’s like getting blood drawn: the best you can hope for is that it is over quickly and you can get on with things.

Few companies and few developers like to talk about the warts in their software, but let’s face it — for decades, SlickEdit has been a single threaded application, nothing but a bicycle-built-for-one. That single thread rode high and strong and did what it wanted, with all the powers and dangers of the world granted to it to do as it pleased. Let’s call this thread George, King George, as it was.

Then we decided to let another thread into our world. Well, needless to say, King George did not like this newcomer in his kingdom. Suddenly, he had to synchronize his peddling and braking and balancing with another thread, and let me tell you, he was not used to doing so much paperwork. Sorry, George, you have to acquire a Mutex before you can use the memory allocator. Sorry, George, you have to release the Mutex when you are done. George was angry, frustrated, and not accustomed to waiting in line behind these mere peasants. They were supposed to make his life easier. Instead, they pervasively filled his kingdom with landmines. George had to step carefully from now on. His smallest comfort was that those little threads also had to step carefully, very carefully. The King was also comforted to know that there still were places that only he could step.

Converting a single-threaded piece of software into multi-threaded software is a task that requires vision. It also requires strictness and thorough investigation of what-calls-what and what-uses-what. The vision comes from finding ways to utilize asynchronous processing and deciding what parts of the application to make thread safe first. The vision also comes from learning new ways to design less stateful APIs and data structures so that you can minimize access to shared data, or at least make the access thread-safe.

It can’t be done all at once.

The techniques for writing thread-safe software and multi-threaded software in general are well documented. It is certainly not a new science, but each thing you convert poses new challenges.

My challenge in SlickEdit 2010 and SlickEdit 2011 was to make it possible for a thread to parse code and insert indexing information into a tag database. Well, that certainly can’t be real hard. That is, until you meet King George.

Step 1: A thread that parses code

SlickEdit has great parsers for many, many languages; the problem was, none of them were written in a thread-safe manner. The lexical analyzer framework was completely stateful and also lacking in flexibility and power. Every parser would need a new lexer, and it had to perform well. The invocation mechanism depended on the Slick-C interpreter, which is still far away from being a thread-safe component. The parsers used global data when they wanted to and communicated directly with the database. To make a long story short, a lot of code had to change.

Step 2: A tagging job queuing framework

Once we could parse code, we couldn’t just start creating threads all willy-nilly. We needed a block of threads to do the work and pass the results forward to the editor. We needed to define what a tagging job was and how the indexing information was collected. We needed to reconsider every place where the editor would launch tagging jobs and see if those jobs could be done on a thread. As it turned out, the answer was “nearly everywhere”. Oh, by the way, King George liked that.

Step 3: A thread-safe tag database

This is one of the big steps forward in SlickEdit 2011. A thread can write to the tag database, making it possible to do everything required to build or update a tag database completely in the background. This was no easy task, because the tag database is a sophisticated component that was built specifically for King George. We had to rethink how we traversed through items in the database. We had to get rid of shared global variables. We had to refine the database block cache so it could be shared by threads.

Step 4: Getting a list of files to tag on a thread

The final step was to scale the threading up from allowing the main thread to schedule jobs one at a time to having a thread schedule a a list of files to be tagged. We needed this thread to find all the files in your workspace, check dates, figure out what language the files were, and finally schedule anything that was new or out-of-date to be tagged. This meant rewriting a lot of single-threaded Slick-C code as thread-safe C++. The speed gains from this change were significant.

The final result

SlickEdit 2011 is a huge improvement over SlickEdit 2010 with respect to its handling of background tagging. King George is beginning to appreciate what these little threads are doing for him and how they are making his job easier now.

The worst problem: Mutex acquisition order

This is what I regard as the worst thread-safe code synchronization problem. Now, if you are fortunate enough to be writing thread-safe code from scratch, where you have an existing, clearly modularized code whose critical sections are small, short-lived, and well encapsulated, it is not a problem likely to hurt you unless you do something silly. But, when you have a large base of single-threaded code with large amounts of shared data that you have to try to make access to thread safe, things get ugly really fast. Here is the classic deadlock condition.

   VSMUTEX mutex1;
   VSMUTEX mutex2;

In the main thread, King George does this.

    mutex1.lock();
    ...                        // I own mutex1 and rule supremely
    ...                        // except that I don't own mutex2 yet
    mutex2.lock();

In another thread, some peasant does this.

   mutex2.lock();
   ...                          // I own mutex2, nobody else can have it,
   ...                          // not even my reverent King
   mutex1.lock();

When King George has mutex2 and is trying to get mutex1, and simultaneously, another thread has mutex1 and is trying to get mutex2, they will deadlock forever. There are a few ways around this, but the best way is the classic solution of don’t do that. The problem is that it is hard to see how pervasive this problem can be when some special case, such as error handing, causes everything you think you know about what order you acquire Mutex’s in to be reversed. This is a problem that can only be solved with thorough analysis and testing and fundamentally sound designs. But, given the circumstances surrounding migrating older single-threaded code to support threading, such designs are harder to come by than one would hope.

Summary

If you read this whole thing looking for deep insight on how to write solid thread-safe code, well, you probably finished sadly disappointed. If you are planning on renting a bicycle built-for-two with your spouse and were looking for riding tips, then you really, really read the wrong article. If you came here because you always thought SlickEdit should do tagging in the background and wondered why it took us so long to implement it that way, then maybe now you understand the obstacles and hurdles a little better. We are still iteratively improving the system and working to improve the tagging throughput. You can look forward to seeing even more performance gains and scaling in the first update (16.0.1).

SlickEdit is moving forward, and finally, George isn’t the only one peddling the bike.

CodeProject

As we began the 64-bit port we faced the same challenges as any company dealing with a large established code base.  A lot of typing issues.  In the 64-bit world, long means different things on different platforms.  In some cases it doesn’t make any difference, in others it does.  These cases have to be carefully examined.  In some cases the solution was not to use long at all.  There were cases where we had used long because it seemed like the right thing to do, but on careful examination, int is completely sufficient.

However, the most interesting case we came up against was a call to the X-Windows library.  The specific call had looked like this for years:

   XtVaSetValues(xftXtTopLevelShell,
               XtNx, -1000,
               XtNy, -1000,
               XtNwidth, 100,
               XtNheight, 100,
               XtNmappedWhenManaged, False,
               0);

And it was fine in our initial builds and testing.  But as we approached our first beta and started to compile our release configuration, the editor would crash on this line.  I spent an evening trying different compiler options, and different versions of the compiler, because I simply did not see a problem with this line.  But there is one.

The functions that start with XtVa take a variable number of arguments.  In this case, that last argument – the ’0′ – is a pointer.  On a 32-bit system, a pointer is 32-bits wide, and an int is 32-bits wide.  So passing 0 works just fine.  On a 64-bit system, pointers are 64-bits wide, and NULL is a 64-bit unsigned number. 0, however, is a 32-bit signed number.  Which actually works fine… until you turn on compiler optimizations.

Here is the corrected code:

   XtVaSetValues(xftXtTopLevelShell,
               XtNx, -1000,
               XtNy, -1000,
               XtNwidth, 100,
               XtNheight, 100,
               XtNmappedWhenManaged, False,
               NULL);

This wasn’t the most confusing problem I encountered, in fact I’m sure to a seasoned 64-bit Linux guru it should not have a been a problem at all.  But it was one of the things I felt was interesting enough to share here.

Anybody have a good 64-bit porting horror story?  Let’s hear them.

• 64-bit Versions for Linux and Windows
• Multithreading the Context Tagging Engine and Auto-Reload
• Support for Ruby Debugging
• Support for Git Version Control
• Dynamic Debugger Enhancements
• Updated Microsoft Visual Studio 2010 Support
• Updated JUnit Support
• SlickEdit License Manager

So what happened? Choosing what goes into a release is the toughest job for a product manager; there is never enough time to develop everything we’d like to get done in a given year. So we have to make hard choices.

We look at our customer base as a set of constituencies, each with different needs and change requests. Each language we support represents a different constituency with different needs, likewise for each platform. Fixing a tagging problem in C++ does little to help a Python programmer and vice versa. Some features, like Backup History, introduced in SlickEdit v9.0, are useful no matter what language or platform you are using.

Another way to divide constituents is into existing customers and new customers. Generally speaking, new features are considered more helpful in going after new customers, while bug fixes are aimed at existing customers. One consistent piece of feedback from existing customers is that they don’t really want new features; they just want the existing features to work better. In each release, we try to strike a balance between features to lure new customers and bug fixes for existing customers.

When we made the feature plan for this year, it became clear that there were parts of SlickEdit that really needed updating. As a product with a very long history—the first version of SlickEdit was released 23 years ago—we have seen some dramatic changes in the platforms we run on and the expectations of our customers.

In the early versions, resources were scarce so you needed to be as lean as possible, use as little memory and CPU as you can. This also makes your program very fast, which is one of our top goals. Now, a typical development machine has 4 cores and 4GB of memory or more. In this environment it’s frustrating to wait for an answer while the program is only using 25% of your available resources. That’s why the multithreading work was so important.

Don’t get me wrong. We’re not out to become a resource hog. We do believe that, for programmers, coding is the most important thing they are doing and that sufficient resources should be brought to bear.

As code bases grow, it’s even more important to have an editor, like SlickEdit, that knows the location and type of your symbols. Being able to generate that information efficiently and access it quickly is always our top priority. SlickEdit 2011 is a big step in giving you the fastest possible code navigation.

A SlickEdit user thought it would be nice to have SlickEdit displayed on his bookshelf, so we sent him an image and he created his own homemade SlickEdit box. It looks great!

GDC is the world’s largest professionals-only game industry event. We’ll be there with hands-on demos of easy project set up, detailed back up history, context tagging and other productivity enhancing features.

Visit us at booth 2120, learn what’s new and checkout our cool giveaways!

Say you are using Eclipse as shown here (Eclipse 3.6.1), and you want to open another view of the same file.

You can do this easily within Eclipse by using the “New Editor” command. Right-click on the buffer tab of the file and select “New Editor”. For faster access, you should bind this command to a key, or use the mnemonic Alt + W, E for the Window menu. This allows you to create a new editor window without ever having to reach for the mouse. Good so far…but what did we get?

Not really what we wanted, because this is pretty useless. We want to be able to see a side-by-side view of these windows. How can I accomplish this in Eclipse? Well, unfortunately, you have to reach for the mouse. You have to click and drag the buffer tab for one of these windows over to where you want it to be. Then you get what you really want.

With SlickEdit Core for Eclipse (v3.6.1), you can accomplish the same thing very quickly, without ever reaching for the mouse. This might seem like a very small detail, and maybe it is to some folks, but if you try to limit (or eliminate ) your mouse usage, you will find that you are a much more comfortable and productive programmer.

If I have the same file open in Eclipse 3.6.1, but this time using the SlickEdit Core 3.6.1 plugin, I can run the command vsplit-window from the SlickEdit command line, and a new editor window is opened to the right of the current editor window. No intermediate step involving the mouse. Of course, you should bind vsplit-window to a key to be more efficient.

vsplit-window demo

SlickEdit Core also has a command for hsplit-window (Ctrl + H by default) for splitting an editor window horizontally, and you can use next-window (Ctrl + Tab or Ctrl + F6 by default) to rapidly switch between all open editor windows.

There are other plugins available which provide similar functionality. I believe there is an Emacs plugin out there which supports the Emacs-style Ctrl X, 3 window splitting, which also does not require the mouse. But no plugin also provides the level of language support of SlickEdit Core. And SlickEdit Core does have a fully functional Emacs emulation, for any Emacs users out there who want to be able to Ctrl + X, 3 within the Eclipse environment.

In programming, however, the mouse can be one of the greatest productivity sinkholes. Time is wasted each time you lift your hand from the keyboard to grab the mouse, and more time is wasted when you move your hand back to home row in preparation for more typing.

So what’s the solution? Keep your hands on the keyboard! To do this use the SlickEdit^® command line and bind commonly used commands to keys.

Launching Operations
SlickEdit provides three ways to launch operations: key bindings, commands, and menus. OK, there are actually four, if you include icons. Since the focus of this article is how to keep your hands on the keyboard, I was going to skip that one.

Key Bindings
Key bindings are the fastest way to launch an operation. They can be pressed at any time while editing. A key binding associates a key sequence with a command. A key sequence is a series of key strokes. Anything you do frequently should be bound to an easily remembered key sequence.

For example the key sequence Ctrl+A means hold down the Control key, typically labeled “Ctrl” on most keyboards, and press the A key. The letter A is represented as an uppercase letter, but this does not mean that you are to press the Shift key. If you are supposed to press the Shift key, the sequence will be written as Ctrl+Shift+A.  We use the uppercase A to match the letter on the keyboard.

Commands
Commands are useful for less frequently used operations or operations that take arguments. They are executed from the SlickEdit command line and are nearly as fast as key bindings. Press the Escape key (in most emulations) to activate the command line, which is displayed at the bottom of the SlickEdit application window. 

  Figure 1, SlickEdit with Command Line

It offers a full command history and completions for command names and arguments. Use the arrow keys or the mouse to scroll through previous commands. As you type, a list of possible completions is displayed. Use the arrow keys or mouse to select a completion. SlickEdit stores recorded macros as commands. You can also use Slick-C to write new commands. Use the _command keyword to identify a macro as a command. Any command can be bound to a key sequence for faster launching. 

Menus
Menus are accessed via the mouse or a keyboard shortcut. Menus are great for infrequently used items that may not be worth a key binding. They are also helpful to learn about new capabilities. But if you use an operation frequently, you will be more productive by binding it to a key sequence or launching it from the command line. Many menus list a keyboard shortcut to launch the operation. This is just the key binding for the associated command. So when you use a keyboard shortcut, you are really just using a key binding.

You can also operate the main menu through hotkeys. Enable the use of hotkeys by selecting Tools > Options > General, selecting the General tab, and putting a check in “Alt menu hotkeys”. This will be selected by default in many emulations. Once enabled, pressing the Alt key will display an underscore beneath each menu option, indicating the letter to press to activate that option. This is not as fast as key bindings, but it does keep your hands on the keyboard and is much faster than using the mouse. In some cases the menu hot key sequence is a good mnemonic for the command. For example, Alt+P, E (to bring up Project > Properties) may be easier to remember and type than binding project-edit to Ctrl plus some function key. 

Icons
SlickEdit presents icons in a series of toolbars related to different tasks. Toolbars can be customized with an extensive set of additional icons. Icons are useful for die-hard mouse users or for setting up infrequently used operations for which you have a hard time remembering the associated command or key binding. 

The Golden Triangle
The three methods (excluding icons) to launch an operation are related, forming the Golden Triangle of operation launching. If you know how to execute an operation with one of these, you can easily configure SlickEdit to launch the operation using the other two methods. Commands form the base for the other two…which is why it is shown as the apex of the triangle (Damn it, Jim, I’m an engineer, not an artist!). Maybe I should have used a Golden U or something. 
 

Figure 2 the Golden Triangle; behold its majesty!

From Key Binding to Command
Sometimes you may want to change the key sequence to which an operation is bound. You first need to find the command associated with that key sequence. Use the what-is command from the SlickEdit command line or select Help > What Is Key from the main menu. The command line will be replaced with the prompt, “What is key:” Enter the key sequence in question, like Ctrl+A (hold down the Control key and press A), and SlickEdit displays the associated command. In CUA emulation, SlickEdit will output, “Ctrl+A runs the command select-all”. You can use the same approach to determine the commands associated with mouse events. After you run what-is, click any mouse button and you will be prompted with a list of mouse events. Select one from the list and SlickEdit displays the associated command. For example, if you select mbutton-down in CUA emulation, SlickEdit will output, “MButtonDn runs the command mou-paste”. 

From Command to Key Binding
To find the key binding for a command, use the where-is command or select Tools > Options > Key Bindings from the main menu. The where-is command works just like what-is, except you type in the command name and it outputs the key sequence. The Key Bindings dialog displays a list of the commands. You can scroll through the list or search for a command by typing the command in the text box at the top. The key binding for the selected command is displayed in the dialog.  

Figure 3, Key Bindings Dialog   

Modifying Key Bindings
The Key Bindings dialog can also be used to set a key binding. Type the command in the Command field, or select one from the list. Then click the “Add Key or Mouse Click” button. Now type the key sequence you want to use. For example, to bind a command to Ctrl+A, hold down the Control key and press A. To bind a command to a mouse event, click any mouse button and then select the appropriate event from the list. When you are finished, click the Bind button. To exit the dialog, click Done.

From Menu to Command
If the menu entry displays a keyboard shortcut, you can quickly find the associated command using what-is and entering the key sequence. If the menu entry does not display a shortcut, then finding the command for an entry involves a little more work.

SlickEdit provides a convenient UI under Macro > Menus that allows you to view and modify menus in SlickEdit. To find commands for the items on the main menu, select “_mdi_menu” from the list and then click the Open button. You are presented with a menu hierarchy that you can expand to find the menu entry in question. Once selected, information about the entry is displayed including the command executed. You can use this menu to add or change the shortcut for a menu item. Doing so has the same effect as using the Key Bindings dialog to bind the menu entry’s command to a key sequence.   

Figure 4, Menu Editor

Some menu entries are added dynamically by SlickEdit, so you may have to search the code to find the associated command. One example of this is Build > Java Options, which is only present when a Java project is active. Unfortunately, finding the associated commands for these entries can be very difficult and not easily covered in an article like this.

Context Menus
It is also easy to find the commands in the context menu for the editor window. The context menu, itself, contains an entry to “Edit This Menu”. Selecting this option brings up a dialog that lists the menu entries and associated information, including the command. Use this dialog to modify the context menus. Note that there are two context menus for the editor window: one when a selection is made and one when no selection is made. You can view or change the function that is used for these menus by selecting Tools > Options > File Extension Setup and selecting the Advanced tab.

From Key Binding to Menu and Back
Menu entries map to key bindings through commands, so key bindings are not directly associated with menu entries. To map from a key binding to a menu or vice versa, you need to look up the associated command. That Golden U is looking better all the time!

Customizing Toolbar Icons
The focus of this article has been to help you keep your hands on the keyboard, so icons weren’t included in the Golden Triangle. Besides, then I would have needed a Golden Square or some other form of rhombus, and that just doesn’t sound cool. You may find it helpful to change the set of displayed toolbars, add or remove icons, or change the behavior for an icon. SlickEdit uses the term “toolbar” to refer to both icon bars and tool windows. To change the set of displayed toolbars, select View > Toolbars and check/uncheck one of the listed toolbars.

The list is divided into two groups. The top group is comprised of tool windows, like the Symbol view and the Projects view. The bottom group is made up of icon bars.

Additional options are available on the Toolbar Customization dialog by selecting View > Toolbars > Customize. The Toolbars tab provides a way to control the visibility of the toolbars. The Toolbars tab allows you to set options for which toolbars are visible, whether they are dockable, etc.

The Categories tab displays the complete set of available icons. These can be added to any icon toolbar by dragging them to the desired location. All of the icons have pre-defined behaviors, except the set in the “User Definable Tools” category. Use these to add your own functionality.

Each icon has an associated command that defines what happens when it is clicked. To view or change that command, right-click on the icon and select Properties. The icon needs to be located in a toolbar to do this. You cannot access the properties for an icon in the Toolbar Customizations dialog.  

“Exit, Stage Left”
OK, that one is a Snagglepuss reference[ii]. Whatever angst I previously expressed for mice has now been transferred to the Golden Polygon of Unspecified Dimensions. Regardless of the shape, you now have the tools you need to configure SlickEdit to work the way YOU think it should, using the key bindings you find natural. This is one of the essential steps in being a true power programmer.
 

[i] Mr. Jinks, sometimes called “Jinks the cat”, appeared in the “Pixie and Dixie” cartoons as part of “The Huckleberry Hound Show”, by Hanna and Barbera.

[ii] Snagglepus is another of Hanna-Barbera’s cartoon characters.

Working with selections

The very first thing I realized when I sat down to do this was that I’d need to get the bounds of the current selection, and I’d never worked with selections before.  Whenever I hit an area that I’m unfamiliar with, the first place I go is the API documentation.  To get there, you can click Help > Contents, and then click API Documentation at the bottom of the contents list.  Next, select Macro Functions By Category and you will be taken to a categorized list of the documented Slick-C functions.  I scrolled down and found the Selection Functions category in the list, clicked it, and started looking through that list for potentially useful ways to get the bounds of the current selection.

Right away, I noticed _get_selinfo() and it looked like a perfect fit.  The problem that I discovered though, is that _get_selinfo() doesn’t provide line numbers for the current selection, only column numbers, which made it useless for the information I needed.  I then decided to look at how other macro functions were using _get_selinfo(), so I right clicked it and selected “Goto reference to _get_selinfo” which lists all of the places in the macro code where it’s called.  You can also use the find-refs command for this.  This led me to other code that used _begin_select() and _end_select(), which I had passed over in the help originally because they sounded more like actions than a way of getting selection information. My strategy for getting the line range was to call _begin_select(), which places the cursor on the first line of the selection, and insert a line of code to get a timestamp.  I would then do the same thing with _end_select() and insert the code to get a second timestamp and report the difference.

Writing the macro

We’ll start by beginning a new macro file the same way we did in Part 1, and we’ll call it “insert_debug_timer.e”.  Using our selection strategy, we can write the following macro code:

After loading this, you can select some text in your editor, run insert-debug-timer() and your selection will be surrounded by the text “This is the beginning” and “This is the end”.  Success!  Now we can move on to inserting the actual code that will do the timing.  There will be two parts to this, the code that gets inserted before the selection, and the code that gets inserted after the selection.  I first made a throw-away command to test what the code might look like (in Slick-C):

Let’s start with the code that gets inserted before the selection.  We know that we’re going to have to detect which language we’re in and insert something different based on that, just like we did in Part 1.  I didn’t want to pollute the code in the insert_debug_timing() command, so I decided that I’d make a separate function to insert the “before” code.  This function will take the indentation text as a parameter and directly insert the text at the current line.

Next we can write the second function, which is basically the same as this one, except that it inserts the code to take a second timestamp, diff the two timestamps and report the time difference.  We now replace the lines in insert_debug_timer() with calls to these two functions.  We now have a command that takes the current selection (or the current line if there’s no selection) and wraps it with timing code.

A final improvement

This is a good start, but there are a small improvements I had to include.  The problem I ran into after about 10 seconds of using the macro is that if you have more than one section you want to time, you get a variable name collision.  Since these debug timing code inserts are really just temporary, we can name the variables anything we want.  I decided to make a global int variable called g_debugVarCounter that we could append to the variable names every time the insert_debug_timer() command is called, and then increment that value at the end of the command.  Here is the declaration of the global counter:

and here’s how we can use it to make the variable names:

Now we can insert debug timing commands wherever we want and there are no variable name collisions. The insert-debug-timer() macro is ready to be bound to a key combination by clicking Tools > Options, then go to Keyboard and Mouse > Key Bindings in the options tree, just like we did in part 1.

The macro file can be downloaded by clicking the this link.

Removing debug timing sections

Another important improvement would be a way to remove any of the code we’ve inserted by running this command.  We’ll cover how to do that in the next blog post… check back soon!

Unfortunately, only the most advanced of the advanced users ever consider getting so deep into an application that they learn to write their own macros for it.  There’s a few reasons for this.  Many people don’t even know that so much functionality is available in macro form.  Even if a user did look into making their own macros, finding out what functionality is available in macro code is an enormous challenge.  We all have deadlines and important things to do, and learning a new code base like the Slick-C macro language just doesn’t realistically fit into most people’s 24 hour day.

I personally love making little knock-off gizmo utilities for things that fit my workflow.  One of the things that I do often is putting debug statements at various points in my code to report the value of some variable.  This is very helpful when you want a history of values, not just a one stop breakpoint in the debugger.  I decided to make a macro that adds these statements automatically given the word under my cursor (assuming it’s a variable).  It’s a simple, first-step macro, and instead of just posting the code, I’m going to walk through the steps to make it.

Starting a macro from scratch

To start, click File > New Item From Template.  This will bring up the “Add New Item” dialog.  Select Slick-C in the “Categories” tree, select a location where you’d like this file (a scratch development folder is best), and enter insert_debug_value as the name.

Click the Add button.  This creates a new file called insert_debug_value.e in the specified directory.  This file will be opened in a new buffer with the following code included:

This is the basis for all macros started from scratch.  You can load it hitting the escape button to go to the command line, then type “load” and hit enter.

SlickEdit will respond by reporting “Module(s) loaded” in the status area at the bottom of the application.  You can now type “insert-debug-value” on the command line and your new command will execute.  Of course, it doesn’t do anything yet…

Implementing the macro

A general strategy for this function will be the following:

1. Get the current word that the cursor is in.
2. Determine which language is being edited.
3. Insert a new line beneath that to output it’s value.

That seems simple enough.  To start, we’ll use the cur_word() function to determine the full word beneath the cursor.  This function has a byref parameter, which returns the beginning column of the current word, so we have to pass a temp variable for that.  We can also use the say() function to report the value of curWord to the stdout window.  The code currently looks like this:

Again, you can reload this by hitting the escape button to go to the command line, then type “load” and hit enter.  If you run it from the command line, it will show the stdout window titled vsapi.dll, and the value of curWord will be shown.

Now we can start to build the text that we’ll insert.  Since we want this inserted line to be indented to match the current line, we’ll get the current indentation using the first_non_blank() function.  This puts the cursor on the first non-blank column on the line.  Next, we’ll get the column number using the p_col property.  We can build an indentation string using the indent_string() function, passing the starting column value.  The code now looks like this:

For this example, we’ll support three languages; Slick-C, C/C++ and Java.  To tell which language we’re in, we can use the p_LangId property, which returns the language ID of the current editor.  We can switch on that value and append the code to the variable containing the text to insert.  Finally we can call insert_line() to insert the text we’ve built.

Go to the command line and reload the file by typing “load” and hitting enter.  Now put the cursor on a variable in the editor, go back to the command line and type “insert-debug-value” and hit enter.  A say() statement will be inserted into the file on the line after the cursor that reports the value of the variable your cursor was on.  Now you have a way to quickly add a debug statement to your code to report the value of the variable without having to write anything.  A final improvement is to store the original line number and column so they can be restored after the new line is inserted.

The macro file can be downloaded by clicking the this link.

Binding a key combination to your macro

A macro like the one we just made works best when bound to a key, since we don’t want to have to go to the command line every time we want to invoke it.  To bind a key combination to this macro, bring up the options by clicking Tools > Options, then go to Keyboard and Mouse > Key Bindings in the options tree.  Type the name of the macro in the “Search by command:” text box to find it.  Double click its entry to bring up the “Bind Key” dialog.  We’ll bind it to “Ctrl+Shift+/”.  Press that key combination and it will appear in the “Key Sequence:” dialog.  Click the “Bind” button to bind it.  The key bindings entry should look like this:

Click OK on the options dialog.  Now, whenever you press “Ctrl+Shift+/” your macro will execute.

Is it perfect?

Absolutely not!  There are many potential problems here.  The cursor may not be on a variable.  The buffer may be read only.  There are also many other languages that this macro could support.  The list is potentially huge.  However, this macro is a starting point from which you can start to tinker around with writing your own macros.  Soon, you’ll be amazed at how much can be done with Slick-C that you’ll start writing lots of little tools and utilities that fit your own unique workflow.  Check back for more blog posts in this series, which will build on what we’ve started here.

Sometimes when you have a project with a large number of makefiles, you may notice that menus are slow to respond. This happens because SlickEdit collects the names of all the targets in each makefile and adds them to menus for build purposes (whether or not you are using SlickEdit to build). To resolve this issue, change the def_show_makefile_target_menu configuration variable to either 0 or 2. The default value, 1, specifies that all makefile submenus are enabled. A value of 0 disables all makefile submenus (Build menu and Project tool window), and a value of 2 enables makefile submenus only in the Project tool window (Build menu makefile targets are disabled).

To change the value of a configuration variable, from the main menu, click Macro > Set Macro Variable. Select the variable to change from the drop-down list, enter the value in the Value field, then click OK.

NOTE This behavior will be changed in the next release so that despite the number of makefiles in your project, there will not be a slow-down in menu response times.

Like most people, I had to set my sights on more attainable goals. So, I chose the field of software development. For someone going to college in the 1980’s, software development was the most futuristic and high-tech thing available. In grad school, I chose to specialize in Artificial Intelligence, the wave of the future (can you hear the biting irony in that, “the wave of the future“? No, it never came to pass). Unfortunately, the number of job openings in AI are right up there with those designing giant fighting robots and captaining starships.

Most of my career has been spent on developing more mundane things, like medical billing applications, credit checkers, mortgage analyzers, etc. There have been a couple bright spots, though. I did get to work for Harris Space Systems developing a new launch system for NASA. And my current job at SlickEdit is still my favorite.

Developing a programming editor may seem pretty mundane compared to my lofty dreams of AI and super-science, but I truly love working on something that I can use. Throughout most of my career, I developed software for use by other people. Now, I’m developing software for the things I do. For everything else I developed, I had to elicit requirements from subject matter experts. At SlickEdit, the developers are the subject matter experts!

It’s also great when I talk to other programmers about what I do. No matter how animated you get while describing the uber-cool design of your credit checker, people’s eyes glaze over.

“No, seriously, did I tell you it uses a priority queue with full transactional semantics?”

See what I mean? When I talk about developing a programming editor you can actually see a degree of interest in their eyes—usually followed by a forlorn look when they realize how boring their work on a credit checker is by comparison.

Finally, the coolest thing about working at SlickEdit is knowing that thousands of programmers, in all fields of development are using our product to write better software. Like most developers, I had dreams of one day working in game development—once I knew that the super-science, starship captaining, and AI weren’t going to pan out. Though that never happened, I feel that I am still making a contribution.

SlickEdit was recently nominated for the 2009 Front Line Awards by Game Developer magazine, in the category of Programming/Production Tools. This kind of recognition is so rewarding! Not only are other people using us to write games, but they like SlickEdit enough to nominate us for an award.

OK, so maybe I didn’t write a cool blood-splatter effect for when you take that perfect head shot, and maybe I didn’t write the code that makes zombies shuffle around more realistically. But it’s fun to think that someone who did write that might have used SlickEdit and that maybe my work and ideas made their job just that much better.

The warm feeling I get from this can carry me through many tough days. Yes, I have some tough days at SlickEdit. When I’m pitching a new feature and I see the other developers’ eyes glaze over—”did I mention that this feature uses a priority queue and full transactional semantics”—I can focus on all the ways SlickEdit is being used to write better software.

If you’re constantly opening files from certain directories, create aliases for those directories to save time. To create a directory alias, from the main menu, click Tools > Options, expand Editing and select Global Aliases. Click New, enter a short text snippet that you can easily remember for the Alias Name, then click OK. Back on the Options dialog, select the new alias, then enter the complete directory path for the alias in the text box on the right.  Click OK on the Options dialog. Now you can use the alias in directory fields on various dialogs in SlickEdit (like File > Open): simply type the Alias Name and press Ctrl+Space to expand it.

Language-Specific Aliases

Language-specific aliases are similar to directory aliases except they can be used in edit windows for any frequently used text, like comment headers and language structures.

To create a language-specific alias, from the main menu, click Tools > Options > Languages, expand your language category and language, then select Aliases. On the Alias option page, click New and enter a short text snippet that you can easily remember for the alias name, then click OK. Back on the Options dialog, select the new alias, then enter the text substitution for the alias in the text box on the right. Click OK on the Options dialog.

Now when you have a buffer or file open in that language, you can use the alias by typing the identifier and pressing Ctrl+Space.

Alias from Selection

A quick way to create a language-specific alias is to create it from a selection. Select some text in the editor, then right-click and select Create Alias from the context menu. Enter a name for the alias and click OK. The Options dialog appears, open to the Language-Specific Alias Options for the current language, and showing the new alias. Click OK on the Options dialog.

In the article he discussing some of his favorite features of SlickEdit and why SlickEdit is his code editor of choice for programming.

On objections on switching editors

If your current editor works well enough for you, why switch? The answer depends on how you define “well enough.” Your current editor probably handles every editing command you think you need now, but consider the possibility that something could make you far more productive. You’ll see a few examples in a moment, but first, here are some of the reasons you might decide not to switch editors.

Regular Expression Search and Replace

This isn’t an exclusive SlickEdit feature, some other editors have it too; but if you haven’t had the opportunity to experience regular expression searches, you should really consider switching to an editor that supports the feature.

Macro Record/Playback

SlickEdit carries out many of its commands through its slick-C programming language (note that both Brief and Emacs have their own languages as well). SlickEdit lets you write your own macros, or do a simple record / playback. This comes in handy when the syntax for find and replace gets too dicey.

Other Features

As you might imagine, because SlickEdit’s been around for 20 years, this article just scratches the surface.

Continue reading Hey, Check Out My Slick New Editor! here: http://www.devx.com/enterprise/Article/42874/0/page/1

SlickEdit’s Slick-C macro language should be no stranger to our users, but many folks aren’t aware that macros can be called when SlickEdit is started. In this tutorial, I’ll demonstrate how to use Automator to create a simple text service for SlickEdit, using this macro call facility.

First, launch the Automator application and create a new service using the Service template. At the top of the new workflow, it should say Service receives selected text in any application. Make sure Replaces selected text is not checked.

From the library’s actions panel, select the Text > New Text File action, and drag it into the workflow as the first item. Pick a name and location for the temporary file to be saved, and make sure Replace existing files is checked, or else you’ll receive an Automator error the second time you use the service. Select the Encoding to be (UTF-8).

From the library’s action panel, select the Utilities > Run Shell Script action, and drag it into workflow as the second item. The shell should be set to the default of /bin/bash. Change the right-hand drop-down to read Pass input as arguments.

Delete any existing text in the shell script editor. Add the following text as the first line.

export VSLICKXNOPLUSNEWMSG="1"

Switch to Finder, and navigate to the Applications directory. Highlight your SlickEdit application, and Control-Click the application, and select Show Package Contents from the context menu. Drill down to the Contents/slickedit/bin, highlight the vs executable, and drag this into the shell script editor. This will insert the full path to the executable in the script editor. Make sure it’s on a new line after the export line you just typed.
Append the following right after vs, making sure the command is all one line.

-#new-file "-#get $1"&

The full script should look like the following:

export VSLICKXNOPLUSNEWMSG="1"
/Applications/SlickEditV1402.app/Contents/slickedit/bin/vs -#new-file "-#get $1"&

Automator Service

Don’t forget the ampersand at the end of the second line. Save the service, (⌘+S), and give it the name “New SlickEdit File”.

Switch to another application, like Safari or TextEdit, highlight some text, and pull down the application’s services menu. Your new service should now be available in the menu in the Text category.

The SlickEdit “magic” is done with the -# arguments. These specify macros to be called when SlickEdit in invoked. Any SlickEdit macro command (defined with the _command keyword in Slick-C) can be called. Surround the entire -# argument with quotes if the Slick-C command takes any parameters, like the get macro in this example.

You can create a similar service that will insert the text into the currently active document by simply removing the -#new-file argument.

By default, service workflows are saved under $HOME/Library/Services. You can remove the service by removing this file.

To rename a Service, select the workflow file under $HOME/Library/Services, Control-Click to bring up the context menu, and select Show Package Contents. Look for the Contents/Info.plist file, and open it in the Property List Editor application. Change the value of the Services/Item/Menu/Menu item title entry. You do not need to rename the workflow file itself.

Boy: Mr. Turtle, how many licks does it take to get to the Tootsie Roll center of a Tootsie Pop?
Mr. Turtle: I’ve never even made it without biting. Ask Mr. Owl.
Boy: Mr. Owl, how many licks does it take to get to the Tootsie Roll center of a Tootsie Pop?
Mr. Owl: Let’s find out. A One… A two-HOO…A three.
(crunch sound effect)
Mr. Owl: Three!

This illustrates two common problems in oral communication. The first is the iterative process of finding someone who might know the answer to your question. In software development, the questions are typically of a more concrete nature, relating to a specific design or implementation choice.

Most software projects depend on a great deal of local knowledge. This is knowledge that is specific to the project, something you couldn’t know prior to working on the project. This include things like architectural and design details. The local knowledge is rarely written down in an organized manner but is contained in the collective experience of the development team. Because it isn’t written down and cataloged it cannot be searched, except through the iterative query process.

The other problem that this commercial illustrates is that of false experts. Like Mr. Owl, you will find people who will give you a definitive answer but one that is, unfortunately, wrong. In software development, it can be very difficult to spot these wrong answers–you don’t get to see someone just bite into the Tootsie Pop to come up with it.

In some cases, the person may truly believe the answer they give, and we’ll assume that until we have proof to the contrary. At other times, people just don’t like to admit that they don’t know something. So, they make up an answer. In either case, the damage to your work is just as bad.

Folklore is typified by this kind of oral communication. It is the main method for communicating important information in primitive cultures. Knowledge is passed from one person to another. Often, because of miscommunication, the knowledge is corrupted by each successive telling.

It’s like that party game where you start off with a sentence and have each person whisper it to another person. This is repeated several times and then the last person writes down the sentence. In the end, the meaning of the sentence is often radically changed with comical results. The same thing happens in software development, but the results are far less comical.

The solution to both of these problems is to document local knowledge. One form of that is code comments. So much has been written on that topic, that I don’t feel the need to add more. However, many things are not appropriate to store in code comments. It’s that kind of knowledge that is most often passed along as folklore.

Fortunately, technology has given us a solution. A wiki provides a centralized knowledge repository that is edited by the group. This allows for the information to be easily reviewed for accuracy. It also eliminates the need to wander around and find someone who might know the answer to your question.

It also addresses another problem. Many people are hesitant to go ask questions. Either they are afraid of looking stupid, or they don’t want to trouble their coworkers. So, they will often flounder around trying to figure it out on their own, wasting time, or they will try to make due without the answer. A wiki allows people to find an answer without the potential embarrassment of exposing their ignorance.

To be successful, a wiki needs to be searchable and browseable. The search capability is needed to find the answer to specific questions. Browseability allows someone to view a set of topics and delve deeper to get more information. This is important to allow someone to gain the initial knowledge on a topic, particularly for getting new team members up to speed. Most packages do a good job providing the search capability. But very few provide a good mechanism to build a browseable knowledge structure.

At SlickEdit, we use MediaWiki for our shared knowledge. It provides both an excellent search and a convenient means to organize topics. The side menu allows you to structure your top-level categories, and each page automatically includes a table of contents if it contains 4 or more subsections. This makes it simple to build a logical knowledge decomposition. It’s this capability to create a browseable structure that sets MediaWiki apart from other wiki software we tried.

Finding the right wiki software and setting up an initial structure is only the first step, though. The main challenge is getting the team to populate it. You face a couple of common problems here.

The first is the normal reluctance of programmers to document things. Many programmers despise any activity that is not directly related to producing code. This is a tough nut to crack, since this attitude is often deeply ingrained in the developers psyche. How you overcome this depends on the person and the arguments that they will listen to. You can appeal to their sense of professionalism and explain that this is part of professional development. You can appeal to their sense of teamwork and explain how this helps make the team more effective. You will need your full set of management skills to get everyone contributing.

Even if everyone is willing to contribute, one problem that often prevents a wiki from reaching its true potential is that of obviousness. Once you know something, it seems obvious to you. If it’s obvious, then why document it? This same problem plagues code comments. The best solution is to make the wiki an essential part of the problem solving process. When someone is trying to answer a question, they should look in the wiki. If they don’t find the answer, they should make a note to come back and add this information to the wiki after folklore has delivered an answer.

So, how does having a wiki alter the scenario depicted in the commercial?
Boy: Hmm, I wonder how many licks does it take to get to the Tootsie Roll center of a Tootsie Pop?
(Boy looks in wiki for the answer and finds an entry by Mr. Owl: “How many licks does it take to get to the Tootsie Roll center of a Tootsie Pop? Three.”)

Well, at least he didn’t have to go bother curmudgeonly, old Mr. Turtle.

In terms of economic stimulus, this could have a much greater effect on the nation. Consider that many programmers use minimalist editors that provide little help to analyze and navigate their code, don’t include powerful completions, or features to cut the number of keystrokes necessary to type their code. If these programmers switched to a more powerful editor, like…oh, let’s say, SlickEdit…their productivity would go way up.

As the productivity of the individual programmers goes up, their projects would get done earlier or include more capabilities. This increases the productivity of the people using that software, which would then increase the profitability of those companies. Since software underlies almost every industry, this could lead to a potential boom, the likes of which hasn’t been seen since the post-WWII expansion. Suddenly, there’s a surge in the US GDP. We pay off the national debt in a few years and have money left over for a comprehensive public health care system.

And it all begins with getting people to switch to a more effective editor.

Unfortunately, SlickEdit isn’t big enough to warrant a special government program like this. We’re not one of those too-big-to-fail kind of companies. But that doesn’t mean you can’t experience your own little economic stimulus.

Look at your coding practices and see if a more powerful editor wouldn’t help you write more code faster with fewer errors. Though the government won’t pay you for switching, the boost in productivity surely will.

SlickEdit is Giving Cash for your Clunky Editor!
Cash for Clunky Editors Program:

If the editor you purchased is lacking the speed, power, and flexibility SlickEdit provides…trade it in for CASH towards SlickEdit.  Call 1-800-934-EDIT (3348) or email sales@slickedit.com, and mention the Cash for Clunky Editors Program to learn about the savings.

The program expires on September 30^th, 2009, so act quickly.

Happy coding,
The SlickEdit Team

1. those with open and honest communication
2. those whose communications better resembled Soviet-style propaganda

As a manager, I’ve always considered accurate information one of my most important assets. I need to know where we are and what it’s going to take to succeed. My team has standing orders to let me know as soon as they figure out that they’re not going to make it so we can adjust the plan.

I’ve always been surprised when the people I have reported to didn’t share this enthusiasm. As managers, our chief responsibility is making effective decisions to achieve the stated goals. How can you possibly do that in an environment that doesn’t encourage people to speak the truth?

On one project, we developed the following phrase to report statuses, “I know of no reason that the project won’t be completed on time.” While most of us had serious misgivings about the plan, anytime someone voiced those concerns their manager would grill them like Perry Mason trying to get a confession. In the end, you really can’t prove that things won’t get done on time, so why get worked over for nothing.

This predilection for denial showed up when we were asked to build a new capability in about 3 months. I did some analysis and determined that it couldn’t be done and that it would take more like 9 months. My manager wasn’t happy with that estimate, so he asked some other developers. One said he could do it, which vindicated the manager and made him happy.

After 3 months, the project was starting to come together, but the core of it still had a lot of work left. So the developer told the manager that he needed a couple more months. The manager, really needing this to get done, granted the extension. That cycle repeated itself a couple of times until, in the end, the project took about 9 months to complete.

You would think that the manager would be upset at a developer who so seriously underestimated the amount of work needed. Instead, he was roundly praised for his can-do attitude.

It takes courage to speak the truth, particularly when it is an unpopular truth. Likewise, it takes courage to be willing to hear the truth, since it will often conflict with your own beliefs and desires. Being willing to speak and hear the truth has always been the hallmark of the best companies for which I have worked.

The basic reason for this is that each feature was written in isolation without finding and reusing the capabilities of the other features. This is a very common problem on most software projects. To address this issue, I believe that software development should be broken down into two different workflows: mechanism application and mechanism creation.

We can define a mechanism as a component with a cohesive set of functionality, like the wheel. In most cases, mechanisms are meant to be reusable, though it is possible that there will be only one use for that mechanism in a particular program. Common mechanisms in software include login processors, calendar widgets, and sorted lists. These elements perform a specific function that is independent of what they are used for.

Mechanisms can also be specific solutions to common design problems, like error logging, object persistence, and thread synchronization. Ideally, these would be encapsulated in a library that is used by other developers, but in some instances it is more a matter of following a specified convention.

For example, one project I worked on specified that each function would contain #ifdefs for tracing and logging with specific information that each function should output. This still represents a mechanism that defines a cohesive functionality, in this case, tracing. But instead of writing a reusable library, the mechanism was primarily a set of conventions we all followed when writing our functions.

During mechanism application, the specialized functionality of a feature is built using existing mechanisms. You can work on your own unless you have a question about the specs or need assistance from another developer. The code being written is unique to the feature, so little attention is given to reuse unless a new mechanism is needed. Then you enter mechanism creation.

During mechanism creation, you are developing a generalized capability that is specifically intended to be reusable. This requires a totally different workflow. You have to stop and do a degree of analysis before you create the new mechanism. Several questions need to be answered. Are you sure there isn’t already a mechanism for this? If not, what are the essential behaviors of this mechanism? Where should it be stored?

These questions are best addressed with other members of the team. The goal is to produce a mechanism that can be used by everyone, not just by you. So, you need to get their input to make sure it does more than meet your immediate needs, or at least doesn’t prevent someone from extending it in the future.

When a developer tackles the new mechanism as part of their normal development, two common problems occur. Often the programmer includes the mechanism as part of the feature-specific code, rather than placing the mechanism into the library where others can find it. Even when they do put the code in the proper place, it often is written in such a way that it is only useful for this feature. You can’t make it reusable without breaking the feature that already depends on it.

In most applications, mechanism application is very straightforward, simple programming and requires little creativity. Mechanism creation, on the other hand, requires a great deal of creativity and design effort. You have to think more about algorithms and efficiency.

So why don’t programmers naturally break their work into these separate workflows? I think there are a number of explanations.

First, I think programmers get very focused on completing a feature. If they have to interrupt that work to enter the slower and more deliberate workflow required to create a new mechanism, then it delays the attainment of their goal.

Secondly, programmers like to program. Designing reusable components requires meetings, documentation, and reviews–all of which get in the way of programming.

Thirdly, most programmers aren’t too keen on collaboration. When you talk things over in a group, you have a chance of not getting your way. If you just build it yourself, you can do it the way you think it should be done.

Finally, by separating the two workflows, the creation of a needed mechanism might be assigned to a different programmer. Since the creation of these mechanisms is often more challenging and, therefore, more fun; developers are hesitant to initiate a workflow that would potentially deprive them of this fun.

Basically, it’s more fun to reinvent the wheel than to determine whether a suitable wheel already exists. If the wheel does need to be invented, it’s less fun to do it with a committee of your peers who may disagree with your vision for the wheel.

This was the case when we put out our first release of SlickEdit 2009, version 14.0.0.5. We had completed our usual beta cycle before releasing this version, which included a number of drops to correct reported problems. After the last beta drop, we made a few more changes, all of which seemed totally risk-free.

Within two hours of releasing SlickEdit 2009, we had reports of severe problems with the File tabs and the File list. These problems trace back to one of these simple, risk-free changes. We had done our normal testing after these changes, and we hadn’t discovered any problems. But this problem was so severe we had to pull the release until it could be fixed.

So, what did we learn from this?

First, there are no small changes. Even when you think you know the effect a change will have, you could be wrong.

Should we have tested more? Sure, you can always test more, but that is no guarantee that you will find a problem. Testing suffers from a horizon effect: you can only see as far as you test. The problem you need to find could lay just beyond or miles beyond. You don’t know until you find it.

Second, testing is different than using. When you are testing, you click all the buttons and try all the functions, but you are rarely able to perform all combinations of operations. Some problems depend on the order in which operations are invoked. Others require multiple operations before the problem surfaces, as was the case with the problem we missed.

It should be no surprise that the parts of SlickEdit that work the best are the things we use everyday. But there are many languages we don’t use on a daily basis. Even if we did, with a product like SlickEdit, our testing cannot hope to replicate the variety and complexity of our customers’ use patterns.

We’ve determined that prior to shipping any release, we need help validating it. So, we’ll create a Release Candidate when we have finished our testing. We’ll make the Release Candidate available for early adopters to test, and if all goes well, it will be used for the General Availability release. In this way, we hope to catch more problems before they are set free to roam the countryside and terrorize the populace.

Q&A

Does that mean you’ve given up on testing? No, we plan to continue testing just as we always have. We just need help with final validation.

What if I don’t have time to help you catch problems? Then wait until a release is no longer a release candidate. At that point, others will have helped to validate it, and you will have less likelihood of experiencing issues with a new version.

If an unladen swallow flies west from New York…

• The next_sexp (Ctrl+Alt+Right) and prev_sexp (Ctrl+Alt+Left) commands can be compared to next_word and prev_word, except that they treat blocks as words.
•  The backward_up_sexp (Ctrl+Alt+Up) command is the shortcut for navigating to the start of the immediately enclosing block (in Lisp, this would be the open paren).
• The forward_down_sexp (Ctrl+Alt+Down) command is used to drill into a block. If the cursor is at the start of a block, it moves the cursor to the first S-expression within the block; otherwise, it behaves like next_sexp.
• The commands select_prev_sexp (Ctrl+Alt+Shift+Left) and select_next_sexp (Ctrl+Alt+Shift+Right) extend a character selection from the cursor position to the start of the next or previous S-expression, respectively. Like the Shift+Cursor commands do to CUA style selections, if executed repeatedly, they will extend the current character selection.
•  The cut_prev_sexp (Ctrl+Alt+Backspace) command will delete the S-expression to the left of the cursor and copy it to the clipboard. Again, if called repeatedly, this will prepend the subsequent deletions to the clipboard.

The let down happened when I started thinking about the content of what I’m reading now versus what I was reading about 5-10 years ago.  Blog content is great, but it’s like reading a newspaper that’s nothing but a big editorial section.  Most posts are packed with unfiltered content that often falls into one of two categories; “You know what I think?” and “This is cool, check this out!”.   Both types of blog post are great and I’ve spent many, many hours reading these.  When I really thought about the content I’m reading though, I realized that I’m actually learning a lot less than I used to.  That wasn’t the only problem either.  Reading primarily in the browser has turned me into a skimmer, something I rarely used to do.  There’s so much pure bloggage out there that you have to skim and filter what’s worth reading and what’s not.  While that’s not awful in itself, I’ve noticed that I tend to retain a lot less when I read this way.  I also found that reading the blogs was only half of the reading I was doing.  The rest was reading people’s comments about what I had just read.  I can easily spend more time reading that than reading actual blog content.

At some point in your life, you say things or do things that make you think to yourself, “I’m really getting old.”  Everything is turning digital now.  Do I sound old yet?  In addition to programming, I’ve been a photographer for a long time, almost thirty years.  I started back in high school doing black and white film and eventually built a darkroom in my house.  About three years ago, I realized that buying film, paper and chemicals and spending countless hours in that darkroom could be replaced by spending a fraction of the time, at no cost, in front of my computer with Photoshop.  It was a sad realization, but I moved on to a digital SLR and turned the darkroom back into the original walk-in closet.  The only thing missing from Photoshop is actually feeling the film and the paper.  It may not sound like much, but after so many years I can say that those things are significant.  There’s something about handling the materials that puts you in touch with the process, and I haven’t found a replacement for that yet when I “develop” my photos the computer.

Reading is the same way.  There’s something about sitting down with a book that puts you in the mode of committing to read.  I can’t browse away from what I’m reading in a book with the click of a mouse.  Actually opening the book, holding it in my lap and turning the pages makes me feel like I’m ready to learning something new.  This is all about the experience of reading, and retaining what you read, without distraction.  It’s the same reason I wasn’t allowed to do my homework with the TV on when I was in school.  I can say for sure that I retain more when I read a book than when I read a blog at the computer.

Most computer books are also directed at actually teaching something.  Whether it’s a book about a programming language, a way of approaching design, or how to see a development project through to completion, most books teach.  However, it’s a rare occasion when a blog post really teaches you something.  Opinion pieces are great and have their place, but when the scale tips from spending time reading books to reading blog posts, you’re also tipping the the scale of how much you’re learning.

So now you’ve read a blog post about why you should try to read less blog posts.  You should probably eat more green vegetables and get eight hours of sleep each night, but I’ll save that for another post.  I’m going to try to make a change in my blogging, and do more writing that leaves readers with something more useful than a simple conversation piece.  Until then, try turning off the browser and go pick up a book… the trees will forgive you.

To display the window, from the main menu, click Tools > Regex Evaluator. Enter some sample text in the top area. Select the type of regular expression syntax to use, then enter your expression pattern in the bottom field. Matching patterns in the test case are indicated with a wavy underline. Groups (tagged expressions) are indicated with a boxed yellow highlight.

SlickEdit provides an emulation mode for the Vim text editor. If you want to learn Vim, or need to hone your skills, you can use the vimtutor command. Most Vim installations come with this command, which displays a special “learn-by-doing” practice file in the editor that you can can actually edit as you learn how to use the Vim commands. This file has been customized for SlickEdit users.

To use the command, open the SlickEdit command line, then type the command and press Enter. The practice file is displayed in the editor. Each time you use the vimtutor command, SlickEdit creates a fresh copy of this file.

Tip

Blueprints

One of the first things I noticed was that whenever I walk past the area where the construction guys are working on, there are always blueprints around.  Serious blueprints, not just stuff scribbled in a notebook.  Someone had taken the time to document in great detail every angle and aspect of even the most boring places in our office.  How often have you ever seen such blueprint level detail in software design documentation?  It’s rarely done, and if it is, it’s rarely maintained.  There are many times when I wished I’d just done the work of writing down my thoughts as I coded, so that if I needed to revise that code in the future, I’d have a blueprint of what was there.  It’s obviously important enough for the construction workers to insist on, why not software engineers?  Most of the code I’ve ever seen or worked on is barely commented, let alone designed or modeled.

Diff, undo and revert

Of course, for construction, having the blueprint level of detail is essential.  For them, there is no Undo command.  If you’re cutting drywall and you saw through a main electrical line or cut a key structural support, there’s no way to easily fix that problem.  If there’s one thing I learned from watching “This Old House”, it’s that when you build something, you measure twice and cut once.  For us software developers, we have a whole arsenal of life saving techniques.  Diff, undo and revert are all things we do when we’ve gone down the wrong path.  I joke sometimes that I wish everything in life had an undo command.  Unfortunately, these things have also made us lazy (there, I said it).  Diff, revert and automated refactoring have caused many software developers to stop measuring at all before cutting.  Admit it, if compiling refactored code could potentially cause the roof to collapse, we’d be a lot better at verifying correctness by:

1. Reading documentation and notes written by other developers whose functions and classes our code relies on.
2. Documenting the functions and classes we write so that others will use them correctly.

These are easy things to do that can potentially save a lot of time in future coding work.

Frog in the Well

There’s a riddle about a frog trying to get out of a well who can jump up three feet, but then falls back two feet.  The more times you cut without measuring, or edit without designing, the more you increase the chance that you will make the wrong cut.  For construction workers, making a wrong cut is absolutely disastrous.  For software engineers, making the wrong cut means backing out and trying again.  It’s easy to forget that there’s a cost to reverting and refactoring; the time you spent writing what is being undone.  I’ve known software engineers that program like the frog trying to get out of that well.

Being able to back out of changes is a luxury that shouldn’t be taken lightly. There will always be times when it’s necessary, but it’s important to understand why it’s necessary.  The next time you have to revert or refactor, ask yourself how much time you lost writing the original code that had to be changed.  How much time could have been saved by designing the code before writing it.  How much time will be lost in the future if you don’t document why you had to revert or refactor?  If you wrote some code that you realized later was a mistake, what will keep other developers from making the same mistake in the future?

Don’t be the frog in the well.  Take a tip from our friends, the construction workers, and provide a plan for the code you intend to create or restructure.  Put it somewhere where everyone can get to it, and finally, tell everyone it’s there.  Not only will you benefit from the fore-thought of your design, but other developers will benefit from your insight before working on the same code.

Hopefully, you could hear the sound of sarcasm dripping from each word in that sentence. I don’t know anyone who looks forward to annual reviews. As a manager, I dread this more than others. Not only do I get to have my own review, but I get to do the review for all of those who report to me.

I have to say that doing annual reviews falls somewhere between performing a root canal on myself and suffering through reruns of “Little House on the Prairie”. I know that seems like a broad area of pain, unless you hate that show as much as I do.

The chief reason for this angst is that no one, it seems, is ever happy with their review. Maybe that’s a good sign that I’m taking the process seriously and trying to really evaluate my team members’ strengths and weaknesses. Maybe that means I’m an overly critical [insert epithet here]. Believe me, nothing would be easier than telling everybody that they rock and just send them back to their cubicles.

I can’t bring myself to do that, though. I have to try to make this a meaningful event. To grow, everyone needs to know where they are strong and where they are weak. How many people realistically have no areas they cannot improve on?

Aside from the discomfort of doing an honest assessment of someone, the biggest problem in most review systems is that the scores are arbitrary and meaningless. At most companies, there is no effort to baseline scores or set a reasonable standard for what they mean.

At one company, we used a complex review system with 16 different ratings in 5 areas. Each was assigned a value from 1 to 10 with a 10 being the best score. When I had finished the reviews for my team, most scores ranged from 5 to 10 with a reasonable bell-shaped distribution. So, 7 and 8 were far more common than 5, 6, 9, and 10. I later learned that another manager had simply gone through and given his people all 9’s and 10’s. Since the raises were tied to scores, his people got bigger raises than mine.

I could have saved so much time and so much aggravation by just doing the same thing. Obviously the company didn’t care. They never said anything to me that my scores were unduly low or that his were unreasonably high.

It makes me miss the simple scoring systems used in college. There you are given a course syllabus that outlines the structure of your grade. It shows what percentage of your grade will come from homework assignments and what percentage will come from exams. Where I attended college, scores were posted on the professor’s door. Not only could you look-up your score, but you could see your ranking among your peers. So, even if you got an 87 on a test, you might find that it was one of the highest scores achieved.

In the work world, you rarely have that kind of clarity. Some of your peers succeed on the basis of their social skills rather than their contributions. And even when you are given a rating, you have no idea how it compares to those of your peers. Is it any wonder that employees typically view annual reviews with suspicion and hostility?

So, to simply things this year, I propose a new system based on the Signs of the Chinese Zodiac . I got the idea from a placemat at a Chinese restaurant. There are 12 animals: Rat, Ox, Tiger, Rabbit, Dragon, Snake, Horse, Ram, Monkey, Rooster, Dog, and Pig. Each animal is assigned a set of characteristics both positive and negative.

For example, the rat is said to be “Forthright, disciplined, systematic, meticulous, charismatic, hardworking, industrious, charming, eloquent, sociable, shrewd. Can be manipulative, vindictive, mendacious, venal, selfish, obstinate, critical, over-ambitious, ruthless, intolerant, scheming.” (from Wikipedia).

The Chinese zodiac assigns an animal to each year, month, day, and hour. So, you can interpret your personality based on these animals and how they interact. The interpretation of these signs is very complex and subtle.

To apply this system to annual reviews, I would take the traditional approach of breaking down performance into key areas: communication, teamwork, leadership, initiative, job knowledge, etc. For each area, the manager assigns one of the 12 animals. Along with the reviews, the employees would be given a key, like the placemat, that lists all of the animals and their characteristics. Together the employee and the manager would discuss the interpretation.

“Well, Frank, you got a Monkey for Communication and Rat for Leadership. I’d like to see you bring these two into better harmony next year. You should strive for an Ox in Communication or maybe a Rooster.”

This would also help when employees compare their results. Yes, we know they aren’t supposed to do that, but in my experience those kind of corporate rules are no more effective than speed limit signs. Using the Signs of the Chinese Zodiac for reviews would eliminate any hard feelings over someone getting a better review.

“Jim got a Rabbit in Customer Focus and I got a Horse.” Walks away with a look of utter puzzlement.

This would also head off any arguments due to an employee feeling they got an unfairly low score. “Damn it, Scott! I can’t believe you gave me a Tiger in Judgment. You know I should have gotten a Ram!”

Yes, this would produce a review system that allows for the arbitrary results of most modern reviews while allowing each employee to find their own meaning in their scores. …and peace and harmony rang throughout the kingdom!

After three years of use it had developed its own unique personality.  It had the perfect background with cool sounds to match.  The fonts were just right.  All of the desktop icons were where I wanted them and I knew exactly where everything was off the Start menu.  I had scripts, shortcuts and bindings to do all the common stuff I need to quickly.  I’d gotten to know all of its quirks, traits, flaws and mannerisms over those few years.

However, like many computers, after installing several versions of many large apps, it wasn’t the playful, energetic puppy that it was back when I started using it.  It was in no rush when rebooting, and I could hear it let out a sigh whenever started Outlook or Visual Studio.  What were once speedy builds turned into mandatory coffee breaks.  Still, I loved that computer… we knew each other and wrote software together every day.

Then, early one morning, our sys admin came over to my office.  “It seems like your computer’s been trying to send out emails directly on port 25 during the middle of the night, any idea what that could be?”  I didn’t know.  We looked up the address where they were being sent, somewhere I’d never heard of before.  “Alright, I’ll bring over the Vista DVD,” he said.

And that’s when it sunk in.  An infection… a virus… the Vista DVD… I was going to have to reformat my machine.  I was going to have to shoot Old Yeller.

[From the movie... Old Yeller's gone rabid and Mama's holding a shotgun]
Travis: No mama!
Mama: There’s no hope for him now. He’s sufferin’. You know we gotta do it.
Travis: I know Mama… But he was my dog… I’ll do it.

I sat quietly for a while after he left, realizing that this was the end.  I spent the next few hours backing up all of my important files and exporting all of my preferences.  “There are automatic updates ready to install, reboot now?” it prompted innocently.  The poor thing had no clue.  I missed him already, and I wondered if a better place awaited him after fdisk.  A place without disk fragmentation, bloated installations, useless polling auto-update tray apps and frozen taskbars.  I said goodbye and shut down one last time before booting from the Vista DVD.

I’m still sitting at the same desk, but everything feels new and a little unknown now.  It’s like working again with that energetic puppy I began with.  He’s eager to start up and get to work, builds are a snap and the desktop is clutter-free.  I’m still getting to know it, and soon he’ll develop his own personality.  I still miss Old Yeller, though.

I worked as a contractor on one such project a few years ago. We were writing a call center application for a large enterprise client. The architect of this system convinced the client that the business analysts would be able to write in a high-level business language (invented by the architect) so that future changes wouldn’t require hiring programmers to modify the system. Each line of business script, it was claimed, had the power of 20 or 30 lines of lower level code. So, this promised even greater efficiency than just eliminating the programmer.

The business language had classes, constructors, destructors, and nearly all of the features of modern object-oriented languages. Maybe it started out as a simplified language that would be accessible to the business team, but it grew into the same level of complexity as the Java code we were writing to implement the rest of the system. There was no way that a business analyst without training as a programmer was going to be able to write effective code with this language.

Even worse, the programming team was struggling to write code with the language. There was no debugger or other tools, not even an editor with color coding. When you had an error, you had to determine if it was a bug in the script or in the interpreter, which was being modified almost daily.

Even if we accept that it is a worthy goal to eliminate the need for programmers, I don’t think it’s possible. That’s because programmers have skills and abilities other than just their knowledge of programming languages.

Whether this is by training or nature, I cannot say. Likely, it is a little of both. Programmers have aptitude in the skills necessary to succeed in our field and these get nurtured through practice. Regardless, I’ve noticed that programmers are often more capable in many ways than their non-programming coworkers.

Programmers think more logically. Working through if-then-else conditions is a core capability for any programmer. While working with business teams on requirements, I have often run across cases the where same ability was lacking.

During one project to develop an expert system for mortgage analysis, I was often given requirements for rules on how to handle loans with particular Loan-To-Value ratios or for a particular loan amounts. Not uncommonly, these requirements would have gaps. I’d have requirements for loans from $0 to $100,000; from $150,000 to $250,000; and for loans over $250,000. But there was a hole between $100,000 and $150,000. At other times I’d have conflicting requirements for overlapping ranges.

Programmers have a superior ability to analyze problems and come up with solutions. They excel at analyzing preconditions, sequences of events, and outcomes. Certainly, this is a key skill in programming, but it is also useful in troubleshooting and business case analysis.

Another key ability where programmers typically have an edge is the ability to make order out of chaos. I think that’s because the programmer is responsible for creating order within the program. We break systems into subsystems, subsystems into modules, and modules into units. There are no physical constraints that dictate the structure of the solution. Whatever order exists is created by the people who write the code. Reflecting on some of the codebases I’ve worked on, it’s clear that this is not a universal trait in all programmers.

While people typically think of programmers as coders, whose main talent lies in writing the arcane syntax of programming languages. I think that their main talent lies in their ability to analyze, troubleshoot, and solve problems. Code is just the physical manifestation that culminates the thought process of the programmer.

Let’s say that someone does manage to write a tool that allows people to define software and control its behavior without having to write code. The person using this tool will still need all of the other mental abilities of a programmer. If this were to happen, we haven’t eliminated the programmer; we just changed the job description a little.

Yes, I can envision a distant future where Artificial Intelligence is used to develop code—but that won’t eliminate programmers, either; it just ported them to a different platform.

Slick-C is a macro programming language upon which the SlickEdit code editor is based.  Slick-C allows developers to modify the look and feel of the editor, write macros to perform custom operations, add new language support, and essentially extend the editor’s functionality until it is completely customized according to your preferences.

From his first post:

Here you’ll find Slick-C macros of all kinds, from overly simple to fairly complex. I’m a writer/editor/journalist by trade, not a professional developer. Slick-C programmers should find something 0f interest here, including plenty of code that can be tweaked or fixed.

The purpose of this blog is to address the shortage of Slick-C code on the Web, while stimulating discussion and encouraging code sharing.

I’ve used Slickedit in my daily work since approximately 1998. Currently I have 388 _command macros in my vusrmacs.e file. I’m sure there are other Slickedit users whose macro folders are wishing to burst free and benefit the larger community.

My professional roles are technical writer; editor and researcher of print and electronic publications; desktop publisher; journalist. My programming experience has generally been limited to high-level scripting languages. I’ve spent a lot of time using numerous text editors and macro languages. Of the two kinds of Slickedit users named in the subtitle of this blog, I’m a Wordsmith rather than a Code Maven.

Regardless, I’ve grown weary of some wasteful pleasantries, and I’ve been trying to make things more efficient. In particular, I’m tired of saying “please” and “thank you” all the time, particularly with my wife. After nearly 25 years of marriage, haven’t I proven my love and respect? Do I need to continually show it through endless “pleases” and “thank yous”?

So, I asked her if she could just assume that every request I ask is automatically preceeded by a “please” and followed by a “thank you”. I mean really, if she expects one every time, why not just assume it’s there in the first place?

In programmer parlance, this would be equivalent to writing a macro. Macros are substitutions that are inserted inline so that the code is altered, as though the substitution were there all along. I won’t bore you with the syntax, but if you’ve used macros before then you know what a time-saver they can be.

Unfortunately, my wife didn’t go along with this notion. It appears that her ability to execute macros is substantially less effective than a C compiler. So, she still expects a tedious “please” and “thank you” for each request. Sheesh!

Some programmers have taken this notion of macros a little too far. From the many programmers I have worked with, I have noticed the following macros in use:

The Greeting Macro — this is a common one, where the programmer has fully eschewed any responsibility for saying “Good morning”, “Hi”, “How’s it going?” or any of the regular acknowledgements of the other person’s existence.

The “Yes sir, I’ll get right on it” Macro – with this macro, a programmer will no longer let you know that they have heard and understood your requests. You must infer that they will comply because they have ceased their efforts to make you feel stupid for asking.

The “No I don’t think you’re a complete moron” Macro – here, the programmer has given up with trying to smile politely and respect your opinion. The macro is intended to soften his critical and belittling demeanor. It is important to note the stress on the word “complete” in this macro.

The Personal Hygiene Macro – I know it’s boring to shower every day, but the rest of us really appreciate it. Trust me on this one!

please_and_thankyou(“If you enjoyed this article, leave a comment.”)

This is a great idea! Technology is so prevalent in our society and in our government that it’s impossible to conceive of a plan for effective government that is not based on a sound technology roadmap. Certainly, if we need a Secretary of Transportation, then we need a Secretary of Technology.

Making this a cabinet-level position will hopefully give the USCTO the authority to bring uncooperative agencies together. In truth, I think that will be the biggest challenge. Bureaucracies are rife with politics. They don’t like to be told what to do or to work with others. They want to do things their way without someone else suggesting a better way.

A Chief Technology Officer can be instrumental in setting goals and directions for our nation’s IT infrastructure. However, I have seen CTOs wreak havoc on organizations that were doing just fine without them. Here are a few common pitfalls I hope the new US CTO will be able to avoid.

Outsourcing Core Expertise

I have worked for years as a contract programmer, and I have worked for companies that provided outsourcing services. There are times when it truly makes sense to outsource. If you are not a software company, but you need to have software built, then you are generally better off hiring a company to do that for you. A company that develops software full-time will be far more successful than one with no experience.

For example, I worked for a company that developed workflow and routing systems that incorporated high-speed scanners. We had significant knowledge and experience with the hardware and issues involved with these systems. Our customers were companies that processed forms for things like book clubs or medical records. Those companies simply could not have built these systems as effectively as we could.

For them, the systems we built were just a tool. Their core knowledge was related to the business of processing the records. They just needed a system that made it faster and easier to process the information.

However, I have seen companies whose main revenue comes from selling software outsource the development of their products. Commonly, this is done by partnering with an offshore development house.

The problem with this approach isn’t that it’s overseas; it’s that the people working on the product do not work for the company. If you make money by building and selling software, then why would you ever want the knowledge necessary to create and maintain your products to be held by someone with no attachment to your company?!?

Cost Centric Management

Improving an organization is hard. It takes thorough analysis and creative thinking to find ways to do things better. Rather than finding ways to do things better, some CTOs try to make their mark by doing things cheaper.

Don’t get me wrong, I do believe that organizations should be run efficiently and that managers should be looking at costs to make sure they are in line. However, cost management is often taken to an extreme.

Examples of this mentality include hiring cheaper programmers rather than focusing on the knowledge and experience needed. Many companies treat programmers like interchangeable cogs with no appreciation for the difference between individuals. So, if they can hire programmers for $10K or $20K less per year, that’s a big win, right?

This mentality drives the offshoring approach. The lower cost is touted as a big win for the company, but little consideration is given to whether the product can be developed as successfully. This is particularly problematic if the development team is split, as is so often the case, with the business team working here and the developers working overseas. Software development has been shown to be far more successful when there is close interaction between the programmers and the subject matter experts, even more so with direct customer interaction.

Companies also attempt to restrict costs by scrimping on the tools they provide. We see that one a lot at SlickEdit. We often hear from programmers who want to buy SlickEdit but are told by their management that $300 is too expensive.

At SlickEdit, every developer has multiple monitors. We believe this is essential to getting your work done efficiently. I have worked at some companies where I bought my own equipment because they would not approve anything more than a single 17” monitor.

The fundamental mistake that drives these decisions is that they assume a fixed level of output. So, they believe they can cut costs and the output will not change. In truth, we know that the level of output in software development is highly variable and subject to many complex factors. The definitive work in this area is “Peopleware” by DeMarco and Lister.

Over Standardization

Standardization can be a good thing. When done properly, it ensures efficiencies of scale and the ability to dynamically manage resources within an organization. Standardization can be helpful to assist everyone in producing a similar result. If taken too far, it becomes a force to make sure that no one can achieve excellence.

No single tool or technology is good for all situations. The cost of trying to pound a square peg into a round hole can often exceed the cost of buying a round peg. You do have to guard against capricious choices (see Design Fail Patterns), but you should guard against a policy that is too rigid. Standardization should be a gravitational force that pulls towards a center, but it should not become an inescapable black hole

The larger the company, the more diverse their technology should be. Small companies may not be able to afford to dabble in different technologies, but larger companies can often see greater efficiency by allowing teams to select the right tools even when they are different. Further, by having a broader technology portfolio they reduce the risks associated with selecting a single technology, and they are more likely to discover new, more efficient ways of doing things.

“Vision”

I often see the word “vision” used with CTOs. They have “vision”. When I hear this word, I cringe. While having vision is often essential in succeeding, too often this word is used as license for narrow-minded, megalomaniacal tendencies that will brook no discussion or alternatives. Can you tell I feel strongly about this one?

Often the CTO forms this vision before they know anything about the organization. In my experience, the employees already know what needs to be done to fix most problems at the company. What they need is a management team that’s willing to listen. Instead, most employees fear going to upper management with problems and solutions.

Sometimes this “vision” is based on a success at a previous company. They see the new company as an opportunity to do what they did before. However, these successes are rarely repeatable. Organizations are just too different. Often, the reason a project succeeds is because of complex factors, not the least of which is the team that implemented it. Given the choice, I’d rather have the team from that successful project rather than one guy with the “vision”. Be careful how much credit you give managers (or any leaders) for the accomplishments of their teams.

Vision should provide an overall direction, a set of values that are used to balance competing needs. It should not be a totalitarian model to which an organization must conform.

I wish the new CTO of the United States much luck. It will be needed. Confidence in our government is at an all-time low. It will take much more than vision to change that.

For the sake of this discussion, we’ll treat defects the same as features. This isn’t totally accurate since some defects simply must be fixed as soon as possible. However, most defects are subject to the same decision process as features.

The Dictatorship

With this system, a single, all-powerful voice decides what gets done when. This is a common approach on smaller projects, where these decisions are made by the project manager. That’s not to say that this person doesn’t listen to advice from others. But when it comes time to decide they, alone, make the call.

Ultimately, the other systems typically have a single person who has to make the final decision. In my opinion, this is an essential characteristic of an effective organization. Everything should funnel up to a single person authorized to make decisions. People at different levels should be empowered to make various decisions, but in the end a single person should have the final authority. Otherwise, you flounder endlessly when a consensus cannot be achieved. It becomes a dictatorship when the leader ignores the advice and guidance of others and acts strictly on their own belief.

This approach only appeals to me if I can be the dictator, using my sagely wisdom to guide the product direction. In truth, this system can work well if the person in charge has a keen sense of what it takes to succeed. From accounts I’ve read, this is not unlike Steve Jobs’ approach to new product development. Though you can argue with his approach, it’s hard to question the results.

The Oligarchy

In an oligarchy , power is shared by small, elite group. This approach is often used on larger projects where various constituencies are represented. You might have representatives from project management, sales, development, quality assurance, and product support. In some cases, actual customer representatives might be involved.

The group meets regularly to discuss what is needed and when. Tradeoffs are weighed between features needed to spur new sales and fixes needed to appease existing customers. Typically, the group is lead by someone with final decision authority, but most decisions have a strong consensus.

This approach is certainly more representative, but it is also much more time-consuming. I’ve worked on projects that used this method, but they were very large with complex interactions between subsystems. Still, a light-weight version of this can be helpful to make sure all factors are weighed effectively.

The Democracy

In its purest form, this approach relies on votes from the masses to make the selection. Sometimes, members of the development team do the voting. In other systems, the customers are allowed to vote.

Though I cannot find a reference to it anymore, I recall that Sun used Duke Dollars as a way for developers to vote for specific fixes in the early days of Java. I’ve worked on teams where each developer was given some number of votes that they could apply to the bugs or features of their choosing.

I’m not a big fan of this approach. When the developers do the voting, this tends to favor the interesting, glamorous features over those that are more mundane. Often, these mundane features make a bigger difference to the customers. When the customers vote, they are typically guided by their own way of working. An effective product has to balance the different ways customers will use it.

You could use a hybrid approach, where the developers or customers submit votes but the decisions is ultimately made by a small group or individual. The problem with this is that it can be demotivating to the voters. If a feature with a high number of votes is rejected, they will ask why they even bothered. So, if you use a voting system, you should be willing to act on the results.

The Meritocracy

In the meritocracy , the best idea wins. Instead of suggesting a feature or voting for it, each feature is submitted with a business case. The business case is used to decide which changes make the biggest difference to the product.

This is my preferred approach to prioritizing features. It allows for input from all stakeholders and provides a means to assess priorities. With this system, anyone can challenge a feature and have it replaced in the schedule by demonstrating that another feature has a better business case.

Unfortunately, it is not always evident which idea has the greatest merit. So, this system relies on approaches from the others to make that call. A team or individual weighs the various proposals and picks the ones that best meet the business needs.

This approach also avoids the “squeaky wheel gets the grease” syndrome. Often, it is the customer or developer who is most vocal that gets their way. Great ideas languish because the proponent is not willing or able to be heard above the din of the highly vocal.

Truthfully, there are very few pure examples of any form of government. Most are a combination of these approaches. The most important characteristics of a feature planning system are:

• The ability to gather ideas from all stakeholders.
• The willingness to listen to these ideas.
• A system to evaluate ideas on their true merit.
• A clear vision of the product that helps to determine which ideas truly enhance the product and which just muddy the waters.

Of course, it wouldn’t hurt if we could somehow take humans out of the equation and have features selected by a race of benevolent and powerful robots. But that’s a post for another time.

Cast your mind back to the days of the tall ships, great wooden vessels that plied the oceans under wind power. Imagine one of those majestic ships sailing along when suddenly it hits a reef, tearing a large hole below the waterline. All hands scramble to save the ship. They bail and bail, but the ship continues to sink. As the ship sinks lower, they bail more furiously until finally the ship is lost. The survivors are washed ashore on a nearby island.

As they stare out at the masts of the ship, still visible above the waves, the Captain asks, “Why weren’t we able to plug the leak?”

One of the crew pipes up, “Captain, sir, we were too busy bailing to plug the leak.”

OK, this is a contrived example, and it’s very hard to believe that it could occur in real life. However, very similar situations frequently arise in software development.

Bad Codebase

The most typical way I’ve seen this occur is on projects where the early work has set us up for failure. The infrastructural code is so full of bugs or badly designed that it has become a stumbling block to get the rest of the system built. The team furiously pounds away at the code, driving toward a critical milestone fixing bugs as they can. But with every iteration, things take longer to do and the codebase gets harder to work with.

In this case, the leak is the poor codebase. The only way to plug the leak is to rewrite that part of the system. Often, the programming team is unable to recognize that this code is a lost cause, particularly if they participated in its development. More commonly, the programmers know that this code is the problem, but they can’t talk management into the schedule slip that is necessary to fix it. In the end, the project takes longer to complete than if we had stopped and rewritten the offending code.

Unfortunately, a leak in software is rarely as visible or as easy to appreciate as a gaping hole in a hull. However, the programmers’ work to patch the system instead of fixing it is just as futile as the sailors who just keep bailing. And the result is nearly as predictable.

Poor Process

Another way this phenomenon is manifested is in adherence to bad processes. I worked on a project that used very poor configuration management techniques. The approach to version control was sloppy, and there were no controls for how integration servers were configured or how code was deployed for testing. Consequently, even though we would get successful tests on the integration server, we continually faced problems in production. These problems stemmed from several causes. Sometimes it was because of files that were edited on the integration server and not checked into source control, so they never got deployed to production. Or someone would set up the directory structure differently so that it would work on one machine but not the other.

When these problems appeared, the proffered solution was that people should be more careful. This case might be slightly different. Instead of thinking that you’re too busy bailing to plug the leak; in this case you believe that bailing may be all that’s needed.

I’m a firm believer that your test machines should mirror your production environment in every way possible and that you should deploy your code for testing exactly as it will be deployed to the production environment. And if I ever catch someone editing a file on a test or integration server, I’ll keel haul them!

No Time for Personal Development

I also see the “too busy bailing” mentality at work in peoples’ careers. As a hiring manager, I have interviewed hundreds of candidates for jobs over the years. I’m frequently amazed to learn how little people invest in their careers and the knowledge necessary to advance.

For example, most of my work has been on Object-Oriented projects. So, I typically ask OO questions of the candidates. One question is about how they learned OO programming. What books did they read? How did they hone this knowledge? Typically, I find that most candidates learned OO in college and have done nothing to build on that knowledge, other than their normal work experience.

I’ve also interviewed candidates for web development. So, I’ll get a resume from a bright young college student who is about to graduate. They tell me they want to be a web developer.

“Great!” I say. “So, have you ever built a website?”

“No.”

“Do you know HTML and JavaScript?”

“We had that in a class once.”

“Well, then what have you done to become a web developer?”

“I’m real busy with class right now.”

So, basically, this guy is looking for someone to pay him to become a web developer. I’ll always consider a new grad without formal experience, but I want someone who has done more than just sit through classes on their way to a degree. Show me some passion or interest in your area by working on something outside of class. Or at least have knowledge in the basic tools.

Tool Selection

The final way I see people being too busy bailing is through adherence to less effective tools. I often interact with people who have been using vi their whole career, or some other minimal editor, and just can’t be bothered to change. No amount of telling them how you can save them time will convince them to switch. They may even admit that they know they could be more productive if they switched, but they don’t want to take the time to learn a new tool.

Truthfully, this could be a case of the tool becoming the job rather than being too busy bailing. In that situation, a person spends so much time, say, hammering that they lose sight of why they are hammering: to build houses. So when a new way of driving nails comes along, they stick to their current way of working. “I’ve been hammering for 20 years. I’m not about to switch.”

Switching tools will always involve an investment in time. But if you pick the right tool, that investment will pay off rapidly.

So watch for signs of bailing in your own work and career. Consider whether there is a leak that needs to be plugged first. If not, then bail for all your worth. If you have spotted a leak and no one will listen, maybe you need to do a different kind of bailing.