It is a sincere privilege to be in an occupation where I get to work with so many smart people. However, there are big downfalls, one of which I am growing impatient with – patronizing the intelligence of co-workers.

Too often people skirt around the core of this issue with generalizations that developers are egotistical, socially inept, and “too smart for their own good”. All though those may be both foundations for and symptoms of the core problem, the real issue is generally found in everyone and is much more selfish. Most intellectuals don’t appreciate other people’s intelligence.

It’s true…but why? Here is my hypothesis…

Let’s say someone spends a week running research and development on a particular sticky piece of code. The solution is well thought out, assumptions tested, and code spiked to ensure that out of all possible options this path was the most correct. Now that person shares the answer with the rest of the team – what do you think the most common answer would be? The most common answer most of the time comes out “Duh…obviously…”, and herein lies my heartburn.

People don’t appreciate other peoples’ knowledge. People don’t appreciate other peoples’ wisdom. Most importantly, people don’t appreciate the provided, immediate shortcut of the other person’s journey.

Just because you can grasp the answer does not mean you have the knowledge, wisdom, experience, or work ethic to come to that answer. Additionally, even if you do – praise the person for giving you a shortcut to higher knowledge! Rejoice in the fact you have a colleague or maybe even a mentor!

I could have simply preached, be humble and appreciative, but that is not enough because that is a topic intellects can understand and as a result undermine it. Truly being humble and appreciative is an act that is continually learned through continuous self realizations. The next time you respond to your co-worker, boss, or intern reflect on what you just said and how you said it…you just might catch yourself being a jerk who says “duh…”.

Something that gets continually drilled into everyone’s head is that in order to become more efficient we need to eliminate all the noise in our personal and professional lives. Focus on what matters and keep a blind eye to everything else.

Before the birth of my first son, I will be the first to admit that I was an unfocused procrastinator with a pinch of twitteraholism. After his birth I found myself with only about 2-3 hours a day to accomplish all the extracurricular interests I had. And as a result, I found myself giving up many previous luxuries such as video games, leisure reading, and even cutting back on night caps.

Now after the birth of my second son (to put this into context, that is two under the age of 15 months of age), I have almost no time what so ever to do any of my interests let alone work on all the aspects of my business that I wish to grow. You know there is no hope of ever playing Xbox again when you can’t even find the time to mow the lawn in the last month. However, amidst all of the chaos, I have accomplished more in the last month than ever before.

I don’t know how many times I have heard people preach “Stop listening! Stop analyzing! Start doing!”…and now that I have been *forced* into practicing this I feel more focused, energized, and productive than I ever have in my entire life.

• Email – Processed once a day…maybe…
• RSS – Speed processed twice a month…maybe…
• Phone – I will answer during work hours….maybe…
• Twitter – Turn on then off 1-4 times a day (still a voyeuristic vice)

And that is just what I have done with my applications. Here is a longer list cross sectioning many aspects of my life:

• Moved from dual monitors to single monitor to increase focus and decrease screen real estate for time sucking apps
• Work in coffee shops to minimize distractions of co-workers and family
• Hire out to a neighbor kid (or neglect for long periods of time) chores like the mowing the lawn or washing the cars
• Make myself committed to time lines and promises that I can not easily break to increase prioritization of tasks

The list goes on and on….

Anywho, I am not going to keep rambling on as I need to get some other things done…and I suggest you do as well.

Quit reading this damn article and get something done today.

Here is my big thought for the day:

The correct process implicitly guides people into correct behavior. The correct architecture forces code into the correct patterns.

A few weeks ago I wrote about how Tracer Bullet Architects show true leadership by creating clear and direct paths prior to the entire team coming aboard is probably the most important activity of a successful project.

However, I would like to take this one step further and suggest that if [as a team leader] you install the most correct process people will want to participate in correct and efficient behavior.

For example, when Napster was first introduced millions of people illegally downloaded music. Why? Not because they were bad people, but because they had no other mechanism for which to purchase (and own) digital copies of their favorite songs. Apple came along with iTunes giving people the first reasonably priced and easy to purchase model which included digital ownership – and the rest is history. People want to do the right thing and will given the correct means.

Building on this concept, it is possible to create project infrastructures that force developers to adhere to good practices such as SOLID. Seriously…I have done it. Some of these architectures would range from MVC/DI/IoC/Mock goodness to Tiered/Stubs/Statics/MockingIsEvil grossness, and each was a good fit given current company. It was the architectures that enforced clean lines of responsibility, increased testability, and [as a result] increased stability.

