The Fine Art of Ruining Your IT Résumé

October 13, 2007

(NOTE: This is focused on IT résumés because that’s what I do, but it could and should be applied to any résumé)

In our line of work, the statistics say we change jobs. Boy, do we ever. It’s been awhile for me but I think the following holds true: changing jobs = applying for a position you want = submitting your résumé to your prospective employer.

I’ve read many résumés in my admittedly short professional career; for more than 3 years, I was a member of a 4-person team that interviewed every candidate applying for either developer or project manager at my company. This team consisted of the director of IT, the development manager, our senior software engineer, and me. In fact, for some time we didn’t have a development manager, so we were only a team of 3. (As a side note, I hope each of you have or have had the chance to interview your future boss at some point in your career ::grin::).

Some of us know how to write a résumé and some of us don’t, but I don’t want to focus on the whole thing. I want to focus on the Work Experience section of your résumé, AKA Here Are The Tasks I Had In Each Job I’ve Worked Worded As Boringly As Possible Hope You Don’t Fall Asleep Reading It Whoops You Did Now You’re Snoring Sweet Dreams.

Let’s start with a hypothetical developer who we’ll call Randall. We’ll make Randall very similar to me in some ways and not so much in others. (And I should note that he’s dissimilar to me in one crucial aspect: I’m not looking for a job at the moment!)

There are a few things you should know about Randall:

  1. He’s a developer at a retail company that has consistently grown in recent years
  2. He has 3+ years of experience
  3. The development team of which he’s a member doesn’t have specialists, i.e. any developer may be assigned any sort of project. Consequently, he’s completed projects from small stored procedures in the database to large Win32 apps designed to manage the company’s product line and inventory.
  4. Like most of us with some experience under our belts, Randall has a couple of projects that he’s particularly proud of. They were a first for the company or they related to a neat domain (cryptography, for example) or they were programmed using a cool design pattern, etc.

Randall has recently decided to apply to several different companies to test the waters. He knows that there’s been a shortage in the IT industry in the last few years and, while he’s satisfied in his current role, he’s developed a curiosity for what else might be out there.

So now Randall is writing the Work Experience section of his résumé. I’ll give you a couple of examples and you see which you think is best.

  1. Application Developer (July 2004 – Present)
    Responsible for maintenance and new development. Other duties include database programming as required.
  2. Application Developer (July 2004 – Present)
    Creation of diverse suite of software in use throughout the company. A project sampling:

    Researched, developed, and deployed company’s first encryption modules for protecting sensitive customer data which is now widely-used across development projects.

    Developed application for end-to-end product management of 23,000+ products, from new product creation to ordering, inventory management, and promotion.

    Key member of a team that created paper-less payroll system to replace legacy paper-based system. This software enabled efficient tracking of cost centers across the company, which has facilitated the company’s continued growth.

So what do you think?

Well, here’s what I want answered in a résumé: who are you and why do I care? Work experience should help tell me that and do it in a way that doesn’t read like furniture instructions.

Tell me a story about yourself.

Tell me what you’ve done.

Tell me why it matters. And if it doesn’t matter, why in the hell are you telling me?

Ask yourself two questions when drafting your work history:

  1. What was the scope? Writing an employee management system for 4 people doesn’t mean nearly as much to me as writing one for 4,000.
  2. What was the outcome? We’re all developers here. Just writing software doesn’t mean much. Writing software that makes a demonstrable difference, though – now that’s worth something.

Oh, and extra points to anyone who doesn’t call it Work Experience or Work History on his or her résumé. Don’t get me started. . .

Productivity Tools For Web Development (A Monday Series: Part 2)

September 25, 2007

[Note: busy day yesterday! Apologies that this part of my Monday series is being posted on Tuesday. Can anyone say, “post scheduling”? Amen!]

Monday #2: A good* replication process – Oh, man. This is one of my favorites.

When I first started developing for the web, I hated deploying new versions of our web applications. Why? Well, because when I first started, I deployed using the following process:

  1. Copy the newly compiled executable to the clipboard
  2. Open Windows Explorer and navigate to the first web server’s production app directory
  3. Rename the current production version
  4. Paste the executable from my clipboard into the production app directory
  5. Repeat for each web server (less than 10, but not by much)
  6. Weep softly, wondering why I’m still doing something so glaringly inefficient

