Tuesday, August 26, 2014

To take thy code personally - Yes or No? That is the question...

One area of conversation that tends to come about in software engineering is the degree to which one takes their code personally. Litmus test: that shiny gem you wrote was code reviewed and recommendations are made to make some changes. Do you:
  1. turn red, tell the reviewer how idiotic they are, storm away, and start looking secretly for a new job?
  2. listen to what the other party has to say and make sense of it as a learning experience?
Now this is only one of many examples of taking code 'personally,' and realistically is a bit of an extreme in option 'a.' This behavior though takes shape and evolves in different ways, but I believe if this is an attribute you posses it's one to shake and shed fast for the betterment of your career,

I have for years stated it wasn't the physical lines of code I laid down, but the byproduct of what I learned that is the real personal reward. I've written apps over the years that for one reason or another didn't make it to prod or where short lived. However the experienced gained from what I did was what kept moving me forward.

For example - "Hey Allen, you aren't upset that app you worked on got scrapped because the business did a 180?" Me: "Nope. Because now I know a ton about x, y, and z and am a better developer for it."

I actually had a (technical) debate/argument about this topic with an industry peer within the last few years. I stated I don't take my code too personally and the experience gained was paramount (after all that continued experience helps me move on and do bigger and better things). Sure I absolutely want what I create to succeed, but if it gets thrown out, rewritten, refactored, or the like I will not loose any sleep at night. I will however if it presents itself take note and learn from it to grow. This person couldn't understand why I wouldn't take great pride in what I did and die by the sword if need be for the lines of code I write and that those that took their code personally were more along the lines of what they thought were 'great programmers'. Problem with this is you so much as critique the architecture/design of ones code with this so called 'passion' and get ready... it's like you just told them they have a 3rd eye or something.

Do not confuse taking your code personally with instilling quality in an application. These are separate and one does not depend on the other. If the code you are responsible for is used on an aircraft and in charge of avionics - sure you absolutely care about that code and it's quality. However, the aircraft dev guru that told you your C++ methodologies were outdated and we are programming for Boeing not Pan Am in the 70's - you need not again take this personally. If you care about your craft you will truly try to grow from others suggestions and wisdom, learn from your experiences, and continue to move forward.

Next and also important, do not confuse taking your code personally and having passion for your craft as a software engineer. Again these are not intersecting lines. I have a major passion for my career and craft as a software engineer. It's what keeps me on the computer late at night learning new technologies, preparing for presentations, and blogging. This has nothing to do with taking personally the code I write. Taken from "the grumpy programmer" and said best by someone with uber experience, "Don't fall in love with your code."

Before posting this I read over what I wrote a few times because I don't want it coming across as I don't care - because I absolutely do; ask those I work with and they should concur. However, I don't let that VB6 app I wrote 12 years ago and put my blood, sweat, and tears into and the fact that it's no longer used bother me one bit. However, the knowledge I gained at that time helped get me to where I am today.

