wandercoding.com

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.

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.

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.

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 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?

I worked for nine years at a major software company specializing in computer aided design software.  During my tenure there, I worked on three major software products which were sold to end users.  The first one, a diagramming products was priced at $199 (or was it $299) and was competitive, both in functionality and price with our competitors.  Sales were ramping up slowly when our competitor was bought by another huge and pervasive company.  This made our product’s future very bleak and it was dropped soon after.

Our next product was an architectural product.  Our competitors charged $500 for a very cool and fairly functional application.  When we finally came out with our first release, it went to the company’s pricing committee, which decided that we should charge $900 (our marketing guy had recommended $500).  It was a cool product and some functionality was better, some not as good, as our competitor’s.  However, the pricing was totally out of whack.  At $900, the decision to buy needed more levels of approval and couldn’t just be purchased on a whim by most architects.  Conversely, a $500 product was much easier to justify and purchase.  After a couple of years of good reviews and slow sales this product was dropped.

The third product was a view and markup product, priced at $199.  It was just what the market needed and wanted and sales were setting records at the company.  Eventually, however, it was decided that it was an important strategic product and should be used to help the company’s general bottom line.  It was given away for free as part of this corporate strategy.  While this was fine for the company, it wasn’t so great for the group that developed it.  When your group produces a toolkit, utility, or other free product, someone is eventually going to notice a red column on the corporate budget.  This is your group, employing many developers, but not providing any direct income.  It’s difficult to quantify “strategic product” on a balance sheet and the memory of why your product was so important in the first place is soon forgotten.  When lean times roll around, what do you think is the first group that’s going to be cut?

It’s sad and unfortunate, but being attached to strategic and free products/projects in your company may eventually put you at risk for being first on the chopping block.  If you’re on such a team, you must continually remind upper management why you were created in the first place and why you continue to justify your existence.  Failure to do so while only likely result in the decision to strategically eliminate a negative on the balance sheet, making your executive look good in the short term, regardless of the long term.  But, when did the future ever influence an executive’s bonus?

I was talking to a friend, Dave, at a party this summer.  He told me how the company he worked for (we’ll call it ABC Corp.)  was working on a contract for another firm (we’ll call them OtherComp).  ABC spent a great deal of time working on the database and software design for this very large project.  They wanted to be sure that they got it right.  However, 6 months into the contract, a competitor (EnemyCorp) approached OtherComp and said they could do the job better and quicker.  OtherComp looked at what ABC had produced so far, mostly design documents, and decided that they’d see what EnemyCorp could do.  EnemyCorp dived right in and started coding.  They produced prototypes and according to my friend were definitely not doing a great job on the whole project.  He suspected that after a while, ABC would be called in to clean up the mess that OtherComp bought from EnemyCorp.

I told Dave that this sounded pretty typical and wasn’t in the least bit surprising, actually.  You have to feel out your customers to see what they’re looking for.  This customer wanted to see something.  Not a document.  A working application.  Something they could look at and “touch” to determine how they liked it.  Something they could point to and comment on.  Tangible progress.

With any large project, there’s a need for solid design work.  However, some customers don’t have the patience to wait months or years to see the real thing.  Plus there’s no guarantee that your design will be perfect either.  For some projects, perhaps a prototype that goes along with the design work (or as some of the design work) would be more appropriate.  This could go a long way to convince your customer that you’re really making progress and keep them from getting distracted by another company.  Watching out for your customer’s best interests should be at the forefront of your activitites, but that might mean watching out for your own interests as well.

I went to visit some friends at my old company earlier this week. By the end of the week, most of them had been laid off. It’s both a sad testament to the times we’re going through and the short-sightedness (and stock-mindedness) of executive management.

The company in question (let’s call them BigCorp) had grown by leaps and bounds in the past couple of years, both due to a number of large acquisitions and massive hiring. One of the companies they bought was a 900 person contracting company in China. BigCorp was looking to grow their presence in China as the Chinese government will be more inclined to buy software from companies either based in China or at least with major operations there. As a result, they were moving a lot of their development work to China. Unfortunately, the developers there lack experience both in programming and in the programming domain. Like most new programmers, they tend to apply brute force to problem-solving and they tend to screw up frequently. The programmers in America spend a lot of their time fixing these problems, but since the software gets produced, upper management doesn’t think anything is wrong.

Well, now some more of those American programmers are gone. They won’t be there to watch after the software that’s produced overseas, but it’s not likely to be noticed. I decided a long time ago that the implications of top-level decisions is often missed and that one’s legacy at a company is forgotten in relatively short order. Will anyone remember that you were the one who used to catch all of the problems with the software before anyone else noticed? Probably not.

