Generalization like rumors usually have some truth to them – at some point, someone formed a thought around a frequently observed piece of truth and… Viola! A generalization was born (or maybe a rumor). Generalizations are incorrect for every single possible case (the exceptions), but there is truth to them.

That’s my disclaimer; now let’s have fun with generalizations.

The Software Evangelist

The epitome of an Evangelist can be observed on Sunday morning TV:

"SHEBBA-WABBA-MULLA-MONEY-POWER-BOOYACKA-POW-BOW!!!!"

A congregation frying like bacon on the floor, 800 numbers requesting money seared into your TV set, and an Evangelist at the helm orchestrating the show.

Evangelists are a great source of inspiration, excellent communicators, and great leaders. However, they often present a one sided biased opinion, a narrow focus, and can be driven by ulterior motives (money, power, viewership, readership, etc).  Listen to any Evangelists with a grain of salt.

Rock Star Developers

Rock Stars are on MTV, and featured in tabloids - they live hard and die young. 

The lyrics of Great Big White describe the life of a rock star:

Well I'm a wasted rock ranger
I live the life of danger
On the road to find a higher high
I don't need no one's affection
All I need is my injection
The music of wild rock will get me by

Some companies seek out "Rock Star Developers", here’s an excerpt from an email I received:

are you a Rock Star? I have an opportunity for a rock star … I am reaching out to you in the hopes that you might the star I and the client are looking for!

So, what is a Rock Star Developer? My perception is a: narcissistic, self-centered, prima donna – someone who doesn’t work well in a team, doesn’t listen, does whatever they want, and lacks dependability. Hiring a Rock Star Developer probably isn’t recommended - unless your organization has a liberal guitar smashing policy, doesn't mind drunken belligerency, and is run by a one man show.

Senior Developers

Everyone wants a Senior Developer, but occasionally these developers are more senior than developers, and certainly not senior developers – often the developer's age (not experience) determines their title. Studies have shown that a developer with 2 years experience can perform at the same level as a developer with decades of experience. Still some Senior Developers have an unexplainable need to let the world know of their seniority through email signatures, resumes, business cards, LinkedIn profiles, and so on.

If you work for 10 years, do you get 10 years of experience or do you get 1 year of experience 10 times? You have to reflect on your activities to get true experience. If you make learning a continuous commitment, you’ll get experience. If you don’t, you won’t, no matter how many years you have under your belt. - Steve McConnell, Code Complete 2nd Edition

Software Architects

Software Architects can be glorified Senior Developers - an architect might be a developer who is senior (like a curmudgeon with a walker) that needed a new title.

Thoughts on generalizations:

There are two sides to these generalizations, the people who claim to be, and the people who are. The people who claim that they’re a Senior Developer are usually impostors, whereas the person who is a Senior Developer is collectively regarded as one by their peers.

Generalizations (like metaphors) are communication mechanisms, sure, there are edge cases and exceptions. Occasionally I encounter aversions to generalizations. Responses like: "Hey that’s not completely true, X,Y,Z disproves that", or "Naw... that’s just incorrect" seem to be made when we forget that we’re just using generalizations.

What generalizations stick out in your mind?

#CalgaryBarCamp was swell. It was refreshing to meet such a diverse group of like minded people that all essentially do the same thing (create software), but do it in different ways using different tools, platforms, and languages. The ad-hoc discussions both in the bar and between sessions were my highlight. A reoccurring theme in our conversations was that technology, tools, and platforms don't matter that much. What really matters is: people, communication, ideas, taking risks, and motivation.

The topic of our discussions reminded me of something David Heinemeier Hansson said when talking about software development:

"You don't need to be a f***ing genius to make any of this stuff work, it's not rocket surgery!" - David Heinemeier Hansson at Startup School 08

DeMarco and Lister also echoed this outlook back in the 80's, and publicized: the High-Tech Illusion:

the High-Tech Illusion: [is] the widely held conviction among people who deal with any aspect of new technology ... that they are in ... high-tech business. [These people] are indulging in this illusion whenever they find themselves explaining at a ... party, say, that that they are "in computers" ... The implication is that they are part of the high-tech world. [These people] usually aren't. The researchers who made the fundamental breakthroughs in those areas are in the high-tech business. The rest of us are appliers of their work. - Peopleware : Productive Projects and Teams

If we were in the High-Tech business, then we'd be the bottom feeders (the parasites, the grunts), because our daily activities revolve around consuming other peoples research and work (programming languages, platforms, frameworks and the like). We are consumers, we're not on the cutting edge nor are we in the high-tech world.

