September 4, 2002 Spout

Attracting and Keeping Good Folks

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.

September 2, 2002

Web Services Plumbing Work Nearly Completed

At a recent talk at XML Web Services One, Don says that a lot of the plumbing work is winding down and that applications are about to take center stage as they have the basic bits they need to really work well. Of course, he says that we still have a couple more years of plumbing work to "finish up", but Don's a long thinker. : )
September 2, 2002 .NET

ASP.NET View State Decoder

"Have you ever wondered what was *really* stored in the view state of your .aspx pages? Well, now you can find out with the free view state decoder utility [1]. Just type in the URL of the page whose view state you would like to decode, and view the contents of the view state through a tree-view, as raw text, or as parsed XML. You can also copy and paste the view state string by hand to decode it. For a screenshot of this utility in action, check out: http://staff.develop.com/onion/images/decoderscreenshot.gif" I've used this and loved it. It works a treat!
August 30, 2002

A Roadmap to the Recently Released Windows APIs

"There is a common belief among programmers--particularly those disinclined to believe the truth of anything coming out of Redmond--that Windows is full of ‘secret functions.’ These functions, so the story goes, are used by Microsoft to prevent independent reimplementation of its operating system and to give its own applications programmers an extra advantage. With the August 2002 release of its Platform SDK, Microsoft is complying with the terms of the consent decree it signed with the Department of Justice in November 2001. ... If you are one of the people who harbor suspicions against Microsoft, then you're not likely to be convinced that the recent release has changed anything. For a lot of the rest of us, including shell integration programmers, cryptographers and the terminally curious, the new information is fascinating and potentially useful, although not always as complete as we'd like."
August 30, 2002 .NET

Day w/ .NET: Join us on IRC undernet channel #c#

Download mIRC, connect to a "Random US/EN Undernet Server" and join the "#c#" channel (it may not be listed).
August 30, 2002

Practical VoIP Using VOCAL

From Razvan Caciula: Voice over IP in a free phone system, free source code. You can make calls now! :) It is not just theory. Good book!
August 30, 2002 Spout

Development for Developers

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.

August 29, 2002 .NET

free .NET development environment

From Hussein: As a Java developer, I was curious about the release of C#. Unfortunately, the list price of more than $1,000 for Microsoft’s developer environment, Visual Studio .NET, extinguished the appeal. I wanted to play with the language, but I couldn’t afford the investment. Thankfully, I discovered a free .NET development environment called SharpDevelop.

← Newer Entries Older Entries →