Work: Psychological Safety -- an ingredient, not a recipe

This was a while back, early in the year, when someone on my team email an article published by Google about what make a good team.  The one buzzword that got thrown around was psychological safety.  Basically,the ability to express thoughts without being shamed and fail without being blamed.  If you have not read about it yet, try reading it at NYTimes or reWork

• http://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-its-quest-to-build-the-perfect-team.html
• https://rework.withgoogle.com/blog/how-to-foster-psychological-safety/

I do think psychological safety is an essential part of a good team.  Innovation requires a lot of experiments and failures.  Getting blamed for each and every failures is very detrimental.  It would be like living with a family member who points out all your imperfection on a daily basis -- that dish is not clean, you are driving too slow, the housework is not done yet, the bill is still unpaid, there is dust on the table, the grass is (few inches) too tall now, the food is too salty/sweet/tough/bland/cold/unhealthy, etc.  Yeah... nothing said love than being reminded about every troubles and flaws.

At the same time, I have a feeling that psychological safety will ended up being the grand philosophy to create a perfect project instead of an ingredient of a good project.  Eventually, it will be re-interpret, exploited, and deemed as a wrong idea.  I like to compare this to a sugar in any cake.  Yes, all cakes need sugar, but it is not the only ingredient and too much can be bad...

After reading the articles, I have been thinking for a while about my own situation in life, and came to the conclusion that the three ingredients that make a good team are...

1. Knowledge -- the logical thinking and technical ability to get things done.
2. Passion -- the drive to bring people together and motivation to get things done.
3. Compassion -- the openness to changes and acceptance of failures.

From my own 11 years in software development, I have worked on 12 teams (the privilege of being in a Tiger Team), two of my top three managers have nothing to do with Computer Science major.

In shortness of time, I have to stop this post now...  Who know when will I ever blog again...

Work: Dependencies Analyzer

Recently, there is a post by Google on Venture Beat regarding causes for build failures.  If there is one thing about Google I give credit for is the hunger and drive beyond the current standard.  They want perfection, or at least as much as possible.  Anyways, the article break down the causes and one of which for Java and C++ is libray dependency.  So, that should not shock anyone working with Java and C++ long enough.  You forgot to include a file and kaboom! A compiler failure five minute later and back to typing one line, and recompile everything again... (@__@)

However, one idea just popped up in my head few minutes ago.  Another big reason for a major breakage is library upgrade.  If you ever work on any software project, you will realized that libraries get updated consistently due to additional features, fixed bugs, or security issues (like HeartBleed).  So, how can you make sure that dependencies upgrade will not break anything?  Smoke tests and unit tests, of course!

If those builds have tests in-place, then it should detect the unexpcted anomalies.  However, current build systems (ex: Jenkins) do not know anything about dependencies.  This is a drawback and a big deterrent to updating to a new library.  It goes against "Do not fix something that did not break" philosophy.  The reason is not because upgrading is bad, but upgrading takes work!  A lot of tedious and no appreciation work. 

My proposal would be to have a build system that can recognize each project's dependencies.  It could be a link to some folder and a script to parse the version number.  It could be manually entered URL, like GitHub.  It could anything really.  If the build system can understand each build's dependencies, then it can be expanded further to do mini-jobs like... find new builds, auto test each new dependency with the current source code, back-port a dependency library to an older version (useful for security fixes, and detect which older versions can be updated to the latest library), report version numbers of each dependency library, test if a specific version is compatible with the latest libraries.  Once these jobs are created, library update/upgrade would be a simple problem.

Obviously, this is an ideal situation.  Most project in most company still does not have a unit test, let alone a smoke test or a validation test.  Again it takes effort and support from management to really do this.  But once it is done, the team can achieve a speedy development with fewer maintenance!!

Work: What Went Wrong?

If everyone thinks the same way, then society would fail at the first stupid idea

Over the last few days, I got some time to think about what make and break a project. After some long thought, it comes down these few reasons:

