Rules

We all know the adage about rules: they are made to be broken.  Rules exist to keep behavior consistent.  I don’t mind most rules when they make sense.  It would probably be frustrating if every time you called a company to ask about something, you got a different answer depending on the whims and moods of the managers or workers there.

However, rules are one thing and guidelines are another.  Recently, I’ve been calling a few companies trying to use some gift certificates.  The response has been varied.  The first company was fantastic.  I swear that everyone who works there must be taking happy-friendly pills because they have been a joy to work with.  Company #2 had more rules, but the worker bee that I spoke with decided to go the extra mile and checked with the executive management who were feeling benevolent that day.  Company #3 was a bunch of automatons.  They had similar rules to Company #2, but weren’t willing to go the extra mile.  Directly communicating with management yielded the same rule-bound thinking.  They were putting good will on the back burner.

Offering superior customer service is one thing that keeps people returning to your company.  I remember one particular CAD software company that had a superior product to everything on the market at the time.  Their salesforce, however, was arrogant and hated by their customers.  They lost the opportunity to grow because their customers didn’t want to deal with them.  In my book, Design, Code, Test, Repeat, I tell the story of another company that wanted so much money for their product that one of their customers decided to simply start their own company to compete.

In the software field, customer service, especially for smaller companies is vital.  The problem is that it can suck up vast resources before you know it.  Having your developers answer customer questions will get customers the answers that they need, but has a real drain on development productivity.  In addition, once a customer gets the direct line to a developer who was able to help, they will almost always call that developer back directly the next time they have a question.  This makes customers very happy in the short term – they get their answer.  What they don’t see is that in the long term, they may be helping that same developer work significant overtime to catch up to a schedule or slip the schedule – bad for the customer in the long term.

To help with these issues, establish fair, but flexible rules for dealing with customers.  How much does it hurt to extend a trial license for another week, for example.  Isolate your developers from direct contact, if this becomes an issue by using online forums, or by having customers call a helpline number.  Having a customer liaison, if you can afford one, will eventually make the liaison very knowledgeable (he or she will have to get the answers), but he will then be able to share the information with all customers who have the same problem (and chances are, more than one person will hit the same problem).  A liaison will also provide a more consistent experience for all of your customers – some developers should definitely not be talking to customers directly.

Keep your customers happy and you give your company a shot at repeat business and future or continued prosperity.  It only takes one bad experience to make your customers hate you and look for another place to do business.

Is It Time To Go?

Not every day is going to be a good one, but not every day should be a bad one either.  Some days it seems like you get up and follow the same routine, almost mindlessly.  You get to work, your boss is an as***le, your work is boring, blah blah blah.  A steady paycheck is good, but you can’t wait for the weekend to come.  You spend half the weekend de-stressing from the week and worrying about going back to work.  It sounds like an advertisement for an anti-depressant, doesn’t it?  All you need is a hound dog to stare at you and the picture is complete.

I’ll be the first one to tell you that the grass is not always greener.  Sometimes, it’s just a different kind of grass.  Sometimes, it’s AstroTurf.  It’s natural, however for a relationship with your company to run its course.  You’ve developed the same kind of code and done the same thing over and you need a change.

Remember, it’s easier to look for a job when you already have one.  Why?  Well, first, you’re less desperate to jump at the first opportunity.  Second, you’re clearly employable.

Life’s too short to be miserable for a long period.  Now, what’s a long period varies from person to person.  Even so, if you’ve been miserable for more than a year, it’s probably time to at least start putting your toes in the water to look for something different.  You may want to switch domains, learn new skills, switch to management or QA.  You might think that your company is looking out for you, but rest assured, unless you’re a part owner, the company is looking out for itself.  If profits are down or the stock price is down, the CEO is going to be looking to boost both, because his or her income is usually based on stock options.  When the price is down, so is the income.  If your company is looking to downsize, or already has, you can never feel safe.  Even if you’re the best coder in your group, who’s to say that the whole group isn’t going to get chopped.

It never hurts to have your resume up to date.  Keeping it fresh and current takes time, so don’t hesitate to get started today.  If you’re looking around, look for somebody who’s hiring.  Sure that sounds like a “duh” thing to say, but they may not advertise jobs in your field.  However, if they’re looking to expand in any area, then they’re thinking about the future.  Richard Bolles (author of What Color is Your Parachute) recommends that you find a company you want to work for, find the proper managers (start calling your network of friends and colleagues to get the names), and give them a quick call.  Even a friendly conversation if they’re not hiring right now can pay off later when they are hiring and remember you.

I don’t think it’s unhealthy to say “Is it time?” now and then.  If the answer is an absolute “no, I love my job”, that’s okay.  If the answer is “maybe”, well then maybe it’s time for a little exploring.  Keep your eyes open, sign up for some automated job board emails, talk to your friends and have them tell you when they run across another software engineer.  Build your network.  And good luck.

Application Programming Insanity

At a previous company, I had the pleasure of managing a couple of development groups and projects. One group consisted of four people, the other had one. My group of four was tasked with creating a printer driver, which had no API, while the group of one (is that really a group?) was writing a toolkit with an API used by many customers to create and read a very important company file format I’ll call DDT (not its real name).

DDT had been around for several years and its scope and responsibilities had grown substantially over the years. For example, while it began as a way to simply record a graphical record of one drawing, it was now being expanded to multiple drawings and meta-data about those drawings. This resulted in a significantly large amount of new code and a completely new interaction model for dealing with the new complexities.

Things didn’t start out too well in my new role. The toolkit was supposed be released in a couple of weeks. My programmer, Bob, felt that shipping a huge XML parser with his tiny toolkit wasn’t a very good idea, so he looked for an alternative. Bob was allegedly a good programmer, but was a master in his own mind. He tried his hand at writing a simple XML writer and parser, and created it in two days of solid coding. At this point, I was not reading any of his code because I didn’t understand a thing about the toolkit yet and this was not common practice at the company either. There were no performance measurements set up for the toolkit, so there was no measurement of the new XML code either. A year later, one of my other programmers investigated why the toolkit was so slow at large files and found that it was reading the XML one character at a time. Unfortunately, for 1Mb files, this is a significant chunk of time.

Meanwhile, I asked Bob if I could see the User’s Guide so I could figure out how to use the toolkit. Did I mention there was no QA on the project either? Well, there was no User’s Guide, so I decided I would write one (no documentation person either). This way I could learn to use the toolkit and give new users a shot at getting started with a clue as well. I got some sample code from Bob and began to look over the code to read a file. I asked him if he was going to create an API for users to make it easier to read the files and he sounded confused. It turns out that I was looking at the API. You know how some people who grow up driving automatic transmissions finally climb into your car with a manual transmission and say, “Wow, that’s complicated. You have to do that yourself?” This was ten times worse. Years later one of my colleagues using the same toolkit said, “It’s not really an API if you’d have an easier time just writing the code yourself.

