Starve Your Fear

Fear

How far are you willing to go to conquer your fears?  I read the other day about a guy who, to conquer his Fear of social rejection, began asking random strangers at restaurants for a bite of their food.  Sound extreme?  Yep…and creepy but I like this guy.  He confronted his Fear head on. Is that something you are willing to do? Confront your Fear head on?

Fear is Irrational

We like to think of ourselves as rational, confident, independent actors yet our actions say otherwise.  We are afraid to take the chance, afraid to step out into the unknown, afraid to fail, afraid to embarrass ourselves.  If, however, we were to sit down and write out the specific, nitty-gritty reasons for our Fear we would come up mostly blank.

Fear is a shadow that lurks in the dark corners of our mind whispering vague threats.  We are afraid to look directly at it and so it grows feeding on a perpetual loop of bad information, doubt, misgivings, and irrationality.  The longer we harbor Fear, the more room we give it by not confronting it, the stronger it grows.

Starve Your Fear

Do you know how to get rid of your Fear? Starve it.  Do not even give it a chance to take hold.  When you feel that first twinge of Fear take immediate action and confront it.  Taking immediate, strong action robs Fear of its power.  It starves it of its food source.

  • Afraid of confronting a direct…do it now
  • Afraid of giving a presentation…volunteer to go first
  • Afraid to make a sales call…make 20…today
  • Afraid you cannot figure out a problem…tackle it now and resolve not to sleep until you solve it
  • Afraid to start a diet because you will fail again…go straight to a gym and hire a trainer right this second

Taking action reveals Fear’s lies as just that.  Call Fear’s bluff and it shrivels to nothing.

Take Action Now

Your turn to take action now in a big way..  What are you afraid of? How are you going to starve your Fear?

Never Say No

Developers, Never Say No To Your Customers

Bad customer service is maddening. Very few things get me more worked up than a customer service rep telling me they cannot help me because “it’s against their company’s policy.” This translates directly to “I have the ability to help you but my company has decided we do not want to.”

Software developers please raise your hand. You are in customer service. Your customers are marketing, sales, accounting, and every other departments in your company. Start treating your customers like customers. (You two in the back who put down your hand…put it back up.)

Those of us in dev land are notorious for how poor our poor customer service. We have the stereotype of anti-social, disconnected, and organizationally unaware employees who interact with the users only if they absolutely must. We routinely frustrate our customers with our unwillingness to think about what we do in business terms.

Don’t believe me? Take some time to go talk to some of your customers.

Where to start you ask? Stop saying “No”. When a customer comes to you with a feature request, enhancement, or whatever you do not get to utter those two letters. It’s not our role to unilaterally shut down a customer’s idea.

But I hear you thinking (yes I can do that)

  • “these requests are often made in isolation without consideration of everything else going on.”
  • “I will be overwhelmed with a deluge of unfocused features”
  • “The customer’s idea is completely unreasonable”

Stop, take a breath, and relax…I did not say you had to just automatically say “Yes”. I just said stop saying “No”.

What to Say Instead of No

If you want happy customers and better relations the proper response is always, “Yes, absolutely, we can do that, and…” by saying “yes…and” you are showing your willingness to help and your ability to put the problem in terms of business value. The “and” depends on the context but the following are some of the examples of “and”.

Quantify Cost

Explain how much the new feature will cost in terms of both time and money. Your customers have budgets. They understand cost. This is their language. In fact the entire business speaks in these terms. Costs vs. Revenues. They are not as irrational you believe. (Well maybe marketing but everybody else is solid.)

Describe Tradeoffs

Explain what will not get done if you spend time on this new feature. Everything we do is a tradeoff…it is just another form of cost. Work on one feature necessitates not working on another. Everybody in your organization understands this.

When they make a request they may have not understood the impact on feature trade-offs, nor should they. That is our job to help them. Just like you do not understand the details of what other departments are working on they have very little idea of your own process and priorities.

Offer Alternatives

Take some time to understand why the user is requesting the new feature in the first place. I have found they typically have a pretty good reason. They have a pain point they need fixed and so they come to you with the first idea that comes to mind. Chances are there exists a dozen other ways of solving the same problem but with lower cost and fewer tradeoffs.