So the answer to the title - 'no', do not take your code personally. Odds are the lines of code you write today will not be around in 10 years. Instead try to find great joy in the experience you gain from what you do because you can take that with you from project to project and it will certainly be around for many, many years to come.


  1. Totally agree with the post, well at least certain aspects...

    Applications will live and die over time this is a fact and no arguing that point. I believe different individuals gain different experiences from developing applications. Speaking as a purist developer who cares about nothing more than coding and derivative experiences… then I agree whole hardily that each coding event yields knowledge to use a building blocks to be an excellent developer. The blocks are built in the same way for those open minded individuals that seek more than just technical experiences. In life it is very natural to possess passion for what you do and the products you create. Did you create something 3 months, 6 months or even a few days prior that you could do better? Yes. I have been there so many times where the blocks of knowledge gathered offer new perspective on how to refactor/reshape a design used to make it more efficient, easier to read and easier to maintain over time. Unfortunately considering business constraints it is critical our development team build systems that survive long periods of time. To be successful as a team is absolutely mission critical to build with long range vision of how can these products survive the test of time. A business does not have the appetite to throw away money (or at least in my experience has very little interest to do so) on wild goose chase ventures or suffer the consequences, going out of business  I am passionate about what I do every day. This drives me and my team but don’t confuse passion for blindness. Of course, business constraints exist where I can’t “scrap it and start from scratch”. We support hundreds of customers that depend on these systems to operate their businesses. However, when we experience a situation where we have to introduce a new module, feature or new system altogether it is critical to step back and think, “this is how I did it before but how can I do it today considering new technology, delivery networks and best practices known in the technical community.” We exercise this approach time and time again as we move our solution to a centralized offering in “the cloud” (buzz word I am really getting tired of… side note). The incremental advancement is a bit of a way of life when an application has survived such a long period and will continue to do so over an even longer period. Taking things personal and being blind to new ideas, design patterns and best practices is misplaced in the development industry but being forward looking and passionate is a quality I seek from individuals to expand my team now and in the future.

    Yours truly, the passionate developer

  2. Hello 'anonymous' ;) Nice to hear from you. I appreciate the comments and feedback.

    Please remember that the title of the post and overall message is about taking ones 'code' personally, and not anything about passion for one’s craft or profession or about a company’s success to create great and innovative software. I added some clarification to this point and added a link that spawned this post from the 'Grumpy Programmer'. However, it’s a good conversation so I’ll follow the tangent. :D

    I have had the wonderful opportunity to see this industry through a realm of glasses and different perspectives so please understand my views tend to be 'generic' to the industry and a craft as a whole. My experiences reflect the varying business lines and individuals I've interacted with over the years. While I respect your feedback, I believe it’s heavily shaped from a particular industry and not necessarily the craft generically as a whole. When I blog, I prefer to look at these views on whole and recognize clearly what works for one shop/culture/industry/team will not necessarily hold water in another. It's my job too as well to be like this.

    The ability to be a chameleon of sorts to adapt is critical to be a great developer or even company. For example from a technology standpoint, most of the industry wouldn't touch WinForms at this point with a 10' pole, and others it's their bread and butter. Doesn't mean using it is 'wrong' just that it needs to be bumped up against the industry and culture for which it is written. It may be completely appropriate but also needs to at least be evaluated for change to remain competitive. The ‘business constraints’ you mention are very different between industries. In some industries the ‘business constraints’ is that if they don’t remain current and modern, they will be yesterday’s news (i.e. MySpace, Yahoo Auctions, etc.) and out of business. Financial, Health, Government, etc. industries are known to have dinosaurs of applications written in COBOL, C++, etc. that live 10’s of years. This is quite different from those that need a competitive edge from their software output and can’t rely on their industry being ‘slow to progress.’

    Trying to predict the future in this industry is just not feasible; no one has a crystal ball. For example - what is the future? HTML5, JavaScript, Native, Xamarin, PhoneGap, etc.? There are ways to make sound decisions based on experiences but trying to predict is tough to do. There's a significant chance those that are looking backward trying to maintain legacy applications to survive for 5-10 down the road will lose their competitive edge because of rapid technology changes. Those trying to predict the future, will be left in the dust as well with the chance that a technology or platform they placed all their eggs into no longer exists or didn't pan out. It’s certainly a balance of both. At a minimum we should all try and take queue from the industry as a whole as to the winds of change and direction rather than trying to script/predict the future in a vacuum.

    The comments here went on a tangent to follow your tangent a bit. My main point was to bring things a bit closer to home about the developer/engineer and their relationship with code. One common trait I believe that developers of any line should follow is that taking lines of code personally is not a good path to follow. This advice is shared not just by me, but a lot that have fought on the battle lines of software engineering over the years. I will not correlate being offended by retired code, to being able to create great software in the future. I do agree totally that the best developers are the ones that have passion about their craft (like you and I my friend)… but also at the same time don’t take their code personally.

    This conversation would have made for an awesome podcast!

  3. Gerald M. Weinberg promoted "egoless programming" in 1971. Used this advice myself for over 25 years. Seems a paradox that programming is a solitary activity assigned to teams, and code usually improves when shared. A good edition is ref: Psychology of Computer Programming: Silver Edition ISBN 10: 0932633420 / 0-932633-42-0 ISBN 13: 9780932633422 wherin Mr. Weinberg offers current (1998) comments on his original chapters. Useful lines of thinking, which I largely endorse, though my closely held view is still that the most successful egoless projects have been those that embraced my ideas. No paradox there.