Hard Times

We are living in interesting and confusing times. Gas prices have skyrocketed, home prices are dropping, foreclosures are increasing at an alarming rate, and our fearless leader seems to constantly side with big business over the common guy with a problem. There’s only one thing to do – take matters into your own hands.

For example, let’s say that your company has laid you off or looks like they might do so. You have choices to make. Do you want to be the last one out the door and try to hold on as long as possible? If so, it’s time to prove or remind your boss that you are key to the continued success of your company. Sometimes, however, things are beyond immediate control. If your entire division or group is about to be let go, then convincing your manager that you’re the best developer on your team is pointless. So, what’s the plan.

Any job change is a chance to evaluate. You have the opportunity to evaluate what kind of work you’re doing, what you’d like to be doing, where you live and would like to live, and what aspect of the business you’re involved in. This is a great time to be purposeful, not rash. Unless things are extremely tight financially, you don’t have to accept the first job that comes along. Consider whether you’d like to change the kind of software you’re developing or the industry it serves. Have you been writing embedded military software? Would you like to try commercial off-the-shelf instead? Are you a web developer and want to try writing financial software? Try to find someone who does this kind of thing and have a talk with them about your qualifications and their assessment of their industry and your suitability to it. Make connections through linkedin.com or another networking site.

Finding another job is your new job. Plan your attack and your day around this. Do research on your city or another that you might like to move to. Find companies that you might like to work for. Use corporate web sites in addition to careerbuilder, dice, or indeed.com (a great local company search engine.) Spend time every day doing some research on new possibilities. Chech web sites, newspaper want ads, and your people connections.

Make your resume shine by having some other people critique it. It’s never quite as good as you think it is and can always stand another opinion. Keep in mind that several people will have differing opinions. Use some web sites or books for good examples and ideas to improve your resume.

Inside connections, not Human Resources, are your best ways to enter a company. Use your people network to find someone inside the company that can check internal job boards and put your resume on the hiring manager’s desk. Few things are more hopeless than adding your resume to the electronic stack of an online company job site.

Take your time, evaluate what you want to do, reflect on your desires, but don’t get lazy. It’s easy to get complacent at your job and get surprised by a massive layoff. Keep your eye on the corporate bottom line and listen to the tone of your CEO’s statements (especially the internal ones). If your company is listed on a stock market, dropping prices are a sure sign that layoffs could be on the CEO’s mind, even if your company has a history of never having them. Every time you change jobs you have an opportunity to learn something new, find a better place to work, add new experiences, and meet more great people. Job hunting stinks, but it’s a job you’ve got to do once in a while. Make it a rewarding one. And when you land an interview, be sure to read Pimp My Salary for getting your best offer.

Walking in Memphis

I just returned from a trip to Memphis to visit friends. We spent the first few days downtown at an excellent hotel, the Talbot Heirs Guesthouse. Downtown Memphis is very walkable and if you don’t feel like walking you can just take the Main Street Trolley. The people were friendly and accomodating just about everywhere we went.

The interesting thing about the town is that it has been up and down. At one time, downtown was vibrant, but underwent a decline beginning in the 1970s. There are numerous empty store fronts, deserted blocks, and panhandlers roaming the streets. But, there are many historic and beautiful buildings. There are rental properties advertising condominiums. And there are some fantastic restaurants. The famous Beale Street, home of the blues, is right downtown, along with the Gibson guitar factory, an NBA stadium, and a minor league baseball stadium.

Now, the question is: if you build it, will they come? There’s little difference between this and software. If you build a website, will people visit? Will you make money actually selling something or by advertising on your site? If you build software, will people buy it? How will you market it? Will you pay to advertise on web sites, in magazines, or at trade shows? Like anything else, things take time. Patience is important, but so is constant action to improve the likelihood of success. And once success has been achieved, never stop trying to improve. The competition will always be after you. Don’t have any competition? If you’re successful and have proven that there’s a market for what you’re doing, the competition will come.

