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 thegreatest, and your words are like gold!
I recently took a new software development job, and I’ve beenexperiencing a lot of ill will from coworkers and peers. It’sreally been killing my job satisfaction.
To explain, I was recently brought in to help a software teamget a product out the door, with a mandate of helping with some webapp code. I’ve been trying my best to integrate with the team,trying to earn some credibility and respect by making myselfuseful.
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 outeverything I believe could be done better. I regularly browsethrough the source repository to find ways that other members couldbe working better.
When other developers ask for my help, I try to maximize myinput by broadening my assistance to cover the way they’redeveloping, how they could improve their typing form, what namingstandard they use, to advocate a better code editing tool, and togive my educated final word regarding the whole storedprocedure/dynamic SQL debate.
Despite all of this, I keep facing resistance, and I don’t thinkthe team likes me very much. Many of my suggestions aren’t adopted,and several people have replied with what I suspect is thinlyveiled sarcasm.
What’s going wrong?
Are these developers just afraid of change? Are they so stuck intheir ways? Do they simply LIKE doing things the wrong way?
The New Guy
Thanks for writing New Guy. It’s a thrill when I canmanufacture a cheap strawman to make a point, so I welcome theopportunity to address this scenario.
Let’s get to why you’re experiencing what you’reexperiencing.
The Politics of Software Development Teams
Many development shops operate as a zero sum game: there are afixed number of promotions, raises, and apple-of-the-boss’-eyepositions that everyone is competing for, and thus one developer’sgain 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 confidentgroups and team members, and attempts could be made to limitthe recruit’s influence by deriding their ideas, limitingtheir input, and marginalizing their contributions.
The longer the existing team has been in place, and the lessconfident they are about their positions and their skill, the worsethis problem usually is.
Of course, their fears may be well-founded. Many new hires aremotivated to push silver-bullet methodologies, to lazily advocatequick-fix online essays, and to make superficial commentary abouthow to improve the code and the products, is the desireto earn themselves enhanced credibility with theoverseers, and thus the opportunity to fast-track past theexisting team members.
The Ugly History of Most Projects
About a decade back, I was tasked with building anaggregation system to pull together data from facilities across thecontinent, and to perform some rudimentary filtering upon it. Theeventual result of this effort was a rather ugly creation thatI was both proud of and ashamed of at the same time.
This system originally grew out of some Excel macros, growinginto an Access solution with some simple automation, and then to aSQL Server database with on-demand manual data extractions, andfinally to a DHTML web application reporting framework against adata warehouse. Through that evolution it incorporated a mish-mashof technology advances, methodology changes, and of coursechanges based upon my own knowledge increasing.
Many of the project steps weren’t actually authorized — I builtthe original application because I was lazy, and wanted toautomate some manual tasks I had been assigned — and theproject was always viewed by management as a short-term hack untilanother 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 theproject was developer initiated, with the users choosing what colorto paint the shed after the fact.
Remarkably that ugly hack job continues to process datatoday.
Yet having that product history under my belt made the positionclose to untenable: With each new developer I got to hear howthe data should have been structured, whether more normalizedor less normalized; how it should have incorporated as yetuninvented technologies like XML; how it doesn’t conform withcoding standards imposed years later; how it was theoreticallyrendered redundant by hypothetical solutions released far later;and how the hack-job code, one of my first projects created inDelphi and Object Pascal, was less than ideal; and so on. Many ofthese criticisms were made as widely and as loudly aspossible, in standard To: All fashion.
Yet, despite all of its real-world warts and appendages, it wasa critical part of the enterprise. Despite all of the bold talkabout its shortcomings, no one could more than superficiallyimprove it or deliver any real alternative.
And that’s the reality that new recruits walk into — productscreated in less than ideal conditions, with limited requirementsand limited sponsor backing, under absurd time constraints, bydevelopers not entirely adept at the technologies, and with limitedor non-existing supporting technologies (ADO, for instance, didn’teven exist yet). Developers who live through such a history areoften resistant to brash or unrealistic commentary.
Of course, this doesn’t mean that the project deserves noconstructive criticisms. Indeed, I would be the firstto say that lessons should have been learned from itsimplementation and failings, and a much better replacement builtusing all current generation technologies. I was always open todiscussion regarding some of the choices made, and to explain itsless than ideal architecture.
Yet I grew an instant dislike to anyone who haughtily pronouncedits shortcomings.
This is the sort of reality that many new developers walk into,with ugly-offspring projects that are nonetheless loved. The legacydevelopers know its faults, and while they work toimprove those that they can, they accept others as necessarycompromises (often compromises of time — it may be ugly, but it’sworked for years so it’s not the best place to spend critical timechanging). They are naturally defensive of their legacy, while morepragmatic than a fresh “everything should leverage all of theadvantages of .NET 2.0” recruit.
Real World Requirements
In the real world you probably don’t need GUIDs for youremployees table primary key. In the real world you can use basicauthentication and extremely heavyweight reporting solutions (suchas 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 worldyou 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 hasto be database vendor netural, platform neutral, infinitelyvertically and horizontally scalable, immediately multilingual,using n-tier connection pooling via a hierarchy of webservices.
The conflict between the real world and the artificialone-sized-fits-all world is a frequent point of contention betweennew hires and existing teams. One organization’s Enterprisesolution is another organization’s short sighted mistake.
To draw from personal experience again, I farmed some code offto a new recruit once, asking them to build some extensions. Sometime later they returned to tell me that the code I sent wasclearly flawed, and that it couldn’t possibly work due to someperceived flaws. I assured them that the code worked, and they wereoff again. Once again they returned to tell me that I was wrong. Iimagined myself a bumblebee with a distraught aerodynamicsscientist 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 quicklydemonstrated that they were wrong.
This is a fairly typical scenario, where new recruits place toomuch confidence in their own knowledge and skills, despite what isoften a domain knowledge deficiency, while simultaneously placingtoo little confidence in the team they are joining.
More often than not that quirky piece of code has a reason, andthat seemingly less-than-optimal solution probably has a verygood explanation.
Putting It Together – How To Fit In
- Always first presume that you’re wrong. Whiledevelopers do make mistakes, and as a new hire you should certainlyassist others in catching and correcting mistakes, you should tryto ensure that you’re certain of your observation beforeproudly declaring your find. It is enormously damaging to yourcredibility when you cry wolf.
- Be discreet with constructive criticism. A developer ismuch more likely to be accept casual suggestionsand quiet leading questions than they are if the same is emailed toAll. Widening the audience is more likely to yielddefensiveness and counterstrikes.
The team is always considering what your motives are, and you willbe called on it and exiled if you degrade the work of others forself-promotion.
- The best way to earn credibility and respect, and an elevatedposition in the pecking order, is through hard work andreal results. Cheap, superficial substitutes– like best practice emails sent to all, or superficialcomments about how great it would be to implement some silverbullet — won’t yield the same effect, and are more easilyneutralized.
- Actions speak louder than words. Simply talking aboutimplementing a team blog, or a wiki, or a new source controlmechanism, or a new technology, is cheap. Everyone knows thatyou’re just trying to claim ownership of the idea when someoneeventually actually does the hard work of doing it, and they’lldetest you for it.
If you want to propose something, put some elbow grease behind it.For instance, demonstrate the foundations of a team blog, includingpreliminary usage guidelines, and a demonstration of all of thesupporting technologies. This doesn’t guarantee that the initiativewill fly, and the effort might be for naught, but the team willidentify that it’s actual motiviation and effort behind it, ratherthan an attempt at some easy points.
- Not every application is a high-volume e-commerce site. Justbecause that’s the most common best-practices subject doesn’tmean that it’s even remotely the best design philosophies for thegroup you’re joining.
Despite all of the selfish and illogical traits describedabove, many teams are staffed with confident developers who areready and willing to accept new hires into the fold, and whowelcome and respond to criticism and doubt fairly and respectfully.Similarly, many new hires are selflessly trying to contribute theirknowledge, and their contributions often are founded on nothing butgood intentions. When they are jockeying for position, it’s oftento earn the respect and trust of their peers rather than to impressthe boss.
Having said that, the development community is (at least thusfar…unless the robots take over) full of humans, and humans areimperfect. Often we try to boost our own relative position bypushing down others, and we stake out domains that we defendagainst all logic. By nature most humans are prone to resistingchange. New hires need to keep these realities in mind, not only toidentify and minimize their own weaknesses, but also to identifythe same in others and to adapt to the greatest extent possible,working to integrate without become life-long foes of theircoworkers.