Be Humble
Published: 2019-10-16 03:56:21

---
title: Be Humble
published: true
date: 2016-03-30 06:16:00 UTC
tags: 
canonical_url: http://www.patrickhyatt.com/2016/03/30/Be-Humble.html
---

Using the poorly referenced dictionary patrickhyatt.com

> Humble (adjective) :
> 
> 1. To keep oneself below the their own egos growth.
> 2. To not be a dick, to not belittle

Programming, or programming in the business realm at least, has a tendency to generate highly skilled individuals, that master an area of knowledge.

Lets take a look at two completely made up examples: Sally, the quality assurance engineer, that sits in the back and has been around for a few years. She _owns_ the application that processes credit cards and refunds. She knows she owns it. There is honestly nobody left in the company that has any knowledge of the product, but her.

Jorge, the quiet developer, that barely speaks louder than the whisper of a feather that falls. Jorge is _the_ guy to to go to with SQL issues. He previously worked at Oracle and knows all kinds of performance tweaks and shortcuts.

Approach both with a question in their area of ownership/expertise.

<!--excerpt-->

How do they respond?

Sally

> “Oh, hey, yeah that exception with the credit card submission, that does look like a problem. I can’t believe we missed that! Send me a copy of the exception and I’ll see if I can reproduce it so we can isolate the issue and get out a fix.”

Jorge

> “Interesting. Definitely not me, that is too amateur of a bug. I think that was Alex’s, but he left the company.”

### Q1. Who would you rather work with?

### Q2. Which response fosters better learning?

### Q3. Which person has interest in the ultimate goal?

The field really does not matter, but in the field we work being historically more introverted/shy people, this stuff is poison. It will slowly kill off any interaction between important knowledge bases. Who wants to talk to Jorge, if every time something goes wrong he will very likely push you onto a non-available ex-employee, that helps none.

Personally, I try to help everyone that gets the urge to ask me. Especially if it is an area of code that I wrote or modified heavily. If I touched it, I immediately assume I introduced the issue. Assume it is in fact my bug/issue that a fellow developer or QA member is reporting. And as a result of owning that, it’s my responsibility to help get it addressed.

This can obviously be huge interrupt to my own tasks. I mean Bernie Sanders HUUUUUUGE (just in time for election season..). However, I strongly believe that most success comes from working with each other and getting through issues as a team/company. I do not know who to attribute my approach to really. Maybe it’s I am the [best programmer in the world](http://blog.codinghorror.com/why-im-the-best-programmer-in-the-world/), or maybe it’s because [I’m a phony](http://www.hanselman.com/blog/ImAPhonyAreYou.aspx). You can make that decision.

This sounds so corporate team builder-ish, but it is not even close. Forget the trust drop, or sinking a hole-in-one, or building the highest paper tower. These things emulate work, but everyone understands that after exercise is over, you all go back to your holes and never work with the group again.

Take a slice of humble pie, choke it down. It may seemingly suck, but it sucks as an individual, and rarely are you an individual when it comes to success.