wandercoding.com

Like the reality show “Survivor”, work is a reality show of its own in a different environment - the cubicle jungle.  Surviving it on your own terms is complicated as there’s no one thing you can do that will help in the very short term.  The secret to surviving is a combination of value and the visibility of that value both in the long term and in recent memory.

On a daily basis, there’s not much to worry about.  You don’t have someone voted out of the office every couple of days.  However, corporate layoffs do happen periodically.  Unfortunately, in larger companies, this is usually done as a percentage cut.  The result seems quite Draconian in nature.

At one point, when I was the manager of my group of eleven, I got a call from my boss.  He told me to pick two names in my group who could be laid off.  The first name was guaranteed to be let go; the second might be let go.  It was a horrible decision to make.  The people were colleagues and friends that I had worked with for several years.  Ultimately, the decisions weren’t that hard to make.  So, what went into the decision-making process?

A goal as a manager is to keep the most valuable team members.  What makes you valuable?  Here are a few contributing factors.

1. Solves problems
2. Has answers
3. Team player
4. Self-propelled
5. Isn’t too cat-like
6. Versatile
7. Helpful
8. Has unique, specialized knowledge
9. Exhibits leadership

If you have many of these traits, you’re likely to be a survivor.  However, people also have to know that you have these traits and this comes in the form of some self-promotion.  In weekly status reports or meetings, make sure that your boss and your colleagues know what you’ve done.  You don’t have to brag or toot your own horn too loud, but you do have to do a little broadcasting.  For example, if you’re in the middle of a large project, be sure to report the progress that you’ve made.  Perhaps you’ve spent time working on other modules that aren’t yours in order to prepare to integrate your code.  Or maybe you’ve built some base code upon which you will build.  Be sure to point out how your base code will be usable as a toolkit for others in your group or company.  When you report things this way, others will give you the accolades and toot your horn for you.

Be sure that when layoff time comes around, you’ve done your best to be valuable and visibly so.  There are no guarantees, but this is a great way to start.

I was reading Scott Hanselman’s blog yesterday (computerzen.com) and read a good post about coding basics. I left a comment about the process of coding and making your code better. I thought that one thing in particular was worth writing about here on my site.

There has long been debate about the value of commenting your code. I grew up with code commenting and have continued to do so through my career. The main arguments against commenting code seem to be that a) the code itself is or should be self-documenting and b) comments are often wrong, so why bother.

My answer to these is:

a) I’ve read so much code in my life that is incomprehensible that I wished the person who wrote it had written a comment (or many) about what the code was trying to do - especially because it’s rare to find non-buggy code. Sooner or later, someone’s going to have to go back to that code and fix something.

b) If the comment is wrong, even that’s not so bad. Out of date comments are a place to start. For some reason, when you see a comment and try to evaluate the code, it’s not that hard to figure out that they’re out of sync. There’s clearly some mental process that gets invoked that helps you understand what the code is trying to do. Plus, if the comment is actually correct, you’ve just clued the person into what’s really going on (or is supposed to be going on).

Clearly, I’m in the “keep the comments” camp. One thing I started doing a while ago is functional design by comments. Before writing a function or object-oriented method, I write a comment for what the function will do. Then, I outline the code by writing comments. Writing code this way forces you to think about what you’re going to code and not just jump in. Once you do this, you start thinking about ways to structure the code most efficiently and maintainably. One more benefit: if your comment on the whole function is huge, chances are that you’ll need to break down the actual contents into multiple sub-functions, allowing you to refactor at the conceptual level sooner, rather than at the coding level later.

Try this simple method for writing code for a little while and you’ll probably get hooked on it too. If one of your colleagues comes over to your desk some day and complements you on a well designed and documented class or function you’ve written, or you simply find your own code easier to maintain, you’ll know you’ve earned your next donut.

A colleague from my last job found me on LinkedIn the other day. It was good to hear from him as he moved to Texas and I would never have found him (lost his contact info.) He told me that he was getting tired of writing software.