Of course people can break processes, of course they can break code, but if the correct solution is in place – they have to try really hard to do the wrong thing. If people continually are breaking process or code, then the answer is easy – you currently have the wrong solution in place.

Creating a zero friction environment is rarely rewarded by your peers; however, it is the most rewarding personal achievement one can accomplish.

If you do something correct, it is as if you did nothing at all. -God (as seen on Futurama)

Everyone is talking about Lean organizations, but what does that mean?

A lot of people think becoming more efficient means minimizing cost and time to market; however, there are other ways to look at it. In the end, the only thing that matters is the ability to measure…

Alan has been writing some really good material on processes and people (yeah weird, who would’ve guessed I would read something like that). The article that really grabbed by attention was: Stopping People From Switching Off During Standups.

Here are some other favorites:

• Building Software Development Expertise – Using The Dreyfus Model
• What’s Your Team Building Budget? – Creating and Recognising Team Building Opportunities
• Why Teams Succeed And Why They Fail
• How To Retain Your IT Employees For Longer

Be sure to stop over and give some of his material a try, I hope you find it as helpful as I have.

As Spiderman once put it, “With great power comes great responsibility”… well unfortunately there are a ton of roles and people that have never heard that phrase because I continually run into people who believe their current position entitles them to bossing people around while providing little value in terms of leadership. I am a huge believer of leading by example and as a result I have modeled my architectural duties around the Tracer Bullet Development tactic.

If you have never hear of tracer bullet development, it was a term coined in the classic The Pragmatic Programmer: From Journeyman to Master. In short, it is very important to trailblaze unknown territory through activities such as mockups, prototyping, and spiking.

However, I sometimes find “architect” level people providing no more worth to their team than a whiteboard full of boxes and arrows and a mouthful of hollow words of encouragement (sarcastic quotes explained). What teams need is clear direction on a clear path.

If what I just said wasn’t clear enough, let me be more blunt – whiteboarding and diagramming are the lowest forms of architecture and they provide the least amount of worth. I realize that I will receive some comment on how in their company is special and creating BUFD UML diagrams is key, blah blah blah. The point I am trying to make is, these activities 99% of the time are nothing more than echoes of the obvious – as a leader it is your responsibility to give direction to the non-obvious!

For example, the current project I am on we need to provide a very rich search capability. As an architect you could really suck and throw some buzzwords at your developer and send them on their way. You could suck less by throwing a couple of real technologies to a developer to give them a launching point for research, but more than likely you are delegating a very important architectural decision to someone who is not veteran enough to make the correct choice. The final option is, you do your job and lead by example by researching the alternatives yourself, picking the path, creating a prototype to validate your hypothesis, and then hand it off with a pre-cleared path.

In order to become a trailblazer, you have to blaze trails. Good architects do not blaze trails with their bossyness and whiteboard markers, instead good architects do it with their intelligence, code, and ability to communicate.

PS – Here are a few more tracer bullet resources, here and here.

Embrace Pain – Ian nails it on the head exactly why most organizations ditch new processes – they can’t stand to endure the pain the mirror brings.

Scrum-Ban – Excellent article as it really illustrates the evolution that most organizations go through as they attempt to move from Agile -> Scrum -> Lean.

The 7 Software Development Wastes – Part 1 – A good introduction to the different types of waste (or muda for you Lean folks).

Sometimes, The Better You Program, The Worse You Communicate – Leon explores the quiet side of developers and why it is bad.

One Day In Kanban Land – The LOL for the day.

Sigh…

First and foremost, let’s address the question, “How do we get others to learn?” I find this question so egotistical and self serving it pains me. A guru that sits atop of the mountain does not climb off of it to go door-to-door knocking looking for students. Why would he? Climbing the mountain is the first sign that the student is willing to put forth the effort to learn.

Additionally, what about allowing survival of the fittest to run its’ course? If some developers walk around with their eyes and ears closed it will not be long before people, companies, and universities will have to “ratchet-up” in order to survive against better and faster competitors.

As for “it’s our duty” portion I say – bullocks! If you sincerely feel a sense of duty, then super cool. Be a blogger, be a author, be a mentor; however, it is not your duty. In order to say “yes” to something you have to say “no” to something else. If you choose to teach your mantra just know that you are taking away your time and attention to something else whether it be your family, work, or even the practices that allowed you to be good enough to teach your wisdom. You can be a hermit guru if you wish and the world will keep spinning.