Best case, doing all that usually took around 2-3 minutes if the network was responding quickly. And pray that there wasn’t a bug that somehow escaped testing, because if there is, the whole process has to be reversed for each server.

Finally, I decided that this was no good. Remember our dear, old friend, the batch file? With a couple of easy steps, a batch file can make all of our wildest dreams come true (assuming that our wildest dreams entail file replication. Be still, my beating heart!)

You’ll need:

  1. A directory into which you can put files you want to replicate – I use C:\replication, but you can create it anywhere you want and call it anything you like
  2. A batch (.BAT) file – There’s a few ways to do this. I have 2 that I use.

    replicate.bat: This allows me to specify a directory as a command line argument. Assuming that your web servers are all configured identically, this will copy the files in your replication directory to the same location on each web server.

    set directory=%1

    for %%f in (1,2,3) do copy /-Y C:\replication \\yourWebServer%%f\d\%directory%

    Example usage from the command prompt: replicate myDirectory\yourShoppingCartApp

    replicate_app.bat: This one copies to the same directory every time, which is what I want when I’m deploying apps.

    for %%f in (1,2,3) do copy /-Y C:\replication \\yourWebServer%%f\productionApps

    Example usage from the command prompt: replicate_app

Once those are set up, just compile or copy your executable to your replication directory. Open a command prompt and run your batch file of choice to deploy your file(s) to all servers in one shot. Total elapsed time: 10 seconds or less.

To save a backup of the current production app, I rename it and put it in the replication directory right next to the new version I want to deploy. Then when I run the replication, the backup is copied to each server along with the new version. You know – just in case. . .

I know there are various utilities that’ll achieve similar effects, but I don’t know of a good free one. And then of course there’s Windows File Replication Service, but that’s sort of low on my list at the moment.

Got a better way to do it? Let me know in a comment.

*”Good” in relative terms. 🙂

Productivity Tools For Web Development (A Monday Series: Part 1)

September 17, 2007

I decided that I need something to fill in gaps between posting longer articles, so it’s time for a series. I’ll post a new part each Monday until I run out of ideas, start a different series, or die. LIFO rules apply here. So let’s get this show on the road…

About 3 months ago, I started on a journey. The destination? Better productivity and organization. Along the way, I’ve read thousands of productivity articles, a few books, and tried hundreds of different apps, shortcuts, and systems.

What follow are the tools I’ve adopted to make web development more productive. However, many of these are applicable to any flavor of development and some will apply to any sort of computer work at all.

Monday #1: Firefox bookmarks – Not just any ol’ bookmark, each Firefox bookmark is customizable with a keyword that lets you enter it into the location bar instead of the URL. So, for example, if I want a shortcut to my shopping cart page named ‘sc’, I first create the bookmark the way I would any other bookmark. Then, I right-click on the bookmark in either the toolbar or the Bookmarks menu and click on Properties. I enter a keyword (‘sc’ for example) in the Keyword field and click ‘Ok’. Now I can type ‘sc’ + Enter to navigate right to the shopping cart page.

Firefox Bookmark properties

On our website, we use different URLs for testing than we do for production, so from the example above, I might set up a bookmark for the shopping cart test URL and give it a keyword of ‘tsc’. I’ve set up bookmarks for all the URLs I frequently hit for testing and it’s saved me a bunch of mousing around.

Got a better way to do it? Let me know in a comment.

And stay tuned for a long post this week! I’ve got a post or two marinating that I think you’ll find tasty.

What? Mouseless browsing in Firefox without an add-on?!?

September 10, 2007

Please shoot me. As long as I have been using Firefox, I only today tripped across this Lifehacker post from November of 2005: Hack Attack: Mouse-less Firefox Whoa.

One of my most bemoaned activities in life was browsing the internet because I always thought it had to be so damned inefficient. Yeah, I could get to the address bar (CTRL + L), use a keyword for any bookmarks (right-click a bookmark, enter a keyword into the Keyword field, type the keyword into the location bar + Enter), or launch a Google search in a new tab from the toolbar (modify about:config together with CTRL + K), but I still had to use the mouse to click links. Yuck!

I normally don’t do short posts, but I’m banking on the fact that some of you may not have seen it either. Very cool stuff!

The problem with “The Problem with Tabbed Interfaces”

September 7, 2007