Let me give you a little background. We worked together at Lockheed in Owego, NY. Owego’s kind of in the middle of the nowhere called the Southern Tier of New York, close to the PA border. Most people call it Upstate New York, which is the 99% of the entire state that’s not New York City or Long Island. The work at Lockheed was embedded software - writing flight display code for the VH71 Presidential Helicopter. It sounds pretty cool and some of it was fun, but writing this kind of software is different from other work I’ve done. There was a very rigid process called DO178B, which is for flight quality, defense contractor oriented embedded software. There are processes that cover the preparation for writing code, writing code, testing it, fixing it, logging that you wrote it, tested it, and fixed it, etc. The type of code you can write was also different. Straight C, no C++, no dynamic memory allocation (only pre-allocated memory). The environment was working in a building where even the access to the parking lot was by keycard. You had to log your work hours - not eating your lunch while working at your desk wasn’t a work hour - and had to work 40 hours a week, no more, no less, unless approved for overtime.

In my career, I’ve worked for 5 different companies. The first four were all very different in personality and environment, but shared the same kind of applications and work - writing object-oriented code for computer aided design software. T-shirts, jeans, and shorts were the dress code. Nobody looked at your hours of work. Lots of teamwork. When I finally decided that I wanted to try something different, I went down to Lockheed. Man, was that a different experience for me. The thing is, it was good for me. I saw different kinds of work being done in a different environment for different customers for a different application domain. For a while, when there was plenty of work to be done, it was fun, too. It was something different to learn and wrap my brain around. I had grown tired of writing the same software for 19 years, so I needed a change of venue.

Eventually, you may get to the same point in your career, sooner or later than I did. Consider a change. Here are some ideas:

• Pick a different application domain. E.g. been writing financial software? Try engineering software.
• Try a different sized company. Tired of the the big corporated nonsense? Try a small startup for it’s own brand of nonsense.
• Tired of wrestling with C++? Learn Java, C#, or Python and get a different job using that technology.
• Tired of writing software at all? How about a move to pre-sales support, management, marketing, application engineering, training, documentation (technical writing)?

The thing is that there are many jobs associated with software that don’t just involve writing software. What you’ve learned about the business as a whole in your job in software is transferable to other aspects of the business. Before you give up on software entirely, see if there’s a way to freshen up your career with a change in venue.

As I write more, I also read more. Recently, I was looking at codinghorror.com and saw that Jeff Atwood was being criticized for not living up to his reputation. Since he was receiving money for his blog site and was “turning professional”, he was now deemed no longer qualified to be doing it. It seems that among other things, Jeff doesn’t know C and everyone knows that if you don’t know C, then you’re not a real programmer. To me, the whole argument is good waste of time. As far as I know, there’s no reasonable test you can take to prove that you’re a worthy software engineer, much less worthy of being a blogger or speaker. The simple fact is, that if you have a keyboard, you can be a blogger, if you have a voice, you can be a speaker, and if you have a loud voice, you can be an “expert”.

As in life, so it is in blogging, and in your career. Time and experience eventually shows who is worth listening to, reading, or working with. I’ve worked with many people for many companies. Those with the loudest mouths were not always the ones with the best ideas. Conversely, the quietest weren’t always the ones with the worst ideas. Similarly, some of the more confident people weren’t always the most competent.

So, what’s a programmer to do? Well, lots, actually.

1. You don’t have to be an expert to have an opinion. Pose your ideas with humility and be willing to take a few shots. Ask that people be honest, but constructive with their criticism. Besides, I’ve seen plenty of mediocre ideas turn into gems after some brainstorming.
2. A little self-confidence goes a long way. If you don’t have enough confidence to try something or say something when you have a chance, you’re going to have a long, relatively steady career. Want to work on the same project for 20 years only to emerge as a dinosaur? Don’t take any chances. However, taking a chance on a new project or opening your mouth with a considered opinion will make people take notice. This is the way to really get somewhere and add some spice to you career.
3. Learn something new, then teach it to your colleagues. Learning how to use a new tool, API, language, or other technology is one way to keep work interesting. If you really want to understand it better, try explaining it to someone else. Being a teacher or a mentor in your company is an easy way to gain recognition and climb the technical ladder. You don’t have to become a manager to go places in your field.

After a few years of really engaging in your work, you may have the knowledge and confidence to share your ideas on a broader scale. You may have your own blog, podcast, or forum in whatever medium is current. Eventually, someone will think you are elevating yourself to the level of guru. But, since you’ve tempered your confidence with humility, you’ll know the truth. You’re just someone doing your best to help your community of fellow software people and you’re willing to take a few shots along the way.