“Don’t Worry”

How two words and once sentence made me who I am today.

Ten years ago the team sat down in a boardroom with expectations to plan the next major release of our software.  The entire team was there.  Release managers, business managers, engineers, testers, & documenters.  The business managers gave the “here’s what we’re going to build” pitch.  The release managers outlined the strategy.  Everyone else asked questions until we were clear on the general aspects of the release.

After the preliminaries we were instructed to provide estimates for our forthcoming work.  At the time it made sense.  They needed to know how long the project would take so that they could see if the work could be completed before the expected release date.  One manager stood at the whiteboard and walked through the various features and core components of the product.  For each work item he suggested a coworker who could work on it.  After some discussion, the assigned worker would provide an estimate in number of days.  We would log the estimate and then continue to the next item on the list.

This was the first time I had seen this done.  I was a new engineer to the company, as were most of the engineers on the team back then.  The manager had lots of experience and was guiding the flow of the meeting as seasoned managers should.  In the two years since I joined the company I had never seen this done.  We had meetings before to discuss the plan and how long it would take, but never with the entire team, and at that point, never with such detail.  I remembered I was excited.  I thought “We’re going to do great this time”.

Then something interesting happened.

Eventually it was my turn.  The manager stated that the preferences module needed some work and suggested that I take it on.  I agreed.  It was an area of the product that I had little knowledge of, so I was happy to do the work.  Then he asked “How long so you think it would take”?  I thought about it and asked some questions about the work.  I received answers and then I asked some more.  After a few more minutes of Q&A I could see some people in the room were getting annoyed.  Everyone had provided answers in a few minutes, and I was taking longer.

Eventually another engineer joined the manager at the whiteboard in an attempt to hurry the conversation.  I was resistant to provide any estimate because I had never worked in the code before and was not comfortable given the information I was provided.  I said “How can I give a number for something I haven’t seen before”?  To this day I have never forgotten the reply I received: “Don’t worry.  It doesn’t matter.  Just give a number”.

My heart felt like it hit the floor, everything else in the room faded, my eyes glazed over, and I blurted out a number.

There are two things I remember about that day.  The first was the disappointment in me for providing an estimate for something I knew nothing about.  The second was my reaction.  It was so sudden, vivid, and all encompassing.  Going forward I attributed my reaction to ‘just being angry at myself’.  It would not be until recently that I truly understood why I reacted the way I did.

—

Two years ago, the team was undergoing a new exercise.  We were exploring the thoughts and opinions of each other to understand our strengths, weaknesses, personal brand (how other see us), and our triggers (what enables us).  The goal was to understand each other so that we could improve ourselves and how we worked with each other.  It was a fun series of exercises that opened my eyes to my coworkers.  I learned as much about them as I did myself.  As we explored the subject of triggers, I thought back to that day when I provided my estimate, and after some thought, I finally realized what enabled my response.  It was not the fact that I was disappointed in myself.  It was something more obvious and mundane.  It was the word ‘”Don’t”.

It seems kind of odd that a single word could trigger such an acute response.  Then again, my coworkers described similar responses to things that triggered them.  They would become blinded to other influences, focused on the thing or person that triggered them, and emotionally involved themselves with what caused the trigger.  Triggers are neither good nor bad.  They are simply the things that enable us.  Understanding our triggers helps us understand why we react to certain influences the way we do.  The benefit in our coworkers knowing them is that they gain insight which helps them work more effectively with each other.  We can understand why we do and say the things we say.  In other words, we understand each other.

While I know that “don’t” triggers me, I am not clear on why it does.  My theory is that “don’t” is a limiting word, kind of like a virtual wall.  I am the kind of person who likes to challenge the status-quo and look to new and improved ways of accomplishing things.  Perhaps I see “don’t” as a barrier to be broken.

Overall I find that my triggers are very helpful.  They enable me to find alternative routes, identify root causes, and locate opportunities for improvement.  The down side is that there are days when I encounter so many triggers that I go to bed exhausted.  In my opinion, it is a small price to pay.

———-8<—————————————————–

I have learned that there are three things that instantly trigger my attention: two words and one sentence:

1. Can’t
2. Don’t
3. and people who complain but do nothing

What are your triggers?

iSoul

It is an interesting thing to question everything that you know.

I have spent the past few weeks thinking about my career and what I want out of it.  I wrote many things that I thought were important or necessary to fulfill my career aspirations.  During that process I had an interesting & surprising epiphany:

What I wanted was not what I really wanted.

