Archive for April, 2006

Professionals train themselves April 8th, 2006

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.

Mr. China: A Memoir

Tim Clissold


ISBN: 0060761407

Pub. Date: February 2006

Publisher: HarperCollins Publishers

What do you expect?

Tim and his partner, Pat, made few hundred investments each thousands times the average annual income of an individual. They did it all over China, from the bitter-cold north-eastern corner to deep valleys of the west. They did it without any clues on how the legal system works, not knowing how businesses were conducted, without trusted local consultation, without good command on Chinese language, without any check and balance mechanism, without reliable monitoring processes. They inspect their investments once in few months, or until a crisis emerges.

He lost few deals to “creative operatives.” Duh!

The book provides good entertainments. Tim's description on BaiJiu (white liquor) is hilarious. I really felt for him during the heart-attack episode. His realization of China will always pursue its “chosen path” was right on. “The civilization has always endured temporary invasions and eventually absorbed the invaders.” Sometime it took a couple of hundred years and that's OK.

But as a business book, it is a yawn. When I talked to a smart venture investor in San Francisco, she was cautious, “Everyone investing in China does not make me. I need to make sure I can get good return before I pour any money into anything.” The lessons Tim learned have been learned for generations. That they also apply to China is not really novelty.