Keeping that thought in mind, here are some basic rules for API development.

  1. If you can provide the information for the user, don’t make the user provide it to you. For example, you had to set up a time structure for the toolkit to tell you what time the file was created. This had to be done even if you didn’t care what time the file was created. Instead, provide a function or method for the user to retrieve the time.
  2. If every user needs to perform the same set of setup steps, try to condense the steps into one, especially if the user doesn’t get any information from the API during these steps. Also, see rule #1.
  3. Organize your API. If it’s a bunch of classes, use solid class designs to keep jobs related to each other. If it’s a set of functions, organize them according to jobs in your documentation – an alphabetical list may be handy for reference later, but organizing by job category will help your users learn to use the toolkit.
  4. Document it. If I’ve learned one thing over the years it’s that writing some documentation makes you think about your code. If you start explaining and get stuck describing why something has to be done before something, why it needs certain information, or can’t figure out why you’re just not doing for the user, then you have a shot at making the API simpler.
  5. Provide sample code. Like writing documentation, providing trivial and non-trivial examples are the way that most users will start their own code. They will likely start by copying your code and modifying it from there. Now, picture a thousand users doing the same thing. Are they all copying this code wondering what each line does (and understanding why they’re doing it) or is it just a blur of setup garbage that users are providing to make your toolkit happy?
  6. Idiot proof it. If you don’t think users will try passing NULL, or null, or nil, or 0 (zero) to your API because they don’t know how to get a handle to the frisbit of grommet of the window, they certainly will. Check all input data and provide useful feedback on it (or better still see rule #1 and don’t ask the user if it’s really not necessary.)

Nothing makes an API better than trying to explain it and use it. Have your colleagues or your most critical users look at it before you release it. Then, take their feedback to heart. You may save yourself dozens of support calls and hundreds of users from fleeing to someone else’s product whose API, toolkit, or product that they can understand.

Learning Vicariously

There are two (well maybe more) basic kinds of learning – what you experience yourself and what you learn through the experiences of others.  Let’s call the latter: learning vicariously.  We regularly try to do both of these kinds of learning in everyday life.  When we’re reading a how-to book, we’re learning from the experience of others.  When we try something ourselves, we’re learning first-hand.

Learning first-hand has it’s pros and cons.  If you do something wrong and learn from the experience how to do better next time or not make the same mistake again, then it did you some good.  If  you make a mistake, then repeat it, well, then the experience isn’t helping you much.  Successes and failures of this kind can be of incredible value if you take the time to evaluate the experience.  If you don’t bother to think about why something went wrong or right, then your future performance will likely be unaffected by the past, making the experience useless.  In my book, Design, Code, Test, Repeat, I tell several stories about Bob’s,  a friend, interviewing travails.  For a while, Bob went to numerous interviews and found a way to blow each one.  Finally, after some evaluation of his performance, he learned from his failures and made improvements.

Vicarious learning has similar pros and cons.  If you read about someone else’s experience, but don’t find a way to relate them to your own, then you’ve failed to learn from it.  This is why we still have thousands of drunk driving deaths every year – we fail to learn from the horrible experiences of others.  However, if you take the time to examine the stories and look at your own behavior, then your future performance can be greatly affected.

The next time you read a story, ask yourself how it relates to your own life and see what you might do better if you follow the same path, or if there is something you could avoid if you don’t repeat the same mistake.

Bleep Bleep

Although I have been unable to locate it, I remember an old Doonesbury cartoon that went something like this: Mike had a friend, Roger, visiting from MIT and was introducing him to B.D. or someone else.  When Roger spoke, all that came out was, “Bleep Bleep.”  I must admit that working around techies all day that’s what some people sound like and I’m sure that I’m no different at times.  I remember a few times when someone would come over to my desk and tell me about something they were working on in terms that were unfamiliar to me.  I would simply respond with, “Bleep Bleep.”

This came up again a couple of weeks ago at judo practice.  One of my students is a Ph.D. graduating from Cornell.  I told him that I wanted to hear his 30 second elevator description of what his work was about.  We got to talking and I mentioned how it was very important to be able to speak to people with different levels of understanding.  Not everyone in your company will have the same technical background that you do, so the ability to communicate effectively with others at their level is crucial.  You’ll often find that salesmen, marketing people, and even CEOs will use terminology incorrectly.  Additionally, they’ll often have a much less thorough background in the field than you do and yet be responsible for presenting your work to the outside world intelligently.

For example, your CEO may have to speak at a shareholders meeting.  He (or she) will need to relate the latest functionality of your software to people who want to invest in it, but have no idea how to use it.  The CEO will have to explain the technology using analogies or simpler terms that investors and analysts can understand and get excited about.  While you may be excited about the implementation, they’re only interested in the UI and general functionality.

On the other end of the spectrum, your ability to converse with your peers and other colleagues in the trenches is equally important.  You must be able to describe complex functionality in a simple way to your documentation people, who then have to help your end users understand things.  Your peers on the other hand probably will know more of your terminology, so they will be happy to use jargon that can shortcut a conversation to the point.

Knowing your audience and speaking or writing at the correct level can have a great impact on your effectiveness and your image.

Babysitting

I was reading an article on nightmare bosses when my mind started drifting towards days gone by.  I was working for a large software company, but in a small division.  At one point I worked for a couple of tough bosses in a row.  The first was tough, but the second one was incompetent.  As I thought about my own performance and behavior during that time, I remembered my lack of motivation.  Then my thoughts travelled farther back in time to when I was a manager.

At one point, I was the development manager for a product group.  I was managing eleven people and we had successfully worked together to produce one product and were working on a second one.  Being a former developer and peer, I was pretty easy to work with and for.  I understood software development and developers and knew to give them a lot of rope for creativity and self-guidance.  On the other hand, I had two employees in particular who were slowing things down on a very tight schedule.  My feet were being held to the fire and I tried to insulate my developers from the pressure as much as possible.

I should have been a little tougher.  Not a nightmare boss, but a boss.  There are many degrees of management and these can apply differently to the different people that you have responsibility for.  Unfortunately, applying the same style to every developer is a mistake that I’ve come to realize only many years later.  Maybe this advice will help you avoid the same mistake.

There are common and different things that make developers work well.  Common items usually include positive feedback, a feeling of appreciation for their work, comfortable and quiet work environment, freedom to choose work-hours, lack of interruptions, good equipment, etc.  These are generalizations, but most people respond well to the above.  Developers respond differently, however, to the amount of supervision, freedom to choose projects, and tightness of specifications.  For example, some developers work very well when unsupervised and with a very loose set of requirements.  Others perform horribly under the same circumstances.  Others still can be easily distracted or have other things going on in their lives that either distract them or that they choose to work on during work hours.

For people who fall into the latter category, a certain amount of babysitting (pardon the use of the word) is in order.  This can be done respectfully, however, and if you’re good, it can be well disguised.  One developer, I discovered later, simply wasn’t doing much work at work.  He needed closer supervision and to understand the importance of what he was (or more accurately wasn’t) doing.  This should have started with a frank discussion of the nature of the situation:

  • We needed his code.
  • It wasn’t just what he was or wasn’t doing, but what would happen to the group if he wasn’t focused.
  • It wasn’t just his reputation, but mine as well.

Then, I should have worked out a plan to cope with him.

  • Get a good understanding of his areas of responsibility and what others were expecting from his code.
  • Formulate a design of the code and a plan and schedule to complete it.
  • Checking in with him every day, going over a goal for the day and progress made.
  • If there was any doubt, sit with him for an hour or two each day to ensure progress.  This could be done under the guise of wanting to understand this area of the system better.

You may be asking yourself, why there wasn’t already a schedule and a design, and in fact there was.  However, these things change over time and if someone is already off track, then it’s time to evaluate things in detail, even if you simply discover that initial designs are still good.

If you’re the manager of a group, remember that as the manager, it’s your job to see that everyone is doing their job to the best of their ability.  This doesn’t need to be a micromanagement activity, but it may need to be for some of your employees.  The best way to find out what’s going on with every member of your group is to visit with them often.  A bi-weekly one-on-one meeting for half an hour is often insufficient for this.  Stopping at everyone’s desk for five minutes every day to two will help you understand what everyone is up to, what roadblocks they may be facing, and what interconnections you can make between team members, who may be duplicating efforts.  Customizing your management style for each developer is simply providing the same kind of flexibility you like to have over the software that you use.  The equivalent of each developer having their own options menu on how they should be managed.  The end result is a smoother way to work.

Imagery

My family and I have just returned from a college tour of New England.  It was grueling, fun, informative, and alternately boring and thrilling.  It’s amazing how similar each presentation is and yet you can get a feel from each college.  For those of you unfamiliar with the latest methods of college admissions presentations, they usually consist of a tour and an information session.  The order of which one comes first is random and in some places, up to you.

Tours are conducted by students and they take you to a residence hall (you usually see a dorm room), a dining hall, an academic building or two (you’ll see a classroom), the library, and a few other unique features of each college.  It’s amazing, but somehow you get a “feel” for the place on the tour by seeing the place and the students who go there.  Some places seem friendly and open, some stuffy and exclusive.

The greater variety (within a very unvarietal setting) is the information session.  For the larger schools, they are done with a combination of talking by an admissions officer and some Powerpoint slides.  Some have students do some of the talking about their personal experiences and their impressions.  These tended to be more interesting, informative, and useful in getting to know a place.  At the smaller, more exclusive schools, the presentations tended to be drier (with one notable exception).  At one Ivy League school, the admissions officer went on so long about how students would be challenged by other students and forced out of their comfort zone that it scared the crap out of my daughter.  Unfortunately, this school may lose some qualified applicants because some snooty admissions officer wants to make the place sound more intimidating than it probably is.

The whole thing made me thing that the presentations are completely lacking in creativity and any really good way of presenting a college to prospective students.  More to the blog’s topics, it also made me think about ways that I’ve presented myself and companies present themselves to the public.  There are things that large companies and smart individuals do to cultivate an image.  Mac computers are for free spirited, independent people.  All financial institutions are conservative, sensible, and reliable, and they have your best interests at heart.

Small companies – and software companies are often small – often want to present an image of being large and stable.  Web sites for them will be polished and give the impression of dozens or hundreds of people at your service, even if there are only 1 or 2 people in the whole place.

On a personal level, you have the ability to present an image of yourself at work as well.  Are you hard or easy to contact?  Are you difficult or easy to talk to?  Do you respond to requests quickly or do you sit on them for weeks?  If you work with lots of other people, do you dress like a crumpled pile of laundry or at least look neat?  Do you smile or scowl most of the time?

In addition to the code you write, you have the ability to make impressions that are far more important to your growth or survival in a company.  It all depends on the image you want to present and this is within your control.

Truly Customizable User Interfaces

My most recent project is working on a small IDE (integrated development environment) for generating micro-C Linux kernels.  It’s an updated version of Fusion.  One thing in particular that it does is present a UI of choices for configuring the kernel to your hardware.  Specifically, we want the end user to be able to add their own hardware without us needing to do the work and releasing an updated version of the software or a patch to it.  This called for some truly customizable UI.

Since the original software was written in VB, I thought C# would be a good platform for the application.  It would allow me to reuse some of the components, like ScintillaNET, and have equivalent operating system calls and components to the original application.  Also, having a built-in MDI (multiple document interface) framework was an added bonus.

The interesting part has really been the customizable UI.  How can we let the user add their hardware to our configuration dialog?  The answer was simple: use WPF (Windows Presentation Foundation).  If you’re not familiar with WPF, it’s Microsoft’s XML-like, declarative UI language (XAML).  It turns out that this is really easy to load at runtime.  By the way, for help in generating the XAML code, I found Kaxaml very helpful.  Then came the other end of the problem.  How does this same end user modify the C header file that this UI generates to add his own hardware needs?

Well, of course, you’d think about putting information into a user-accessible file that you could load at runtime.  You could parse it for “commands” that would retrieve information from the UI and log the information for output to the header files.  This would generally work fine, but some operations can be a little complicated and I had no desire to build a true lexical parser to handle operations that C# or some other scripting language already had built in.  After a quick search, I found out that C# can compile code at runtime.  Another search took me to Westwind, where I found a nice package built around the numerous commands that C# makes you execute to accomplish the task.  The Westwind code builds a class and takes constructor arguments.  I added a callback class to the arguments, so my end-users can add C# code and calls to my specific class to generate the header files.

I hope this gives you some ideas on how to increase the level of customization in your application or how to add some user-level customization.

Talent vs. Work Ethic

In my life and my career I’ve seen people with enormous talent and people with great work ethic.  Does either one guarantee your success?  Is it better to have one than the other?

My experience tells me that it’s the combination that matters most.  I’ve seen talentless people plug away at things for years.  In my judo club, there are people from numerous backgrounds that come and work.  Some people have innate talent, others don’t.  However, over the years, even those without talent can make some progress and become competent judo players.  I’ve also seen players with great talent that didn’t want to work hard.  Their judo is very good, but they could have been great if they had the dedication to work on it.

Software is a bit different.  If you don’t have any talent, then you’re in trouble.  The thing is, since there are many different kinds of software, there are options for you.  Object-oriented programming not your forte?  Try databases.  Not so good at application programming?  How about web sites?

Years ago, I hired a Ph.D. who specialized in neural networks.  We figured he was smart so we could teach him how to program for our application development work.  It was a disaster.  He didn’t get object-oriented programming, couldn’t read code, couldn’t code at all.  He went back to academia, where I’m sure he’ll be a success.

Even in software, I’ve seen talented people who still got nowhere.  They couldn’t communicate their ideas well or they simply didn’t want to do the grunt work of communicating their brilliant designs to the computer.  Then there were the folks who simply thought that they were brilliant and that their code was beautiful, but that’s a different topic entirely.

Success is a complex formula, but can be summarized for an individual developer as:

talent + work ethic + task suitability= success

This doesn’t take into account any of the other things like communication skills, design skills, etc.  Keep in mind that in the above equation, missing one element can mean that things will be more difficult for you – it may be time to switch something.  Asking your manager or a colleague can help you decide if it’s time to change something or steps to improve something.

Where Leadership Comes From

Where does leadership come from?  What is leadership?

For some people, the answer to these questions is simple.  It obviously comes from above.  In the corporate world, this means from the CEO, vice president, director of marketing, or your direct manager.  Of course, there are many times when leadership from above is lacking or is ambiguous.  The messages aren’t coming or they’re not clear or they’re mixed.

However, there are more subtle types of leadership and there are things that you can do as a non-manager or low-level manager to provide it.  This is one of the themes of my book, Design, Code, Test, Repeat – leadership takes many forms.  I have always strived to play a leader role in my work.  It’s not about standing on a soapbox and screaming about coding standards or design document format.  It’s about keeping an eye on what’s going on in your group and in your company.  It’s about questioning decisions that are made – it doesn’t have to be in a disrespectful way, just asking for clarification when things seem a bit strange to you.  It’s about not just being a sheep and being pushed to the next problem to fix.  It’s about keeping your head up and seeing above the treeline as well as keeping your head down and on the details of your project.

Having someone on your project who has these attributes is extremely valuable as chances are that your manager doesn’t have all of them and doesn’t have the bandwidth to cover all of the bases alone.  Having leaders on the team makes everyone’s job easier.  Shouldn’t that leader be you?