Be a Partner not an Adversary

Bottom line, treat requests as if from a partner or valued customer…because they are. These people are not supplicants looking for handouts or an adversary to compete with. They are members of your organization working toward a common goal.

Make yourself part of the solution and not a barrier to it.

Deciding to Change

Have you made the decision to change or at least make a change? I do on an almost daily basis. More particularly, I work constantly on personal development (there is a lot to improve) and every time I think I have things figured out somebody confronts me with 10 more things I still need to grow in. Recently that has been the Chirs LoCurto podcasts.

Here is what I run into and I am sure I am not alone. The practical, concrete, “lets do this thing” next step is not always clear.

It is so easy to come away from a great podcast, book, or video and be fired up about doing “the thing”. But then not sure what the next step is to achieve “the thing”. So much of the material available is inspirational not prescriptional. Nuance isn’t always my thing. Give it to me straight baby. What is the next concrete thing I need to do cause once I got it I’m all over it.

Also, the thrill of inspiration lasts till about minute 3 into the workday. And then its gone, lost to the urgency of the moment. Time to get stuff done and inspiration doesn’t cut it when the world is on fire.

Here is my approach to the problem (perhaps not optimal but I’m going with it)

I consume a ton of material and am offered lots of advice from various authors. When I see a trend or find a couple of items that really appeal to me I pick one thing, break it down into a couple of next steps and start working on it and just ignore all the rest. (as a side note I don’t make some comprehensive overarching plan because then I would never get to it)

If I don’t do this the onslaught of info is overwhelming and I just do nothing.

JavaScript Prototype Chaining Isn’t So Scary

Prototype Chaining From 35,000 Feet

The first time I heard the term ‘prototype chaining’ I was impressed.  It sounded fancy…and complicated.  Turns out, it is not.

Prototype chaining is composed of two words (see I told you it was easy)

Prototype: The word prototype means template, master copy, or design pattern. Templates are used to create exact copies of other things based on the original design.  Think of a rubber stamp, stencil, or one of those little play dough forms used to make tiny ice cream cones.  JavaScript prototypes are just like that.

Chaining: In the physical world chains are a series of metal links connected in series to form…well a chain.  One link hooks to another which hooks to another.

Based purely on this word breakdown JavaScript Prototype Chains are simply a series of object prototypes all linked together in some sort of linear fashion.  I know, still not clear but keep this mental model of a chain in place as you read through the rest of this article.

Prototypes

JavaScript prototypes are analogous to base classes in traditional Object Oriented languages such as C# or Java.  The purpose of base classes is simply to extract shared functionality in such a way that multiple classes can share this functionality without having to have their own copies.

Now JavaScript does not have classes.  It really cares only about functions…no class warfare here (society could learn a lot from JavaScript).  Functions are everything to JavaScript.  You can instantiate them, create anonymous functions, assign functions to variables, pass functions into other functions as parameters, and return functions from other functions.

Instead of using base classes like its OO brethren, JavaScript functions have a special property called prototype.  This special property is actually not all that special.  It is, at its core, simply another property.  This not-so-special property contains a reference to another function.  Any functionality exposed by this prototype function is automatically inherited by the function that the prototype is attached to!

Examples you say? Get ready to be disappointed.  There is not much to show you.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// Define a basic function
function Car(){}
 
// Define a basic function that identifies itself
function Vehicle() {
     this.whoAmI = 'I am a vehicle';
}
 
// Car inherits from vehicle
Car.prototype = new Vehicle();
 
// Create an instance of 'Car'
var myCar = new Car();
 
// Asking myCar identify itself causes it to call the inherited
// code in 'Vehicle'
console.log(myCar.whoAmI); //'I am a vehicle'

That is it!  Now Trucks, Bikes, Motorcycles, Buses, Airplanes, and Zeppelins, can share in the Vehicle goodness without having to making their own copies of the “whoAmI” code.

Side note: there is actually a slightly better way of setting prototype but for the simplicity of the sample I wanted to leave it out.  I will create another blog post on setting prototypes at some point in the future.

Chaining

