Is your ego getting in the way of your career?

If you saw the title of this post and thought to yourself  "Of course its not, how could being the smartest guy in the office hold me back." your ego might be getting in the way of your career.   If you are a great teacher but not a great listener your ego may be getting in the way of your career.   If you don't wake up every day thinking that you could fill Texas Stadium with what you don't know your ego may be getting in the way of your career.  As programmers we are typically very smart people, we solve complicated and abstract problems and others tend to marvel at our skills.  We all know that look of amazement on somebody's face when we tell them that we are a programmer.  So who could blame us for being a little "self confident".  

The key to a successful career as a software developer is to not let that ego get in our way.  I feel that there are two types of programmer egomaniacs: the "Kobe Bryant" and the "Kwame Brown".  I'm sure that most of you who read this will know who Kobe Bryant.  However, Kwame Brown is a name that most of you probably won't know.  That's because he is one of the biggest busts in NBA history.  A former number 1 draft pick who never realized his full potential and now has a hard time staying on an NBA team.

Lets start by talking about the Kwame Brown.  I was a Kwame Brown so this part will be highly introspective.  Kwame Brown was a number one overall draft pick in the NBA right out of high school.  In high school he was a big fish in a little pond.  He was talented but not as talented as he thought he was.  Since he had a relative amount of success in high school never put in the work that took to succeed at the next level.  

ColdFusion seems to breed more of these types of developers than other languages.  That is likely because its so easy to achieve a relative amount of success with ColdFusion.  The Kwame Brown doesn't like frameworks because they think then can roll their own, the Kwame Brown writes mostly in components and feels like they know all there is to know about object oriented programming.  This person picks up a technical book, reads the first two chapters and thinks to themselves, "I already know this stuff" and puts the book down. 

Its hard to say exactly what snapped me out of my rut.  I think it started when I had to open up my code to a outside consultant.  Something finally clicked inside me where I asked myself, "Is this something I'd be proud to show somebody else?"  I was somewhat confident in my approach (of course I was, I was a Kwame Brown) however this consultant started asking me things like, why aren't you using coldspring?  Why didn't you just use ColdBox or Model Glue?  Finally I decided to open up to and learn about these things he was talking about.  And the more new things I learned the more I realized that I didn't know.  IoC, unit testing, MVC, refactoring, design patterns, I was in trouble! 

The developer I am today is a completely different person than that one from two years ago.  Today I wake up each day thinking about how much I don't know and how much fun it will be to learn something new.  I actively explore different programming languages, and I read, a lot.  I read books cover to cover now.  I approach early chapters as an opportunity to learn something new about something that I may or may not I feel that I already know.   I try to blog about what I learn, nothing tells you if you understand something or not like sharing it with others.   I love looking at others code now, I pull a lot of open source projects from github and try to understand the code behind these.  I went so far as to enroll back in school to pursue a Computer Science degree to make sure that I had all the fundamentals I needed to become the best programmer I could.  One of the unexpected side effects of this is that I have a renewed passion for my job.  Each and every day I look forward to coming into work and challenging myself.  I have bad days for sure, but the number of good days I have now far outnumber the bad ones. 

This brings us to the "Kobe Bryant" type of ego maniac.  This person is the "superstar" programmer, a natural talent.  This person reads a book on regular expressions and is churning out complex pattern matches the next day.  They are usually the smartest person in a room full of smart people,  and they want you to know it.  This type of person rarely laughs at others jokes but will heartily laugh at a bug they discover in someone else's code and not hesitate to tell that person about it but rarely offer to sit down with that person and help them learn how to fix it. They hate sharing their knowledge because they get easily frustrated explaining things to others who don't "get it".  This type of developer also hates listening to others suggestions.  When a Kobe Bryant has use a module written by another developer the first thing they do is rewrite the code. 

I've worked with many of them before and I've rarely seen them become anything more than executors.   This is because that the people higher up the food chain can see how others react to these types of developers. Their team members will rarely go out of their way to sing this person's praises knowing that it will only feed their ego.  Instead their peers will watch them closely for any mistake and make sure they point it out to them and everybody else on the team.  Typically the Kobe Bryant developer is so self assured that they either don't see how others react to them or are so confident that their superior knowledge will surely allow them to rise to the top regardless if others like them or not.  Also the people doing the promoting know that they'll have to work more closely with this person and will balk at the notion of having increased interaction with this type of egomaniac.