It all started with my annual goals.  Every year my peers and I write down the goals we want to accomplish over the next year.  These can include things like ‘Deliver X on schedule’, or ‘Solve problem Y’.  A useful best practice is to tie your annual goals to your bosses.  If s/he has a goal that reads ‘Release product Z on schedule’, you could have a goal that reads ‘Develop process Q to assist the successful delivery of product Z’.  Using this technique, your goals will match your bosses goals for the year and the two of you are working towards the same result.

This year my annual goals were straightforward.  I am part of a team which is working towards delivering a standalone product.  We have a schedule of milestones that we need to meet, tied to requirements that the product needs to fulfill.  My goals parallel those needs and are aligned with my boss (e.g. ensure 80% code coverage for business processes).

While many annual goals are tied to business objectives, they also can have a personal element to them.  For example, ‘80% code coverage’ is a business objective regarding the quality goal of the product.  You may have a secondary goal to acquire training on how to write unit tests to ensure you reach 80% coverage.  This secondary goal is your personal development goal.  It supports your annual goal & grows you professionally.

As I said, my annual goals were straight forward, but once I started writing my personal development goals, I found myself consistently rewriting them.  Something did not feel right, and I could not figure out what.  They related to my business objectives, but they did not seem to relate to me.  How could I complete these goals, which are supposed to grow me professionally, when they did not seem to relate to me?

After spending a couple hours rewriting my personal goals I felt I needed to take a step back and look at my goals from a different perspective.  I started with the basics:

What do I value when I build software?

Answering this question is not as easy as it sounds.  It would be easy to pen "High quality code" or "Make teams successful".  There is nothing wrong with having these values, but for me, if I used them I would feel like I was cheating.  Who doesn’t want a team to be successful?  Of course every developer strives to produce quality code (I hope).  These answers are easy & common.  They did not reflect me.

I wanted my values to reflect what I believe in, how I work, & what philosophies & practices I encourage. After a few weeks of deep thinking, I managed to distill my thoughts and beliefs in to a short list:

My Personal Professional Values

1. Continuously Learn & Apply over Stagnation
2. Maintainability & Quality over ‘Done’
3. Eliminating Waste & Rot over Complacency
4. Building Value over Perceived Value
5. Testability over Debugging

These are my values which I have either directly or indirectly promoted through the years.  While at times I may have wavered from them, I always come back to these key values; naturally & effortlessly.  They are what I believe in.  They are what drive my thoughts.  Some day this listing may change (‘never say never’), but not today.

After weeks of soul searching, writing & re-writing, I finally had an anchor for my personal development goals.  With my values acting as high-level requirements, the goals are coming quickly.

Now I write my personal development goals with confidence, knowing that they are tied to what I value professionally.  This is what I want.

Me and my Mind Maps

As a follow up to my previous post, here is a snapshot of one of my technology mind maps:

For those who are curious, the tool I currently use is MindManager Lite 7 from MindJet.  I have also used FreeMind in the past.  It is a good, free alternative to MindManager if you do not want to spend the bucks.

What is ‘Better’?

People know nothing.

Many, many moons ago I attended my first philosophy class at university.  The title was ‘ The Philosophy of Science’.  I enjoyed that class very much and I will never forget what happened on the first day.

The professor came in and sat down on the table in front of us.  He introduced himself and the course, and then he went around the room to query us on our majors.  Since the majority of the class was majoring in computing science he then posed this question:

"How do you know when you have improved a computer?"

I immediately answered, smiling with confidence that I had the answer.

"When it is faster, better, and cheaper."

The professor thought for a second and then asked me "What is ‘better’"?

Things went downhill from there.  While the class agreed that you have improved the design of a computing system when it is better than the previous version, no one could truly define what that meant.  We would spout things like ‘bigger cache’ and ‘more megahertz’, but nothing truly captured what was a ‘better’ computer.

The big lesson at the end of the course was that you can never truly know anything.  You can only alter your perceptions of what you observe to reach a conclusion, but you can never truly know.

Ok, so what is my point?

I have been on a reading spree the past year.  I have re-read some books I have not touched in years, as well as new books in fields which I typically do not touch.  I have a listing of about 25 blogs I regularly read as well.  I have also subscribed to several podcasts which I also review regularly.  Every learning I have from these resources goes in to a small collection of mind maps.  I use these mind maps in many aspects of my life such as proofing emails, organizing my priorities, and storing important information.  While I cannot provide a single measurement of how I have improved, I know I am getting better:
 

• I can quickly locate information I read months ago when I need it
• I have caught defects using my every growing checklists
• I have improved the quality & clarity of my emails
• My day "feels" more productive and in control

"Better", as the story above outlines, is a relative & perceptual thing.  While I cannot define what ‘better’ is, I do know that the small improvements I have made have made me better.