Chaining is just an extension on our discussion of prototypes.  As stated earlier Prototype Chaining is simply a chain of prototypes.  This chaining occurs when one function’s prototype property is itself a function with its own prototype property.

Here is an example

1
2
3
4
5
6
7
8
9
10
11
12
13
14
function Car(){}
 
function Vehicle() {}
 
function Machine() {
     this.whoAmI = 'I am a machine';
}
 
Vehicle.prototype = new Machine();
Car.prototype = new Vehicle();
 
var myCar = new Car();
 
console.log(myCar.whoAmI);

In this code sample the Car prototype property points to Vehicle function and the Vehicle prototype property points to the Machine function. Side Note: we never set the Machine prototype property so where does that point? It points to Object and Object.prototype is null.

On the last line when myCar.whoAmI is called the JavaScript engine looks in Car for “whoAmI”.  When it cannot find it there it checks the Car prototype.  The Car prototype is Vehicle which also does not contain a definition for “whoAmI”.  Again the JavaScript engine checks the Vehicle prototype, “Machine” and finally finds the property “whoAmI”.

prototype chain

 

semantic side note: You will notice the use of __proto__.  This property is the real object used in the lookup chain.  The prototype property is used to actually populate __proto__.  Not all js engines allow direct access to this property though so stay away from using it for now.

 Prototype Chains in Chrome

For the following code snippet:

1
2
3
4
5
6
7
8
9
10
11
12
13
function Car(){}
 
function Vehicle() {}
 
function Machine() {
     this.whoAmI = 'I am a machine';
}
 
Vehicle.prototype = new Machine();
 
Car.prototype = new Vehicle();
 
var myCar = new Car();

Here is what the prototype chain looks like in Chrome’s web tools (notice the use of __proto__):
Prototype chain from chrome

Hiring Criteria: Work Hard and Deliver

Hiring Criteria: positive traits

Works Hard

This does not mean nights and weekends and four-month death marches.  It means hitting the ground running, focusing on your work, and finishing the job.  This means leaving the office exhausted because you gave it everything you had.

Passionate about software

Software development is more than just your job.  It is your passion.  It is part of who you are.  Do any of the following describe you?

  • Regularly listen to software podcasts
  • Build hobby projects
  • Try new technologies simply because they find them interesting
  • Quote Spolsky on a semi-regular basis
  • Carry a copy of Cormen with you because it is your favorite reading

Insatiably Curious

Curiosity allows us to think find solutions to difficult problems.  We want people who are constantly asking why, testing their assumptions, and exploring novel lines of thought.

Gets things done

Hard work, passion, and curiosity are worth only so much if you can’t ship product.  We need people who know how to deliver features.  It is easy to talk the talk but when things get hard are you a person who can get work done?  The ability to deliver value is my number one hiring criteria.  (this has not always been the case but I have learned to look for it)

Hiring Criteria: negative traits

  • Victims.  Step up and find a solution.  You do not need somebody holding your hand.
  • Rock-stars, ninjas, or prima donnas. We win and lose as a team.  This is not a personal sport.
  • Whiners and gripers. We want people who spend more time worrying about delivering software than they do about all the things that are wrong.
  • Free riders. We are here to get things done.  Do your share.

Simon Sinek: How great leaders inspire action

Why vs. What by Simon Sinek

Simon Sinek giving a talk at TED back in 2009.  Why do some companies seem to reach their customers better.  Why do some succeed and others do not even though they share the same environment and abilities.  They understand their Why not just their What and How.  When you understand the Why and communicate it your audience understand it visceraly.

Simon Sinek: How great leaders inspire action – TED

Book: Rhinoceros Success

Rhinoceros Success :
the Secret to Charging Full Speed Toward Every Opportunity

By:  Scott Alexander

Rhinoceros Success : the Secret to Charging Full Speed Toward Every Opportunity

Are you a Rhino or a Cow?

Rhinoceros Success : the Secret to Charging Full Speed Toward Every OpportunityRhinoceros Success is the first (and probably the last) personal development book I have read that uses rhinos, cows, and torpedoes as a metaphor for life.  It employs kitsch, hyperbole, and melodrama to make its point.  The book is combines clichés, mixed metaphors, and fragmented sentences.  Truthfully, it is ridiculous.