UPDATE: I posted this before reading the comments on the post I referenced, so if you read those, don’t read this 🙂

Jeff Atwood of Coding Horror published a post today entitled The Problem with Tabbed Interfaces. He explains that he has difficulty finding the site he already has open because it’s obscured by the tab mechanism, which results in him opening multiple instances of Gmail, for example.

The depressing thing is that it’s usually faster to mindlessly launch a new browser than it is to go through this tedious routine of playing Where’s Waldo with (n) browsers and (n) tabs

Well, yeah. I remember having that issue, too, before I realized that I didn’t need (n) browsers open. That’s sort of the point of having a tabbed interface, isn’t it? All I could think while reading the post was, “Close all your browsers but one! Problem solved”.

Anytime I need to find a site that I know I already have opened, I find the single instance of Firefox in my task switcher, hit CTRL+TAB a couple of times, and smile. Maybe Jeff works drastically different than I do, but I’m missing the part where using a single browser is an issue.

Trust me: don’t fire that bad developer just yet (part 2)

September 6, 2007

So you didn’t take my advice (part 1). You went ahead and fired the guy anyway, didn’t you?

Now you’ve done it. This is terrible. Your IT department is going to disintegrate and your company will go the way of BetaMax, 5″ floppies, CRT monitors, and the buttermilk pancake helmet (delicious but ineffective, as any historian familiar with medieval times will attest)! Run for your lives!!

Ok, ok. It isn’t that bad. BUT here are some things you might’ve done when you fired that dude.

  1. You’ve created a slippery slope – Once you let someone go because they required a tad too much effort and supervision, it becomes a little easier to let the next person go, and next thing you know, you’ve not only fallen down the slope, you’ve landed on your groin and lost a shoe on the way. You may start to see patterns in another developer that remind you of the bad developer you fired.

    Don’t misunderstand: people absolutely do behave in patterns, BUT the evaluation of those patterns should be confined to each person; they’re not necessarily transferable from one individual to another. So, for example, if you notice that Bill has difficulty understanding your shopping cart module just like that guy you fired, don’t assume that there will be other similarities. Maybe that particular module is just tough, but Bill will do a killer job once he gets the hang of it.

  2. You’ve created an atmosphere that doesn’t allow failure – Without meaning to, you made a martyr of that guy you fired. He’s now the example your team will relate to when they’re feeling overwhelmed or confused. Even the developers that agreed with the decision at the time will come to resent it to some degree and wonder if it might’ve been possible to give the guy just a little longer.

    If you want to see developers that are paralyzed to do any real risky work , start firing their co-workers for not “getting it” or for making mistakes on a project. And by “risky work”, I mean working on any system that is truly key to your business – think order taking or shipping, for example. It’s risky because it’s the type of system that has to work. You may know these systems as “the ones that actually make us money“. These types of projects are already stressful enough without your developers thinking that they could be canned if they make a slip.

  3. You’ve created a hole in your consistency bubble – Cycling quickly through developers (remember: our hypothetical programmer has only been working at your company for 1 or 2 months), causes a high level of uncertainty for the rest of your team, and it’s only worse if they actually like the guy you fired. Serious personality types won’t like him on principle because he’s a weight to the rest of the team; carefree types won’t mind so much. Regardless, though, everyone needs time to adjust to team dynamics. Change them too often and you’ll sacrifice more than just productivity and deadlines.

Your mileage will vary, but you should certainly examine your situation to ensure that any of the above issues are identified and dealt with to the best of your ability. Unless you don’t care, that is.

In that case, fire away!

Trust me: don’t fire that bad developer just yet* (part 1)

August 28, 2007

You know this person. For the sake of this post, let’s assume it’s a guy. And this particular guy is obviously the worst developer on your team.

He’s been at your company for a month or two. He doesn’t understand your code base. He doesn’t understand best practice paradigms (yes, I know they’re open for debate, but assume I’m talking about your best practice paradigms). He doesn’t listen when you offer feedback. His communication skills are, as a good friend of mine might say, sub-optimal. He requires more attention than developers that are twice as capable.

But please don’t fire him yet.

