Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

The Three Counterproductive Messages of Software Development

Understanding the messages we accept regarding technical proficiency plays an important role in the making of great software.


advertisement
When I was a little boy my father took me to an amusement park. As we walked down the midway we passed a shooting gallery, 5 shots for a quarter. I told my father that I wanted to take some shots. So he plunked down a quarter and I picked up the air rifle. After a few shots the old man that was running the concession stopped me and said, "Boy, why do you keep shooting at the bottom row for the cheap prizes? You already paid the quarter. Shoot for the top!"

And thus an important message was turned into a lifelong lesson.

[login] When it comes to software development, I am all about individual and collective "shooting for the top." It's turned into a life's work. Understanding the factors that allow teams to make great code has been a deep, deep interest of mine for a while now.



One of the things I've observed that stops a lot of teams from making great software is their internal messages. They send messages to themselves and among themselves that reinforce counterproductive beliefs that permeate every aspect of the software development lifecycle.

In my travels along the highway of software development I've come across three messages that have stopped a lot of amazing software from being made. These messages are:
    * I'm not artistic

    * I'm not technical

    * Emotions don't count

Allow me to elaborate.

I'm not artistic

Human beings are born artistic. However, most times if you were to put a box of crayons and paper in front of the average IT software developer and ask him or her to make something meaningful with the materials at hand, you'd be looked at as daffy.

Somehow the notion of collective and individual creative play, just doodling around with crayons, Legos, scissors and construction paper-all the stuff that was really fun in first grade-gets lost as we progress into professional adulthood. It's been my experience that in the world of IT based software development, taking time to "play around" creatively is viewed at best as an entertaining but trivial novelty. At worst it's a sign of incompetent malingering.

Yet, most of the people that I have come across that are exceptional developers engage in some sort or artistic expression almost daily. They enjoy making things-making music, making photographs, making paintings, making film, cabinet making, the list goes on. They understand that artistic expression is a broad landscape in which experience from any given episode can be applied to the day to day creative process relevant to software development.

As a gifted, enterprise level DBA, told me once, "Whether I am making an ERD (entity relationship diagram) or designing a sauna for my basement, it doesn't matter to me. It's all the same thing!"

Those in the know understand that the act of exercising simple, fearless artistic expression without the shackles of cruel self-judgment hones the skills and discipline necessary to tackle the really big problems of software development.

So the next time you find your team stuck, unable to move forward, needing motivation, inspiration and new ideas, break out the crayons and paper.

I'm not technical

It takes a lot of different types of people to make modern software, not just programmers but also systems engineers, graphic artists, media engineers, products planners, financial folks, to name a few. Sadly, many of the non-programmer folks associated with the software development lifecycle walk around with feelings of intimidation and inadequacy. I've heard the phrase, "I'm not technical" uttered more than once. It seems to be a message that sticks.

Computer programmers are a complex bunch, predisposed to keeping the workings of their vocation "hard to get". My intuitions tell me that it comes from being outside of the mainstream for a long time.

It's an isolating experience sitting alone for days programming with only the company of a computer, some email and instant messaging. Code really does fight back, and getting it to behave properly means that coders have to speak the code's language. As a result, that which starts as isolation, over time becomes a type of special club that requires understanding a special language in order to gain admission.

The interesting paradox is that although the language of code is hard to learn, most of the time what the language talks about is some pretty commonsense stuff. Still, to the layman it all seems complicated and somewhat intimidating. Once intimidated, the non-coder seems to forget about his or her innate technical proficiency, that functioning in the modern world requires a very high degree of technical skill. It takes a lot of technology and technological understanding to send an email, drive a car, use a telephone, and maintain a bank account. But, once the message "I'm not technical" finds a willing recipient, all is forgotten. The "I'm not technical" team member falls into an "I'm not technical" silence, holding back what may be a very good idea to solve a pressing problem at hand.

This is not to say that that technical ignorance is acceptable, despite the fact that at some point we all become technically ignorant about something. Quite the contrary. Becoming more technically aware, continuously, is a core requirement for participating in the modern commercial world. What is acceptable is to say, "I want to contribute to the conversation but I need help understanding some concepts that are being discussed. Please, will you explain [CONCEPT I DO NOT UNDERSTAND HERE] to me?"

Emotions don't count

When it comes to making software, if you don't think emotional state matters, talk to an advertising person. Ad people figured out a long time ago that people connect to products emotionally, and then reason kicks in. In the ad world you are not buying a toothpaste, you are becoming kissable; it not the rubber, it's the feeling of safety you get from seeing a baby in the middle of a stack of Michelin tires; it's not the cigarettes, it the coolness of Joe Camel. Everybody on Madison Avenue knows that great cheese comes from happy cows.

So if great cheese comes from happy cows, it's not too far a leap to accept the notion that great software come from happy developers. When we're in a good emotional place, we work better.

Getting into the dynamics and intricacies of the knowledge worker's emotional state is tricky business and a bit beyond the scope of this article. However, accepting that we are emotional as well as thinking beings and understanding that there is a relationship between thinking and feeling are important considerations to have when developing innovative ways to enhance the productivity of a modern workforce.

Having a development team get to a good emotional place, at will, takes time. However, there are easy ways to start. For example, changing the semantic meaning of the term, "How are you doing?" from "Greetings!" to "I really, really want to know how you are feeling at the moment." can make a big difference in how a team operates on any given day. If a person responds, "I am feeling happy", you can anticipate a productive day. If the response is, "I am feeling sad", you might need to mitigate because things are going to be a bit slow.

Again, how we feel has a direct impact on how we think. It's better to know the emotional state of a team member than not know or to guess.

Conclusion

Messages are a powerful force in the world of software development. They shape our belief system. Some beliefs serve us well. Some beliefs stand in our way and prevent us from making amazing products. Many times beliefs that block us are founded on counterproductive messages. Understanding the messages we accept and being able to distinguish between those that help us and those that hurt us, particularly in terms of artistic expression, technical proficiency and emotional well being plays an important role in the making of great software.


   
Bob Reselman has written numerous books and articles about computer programming and topics related to software development. Presently Bob is a Technical Process Architect at Edmunds Inc. Edmunds Inc. is a leading publisher of high volume, high availability, state of the art, Java based Web sites dedicated to empowering the automotive consumer. Experience Edmunds technology by visiting, www.Edmunds.com and www.InsideLine.com.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap