A friend of mine requested an essay on my thoughts of attracting and keeping good employees. I’ve had the privilege of working with some of the best and the brightest over the years and seeing how companies hire and keep them. My take is that companies that attract the best do so with a reputation of excellence. As one example, Google has kick-ass technology, so I’m sure most of you want to work there (I know I do : ). On the other hand, there are plenty of companies that have a reputation for buggy, unusable software that turn us off, all without ever hearing about the salary and benefits package.

If you can attract good folks, you’ll also attract lots of mediocre folks and some not-so-good folks. There are all kinds of ways to screen these folks out. My favorite is to ask them “why?” questions. If they can tell me the name of the operator that appears as a colon between the last paren of a C++ constructor signature declaration and the opening curly place, that’s great. But if they can tell me why C++ has it, and why Java and C# doesn’t, they’re hired. Of course, I let the interview candidate pick their own area of expertise and ask them questions about what they know best to see how deeply they’ve gone in their explorations. The ability to figure out the “why” is a necessary skill for folks that you’re going to trust to take vague requirements and come up with Google-like results in an environment where no two consecutive projects use the same set of technologies (or even similar ones, increasingly).

To select for personality, as well as technology, I like to whip behavior interviewing questions on folks. Instead of sketching a situation for an interviewee, e.g. “how would you deal with conflict in the work place?”, behavioral interview questions ask people to remember real situations they’ve been in and how they reacted, e.g. “Imagine a time when you had conflict in the work place. How did you handle it?” Everyone knows the right way to handle conflict in the work place, but far fewer of them have handled it properly when it actually happened. The idea of behavioral interviewing is that past behavior indicates future behavior, so if you don’t like that your candidate punched his last manager in the nose, that’s something to find out up front.

Once a good person has been hired, keeping them is a matter of paying them what they’re worth, letting them do what they’re good at, helping them get better at what they’re not so good at, making sure you don’t waste their time on stuff that doesn’t matter, showing appreciation for a job well done and otherwise staying the hell out of their way.

Here. "I got an email today from David, who says, 'So, I am looking to see what I can do to develop my skills as a designer. The trouble that I have, is simple. Where does a programmer that is over 40 years old, with a good job, and a good family turn to to learn something like this?'"

I got an email today from David, who says, “So, I am looking to see what I can do to develop my skills as a designer. The trouble that I have, is simple. Where does a programmer that is over 40 years old, with a good job, and a good family turn to to learn something like this?”

David, developing in any career means taking risks, trying new things, making mistakes. Some specific things you can do to improve your developer/designer skills include:

• Examine your goals. Do you want to be a better coder, a better designer, a better tester? What’s better to you? Fewer lines of code? More lines of code? Faster code? More readable code? More documentation of code/design? More thorough designs? More testable code? More unit tests? Set yourself a list of goals and examine it on a regular basis to keep yourself on track.
• Read some books and articles, like Writing Solid Code, and re-write some of your own code using the techniques you’ve read.
• Pick your favorite feature in your favorite application. Design it. Implement it.
• Read and review other peoples code to see what they do, especially in languages and task you’re unfamiliar with to get a different point of view.
• Pick a bug out of the bug database. Find the real cause. Find the implementation mistake that caused it. Find the design mistake that caused it. Change the implementation and/or design to find other similar bugs in your code base. Change the design/implementation to make similar bugs impossible in the future.
• Run a code review to get your peers’ feedback on your code.
• Get together with a group of developers at your job for weekly lunch lectures. Teaching someone is a great way to learn.
• Take the time to really do something “right.” You can’t always do this due to other real-world constraints, but if you never do it, you’re much less likely to get things right in the future.
• Take the time to follow your “fetishes.” I can’t tell you how often I’ve followed up on something that didn’t have anything to do with what I was doing, but I just couldn’t leave it alone, and then it dove-tailed with something else I needed to do almost immediately. Most of this web site is a result of following this advice.
• Attend a conference and ask a lot of questions. Really drill the speakers to make sure you “get it” (especially if it’s me : ).
• Write an article on something and send it around to your peers or put it up on the web. Writing about something is the only thing I can think of that’s better than teaching as a way for you to learn.
• Hang out on the mailing lists and news groups, but only answer questions you don’t know the answers to. Don’t worry about being wrong and thank everyone who shows you when you are.
• Write a hunk of freeware/shareware/open source software and put your software up on the web along with an installer and documentation. Maintain it.
• Find yourself a mentor. Ask lots of questions and get them to review your work. I’ve had a number of mentors of my own over the years (Mike Woodring, Paul Crutcher, Don Box, Tim Ewald, John Robbins) and it’s made a world of difference.

If you’d like some “hands on” guidance to improve your skills as a developer, I’m available as a mentor. I’ve mentored a number of folks over the years and they’ve had some nice things to say about the process. But don’t feel you need me to take advantage of these tips. Take risks, try new things, make mistakes.

As I write this, several thousand emails are being sent to the initial list of SellsBrothers News newsletter subscribers. My motive (to let folks know what was happening on the site without having to visit every day) was pure, but if I would have know how hard it was going to be to set the thing up, I don’t that I would have started.