Ok, some of you can (and should) fire that guy out of a cannon, but don’t even think about it until you’ve given him a chance. Let me be clear: “a chance” consists of the following elements.

  1. Clear direction: He needs exactly 1 boss. Not 1.5 bosses. Not 1 direct supervisor and 1 director that sometimes hands him other assignments. 1 (ONE) boss – no more no less. If every assignment isn’t funneled directly through that 1 boss, additional lines of communication have to be established. And that doesn’t work. Ever.

    Office Space is funny because it resonates truth with anyone who’s ever been in a situation where he has multiple supervisors and none of them fully know what’s going on. Believe it.

  2. Well-defined expectations: This is tightly coupled with direction. Our hypothetical developer has to know what’s he’s supposed to be doing and what result is expected. When do you expect him to be done? And what does “done” consist of? Experienced developers tend to make the assumption that everyone knows good code from bad. So do you want his assignments “done” or “done well”? If he doesn’t know the difference, is that his fault or yours?
  3. Consistency: If you can’t offer him a consistent work environment, don’t expect him to be successful. People need schedules. People need a degree of certainty. People need to know that scheduled meetings will happen at the scheduled time for the scheduled length. They need to know that project decisions are made the same way every time. (Side note: if your organization doesn’t make decisions the same way every time, you’ve got other problems. In that case, it’s your job to insulate your developers as much as possible and create a consistency bubble around your team)
  4. One code review (at the bare minimum): If he hasn’t had at least one code review and the opportunity to respond to the review feedback, don’t fire him! I don’t care what your mentoring process is (you do have a mentoring process, don’t you?), there’s no substitute for getting constructive feedback from a group of your peers. I’ve seen poorly performing developers make a 180 after a good code review or two.

In part 2, I’ll talk about what you’re leaving on the table when you fire someone too hastily.

*No, this isn’t about me. I hope. 😉

I’m 100% certain that nothing is certain

August 20, 2007

As Scott Adams has said more than once, human beings (or “moist robots” if you subscribe to that sort of thing) are often absolutely, 100% certain about something only to change their minds later based on either experience or new evidence. If I’m honest, I know that this has happened several times in my own life. And I’ll bet that if you think about it, it’s probably happened in yours, too.

Let’s take a short trip back in time . . . ::cue flashback music and cheesy-but-oh-so-effective screen transition:: June 2007. San Jose, California. The 3rd annual Internet Retailer conference. Along with my boss and one of our web designers, I’m sitting in an auditorium with about 4,000 other websters. There’s a large stage in the front of the room and 5 large screens are spaced evenly along the back wall. On this stage is a panel of “industry experts“*, one of many such panels on display throughout the week (“Oh wow, Morgan. Look at that beautiful panel! And so well-mannered! We’ll have to get one of those for our office!”). This particular panel of guys and gals is covering mobile devices – mainly smart phones and cell phones.

At the podium, a gentleman is explaining that the mobile device platform will increasingly become a key vehicle for retail opportunity. He’s got graphs. He’s got statistics. He’s wearing his most persuasive, gotta-make-the-sale-or-we-don’t-eat suit. Hell, he probably got his hair did for just this event.

There’s just one problem. I’m not buying it.

With all the gusto I can muster, I call BS in no uncertain terms. My main argument is that the form factor for mobile devices is crap.

  1. The screen is too damn small! Why would anyone shop when seeing the picture of the item is nearly impossible?
  2. The input devices suck! Yeah, you can get a “full” QWERTY keyboard on a mobile device, but you wouldn’t use it to shop unless someone was threatening your dog.
  3. The web browsers on mobile devices are altogether unsavory! (Yes, these are the types of exclamations I make on a routine basis) We’re light-years from being able to render the authentic web experience on a mobile device and until we can do that, you won’t see the platform begin to make a dent in traditional web retail.

Of these things, I was certain.

That was June. This is August.

And did I mention that I bought something using my mobile device less than a month after the Internet Retailer conference? No? Well, I navigated to a retail site using my BlackBerry, searched for a product I was interested in, and then. . . (wait for it). . . I bought it.

How could this happen, you ask? “Mark”, you’re screaming as you read this, “you said no one would shop using a mobile device! Did someone threaten your dog?!”. Listen, I really meant those things. I did! What I didn’t realize is that the whole “mobile devices are crap for shopping” argument is squashed handily by the word “mobile”. Yes, you can take them anywhere. So yeah, it may not be as comfy as shopping from home, but, not unlike a Porta-Potty, the convenience far outweighs the interface issues.