So what can you do if you have some "Kobe Bryant" in you?  First learn to listen to others and sincerely try to value others input.  Here your reputation can work to your advantage.  If you are known as being a know it all telling someone else "that's a really good idea, thanks for sharing" can go farther than if it was said by someone who is constantly throwing around compliments.  Also actively seek out others opinions.  Even if you have no intention of listening to what they have to say just ask someone, "would you mind looking this code over for me" will make others feel that you value their opinion.   Lastly know that its OK to laugh at a stupid joke, nobody will question your intelligence if you laugh at the latest "Two guys walk into a bar" joke.

 If you suffer from either of these conditions its not too hard to turn things around and become a "Tim Duncan".  Tim Duncan is liked by others, is always working hard on his game, and is a true leader on a championship team.  That's the kind of developer I want to be, however I know that I have to work hard each and every day to achieve it and not fall back into my Kwame Brown ways.

Writing better CFML Series - An Introduction

Personally I feel that a lot of the negative comments pointed towards ColdFusion are due to the fact that its so easy to learn, and like any language, tough to master.  I think a lot of people pick it up, write a site that works, and consider themselves "programmers".  While this in itself  isn't a bad thing because the ColdFusion community needs as many developers as it can get.   I think that this leads to  a lot of poorly written CFML out there and that that it tends to give ColdFusion a bad reputation.  Instead of getting into a flame war with everybody out there bashing ColdFusion I decided to do what I could about it and write a series of blog posts that are aimed at helping entry to mid-level developers write better CFML.

One of the problems with a lot of the resources out there is that they are either too high level or to advanced.  I think there is a large void in best-practices or mid-level tutorials and articles.  Everybody wants to write about complex or advanced topics that will wow the community and have others lauding over their knowledge (who wouldn't).  

In addition to writing about the many things I have planned my goal is to put out at least two posts a month covering topics like:

• Object composition: writing useful, well constructed objects and minimizing an objects API
•  Writing maintainable code by looking at an object's functions and properties and a quick look into refactoring to make messy code more readable
• A deeper dive into MVC and what "separation of concerns" really means also some guidelines to where objects should live in the MVC pattern.
• Loosely coupling objects and why its a good thing  along with a brief overview of dependency injection.
• What in the world are interfaces and why you should implement them and use them for a functions return type and parameter types?
• Some best practices when writing ColdFusion

If anybody else has any suggestions for things they frequently see in poorly written CFML please let me know, I'd love for more ideas on things to write about.

Book Review - O'Reilly's "97 Things Every Software Architect Should Know"

“97 Things Ever Software Architect Should Know” by O’Reily media is a short book composed of 97 short essays by a variety of contributors.   Before reading this book my expectations were somewhat high for it as I was recently assigned the official title of “Technical Solution Architect” so I was hopeful that I could glean a lot of knowledge from some seasoned industry vets.   

One of the first things I noted about this book was that it seemed relatively short for 97 solid pieces of information, the book weighs in at 264 pages in ePub format.  Most good authors with something important to share typically have a hard time condensing a good thought into less than 10 pages. When I read a technical book I always highlight interesting or helpful information that I want to remember.   One of the most concerning things about this book was that I didn’t highlight a single item until chapter 10, or approximately 9.7% into the book.  This chapter talks about quantifying results which was one of the best concepts I took from the book.  The main principal here is to use quantifiable measures in your requirements instead of abstract terms. Instead of adding the words “quick response time” to a requirement use “average response time in under 20ms” instead.  

A lot of the chapters in this book talk about some very fundamental concepts such as simplifying your technical design, which a lesson that I think would do a lot of us good to stay true to.   Other things stressed in this book are:  always put the client first when architecting an application, focus on the maintainability of the system, don’t over plan for the future, plan for today, and to always try to loosely couple system dependencies.  

While in the end I didn’t feel that I learned a whole lot from this book I did find it a quick and somewhat enjoyable read.  It also does a good job of enforcing some fundamentals that we all tend to forget over time.  It was a good refresher to focus on simplicity and the client’s needs.  Too often when architecting an application it’s easy to get wrapped up in implementing the latest frameworks,  go a little overboard with design-pattern s, and over obfuscate simple tasks.   

I wouldn’t recommend putting this book on the top of your “to read” list if you are looking to improve your development or architecture skills.    I would put it somewhere after Fowler’s “Refactoring” and “Patterns of Enterprise Architecture” books and somewhere above “Access 2010  For Dummies”.  If you don't find it the most stimulating book you've ever read you may get a few lol's out of some of the pictures the authors chose to submit.  I know more than once I thought to myself  "That was the BEST picture that person could come up with?", you can decide for yourself who I'm talking about.  To find out more or to purchase this book check it out on O'Reilly's website here http://oreilly.com/catalog/9780596522704/.