• people: managers, co-workers, supporting teams, external teams
• plan: vision, milestones, requirements, designs
• execution: tools, communications, automation
• non-engineering: timeline, finance, competitors

So, why oh why... do projects fail? Because there are thousands of ways it could go wrong. And should one factor stands out too much, it becomes a loose string in a sweater that slowly taking other parts down with it.
      If the leader has no vision, then there is no direction
      If the team does not have the right tools, then the product will be delayed
      If the co-workers do not get along, then parts won't fit well together

So, when I was asked what went well, I could have given the usual answer -- we work hard, we tried to plan, we created some automation, etc. But I answered with what went wrong -- lack planning, and insufficient tools. However, I never got around to people... It is sad to see that there are much more to be said, but change-agents limit the scope. If the goal is to bring changes, then all ideas should come before any time constraints. The insufficiency of patient, sincerity, and humility is what I see, and it means nothing will change. THAT is what went wrong after all the wrongs...

Work: First 50 weeks

It has been about 50 weeks since I first started working at Y! in Burbank. It has been very difficult for a long stretch of those 50 weeks. But as I flied back to Burbank today, I did some calculation in my head about all the trips I took to San Jose. In the pass 50 weeks, I have made 25 trips to San Jose...

50 weeks x 5 days/week = 250 days
25 trips = 25 days in San Jose
25 days in SJ / 250 working days = 10% working days in San Jose

I rarely made any trip up north in the pass three months, but at 50 weeks, 10% of my working days are in San Jose! Hopefully, this is behind me, and the next 50 weeks will be a lot better.

In case that was not obvious, I do not particularly enjoy weekly flight.

Random:

It goes back to what he who had left said, "What do you not know?"
I replied, "How do I know what I do not know?"
He responded, "Well, it is important to realized what you do not know."
He paused a little and continued, "... and make sure you know it."

I agreed with what this brilliant mind had said. However, to be that person that leverages and applies these points is a different story.

There I am, today, trying to explain something. Then there they are, trying to explain to me about what I should do, without fully listened first or understood what I am doing. Should I have cut them off, and told them the real deal? They are in the a hurry to talk, but not listen. I am always listening, but talk slowly.

I do know why these people do not listen. They are always in a rush. There is no time. Not to listen or understand. They did not say anything wrong, but it did not applied here. What I do not know is how to make them slow down and listen carefully. I do not know is how few individuals come up with a noteworthy opinion or questions before thinking it thoroughly. Yet, most just said random stuff.

I realized what I do not know is why so few people are being honest.
I realized what I do not know is what I expect out of my life.
I realized what I do not know is how to other people truly happy.
I realized what I do not know is when I can ever truly be myself.
I realized what I do not know is who is really behind that mask.
I realized what I do not know is where all these words will lead to...

I understood the message of the brilliant mind, but never able to figure him out as a person.

Random: Big Plan

Who are you if without any ambition, goal, or dream.
Who will you be if without moving toward your goal.

It is almost 3 AM, and I have been trying to sleep for the last 4 hours. It could have been the coffee, but the effect is way too long. But I think it is the big plan that I have thought about for the last week: a master degree.

I didn't realized before, but couple weeks ago I found out that majority of people in my group got a master degree or better. I know a lot of my friends are getting one, but it didn't register until now. Considering this, and factor 10 years into the future, a master degree will be essential in getting a good job.

It has to start, there is no compromise. Period.

Random: High Five

Simple things that used to be so irrelevant.

It seemed like years ago since I last did high-five with a stranger. Then today it happened. With a stranger over a Foosball game, despite scoring on my own goal. I felt something. Not sure if it is just a nostalgic feeling of "good old time", a sadness by how long it has been, or a self-pity from seeing them happily went to play soccer afterward.

It was Friday, and 15 minutes before 5 o'clock.
They probably are not technical-engineers.
Should I be jealous of that?