Perfect Programming

I like reading other software blogs as much as writing my own. My big advantage so far, is that I don’t tell people how to write code (yet). Why is this an advantage? Because, so far, I’ve managed to avoid the wrath of the Perfect Programmer.

Who is the Perfect Programmer? He’s (or she’s) the one who responds to the blog posts with things like: Don’t let Jeff Atwood Lead Your Web Project or corrects silly bits of code on code postings, where the correctness of the code example doesn’t matter because it’s only for illustrative purposes.

Fortunately, in my career, I’ve only run into a few perfect programmers, who have commented on my code without tact. My code is far from perfect (even perfect programmers write crappy code), but most people who have commented on it have at least done so constructively. This brings us to my real point for this post.

Criticism is a dish best served warm (as opposed to revenge, which we all know should be served cold – it must taste like gazpacho). I’ve found it best to approach someone in a more questioning manner, asking someone to explain what they were trying to do first. After all, is it possible that you misunderstood the intent of the code or the design?

In a previous life, I worked with a guy who was a good coder, but could be a bit on the testy side. He had added a new feature to the API that was very useful, but would be difficult for users to interact with. A couple of people told him so and he became very frustrated with the criticism and insisted that it was perfect as is. I was asked to talk to him, so I went over to his desk and asked him to show me the new functionality. He told me about it and showed me the code that a user would have to write. There was one piece of information the user would have to supply that wasn’t obvious to me, and therefore users as well. I simply asked him to tell me about what the user would have to do to get this piece of information. Once he started to explain it, he stopped in mid-sentence. He said, “I can see how I can make this whole thing much simpler,” and he did. He changed the code and it was very clear and much simpler than the original. I had gotten him to criticize his own code.

Along the same lines, this is one reason why I always write comments and documentation on my classes. I find that once I start trying to explain what the code is supposed to do that I find out how convoluted I may have made it. Try thinking like a user when you design something. Try thinking like your colleague when you have an issue with their code. You’ll find that people will learn to trust you and accept suggestions more readily without getting defensive.

Distribute This Around

I’m not sure exactly when this started, but my recollection is that it began spreading in the late 1980’s. What am I talking about? I’m talking about a scourge that spread so quickly and has become so prevalent that it is practically inescapable in today’s world. I’m talking about redundant-speak.

It started small. People in meetings started saying things like “continue on” when continue would have done just fine. Then other people who presumably didn’t want to be left out must have come to the realization that they weren’t being clear enough if they didn’t say things twice in the same sentence. Memos suddenly needed to be “distributed around” and “circulated around”, when distributing or circulating them would have been sufficient.

With the price of words skyrocketing, it should be clear that we need to decrease down the amount of redundant speak (did you catch the one in this sentence?). Okay, so words aren’t really getting more expensive, but there’s still no need for the prevalence of this kind of talk. Communicating clearly and effectively isn’t difficult. Removing modifier words isn’t difficult, either. The first step is recognizing that there’s a redundancy in the first place. Next time you listen to someone speak, listen for a two word combination that describes one thing. If the description tells you two different things, then it’s fine. However, if the second word, or sometimes a supporting phrase, doesn’t add anything, then it’s redundant.

Once you recognize this kind of speech and writing, you can examine your own. Once you start removing the redundancies, your communication will be clearer and more direct. Try not to revert back to your previous behavior (did you catch “revert back” when “revert” will do?). Help remove redundant speak from the world until it’s totally abolished.

For a nice list of redundancies, check out: http://kcweb.nhmccd.edu/employee/jsamuels/redund.htm

Survivor – Cubicle Jungle

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.

Comment on Comments

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.

Menus of Venues

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.

Guru-ness

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.

A Load of Bunko

