wandercoding.com

It’s been a while since I’ve interviewed for a job.  The last time was when I was working at Lockheed and wanted to find something closer to home.  I went to a small, local software developer and two guys put me through the ringer with test questions.  At the end of a day of work, I was tired, uninspiring, not very sharp, and I didn’t get the job.  Some things are just as well, I suppose.  You won’t get every job you interview for because you’re not right for every job.  I probably wasn’t right for that job anyway.

In my 24 years of software development, I’ve given and received numerous types of interviews.  From grueling take home tests, on the spot tests, mind puzzles, behavioral interviewing, mindless “what did you do at your last job” questions, “what’s your greatest weakness”, etc.  In my experience, they all suck.  Interviewing just plain sucks.  I participated in the hiring of my new manager many years ago.  We put several guys through a two day process, finally chose one, and he still was clueless.  The fact is: interviewing is a crap-shoot.

Your best bet with interviewing is to try a combination of things.  If it’s for a programmer, then you have them do some programming.  They can do it at home or on paper during the interview, but it should be something that’s not a trick problem.  The purpose of something like this should simply be to make sure that this person can actually write some code.  Have them design a simple class to do a simple job (some people can code a procedure, but class design is beyond them).

Skip the mind game problems.  They’re dumb and all they prove is that they can either remember the answer or can figure out a mind game problem.  What color is a newborn African-American baby’s teeth?  Really?  The answer isn’t white.  It’s nothing – babies don’t have teeth when they’re born.

Your job when you’re interviewing someone is to find out if they can work with you and do the work.  Yes, make them do some coding.  Show them your code and ask them about it.  You might try some pair-programming with them.  Give them a demo of your product and see what their reaction/questions/comments about it are.  Are they engaged?  Interested?  Do they have a clue about your domain?  Can they understand what you’re talking about?

Talk about their previous work.  Find out what they’ve worked on – in detail.  What pieces of a product did they actually code?  In what language?  With what tools?

Finally, remember this is a two-way street.  Don’t treat your interviewee like a child.  You want them to want to work with you at your company.  I’ve been on many interviews where companies treat you like they’re the last hope you have of finding work, rather than courting you, and I’ve turned down jobs because of it.  Who wants to work for people who seem like they enjoy putting you through a ringer?

I chose the title Managing Coach to point out the difference between this type of management and Managing First Class.  You might argue that it’s a horrible analogy, but let’s see where it goes.

I’ve had the pleasure of working with and for some wonderful managers, and conversely the pain and misery of working for bad ones.  A First Class manager sits separately from the rest of the crew (they’re all in cattle class, packed into cubicles, after all).  They hobnob with upper management and periodically make announcements during staff meetings about the status of the flight (or product release).  Then they go back to First Class, have another drink, and work on a presentation or other high-level document.  They have little knowledge of the daily activities of the developers and sometimes have little knowledge of the technology either.

The First Class manager, on the other hand, knows a lot about what’s going on in the rest of the company – the role their project plays, deadlines that others are facing, and their relationships to the ones his group is facing.  He’s able to stay on the radar of other company managers and his superiors.  Because of this, he’s able to hear about projects that his group might participate in, or that may affect the future of his group.

A Coach manager (there’s a double meaning to ‘Coach’) has more interaction with the passengers (developers).  He (or she) takes an active role in the day to day activities, providing guidance and inspiration.  He knows what people are working on, what’s moving and what’s not moving, and why.  If a developer is stuck, he knows enough to ask some pertinent questions and make a suggestion or two that might get the developer unstuck or walk away himself with a task to remove an obstacle.

Regardless of where a manager sits, it’s his activities that matter.  Some managers concentrate only on one aspect or another.  The best managers do both.  Just because a manager doesn’t have extensive knowledge of technology doesn’t make him useless in being a Coach.  There have been times in my career where my manager could have steered me in the right direction with a very non-technical conversation, if he had taken the time.  I can also remember numerous times when I was a manager, when developers would knock on my door, describe a problem in detail until my mind and eyes glazed over, then have an inspiration, thank me for listening, and leave with a solution in hand.  What role did I play?  Just a sympathetic ear.

You might gather from my last example that availability is a good trait to have.  If your manager is in meetings all the time, they’re probably a First Class manager (this is not a rule, by any means).  To be an effective development manager, being available to your developers and seeking them out for informal updates can make for a less intimidating and more informative and productive relationship.

If you’re a manager, think about what you can do to enhance both aspects of your management skills.  If you’re a developer, show this article to your manager to give him some food for thought.  Even managers need a coach.

I can only think of one reason that the CEOs of companies don’t outsource their most expensive people.  They is them.

I’m going to make some sweeping generalizations and estimations here, so bear with me.  I’m going to stick with larger software companies because they are more likely to open overseas offices or outsource jobs.  Larger software companies tend to have higher paid CEOs and also higher pay for their software engineers.  Let’s do the math.  Average CEO pay: $10million in money and stock options.  Average software engineer pay: $70,000 to $100,000 in money and stock options.  Ratio: at least 100 to 1.

If you believe my estimates are out of whack, that’s ok.  Let’s assume that the ratio is closer to 25:1 or 50:1.  When one accounts for the entire executive staff – you know all the VPs of this, that and the other – you can add another 10 people or so whose ratios are 5:1 or 10:1 versus the average worker.  You can also add the board members, who tend to be CEOs of other companies.  They can make $100,000 for attending a dozen meetings a year.  Sometimes they get stock options, too.

It seems clear to me that a large company could very effectively save 80% of their executive compensation by moving those jobs to qualified people in India or China.  Clearly if the engineers there are capable of writing our software, they should be smart enough to run the company as well.

I’m obviously not a fan of massive outsourcing or excessive executive compensation.  I don’t believe that either of them accomplish what they’re cracked up to achieve.  I’ve seen outsourcing fail miserably due to communication problems, over-promising results, and even cultural hesitation to say, “No, we can’t do that.”  I also don’t understand how executives justify outrageous pay, bonuses, and golden parachutes, even when they don’t perform.

There’s a happy medium somewhere, but it seems to be getting lost.  The next time your CEO suggests that outsourcing will save your company tons of money, maybe you can find an anonymous way of suggesting that the CEO could outsource their own job to save even more.

I try not to lump people into buckets.  I like to think I’m open-minded enough to consider various points of view.  One thing, however, that really makes me mad is fear-mongering.  When W was running for his second term, the Republican supporters ran TV commercials warning us all that the U.S. could be headed for disasterous terrorist attacks if we voted for a Democrat who would most certainly be “soft” on terror.  More recently, there are ads urging me to call my Congressman and tell him that he should vote no on the health care plan.  The ads are full of fear-inducing messages about rationing, skyrocketing costs (aren’t they already?), etc.  Two of the messages talk about two different Congressmen, each of whom is the deciding vote.  Well, which one is it?

Politicians do it, marketing people do it, and salesmen do it.  “You don’t want the extended super warranty?  It protects your computer for 20 years and covers damage, even if you drop it in the toilet.”  Now, stories of people dropping their cell phones in the toilet are widespread, but your computer won’t fit in the toilet.

Too many decisions are based on fear.  Some decisions are valid to make on this basis.  Do you walk down the street in a neighborhood that’s known for trouble?  Do you leave your car unlocked when you know that there are people around who regularly steal cars?  Do you go skydiving without being absolutely anal about checking everything that come into play?  Of course, not.  However, most of the ads on TV and salesmen trying to sell you something are betting that you won’t do the research.  You won’t bother to find out the truth.

We all make decisions about things on the spur of the moment, often based on the fear induced by the situation or persuader at hand.  However, when you take some time to think it over in the absence of the pressure, you often come up with a clearer view of the situation.

People who resort to this are manipulating you and nothing makes me angrier than being manipulated.  When you can, take the time.  Do the research.  Make up your own mind.  Punish the fear-mongers.

Marketing people tend to get a bad rap, especially in software.  Just read a few Dilbert comics about the soulless folks in marketing and you’ll get a gist of their status.  I’m not suggesting that it’s entirely undeserved either, but not all marketing folks are dishonest, horrible people.  On the contrary, I’ve worked with many bright, knowledgeable folks who made a big impact on the company I was working for.

This post will deal mostly with an overview.  There are generally two kinds of marketing: inbound and outbound.  Inbound is the art of determining customer needs and producing products to meet those needs (i.e. taking in information).  Outbound is taking the products that you have and presenting them to the customers in the form of websites, webinars, presentations, brochures, advertising, trial software, etc. (i.e. sending out information).

Ideally, you’ll have folks at your company that are concerned with both inbound and outbound marketing.  Good inbound marketing is key to producing the products that customers will actually buy.  It should involve conversations with customers, and involve them in the testing of your software in alpha and beta stages of development.  I’ve always been leery of know-it-all people who come into the company and try to turn the place upside-down without any experience in the domain of the products (i.e. they’ve got 10 years of marketing experience, but they don’t know anything about building construction or software that supports it, for example).  That’s not to say that you shouldn’t hire someone not familiar with your domain, but you should expect them to, and encourage them to learn about it.  In the absence of this, your products can easily be led down a path of uselessness in the field.  It’s seriously hard to listen to folks who’ll pontificate on the direction your software should take when they haven’t a clue how it’s really used.  Expecting that your software will create a complete shift in how your customers will do business is a recipe for disaster.  Most companies are like slow-moving barges.  Having them move quickly because you’ve changed entire processes will likely result in a loss of sales.  When in doubt, ask several customers.

Good outbound marketing is essential to support sales and must be done at the appropriate level for your software and customers.  For example, if you write highly specialized software that costs thousands of dollars per license and will likely sell only a few copies per year, buying a Super Bowl ad is probably not a good use of your advertising budget.  Of course, the biggest bang for your buck is quality website.  When your customers find you, you save time and money.  Ensure that your site is clean and makes it easy to find out the information a user will want to know.  If possible, allow them to download a trial, preferably fully functioning.  After that, the marketing folks will have to figure out what to spend their money on to best increase awareness of your product and attract customers.  In my experience, huge booths at huge conferences are not cost effective if your software is high cost and long sales time.  For lower cost, easy to justify sales, it might work better.

This column isn’t the place to do a complete breakdown on marketing.  Besides, I’m a software guy and you probably are, too.  The point is to arm you will a little knowledge about what your marketing folks are supposed to be doing.  If they’re not, maybe you can nudge them in the right direction.  It can be hard to see the big picture when you’re in the middle of a detailed project.  Asking questions about what’s going on can lead everyone to think harder about the big picture and where the focus of effort should be.

Don’t forget to buy Design, Code, Test, Repeat.  It’s a fun, funny, and helpful read.

Recently, I’ve gotten to the point in my release cycle where I’m almost ready for Beta(!) on my IDE for uCLinux uboot, kernel, and application development, Fusion MMX.  Building it has been a lot of fun and very educational as well.  I’ve been able to find so many useful open-source utilities to make development easier.

Of course, that means that some documentation is in order.  I’ve written plenty of documentation in the past, most recently for GTO, a Java application.  For that product, I chose to use JavaHelp, which wasn’t difficult to learn or use, but it was a rather manual process of taking screen shots, trimming them, labeling them, etc.  I couldn’t find a free (we’re a small company, so we like free) environment for creating this and I didn’t want to have to go through the manual process with all of the menus, dialogs, toolbars, and context menus for Fusion.  I also didn’t want to have to learn the ins and outs of Microsoft’s help compiler environment if I didn’t have to.  I just wanted to write the documentation, if possible, and let someone else take care of the busywork.

While I couldn’t find something free, I did find the next best thing: something that was so good and so inexpensive that it paid for itself – Dr. Explain.  What I found there was an application that was simple to use, handled the details of the help environment, and made documentation incredibly easy.  The one feature that literally paid for itself was the UI capture tool.  Start the tool, then focus on a UI element (window, menu, toolbar, dialog) and click.  Dr. Explain takes a screen shot of the element, then labels the individual items to be documented.  Holy cow, what an easy way to do documentation.  The creation of internal and external hyperlinks made cross-referencing a breeze.

Finally, I can export it to html, chm, or rtf for maximum flexibility.  For my next revision of GTO (the java-based application), I’ll be trying to use Dr. Explain for that documentation, too.  I don’t usually write product reviews, but when I run across something that I like this much, I want to share it with my fellow developers.

There’s nothing like eating your own cooking to tell you how the food is.  Unfortunately, the pride we get from doing it ourselves can sometimes cloud our judgment.  The same thing applies to just about any other human endeavor.  People often have an inflated opinion of themselves and what they have or can accomplish (I’m no exception).  If you need any proof, just watch the first few weeks of American Idol.

Those of us in the software business tend to think that our own software is way better than anyone else’s.  Of course it is – you wrote it yourself, didn’t you?  Unfortunately, your competitors are filled with people just like you.  They’re probably just as smart as you and have the same pride in their work and their resultant software.  No one is beyond this kind of thinking – not even Joel Spolsky.  He wrote this a few months ago:

I had to wonder. We do have a large competitor in our market that appears to be growing a lot faster than we are. The company is closing big deals with big, enterprise customers. And the wheels are falling off the donkey cart over there as the company stretches to fulfill its obligations. Meanwhile, our product is miles better, and we’re a well-run company, but it doesn’t seem to matter. Why?
…
Step One, I think, is to pluck off our biggest competitors. We’re pretty certain that we’ve already built a great product that meets our customers’ needs — but there are still too many cases where we find out that, for some reason, someone went with the other guy. So that’s the development team’s mission for 2010: to eliminate any possible reason that customers might buy our competitors’ junk, just because there is some dinky little feature that they told themselves they absolutely couldn’t live without. I don’t think this is going to be very hard, frankly. Developing great software is something I’m pretty sure we’re good at.

Those are strong words. “Competitor’s junk”?  That’s a very common way of looking at your competition and it clouds your judgment because it’s usually wrong.  “Pluck off our biggest competitors”? If that’s so easy, why hasn’t it happened already?  I love Joel’s blog and admire his goals for his company, but there’s a lot going on and going wrong here.

The responses to his article were interesting. One in particular shows how personal our feelings are about our own software:

JIRA [a competitive product to Joel's Fogbugz] is a great product. I last used Fogbugz in June 2008, and then moved to a company using JIRA. It’s a real pleasure to use, which is good, because I use it for hours every day. Fogbugz was not a pleasure to use. Maybe Fogbugz is way better now, but if I were in a position to choose for another company, I’m pretty sure it would be JIRA all the way.

So, how do you get past this? One option is to eat your own cooking and the cooking of others. Get a copy of your competitor’s software. Dive into it and really examine its strengths and weaknesses. Find out what their customers like about it. Find out why they didn’t buy yours. Your sales and marketing staff is supposed to do this at your company.

On a more personal level, what can you do to improve your software? Use it yourself. If you can get a copy of your competitors, use it as well. What takes less time to get similar tasks done. How easy is it to do the job? What bugs do you find? Are there dead ends? Are there features missing? Does it take multiple steps to get a simple job done? Is there a method that’s counterintuitive or that requires users to change their way to doing business (this is big roadblock for some people)?

As a solo developer, I have the benefit of being the product designer as well as the coder. If I don’t find something easy to do in my products, I change it. If I can’t do something in the product, I add a new feature. If I run across a bug, I fix it. Note: when you run across a bug in your software, make sure that you either fix it or enter it in the bug database. It’s too easy to ignore bugs you live with every day because we developers are more tolerant of our own bugs – don’t be.  And don’t assume because you and everyone else lives with the bug that it’s in the database unless you check.

Finally, try to be objective. Stop pretending you love your own software so much and pretend you’re an end-user working with it for the first time. Then you’ll get an idea of why it’s so good or why it needs improvement.

Gads, I’ve been writing software for a long time.  I started my professional career in 1986, writing LISP on Symbolics machines.  Back then, there was no web (well, not as we know it today) on which you could look up easy answers to coding problems, share toolkits, or converse with other developers (well, there was usenet, but it wasn’t the same world as it is today).

Today, we have a virtual community of developers.  While our companies may compete, it wouldn’t be unusual for two developers to accidentally help each other by responding to messages on a help board such as Stack Overflow.

Recently I posted a question there that I knew would elicit responses such as, “Why are you trying to do that?”  I know what I’m trying to do might be loony, but it seemed to make sense at the time.  Working alone at home, I don’t have the same personal networking with my colleagues that I used to have at previous jobs.  Sometimes I miss the interpersonal relationships, the banter, and the ability to bounce a nutty idea off another developer.  Instead, I do web searches and ask questions on forums.  At times, it can even be a little embarrassing to ask a question on a forum, but the fact is, everyone’s in pretty much the same boat.  Most developers are just like you and me – nice people, willing to help or give you and hand, and expect the same in return.

It’s a community of software developers, who write toolkits, utilities, sample code, and free applications that help us all get our work done.  I don’t know if Richard Stallman is right about all software being free, but I do know that with the free exchange of ideas we all write better software.  A big thanks to my fellow developers around the world.

The time of year has rolled around once more where gift-giving is the order of the day.  Sure, this is a shameless plug (have I ever claimed to be shameful?), but I can’t think of a better gift for your friend, spouse, colleague, or manager than my book – Design, Code, Test, Repeat.  It’s probably the funniest book about software you’ll read, but it’s also informative.  I introduce you to my friends’ and my best and worst experiences in over 20 years of software development and management.

Here’s just a sampling of the topics in the book:

• Interviewing – How to suck and how not to suck at it.  In these times of job-hunting and layoffs, avoiding mistakes and steering interviews are invaluable skills.
• Handling yourself professionally on the job and dealing with process, projects, and people.
• Best practices for your projects.
• Best practices for your career.

Not only is there a wealth of information, but to keep things fun, it’s filled with small cartoons and drawings.  For your perusal, I’m including another small excerpt.  Here’s a story about a friend, Bob, who was interviewing a guy for a software position.

The Philosopher

Bob was interviewing people for a position on his team and found a guy named Ivan who was about to graduate with a Ph.D. in computer science from a nearby university. In the past, they had had some very good luck hiring smart people who were lacking in some software experience and teaching them how to write software. If you have an engineering background, you’ve probably done a bit of programming in school anyway and the problem-solving skills are useful in both fields. This guy even had a background in computer science, so while his practical experience seemed to be lacking, he seemed promising.

They had Ivan come in for a half day of interviewing. He was polite and likeable, but clearly lacking in experience – pretty much what we expected. The problem was that for a guy who had very little practical experience, he had a philosophy about everything. He’d say things like, “My philosophy on starting a new coding project is to sit down and do some rough design work before starting a prototype.” It sounds reasonable enough doesn’t it? But since he’d never had a real job, it was a bit questionable. Additionally, his answers to most of the other questions were just vague philosophies as well. Now this guy had been a teaching assistant for a Java class, so he should have been able to come out with something concrete based on his work on a Ph.D. in computer science, right?

Unfortunately, they didn’t do a great job that day of really testing his Java coding skills. Instead, even though they had doubts, they hired him under the assumption that like our other people fresh from school that the equations:

Education = Brain

Brain + Mentoring = Future Valuable and Productive Employee

would hold true. It didn’t. The guy couldn’t code his way out of a paper bag. They tried to get his feet wet by having him check some code out of our source code repository, copy and paste some changes into the files, compile and test them, then check them back in. Believe it or not, he needed help with the copying and pasting part. Not how to use copy and paste tools, but finding the same code in the other files and putting the right code in there. After giving him several mentors, having him audit another Java course, and giving him 9 months (much too generous) to get up to speed, they had to give up and let him go. He went back into academia and is a Professor somewhere now. He was indeed a smart guy, but just wasn’t made for the kind of work they were doing.

In the end, if you have doubts, you’re better off passing on a candidate or perhaps having a short trial period, if that’s possible, to truly assess whether you have a winner on your hands. Better yet, try some of the suggestions below to remove the doubts and clarify the candidate’s true potential.

Have a great holiday.

Don’t forget to buy Design, Code, Test, Repeat.  It’s a fun, funny, and helpful read.

Some authors are releasing books based on blog entries.  Well, I’m going to go the other way around.  I’m going to publish a few blog entries based on my book,  Design, Code, Test, Repeat.  Here are a couple of sections from Chapter 15:  It Doesn’t Get Any Better Than This – Best Practices.

Dominance and Submission
One of the things a couple of companies did was to use sub-mission documents. When you checked in your code, you filled in a simple form with information about what the code was for, what files and versions were involved, and what bugs you (may have) fixed. This document was checked into the source control system and emailed to your colleagues. Although writing these was somewhat tedious, they were very helpful in seeing what files went together as a bug fix or new code submission. If the build broke or a new bug crept into the system, you might be able to spot what happened by reading through some of these documents. They were also very helpful in tracking who was doing what. Several people would read these after returning from vacation to see what had been going on while they were away. Another benefit was that simply reviewing your sub-mission documents for the week made it easy to write your weekly status report.
These documents were referenced in the bug tracking database and the comments for the files that were checked in. This allowed for easy cross-referencing. If you knew the bug, the file(s), or the submission document, you could trace any desired information from there.

Put Down the Keyboard and Step Away From the Code!
As your release date gets closer, you’ll likely be pushing to fix all of the bugs in the system. If you’re not using a bug tracking system – and you should be – then you’ll probably be using a common spreadsheet or some other method. All of the bugs in your system should be rated according to their severity and desirability to be fixed before release.
It’s unfortunate, but your software is probably going to ship with some known bugs in it, simply because it needs to get out the door on time. However, just because you have a bug doesn’t mean it should be fixed. First of all, bug fixing time shouldn’t just be a free-for-all. Developers are more likely to spend time fixing the “low-hanging fruit.” These are the easy bugs to fix or the ones in the developer’s own code that they find most embarrassing. You may wish to let them have some time to do that, but then you should really concentrate on the most important bugs – the ones that crash the system and block functionality from working. Towards the very end of the release, only specific bugs should even be permitted to have fixes. This will prevent the “fix one bug, create two more” syndrome from keeping your release from shipping.
Managing this time well gives you the opportunity to truly control the quality of the software you send out and when it gets sent.