So now I’m certain that the mobile device platform will increasingly become a key vehicle for retail opportunity. I don’t have graphs, I don’t have statistics, and I’m not wearing a suit. What I do have is a mobile device and a powerful need to buy stuff.

Got any similar “certainties” you’d like to share? Let me know.

Land of the lost (or, All computer folks are not equal)

August 16, 2007

Without warning, I’m hit:

“Layer 2 MAC resolution through the ARP cache”

I stagger slightly.

“24-bitted mask with a dotted decimal”

My vision begins to blur.

“A typical situation is where an ARP flood or broadcast storm can cause keepalive or VRID messages from being delivered”

With slight embarrassment, I realize that I’m drooling.

Welcome to my personal reminder of how truly, completely, unfathomably different computer disciplines can be. Much to my mix of amusement and chagrin, the quotes above and many more were used oh-so-casually by my trainer last week while I was in Denver. See, he was (and presumably still is) a diehard networking guy. So was everyone in the class. Well, everyone who wasn’t me, that is.

While I know we all seem alike to the lay-person, there are many different, totally unrelated flavors of computer folk. So that you may be warned, descriptions of a few of them follow.

  • The networker: generally unappealing and slovenly, these sad people work with servers, routing, and (yuck) security. This role is the closest IT professionals can get to manual labor, since they may have to physically run cables and move servers. As a result, they’re nearly all hunchbacked.
  • The database administrator: cross-eyed from hours of staring at execution plans and performance statistics, the database administrator is best avoided at all costs. For entertainment, they’ll appear out of nowhere at your cubicle to discuss query optimization, job scheduling, and clustered indices. Run away quickly if they approach you about “natural joins”.
  • The Windows developer: in my experience, these individuals have as many as 3 teeth. However, 2 of those will be in their pockets. This breed of IT “professional” is particularly inclined to be found in seedy discussion forums known as “newsgroups”. Often still drunk from the previous night’s binge, Windows developers have small, beady eyes from lengthy debugging sessions and are quick to espouse the virtues of “exception handling” and “design”: 2 universally reprehensible concepts. Very unsavory guys and gals.
  • The web developer: by all reports, the saviors of the IT industry. As elegant and graceful as the experiences they create, their reasoning skills are only rivaled by their intelligence. Generally recognized as a boon to productivity, the web developer is highly sought-after in all business circles for his/her robust skill-set and infectious positive attitude. Will often be heard uttering the question and entirely true answer, “You know what sucks about being a web developer? Nothing.”

So next time you’re asking your IT professional buddy why he isn’t smart enough to fix your printer, remember that we’re not all created equal. As illustrated above, some of us are only marginally smarter than that printer and most are less capable.

Sorry, honey. My BlackBerry and I need some space

August 14, 2007

I know this may come as a shock to you, dear. Me and my BlackBerry 8300 Curve (which I nicknamed “Double Bee“) have been spending a lot of time together lately and, well, things just sort of happened.

At first, it was the occasional web browsing session. My BlackBerry isn’t the most robust surfing platform, no, but it’s reasonably fast and pleasing to use for sites that support mobile. Once I set Google Reader as my home page for “Double Bee”‘s browser, there was no going back. I was hooked. (Side note: It just seems wrong somehow to have access to RSS feeds while you’re in the bathroom at work, doesn’t it?)

As time went on, my BlackBerry was able to provide access to my Gmail. Before, I didn’t even realize I needed access to my email 24/7, but now I’ve become very attached. By using filters and labels, it doubles as a task list that I always have with me.

Next came Google Maps. Oh, Google Maps via BlackBerry, where have you been all my directionally-challenged, perpetually-lost in my own hometown life? Take the things you love about Google (intelligent parsing – ever tried just typing in a street name? – and directions/location info, to name 2) and now put them in your pocket. Forget needing your laptop. Forget needing wi-fi.

True story: hungry for some take-out on my way home one evening, I typed in the one-word name of a local pizza joint and nothing else into Google Maps. 10 seconds later, “Double Bee” was showing me a map with the 2 locations for the restaurant. I picked the one closest to my house and pressed the call button. The rest is delicious, pizza-filled history.

When you add in the fact that I got it for -$10, there’s really no comparison, honey. And nothing screams, “I work in IT! Hear me roar! Yes, this is duct tape on my glasses!“, like a BlackBerry in a belt holster.

How could it not be true love?