Recently I read the book “The Adventures of Johnny Bunko” by Daniel Pink and thought it was very good. It’s short, to the point, and it’s a manga graphic novel. You can read the whole thing in 45 minutes. I don’t want to spoil the point (or kill the book sales), so I’ll simply point out that the book highlights six lessons for having a good career. Although it claims to be the only career guide you’ll ever need, it’s a bit short on details in that respect. On the plus side, it’s a great starting place. If you’re looking for more information on specific career advice, you’ve come to the right place (wandercoding.com that is) if you’re in the software business.

While looking over the web site for the Bunko book and Dan Pink’s site, I came across an interesting exercise. The idea is to describe yourself (as in an autobiography) in six words (see http://www.johnnybunko.com/home/one-cool-guy-six-short-words/ for details and other examples). It’s an intriguing idea and I thought I’d try it out as well. I quit my job a year ago to do some independent software development and other creative things and figure out where my life was going to go next. So far I’ve been writing a book, planning another book, writing two blogs (this one and one on Judo), started a software prototype, thinking about another software project, may do some software contract work for a friend, and have plans for a Judo program focused for schools. I’ve still got some other ideas written in my notebook that I haven’t found the personal bandwidth to pursue yet, too. But that’s more than six words, isn’t it. So, here goes: “So many options, so little time.” or “Software, Judo, what will 2.0 be?” or “Choosing hard, drifting easy. Wind changes.”

What would you say about yourself?

The Dash

As mentioned on my About page, I’m also a Judo player and instructor. Recently a member of the Judo community died and in an email with the announcement of his passing, someone included a copy of “The Dash” by Linda Ellis. I must admit that I’ve never read this poem before. The gist of it is: on your tombstone (sorry if this is too far away for anyone to worry about, just work with me here) there will be a date of birth and date of death with a dash in between. The poem asks the simple question, “What will you do with your dash.”

I must admit that at times during my career (it ain’t over yet, either), I’ve had thoughts like this. Why am I doing this? What does it matter? Sure, some of it has been great fun, I’ve made many friends, I’ve been able to make a good living, and should be able to retire one day in relative comfort. But, is there any real value to the world in what I’m doing? Sorry, yes, this will be a philosophical entry.

I wonder about this occasionally with other people in mind, too. What about my mechanic? What about the folks who work at my local grocery store, at Target, or the gas station. What do they contribute to society? What I’ve come up with so far is simple. Everyone contributes in a small way. The software that I’ve written hasn’t solved global warming, ended hunger, or stopped genocide in Darfur. But, it has helped people build things (I’ve written mostly mechanical CAD software, but other kinds as well.) The users of my software have built machines, buildings, and who knows what else with it. Those things have probably helped house people, built equipment to help people earn their living, or may have been used to design hospitals, schools, medical equipment, etc. The people that I’ve worked with were happy to work with me (well, I assume that most of the time they were. Everyone’s a pain in the butt now and then). However, my enthusiasm, energy, creativity, and sense of humor made the workplace enjoyable. In turn, my former colleagues made my life at work more enjoyable. Even those who were sticklers for process or coding practices helped me do my job better. As for my mechanic, how would I get to work, visit my family or go on vacation without him? My trip to the grocery store is alway more entertaining and enjoyable because my favorite checkout woman has such a wonderful disposition and a sunny smile.

I’m afraid that our purpose is sometimes to simply be a cog in a big machine. Even if you’re the President of your company and therefore consider yourself to be a bigwig rather than a cog, what does your company really do? Well, if it’s a software company, you make software. It likely won’t save the world single handedly. Man survived before it existed and will likely survive after it has gone out of business (unless you’re developing SkyNet). But, being a cog is an important part of the overall machine. If this doesn’t satisfy your need to feel like you really contributed something, find a place to volunteer, be a mentor, be a Big Brother or Big Sister. It’s hard to be the one person who’s going to save the world – even those who try usually end up screwing it up more than helping. Simply being a productive part is help enough. Everything else can only make it better. Your “dash” is up to you.