Old Man Manager's Weblog

Professionals train themselves

Kevin, an engineering manager, was frustrated. Good projects do not come to his engineers. If there are no projects, there will be no accomplishments, and no advancements. China will feel like the high-tech colony of the 21st century and get only menial works and be stuck in the "low wage" end of the industry.

I felt for Kevin's despair. At the same time, I was astronished on how his young engineers have missed the basics and focused on the wrong things.

Like atheletes, good software engineers move up the career ladder will skills. It is quite simple, choose the arena, suit up and compete. The winners move on. The question is, "Are you training yourself everyday?"

The general categories for a software engineer evaluation are:

• Credential:

  The pieces of paper that prove you qualified for certain tasks. The most basic ones are the diplomas. Then we have those issued by various institutes. These paper give the boss various degree of confidence that you can accomplish the tasks she needs you for. If the task has a commensurate higher job level, you may get the promotion tegether with the assignment.

  Credentials, particularly diplomas, also show your tenacity and conformity. You may not have learned much, but you stuck it out for years and met all requirements. If you can go through that, you must have what it will take to finish this project.

• Experience:

  Young engineers hate to compete on experience. You are not qualified because you have never done this before. But how can you get the 1st project then?

• Skills:

  Skills are easy. Although hard to describe precisely, an engineer know how skilled she is. Software, after all, is a craft. Within few minutes, an engineer would have sized up others and a pecking order is formed.

These basic three are part of all promotion considerations. The weights of them differ as career progresses. In general, Sun values credential the least, skills most, and experience a very close second. Ask. "Am I the most skilled and experienced among my peers?" Like atheletic competitions, software career is meritocratic. Do not waste efforts on anything before mastering the basics.

Next time, when you have finished the project, try do a bit extra:

1. Testability:

   How is the code testable? Is there test programs that automate the process? When problems surface in the system, how easy it is to isolate the bug?

   Along the same line is demo. How would you show someone your proud achievement? Did you write another piece of program to show it off?

2. Usability:

   Is there a web-based interface? Is there a tool to make it easier? How is the user experience? Do not hide behind areas of technology. A kernel module or a device driver can have user interfaces just like a Java application. As long as a human being can use it, you need to consider usability.

3. Elegance:

   Is the code efficient and pretty? Nicely modulized, neatly formated, appropriately named, cleanly inferfaced? How did you treat the global state variables? How much you rely on side-effect to accomplish works? Are you proud of this piece of work like a poet?

4. Documentation:

   Did you comment the code well? Did you write the design document? Did you let the next person who is unfortunately stuck with your code know where to pay attention?

These are where you gain experience without the assigned project. There is always something extra you can do to make your project better. When you are doing that extra amount of work, you gain experience on areas you do not normally practice in. Choose what you need to practice and do the extra work there.

And you would have done something wonderful to yourself. When you are doing those, your manager will notice that you walked the extra mile and did the extra-currriculum work. That shows your diligence, willingness to learn, and potential.

Most importantly, you gain control of your own career by doing these. Those extra works make you a better software engineer. An accomplished software engineer write his/her own ticket. You will name the next project you want to work on. Opportunities will come knocking on your door.

Lastly, wherever you look, there are bugs to be fixed and source code to be read. Pick an area of interest, read the source code, try to fix few bugs that seems trivial, talk to the owner of the code and ask him/her to review or integrate what you have done. They will appreciate it and you get the experience. This is the power of Sun's openness. Don't squander. Train yourself.

Posted at 09:25PM Apr 11, 2006 by oldmanmanager in Practical Engineers  |  Comments[2]