Out of Bounds : Avoiding Career Protection Faults
#define KNOW_IT_ALL_DEVELOPER 64
#define TEAM_VIEW_OF_THE_NEW_GUY 8
#define UNWANTED_INPUT 1
team_integration[KNOW_IT_ALL_DEVELOPER] = UNWANTED_INPUT;
The following is an email I could have gotten recently.
Hi there. First time caller, long time listener. You’re the
greatest, and your words are like gold!
I recently took a new software development job, and I’ve been
experiencing a lot of ill will from coworkers and peers. It’s
really been killing my job satisfaction.
To explain, I was recently brought in to help a software team
get a product out the door, with a mandate of helping with some web
app code. I’ve been trying my best to integrate with the team,
trying to earn some credibility and respect by making myself
I’ve been forwarding various Joel On Software essays to All,
recommending that the office stock up on Code Complete, Peopleware,
and the Mythical Man Month, and I make an effort to point out
everything I believe could be done better. I regularly browse
through the source repository to find ways that other members could
be working better.
When other developers ask for my help, I try to maximize my
input by broadening my assistance to cover the way they’re
developing, how they could improve their typing form, what naming
standard they use, to advocate a better code editing tool, and to
give my educated final word regarding the whole stored
procedure/dynamic SQL debate.
Despite all of this, I keep facing resistance, and I don’t think
the team likes me very much. Many of my suggestions aren’t adopted,
and several people have replied with what I suspect is thinly
What’s going wrong?
Are these developers just afraid of change? Are they so stuck in
their ways? Do they simply LIKE doing things the wrong way?
The New Guy
Thanks for writing New Guy. It’s a thrill when I can
manufacture a cheap strawman to make a point, so I welcome the
opportunity to address this scenario.
Let’s get to why you’re experiencing what you’re
The Politics of Software Development Teams
Many development shops operate as a zero sum game: there are a
fixed number of promotions, raises, and apple-of-the-boss’-eye
positions that everyone is competing for, and thus one developer’s
gain is at the cost of the rest of the group.
Given this sad reality, when a new recruit joins the team,
there may be resistance, particularly among less confident
groups and team members, and attempts could be made to limit
the recruit’s influence by deriding their ideas, limiting
their input, and marginalizing their contributions.
The longer the existing team has been in place, and the less
confident they are about their positions and their skill, the worse
this problem usually is.
Of course, their fears may be well-founded. Many new hires are
motivated to push silver-bullet methodologies, to lazily advocate
quick-fix online essays, and to make superficial commentary about
how to improve the code and the products, is the desire
to earn themselves enhanced credibility with the
overseers, and thus the opportunity to fast-track past the
existing team members.
The Ugly History of Most Projects
About a decade back, I was tasked with building an
aggregation system to pull together data from facilities across the
continent, and to perform some rudimentary filtering upon it. The
eventual result of this effort was a rather ugly creation that
I was both proud of and ashamed of at the same time.
This system originally grew out of some Excel macros, growing
into an Access solution with some simple automation, and then to a
SQL Server database with on-demand manual data extractions, and
finally to a DHTML web application reporting framework against a
data warehouse. Through that evolution it incorporated a mish-mash
of technology advances, methodology changes, and of course
changes based upon my own knowledge increasing.
Many of the project steps weren’t actually authorized — I built
the original application because I was lazy, and wanted to
automate some manual tasks I had been assigned — and the
project was always viewed by management as a short-term hack until
another of the organization’s products could render it irrelevant,
so rewrites and major refactoring were out of the question.
Requirements and user input was incredibly sparse, and most of the
project was developer initiated, with the users choosing what color
to paint the shed after the fact.
Remarkably that ugly hack job continues to process data
Yet having that product history under my belt made the position
close to untenable: With each new developer I got to hear how
the data should have been structured, whether more normalized
or less normalized; how it should have incorporated as yet
uninvented technologies like XML; how it doesn’t conform with
coding standards imposed years later; how it was theoretically
rendered redundant by hypothetical solutions released far later;
and how the hack-job code, one of my first projects created in
Delphi and Object Pascal, was less than ideal; and so on. Many of
these criticisms were made as widely and as loudly as
possible, in standard To: All fashion.
Yet, despite all of its real-world warts and appendages, it was
a critical part of the enterprise. Despite all of the bold talk
about its shortcomings, no one could more than superficially
improve it or deliver any real alternative.
And that’s the reality that new recruits walk into — products
created in less than ideal conditions, with limited requirements
and limited sponsor backing, under absurd time constraints, by
developers not entirely adept at the technologies, and with limited
or non-existing supporting technologies (ADO, for instance, didn’t
even exist yet). Developers who live through such a history are
often resistant to brash or unrealistic commentary.
Of course, this doesn’t mean that the project deserves no
constructive criticisms. Indeed, I would be the first
to say that lessons should have been learned from its
implementation and failings, and a much better replacement built
using all current generation technologies. I was always open to
discussion regarding some of the choices made, and to explain its
less than ideal architecture.
Yet I grew an instant dislike to anyone who haughtily pronounced
This is the sort of reality that many new developers walk into,
with ugly-offspring projects that are nonetheless loved. The legacy
developers know its faults, and while they work to
improve those that they can, they accept others as necessary
compromises (often compromises of time — it may be ugly, but it’s
worked for years so it’s not the best place to spend critical time
changing). They are naturally defensive of their legacy, while more
pragmatic than a fresh “everything should leverage all of the
advantages of .NET 2.0″ recruit.
Real World Requirements
In the real world you probably don’t need GUIDs for your
employees table primary key. In the real world you can use basic
authentication and extremely heavyweight reporting solutions (such
as Excel automation) on a high value, single customer web server.
In the real world client-server architectures can often suffice,
and less-efficient code is often satisfactory. In the real world
you can often get away with unilingual applications.
Of course in the artificial one-sized-fits-all ecommerce world,
all of these are sins. In the artificial world every solution has
to be database vendor netural, platform neutral, infinitely
vertically and horizontally scalable, immediately multilingual,
using n-tier connection pooling via a hierarchy of web
The conflict between the real world and the artificial
one-sized-fits-all world is a frequent point of contention between
new hires and existing teams. One organization’s Enterprise
solution is another organization’s short sighted mistake.
To draw from personal experience again, I farmed some code off
to a new recruit once, asking them to build some extensions. Some
time later they returned to tell me that the code I sent was
clearly flawed, and that it couldn’t possibly work due to some
perceived flaws. I assured them that the code worked, and they were
off again. Once again they returned to tell me that I was wrong. I
imagined myself a bumblebee with a distraught aerodynamics
scientist informing me that it was impossible that I could fly.
The code I sent them was straight from the production branch,
and had been operating robustly for over a year. I quickly
demonstrated that they were wrong.
This is a fairly typical scenario, where new recruits place too
much confidence in their own knowledge and skills, despite what is
often a domain knowledge deficiency, while simultaneously placing
too little confidence in the team they are joining.
More often than not that quirky piece of code has a reason, and
that seemingly less-than-optimal solution probably has a very
Putting It Together – How To Fit In
- Always first presume that you’re wrong. While
developers do make mistakes, and as a new hire you should certainly
assist others in catching and correcting mistakes, you should try
to ensure that you’re certain of your observation before
proudly declaring your find. It is enormously damaging to your
credibility when you cry wolf.
- Be discreet with constructive criticism. A developer is
much more likely to be accept casual suggestions
and quiet leading questions than they are if the same is emailed to
All. Widening the audience is more likely to yield
defensiveness and counterstrikes.
The team is always considering what your motives are, and you will
be called on it and exiled if you degrade the work of others for
- The best way to earn credibility and respect, and an elevated
position in the pecking order, is through hard work and
real results. Cheap, superficial substitutes
— like best practice emails sent to all, or superficial
comments about how great it would be to implement some silver
bullet — won’t yield the same effect, and are more easily
- Actions speak louder than words. Simply talking about
implementing a team blog, or a wiki, or a new source control
mechanism, or a new technology, is cheap. Everyone knows that
you’re just trying to claim ownership of the idea when someone
eventually actually does the hard work of doing it, and they’ll
detest you for it.
If you want to propose something, put some elbow grease behind it.
For instance, demonstrate the foundations of a team blog, including
preliminary usage guidelines, and a demonstration of all of the
supporting technologies. This doesn’t guarantee that the initiative
will fly, and the effort might be for naught, but the team will
identify that it’s actual motiviation and effort behind it, rather
than an attempt at some easy points.
- Not every application is a high-volume e-commerce site. Just
because that’s the most common best-practices subject doesn’t
mean that it’s even remotely the best design philosophies for the
group you’re joining.
Despite all of the selfish and illogical traits described
above, many teams are staffed with confident developers who are
ready and willing to accept new hires into the fold, and who
welcome and respond to criticism and doubt fairly and respectfully.
Similarly, many new hires are selflessly trying to contribute their
knowledge, and their contributions often are founded on nothing but
good intentions. When they are jockeying for position, it’s often
to earn the respect and trust of their peers rather than to impress
Having said that, the development community is (at least thus
far…unless the robots take over) full of humans, and humans are
imperfect. Often we try to boost our own relative position by
pushing down others, and we stake out domains that we defend
against all logic. By nature most humans are prone to resisting
change. New hires need to keep these realities in mind, not only to
identify and minimize their own weaknesses, but also to identify
the same in others and to adapt to the greatest extent possible,
working to integrate without become life-long foes of their