Legacy aside, BigCorp set up this particular group of developers for the axe a couple of years ago. When they first started on their last project it was to be an inexpensive product that would be part of the corporate strategy in making BigCorp’s software more ubiquitous. Eventually, BigCorp decided that this product should be free so it could be even more ubiquitous. Well, when push comes to shove, eventually someone comes along a couple of years later and they see a group that doesn’t make any money and a bunch of programmers that get paid a lot to produce it. If it comes to cutting that group versus another one that produces money, which one would do you think is more likely to get chopped?

In the end, it results in unemployed programmers one way or another. The most important thing is that as demoralizing as things get when you’re on the bloody end of the “axe”, you have to remember that you were valuable once and will be again. Take a few days to sulk and grumble, scream at your dog that it’s just not fair, then dust yourself off and get on with your next chapter. Polish up the resume, start calling all your employed friends and family, and get the names of people inside companies that can hire you (go around the human resources department). Sure it sucks that you have to go through this (I’ve done it several times due to lay-offs and corporate downturns), but each new job offers a chance to experience something different, make new friends, and learn something new.

I was talking to my father a few months ago when I posed this question. Are we watching the death of boxing as a popular sport and if so, why? I suggested that boxing started to decline when public broadcast turned to pay-per-view and private broadcasting, such as closed-circuit television. Back when I was a kid, all of the major fights were on national television. I can still remember Howard Cosell calling the Ali, Frazier, Norton, and Foreman fights. Back then, everyone knew who the heavyweight champion of the world was – and there was only one at the time, not five. But, money gets the best of everyone sooner or later. Promoters decided that they could use boxing’s popularity to leverage revenues by charging people to watch it. In the short term, this worked great. Over the years, however, I think people slowly lost interest because of this. The promoters started setting a bar that you had to hurdle to see the fight. Eventually, you have to decide whether you’re willing to shell out $50 to watch a fight on TV. If you know the fighters, you might decide to invite some friends over and split the cost and it turns into a small party, like Sunday afternoon football.

However, these things can spiral. Some people won’t go over the hurdle. They start to lose touch with the fighters. Popularity declines a bit. Coverage in the newspaper gets smaller. Coverage on TV used to be in the mainstream stations even for the weigh-ins. Now, if there’s coverage, it’s on ESPN. That may be the best place to report on it, but it’s yet a smaller number of viewers than your local ABC news sports report.

With every hurdle and every dilution comes a smaller market share. Combine this with other interests, like mixed martial arts and the UFC, and you’ve got a recipe for decline. Once you start to coast and don’t invest in your product, you can bet that someone else will come along and take the interest away.

I was reading Jeff Atwood’s post on Programming: Love It or Leave It which was derived from a Joel Spolsky forum entry. This got me thinking about some of the responses and some of my own experiences. I’ve mostly worked on products as opposed to IT departments. As Joel points out in one of his responses, “[you're] going to get more out of computer careers if [you] work in a product company.” This is because products tend to be longer life projects, tend to suffer less from budget cuts than internal IT projects, and mostly because they involve more design and creativity components as you have to try to appeal to customers who don’t have to buy from you. In a product company, you’re more likely going to have to produce software for sale as opposed to maintaining databases, hardware, or software, or another of hundreds of mundane tasks.

There are so many possibilities in the computer programming world. When I talk to people about what they’re looking for in their next job, I point out that there are many different possibilities. Small product start-ups, small companies with established products, large product companies, web-site companies, web-site design and consulting companies, large and small embedded software companies, IT service companies, non-software companies with IT departments, universities with research programming needs and IT needs, and many, many more.

Each one of these places offers different kinds of work. Some people have said that there is a shift in programming going on today. My friends who work for a large software product company spend a good amount of their time designing code for people in China to write. They get software back that may or may not work well and may not be up to par. Then they have to either request changes or fix it themselves. They tell me that it would be easier and more efficient to simply write the code themselves. Either way, this is what’s happening at that company and they don’t believe it’s going to change any time soon.

If you don’t like what you’re doing there are several choices. Do something entirely different and quit programming. This is the extreme approach. Alternatively, find a different kind of company or software. Your experience is transferable, but you may have to convince potential employers of this. Doing some personal projects can help fill in missing job experience. For example, if you’re in web programming and are looking to move into a product atmosphere, download a Java environment and develop a small shareware or freeware application. You’ll have something tangible to point to and you’ll find out whether you really like doing that kind of development work.

There’s a world of software out there, some of it hiding where you might not suspect. Do some web searching and personal networking. The economy may stink right now, but there are many companies that still need to get work done and there are jobs out there if you dig enough.