It began with a simple form on the web site to take people’s email addresses, which were in turn emailed to me and sorted into a Outlook folder. When that reached a couple thousand without yet having sent out a single issue, I figured it was time to put it into a real database. So, which a bit of data cleaning through VS.NET and Excel to get the dates right, I plunked it into an Access that would serve as the repository on my ISP-managed site. That was all fine and dandy but for one problem: I had to send emails using the data from my own machine, not the machine with my live site (and therefore the latest subscriber data). Did I really want to download an Access database from my ISP every time I needed to send a newsletter? It won’t be often, I admit, but that still seems wrong, doesn’t it?

So, I paid the extra $10/month to get SQL Server support on my site and worked with a friend of mine (Paul Crutcher) to build the form to take name, email address and HTML vs. Text settings. Except it’s not just one form. To make sure that folks aren’t subscribing other folks, we send out a confirmation email with an URL in it that updates the database and shows another form indicating whether that worked or not. Then, in case anyone changed their mind, we needed another form to change subscription settings along with another form letting them know that their changes were made. Of course, before we could let them change their settings, we needed to let them log in, which was another form. And, if they forgot their password, they need another form so that they can enter their email address and we can send it to them. Further, if the worst happens and they tire of my musings, they need to be able to unsubscribe themselves.

Not only did Paul build all of these forms, but he built them in two parts, a form part and a control part, so that I could update the form part to have the sellsbrothers.com look ‘n’ feel, while leaving the real logic in the control part untouched (and potentially reusable). All in all, just letting folks manage their newsletter subscriptions was 46 hunks of HTML packaged as .htm, .aspx and .ascx files. 46! I would have downloaded something and integrated it, but I never found anything to do the job (and this is where I get a hundred emails showing me the error of my ways… : ).

Of course, all that user-managed subscription work was to avoid one thing: angry emails. I didn’t want folks who’d forgotten they subscribed many months ago or, worse, folks that were subscribed implicitly from other activities like the DevCon, to find themselves on a list with no way to get off of it except for sending me angry emails. That’s just how insecure I am. : )

So, after a few weeks of Paul and I working on the pages to do the administration for me, I thought that the hard part was over. I was wrong. While I did have an SQL database on my site, it was still nearly empty. There were some folks who were newly subscribed after the new code went live, but all of the folks who’d subscribed before then were stuck in an Access database. “That’s OK,” I thought. “SQL Server and Access were made by the same folks. I’m sure I won’t have any problems moving the data.” That was two weeks ago. It took tons of advice from my database friends (thanks BobB and ShawnW and BrianR!), along with a final push from my brethren on the Off Topic Mailing List to get the data moved to the right place. The good news is that I got to polish my T-SQL skills a bit and I got to play with DTS and the Enterprise Manager (both very nice pieces of software).

But that’s not all. Once I had the subscribers in the database, I then had to send several thousand emails, sorted into folks that want HTML and folks that want Text, keeping track of bad email addresses. This time, I went looking for a commercial product to do the job. I figured that since my inbox was full of spam (SpamNet is my new best friend!), that there must be really great tools for sending emails by the boatload. And again, my friends on the Off Topic mailing list were there to help with a recommendation of the Advanced Direct Remailer. ADR is also a nice piece of software that comes out of the box configured almost right, but not quite and the documentation has to be read very carefully. ADR is an SMTP server that takes mail from your mail client and forwards it to a list of folks based on who you sent it to. For example, you can send it to foo@localhost where “foo” is a mailbox that resolves to a list of email addresses in a text file or you can send it to bar@localhost where “bar” is a mailbox that resolves to a select statement from a database. That all works great, except if you get any of the settings at all wrong, ADR starts acting like a real email server and just tries to send the email to foo@localhost. Well, actually, it can’t be foo@localhost for me, since I’m using Outlook XP, a marvel of software engineering that in it’s infinite wisdom prohibits me from sending an email to a server without a ”.” in it. So, I send an email to foo@127.0.0.1, which ends up in ADR, but the default settings only resolve requests sent to “localhost”, so ADR won’t do the queries. However, it is talking to the built-in SMTP server on my machine (which I need for testing my web site before publishing it), so it looks like it’s doing something, making it even harder to figure out what’s going on, since I’ve never seen what ADR does when it works correctly.

When I finally do get everything right and the emails are queued in ADR properly, I can tell it’s going to take hours of 100% CPU utilization for the newsletter to get out, so I go on to something else. But I can’t stay away for very long, so I’m constantly logging into the machine doing the sending via Terminal Services to check on the progress. With the CPU fully utilized, all the failed TS connections (I have to keep trying!) eventually crash the ADR machine, causing a panic as I reboot. I needed have worried. ADR has kept everything logged and picks up right where it left off before the crash. Truly an amazing piece of software.

Why do I feel like Jerry Pournelle all of a sudden?

Now, as I’m drawing this missive to a close, I’m getting half a dozen emails from subscribers that wish to unsubscribe but can’t because of the peculiarities of the imported data vs. what I tested against. So, the angry emails have started. Here’s a particularly angry one:

Subject: Get me off your spam list

You are too much of a hassle to remove, you lie about where you got my address, I do not trust you at all.

I will prosecute you my every means possible if you do not remove my address from your database.

If I find out you spread my address, I will go after you for that.

Oh, well. I tried…

Yesterday my eight-year-old and I had the following conversation:

John: “Dad, do you know a lot about computers?”
Dad: “I know my share.”

John: “But do you really know a lot?”
Dad: “I know pretty much.”

John: “What buttons to you press to make that come up (pointing to the Start button)?”
Dad: “Ctrl+Esc”

John: “And how to you make it do Run?”
Dad: “Ctrl+Esc+R”

John: “Cool.”

Cool indeed. : )

Do you feel it? I do and I know that a bunch of my friends do. The whole IT industry is in recovery from the crashing lows that can only happen after impossible highs. In recent conversations, I hear terms like “burned out,” “bitter” and “jaded” coming up again and again in our conversations. Since I got into this industry just as it was idling before take off, I have no frame of reference, but I’m guessing that things will level off at a bit better cash flow than right now, but much better morale.

The question is, how long will it take for the energy and excitement to come back? I know that I’m still healing from a three-year stint on my last big project, and even though I have an itch to try something else, I fantasize about trying my hand at another industry. I always figured that the shake-out would make the bottom feeders leave for something else, but now that we seemed to have settled on good, although not great, salaries and benefits and shaky processes at best, how many of the top folks will just bail from something else? I haven’t actually seen anyone I respect leave for greener pastures, so I’ve got my fingers crossed that things will turn around.

I had lunch with a couple of colleagues on the lecture circuit today and after they asked me what I was working on (Genghis, the Web Services DevCon in October, ref-counting for Rotor, a few books, some consulting, etc), they asked where I found the time. Here’s how:

1. I work with a *ton* of very talented folks. The following are just the ones I’m remembering off the top of my head that I’ve been working with lately: Chris Tavares, Brad Wilson, Shawn Van Ness, Jon Flanders, Don Box, Tim Ewald, all the Web Services DevCon speakers and staff, all the Genghis contributors, Tim Tabor, Michael Weinhardt, Microsoft, Dharma Shukla, Brian Harry, Chris Andersen, Mark Boulter, and, of course, all of my former DevelopMentor brethren.
    
2. But most importantly, I don’t attend meetings or request vacations or approve vacations or attend meetings or receive reviews or give reviews or attend meetings (did I already say that?) or do any of the other things that employees have to do. Skipping these activities easily doubles or triples my productivity. Of course, I had to give up the steady paycheck to make it happen and it’s not the life for everyone, but it works for me just fine. : )

Real software engineering has so little to do with actual technology, it’s kinda sad. I’m lucky. I only have to do the technology part. My question is, how do people with full-time jobs find the time to learn the technology?

guest editorial by Don Box, Tue, Jun 25, 2002

Chris, I just read your “Object vs. XML” post on the spout and I’d be pleased if you would allow me to respond with my own personal spoutlet. Here goes:

For much of the 1990′s, I spent a lot of time writing COM code in C++. The combination of C++’s static type system + COM’s dynamic type system was a very powerful combination that I am proud to have been involved with, even though my contributions to COM were from afar as a non-Microsoftie.

In March of 1998, I had the pleasure of working on the initial SOAP protocol with Microsoft and Dave. That experience was a turning point for me, as it forced me to acknowledge type systems that were not part of the classic OO family that I had come to know as the “one true way.”

Unlike COM or Java, XML tends to attract developers of every stripe, each of which has a wildly different sense of esthetics with respect to language design, data vs. processing model, structural vs. nominal typing, functional vs. declarative vs. imperative styles, etc.

Because XML’s raison d’etre is interop, XML needs to be neutral with respect to these choices, otherwise, the barrier to entry becomes too excessive for some communities to participate. The current pushback against XML Schemas is a great example of this effect.

XML Schema imposes a type system over XML Infosets that is very similar to the OO type systems you are familiar with. This makes XML Schemas well-suited for importing directly into Java or C# programs.

Unfortunately, the XML Schema type system has features that don’t make sense if your world doesn’t revolve around named user-defined types (e.g., several script languages, SQL, etc.). For that reason, some members of the XML community has been lobbying for something with a looser type model than XML Schemas. Had the XML Schema working group made it clearer how to do this sort of thing with XML Schemas, I believe the time for adoption would be that much shorter.

Getting back to your original post, I find your characterization of my colleagues and I as “so steeped in the new world that they forget where they came from” a bit misleading.

As an XML guy, I try not to focus too much on where I came from. Rather, I try to bend over backwards to be respectful of where other people came from.

I don’t want the guy writing ML code in Dayton, Ohio to shove his world view down my throat.

I’m trying hard to reciprocate by keeping my OO/C++/COM sensibilities in perspective.

XML is about inclusion.

It’s the ultimate Rorschach test.

We all make it into what we need it to be.

That’s the “secret sauce” that makes XML what it is.