Perhaps building software could be much like outfitting yourself for a day in the snow. You head off to the local shopping mall, you acquire the functional items to keep yourself warm, but brands and store choice don't really matter. Whether we're buying winter boots or choosing a programming language, technology doesn't really matter. There are an infinite number of ways to solve any problem, as well as an infinite number of technical permutations to form a solution. If we can solve the problem within the constraints of our problem domain then we've succeeded.

The High-Tech Illusion often permeates my world - I work as a Web Developer in the Microsoft realm. I continually see the High-Tech Illusion manifests itself in these situations:

• Colleagues talking in vague opaque high-level metaphors that patronizingly shield you from the inter working of what they assume is beyond your comprehension
• Fixations on specific tools, hardware, platforms, and methodologies while the problem that needs to be solved is diluted and any combination of these items could solve the problem
• Colleagues that assume superiority and can't acknowledge that knowledge is acquired through research and a continual efforts to improve

Pretentiousness in the software realm (in teams, organization, and so on) is usually the byproduct of someone that's living the High-Tech Illusion.

I've been guilty of subscribing to the High-Tech Illusion. How does the High-Tech Illusion permeate your world? How can we get back to reality?

Team work and interpersonal skills are absolutely essential for the present day knowledge worker (software developers, and the like). If you don't like working in teams, don't know how to work in a team, then you may not be able to find work.

In the larger software community, most agree that:

programming is a social activity, ... being the lone wolf ... is not what we do anymore  - Douglas Crockford  

And most of us have come to understand that:

Team dynamics; how well a team works together has a bigger impact on a project than the developer’s individual capabilities. And that: No individual is a success who hurts the team, and no individual is a failure who helps it.- Software Project Survival Guide

So, it should come as no surprise when a company (like Microsoft) that depends almost entirely on team work lists Team working and interpersonal skills as the VERY most important business skill. - Computer knowledge 'undervalued'

However; it's often hard for the those in management to understand that you can't force people into a team environment - let alone change or mold them. So, if someone doesn't like working on teams, has never worked on a team, or doesn't agree with your existing team's cultural views, then you should ask why. Because:

the people that work for you through whatever period will be more or less the same at the end as they were at the beginning.  If they're not right for the job from the start, they never will be. - Peopleware: Productive Projects and Teams

In reality, we have very little influence on our team members, poorly matched cultural values will likely result in poorly functioning teams, which in turn negatively results the projects success. Joel Spolsky takes this train of thought a little further and suggests that:

it is much, much better to reject a good candidate than to accept a bad candidate. A bad candidate will cost a lot of money and effort - The Guerrilla Guide to Interviewing (version 3.0)

However; most organizations don't have the exposure that Spolsky does, and can hardly find candidates period - let alone the very best candidates. Often in the real world, the only chance you'll have to guide (influence) any team of developers (or anyone), is to lead by example. Jeff Atwood offers some great advice: 

Cajoling and berating your coworkers into compliance isn't an effective motivational technique for software developers, at least not in my experience. If you want to pull your team up to a higher level of engineering, you need a leader, not an enforcer. The goal isn't to brainwash everyone you work with, but to negotiate ...

So much of leadership is learning to give a damn about other people, something that us programmers are notoriously bad at. We may love our machines and our code, but our teammates prove much more complicated. - Leading by Example

Team work and interpersonal skills are more important than technical skills. The ability to work in a team is absolutely mandatory for today's software developer.

Whether it be a group people living in the same area, the scientific community, the business community, the software community, or the global village, community is what keeps us all grounded.

Community's facilitate cross pollination (the sharing of ideas, thoughts, and alternatives), and keep egos in check. Communities reduce ignorance, can prevent the Not Invented Here (NIH) mentality, can prevent Social Isolation, and can prevent other personal or business stifling consequences.  By expanding our communities we become more grounded. To expand our community in the scientific / software realm we can attending local events, network with colleagues, participate in online forums, participate in peer reviews, contribute as technical editors, subscribe to industry related magazines and publishing's, maintain professional memberships, donate time, or contribute to other community related events.

Community is important, expand your community!

In an effort to expand my community I'm:

• Editing technical books
• Contributing to online forums
• Blogging

In the future I'd like to:

• Present at user groups
• Contribute to an open source project
• Attend more conferences
  

How are you expanding your community?

Related thoughts:

"No man is an island, entire of itself
every man is a piece of the continent, ..."
- John Donne, Meditation XVII, English clergyman & poet (1572 - 1631)

"Not Invented Here, in the context of corporate culture, sometimes occurs as a result of simple ignorance, as many companies simply never do the research to know whether a solution already exists."
- Wikipedia: Not Invented Here

"If it's a core business function -- do it yourself, no matter what."
- Joel Spolsky, In Defense of Not-Invented-Here Syndrome