The Fear of Being Wrong

Learning to program is not easy.

You can be on the top of your mental condition. You type, double-check, and triple-check your code and syntax. You believe you have been as thorough as you can possibly be.

One missing semi-colon. One misplaced comma. One neglected closing parenthesis or bracket. One incorrectly indented statement. The computer barks back and coldly point out your mistake.

Worse sometimes, the code executed but the results were totally not what you had expected. You tried to look for where it had gone wrong, and the computer just sat by and watched you sweat.

The computer seems to say… Hey, you wrote the code, so you figure it out! You feel even a machine is criticizing your apparent incompetence.

But to let that fear hold you back from even starting to program, that is a bigger shame.

So, go ahead and start. Be wrong, plenty of time, and learn. No one else will be criticizing — it is just a dumb machine.

Learning to Program

I have been in the IT field for 30+ years, and my background has been focusing on infrastructure and operations. I do like programming but not proficient and experienced enough to consider myself a professional programmer.

This is not the all-inclusive list, but it is a list I stick with on my journey to become better at programming.

  1. Read examples > Write code > Rinse > Repeat. Do this every day. Practice does make it better. Without the constant practice/reinforcement, atrophy can set in and destroy the progress you have made.
  2. Learn purposefully. Learning programming without knowing what you are doing something for can be boring. Think of something you wish to create and practice coding to realize that creation. The purpose you buy into early on can help smooth out some of the frustration moments results from getting things to work.
  3. Get Help Promptly. Don’t get stuck for too long. If you need to look things up or “google” the answers, do so without shame.
  4. Talk to other programmers. Develop an advisory or a go-to source when you need some additional expert opinions. The Stack Overflow and similar Q&A community is a great place to start.

All great programmers I know or read about all do one thing in common. They poke the box and test their assumptions and skills every day.

Excellence and Remarkable

Tom Peters and Bob Lewis call it “Excellence.” Seth Godin calls it “Remarkable.”

Both terms refer to work or art that are beyond simple quality and typical commodity.

Quality used to be the main differentiator amongst the competitors. People seek out quality products/services and talk about them.

These days, with plenty of choices available in any given product/service category, the quality is now considered given. Lack or no quality is the easy route to put yourself out of the game.

When everyone can offer quality, commodity sets in and the price gets driven down. The race to the bottom begins.

The other option is to deliver excellence and remarkability. Give something for people to talk or remark about.

By being excellent and remarkable, it enables the race to the top.


(從我的一個喜歡與尊敬的作家,賽斯 高汀)








Quality vs. Excellence

Some people use the terms quality and excellence interchangeably. My view is in the camp of Bob Lewis’ Bare Bones Change Management, and I believe they carry distinct meanings.

Six Sigma talks about quality as the number defects per million opportunities. Another word, high quality equates to very low or zero defect.

Excellence implies superior functionality or presence of good taste. Excellence can also represent a robust capability that can be tailored to individual needs.

To achieve high quality, organizations need to reduce variations in the process. That calls for standardization in a process.

To achieve high excellence, organizations need to be able to deliver goods or services in a highly customized way. Doing things in a customized way means more variation and, consequently, less standardization.

In the world of high standardization and commoditization, achieving success through quality alone is no longer sufficient. Many factories can easily produce quality when they choose to.

On the other hand, the ability to deliver excellence to meet the needs of certain customer segment is where the competitive advantage is at.

The Art of Leveling Up

I recently read “The War of Art” by Steven Pressfield and Shawn Coyne. Like what Seth Godin advocates, your “art” is something you would do and generously share with others.

Your “art” will exist because you believe it can serve to lead or to connect others.

It is something you would do even if no one else saw any value in it.

Some people might even criticize your art. Not everyone will like it.

My art is delivering the most helpful advice to my consulting clients. Some days I am better at it than others. Often, I still have a lot to learn and a lot to improve.

Not every one of my advice or recommendations will resonate with all my clients. That is OK.

As I often remind my co-workers, “we are professionals, and we bring expertise with us to educate our clients and assist them where they need help.”

Our recommendations might not always be what our clients hope to hear, but we do it with empathy and a high degree of emotional intelligence.

Showing our clients how to level up their game – that is our art.

Project Management, A Process or Practice?

Is the work of project management a process or practice?

I think project management is both a work of process and practice, so what is the distinction?

A process focuses on being consistent and repeatable – you should be able to get predictable results from a process.

PMBOK has five process groups with ten knowledge areas intersecting those process groups for various project management stages.

Practice focuses on applying knowledge, judgment, and wisdom to achieve the desired outcome and dealing with changes. All project managers need to produce results by balancing the triple constraints: scope, time, and cost. Those constraints can often change during project execution.

A good project management practice established and executed by qualified personnel will bring the desired results, even with those limitations.

These days, just about everything we do requires a mix of process and practice. For example, implementing just the ITIL processes verbatim from the framework without applying the necessary effort on building an ITSM practice will just yield generalized, paper processes.

With the pace of changes picking up and the predictability of our environment shrinking, developing a practice is just as important as developing the required processes.