I recently bumped into this story and found it quite appropriate:

In ancient Greece there once lived a wise philosopher, he was greatly admired by his peers and extremely smart for his time, indeed he was considered a genius. There was a young man who looked up to this philosopher with great admiration, he wanted to know everything he knew, and become great like he was.

The young man approached the philosopher one day seeking to become an understudy. The philosopher informed the young man that he would not teach him – he was not a teacher but a philosopher. The young man persisted, he asked the philosopher every morning for a lesson, anything would do. This went on for several months. Finally, one day the philosopher agreed and informed the young man that his first lesson would be taught at the beach the following morning, he was to meet him there at dawn sharp.

The young man didn’t sleep much that night, he was anticipating the great lesson he would learn about the ocean, or maybe the sand, or maybe some deep insight to the mating ritual of crabs; it didn’t matter, he was finely going to learn something. He showed up at the beach at dawn sharp as agreed, but the philosopher was no where to be seen. He scanned the beach up and down several times, he gazed as far as he could down the road to town hoping his teacher was simply late, nothing.

A little discouraged he sat down and gazed out into the ocean, and then he saw him, or his head rather, about seven paces out into the water, submerged all the way up to his chin. The young man was surprised but excited, he leaped up and ran out to his new teacher as fast as he could. When he got within arms length of the philosopher, the philosopher grabbed him by the arm and twisted him under the water, the young man struggled, but the philosopher was fast and agile, he had a firm grip. The young man was unprepared to be forced under water so quickly, he only had half a lung full of air. 10 seconds passed, then 20 then 30, but he could not free himself from the old man.

Panic started to set in, he realized that he was about to die, his vision started to tunnel, he desperately needed some air. Just before he was about to give up and take in a lung full of sea water the philosopher let him free. The young man, quite frightened, swam as fast as he could to shore. He yelled out to the philosopher and asked, “What was that for, are you crazy?” to which the old man replied “That was your lesson. When you want knowledge as much as you just wanted air, you’ll find it” – Found on SerenityCheck

Bloggers, authors, forum contributors, speakers, and team leaders – I salute you. You continually open the door of wisdom to many, but it is the student’s choice alone whether or not to walk through.

We all do it.

File, Open. Scroll down, scroll down, pause. WTF!^$%@!. Scroll up, pause. Scroll down. “Wow……, dude you have to come look at this…”

Yeah, we have all been there, finding code that we love to hate. It’s sloppy, hard to read, and looks like a monkey with no fingers pounded it out. Code so ugly only it’s mother could love.

But really who can blame software developers for hating other developers code? A large part of software development is artistry and intellectual matter. I assume that literary authors have a difficult time truly enjoying other authors’ work because either they believe it is horrible or they deeply respect it but then have a sense of jealousy.

So what can we do to find enlightenment instead of anger in these moments of discovering rotten intellectual stew?

Laugh

It is very easy to get angry, but why? The damage is already done, so let’s do something constructive.

Pretend that you wrote the code 5 years ago. Hell, maybe you are looking at your own old code – oh the irony! Whether a co-worker, past employee, or you wrote the code – take a moment to chuckle at it. Chuckle at it’s complexity, chuckle at it’s comments, but most important chuckle at fact that you once were at this point too and that is why you are now wise enough to recognize a better way of doing things.

Learn

One of the largest life lessons I could ever learned was to take every single moment, reflect on it, and attempt to learn something new.

Although there may be a dozen better technical implementations, take the opportunity to speak to the original author and try and understand what they were thinking. In my career, the most enlightening moments have been listening to the innocence of interns.

Learning goes both ways, and be sure to also teach offenders why some code is smelly. Teach the wisdom, direct the plan, and help (or review) the execution.

Leave It Better

I don’t know who started the “Campground Rule” but Uncle Bob used it in his book Clean Code:

We should leave the code cleaner than we found it – Robert Martin

Identifying and laughing at bad code helps you accept it, but only fixing it helps you find new love in it.

To-do list is so long! I will prioritize by first doing “What will most piss off the client if it isn’t done”. Then move on to “irritate”. – AmazonGrace

I have written about prioritization of your Most Important Tasks (MIT) before; however, I thought this to be an absolutely brilliant way to look at your priority list.

The moral of the story – success is relative, client happiness is an objective one-way street. Even if a project is an extreme failure in your eyes, concentrating on the tasks that the end clients/consumers measures success is [the majority of the time] the correct decision.