…And I love it.  There are not many books I will read more than once and this is one of them.

In this book Scott Alexander asks you if you are a dumb cow sitting under a tree letting life just happen to you or if you are a hard charging rhinoceros chasing down what you want, laughing at troubles, and running over every obstacle in your way.  He also points out that rhinos are not afraid of torpedoes.  Are you afraid of torpedoes?  If you are then you are a cow.

Some have given this book a poor rating.  I think they have missed the point.  They are the intellectuals, business book authors, and mid-level managers (me raises hand) who want to over complicate winning.  They are cows.

They see successful people and not emulate them they back fill complicated stories about how these rhinos got to where they are.  Creating these stories makes them feel better about themselves.  If they can come up with an intricate enough of a story then it is not their fault that they are mediocre cows just waiting for the jungle to decide their fate.

What they do not realize is that the successful people upon which they endow mystical, secret knowledge are in fact just like them but are simply willing to do what nobody else wants to.  They take on obstacles that scare everybody else.  They do it by being a hard-charging rhinos that laugh at difficulties, get knocked down but then spring to their feet and continue charging.

I’ll leave it up to you to decide if you are a Rhinoceros or a Cow.

Want to be effective? Stop with the email.

How many times have you been in a meeting when someone is asked a question and they look up from their computer, slightly startled, and say something like,”Could you say that last part again? I’m not sure I understand.”  They try to play it off as if they are just thinking deeply about the question but their face gives away the fact they have no idea what has been going on in the meeting for at least the last ten minutes.

Few things at work gets me worked up more often than people checking email in meetings.  I am getting mad now just writing about it.  Checking email during meetings is the most expensive, time-wasting, inconsiderate activity you will find regularly practiced in the corporate environment.

Email in Meetings is Expensive

Meetings are one of the most expensive things we do at work.  There are several people sitting in a room for, typically, an hour at a time.  When you take the average hourly rate of all the attendees and multiply it out your realize how much it costs for the luxury of these face-to-face discussions.

Delays caused by distracted attendees are not just to that person’s time alone.  The cost is the time of everybody in the room.  Every time the meeting stops to get someone up to speed the delay is compounded by the number of people in the room.

If meetings are so expensive then you may ask why we hold them?  the answer is face-to-face communication is orders of magnitude more effective than holding conversations electronically.  Email is a poor substitute for in-person discussions.  It is the reason people will fly halfway around the world just to attend a meeting.

Email in Meetings is Inconsiderate

Actively “doing email” in meetings is as inconsiderate as answering your phone while at the front of a checkout lane, interrupting someone else’s discussion because you want to ask something, or using your speakerphone from your cube.  In each case the person interrupting others is saying his needs trump everyone else’s.

If you do not find these inconsiderate then you have bigger issues.  If you do, however, get frustrated by these kinds of things you should realize that emailing during a meeting is absolutely no different.  When you email during a meeting you are effectively saying you have more important things to do and everyone else should adjust to fit your super-busy workload.

Email in Meetings is Ineffective

Study after study shows that people are not multitaskers.  Multitasking just does not work.  A person cannot do two things at once and still do justice to both.  People that say they are effective multitaskers are fooling themselves. Period.  They may indeed be better at multitasking than others but going from completely ineffective to partially ineffective is not adequate.  They are still harming the output of both tasks.
If a person is so busy they absolutely must stop everything they are doing to check email then they should not be in the meeting to begin with.  They are not doing justice to either the email they are sending nor the meeting they are attending.  They need to pick one and attend to it exclusively.
Additionally almost all email can wait several hours for an answer.  Email, by its very nature, is asynchronous.  There is no guarantee when or if the recipient has read it. If the issue were indeed so critical that the sender needs an answer immediately it is the job of the sender to get up from their desk and find the person they need an answer from.

Not Convinced?

Who is the most effective person you know?  They are the person with the busiest schedule that still gets the most done.  Watch them the next time you are in a meeting with them.  My guess is you will rarely see them checking email.
Ask yourself this question: If the CEO of your company invited you to a meeting would you be busy checking your email?  Would you expect the CEO to be checking email?  If the answer to both of these is no then you should not be checking email in any of your other meetings.