After an incredibly hot, dry summer here in Southern Ontario -- one which left many lawns scorched to the point of being bare dirt -- the winter has followed suit, setting records as the warmest ever measured.

Several nights it has pushed 9C at 9pm at night, which is extraordinary considering the average daily high, normally touched for only the briefest of moments in the early afternoon, is -4C.

This unseasonably warm weather has some of the plants and wildlife confused. Plants are sprouting in the garden. Squirrels rush around in a "twitterpated" state.

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

int team_integration[TEAM_VIEW_OF_THE_NEW_GUY]; 
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 useful.

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 veiled sarcasm.

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?

Yours truly,
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 experiencing.

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 today.

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 its shortcomings.

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 services.

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.

Practical Knowledge

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 good explanation.

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 self-promotion.
  
  
• 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 neutralized.
  
  
• 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.

Conclusion

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 the boss.

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 coworkers.

Tagged: [Software Development], [Programming], [Software-Development]

Unbeknownst to many newspaper readers, letters to the editor are usually edited by a letters editor. While the stated goal is to reduce verbosity, the result is often a change in the bias or tone of the submitter. These changes are generally never run by the original author, and can significantly change what the author was trying to convey.

Sometimes letter editors completely mangle the original submission. I had several letters printed in the London Free Press over the years where well crafted submissions were edited into semi-literate diatribes.

As an example of minor editing, consider a letter that I had printed in the Toronto Star this weekend.

Providing an excellent example of hysterical fear-mongering, Shane Bowden wrote that Ontarians "chose to completely reject" a Western-based party. That comes as quite a surprise given that close to 2 million Ontarians cast their vote for Stephen Harper, giving the Conservatives 40 seats from Ontario. Even more telling is the reappearance of the nonsensical persecution complex, imagining that Harper was thwarted by cowboy-fearing Ontarians. Ontarians base their votes on party platforms and conservative-liberal ideology, not some myopic regional inferiority complex

Compare that to the original submission.

Providing an excellent example of hysterical fear mongering, Shane Bowden wrote (Jan. 26th) to tell us that Ontarians "chose to completely reject" a Western-based party. That comes as quite a surprise given that close to 2 million Ontarians cast their vote for Mr. Harper, giving the Conservatives a respectable 40 seats from Ontario. Indeed, the Conservatives garnered more than twice the votes in Ontario than they did in Alberta, putting on an extraordinarily strong showing for a regrouping party, and providing them an opportunity to prove themselves and their policies to Canada.

Even more telling is the reappearance of the nonsensical persecution complex, imagining that Mr. Harper's ascent was thwarted by cowboy-fearing Ontarians, eager to hold down the rising West. Remarkably, the Ontarians I've spoken to seem to base their votes on party platforms and conservative/liberal ideology, not some sort of myopic regional inferiority complex.

The editing is subtle, but the result is a different tone and bias than what was intended.

I've had a personal video recorder (PVR) for about a year now, finding it an invaluable part of a modern lifestyle (to use a tired cliché). While we watch little TV, the PVR allows us to ensure that we're watching exactly what we want to watch, when we want to watch it. Even if that means that we want to catch Survivor but our children have swimming that night.

Liberated by the PVR, even when we're watching a program "live" we intentionally sit down a bit late to enjoy the full luxury of fast-forwarding along with the standard rewind functionality. It really is television freedom, though I know the fun won't last, and restrictive DRM is slowly going to take away all that PVR giveth. 

We're enjoying it while we can.

...my reality perception device -- my brain -- regularly tries to rely upon PVR-like functionality in the real world...

One interesting side-effect of the convenience benefits of a PVR -- the user empowerment offering almost time-travel like functionality -- is that my reality perception device (my brain) regularly tries to rely upon PVR-like functionality in the real world. More times than I care to remember, I've witnessed something while driving or just generally out and about, and I'll try to mentally grasp how I can rewind the scene so I can point it out to my wife, or so I can focus on a detail I didn't entirely catch. Then I remember that I can't rewind life, but it really is jarring when it happens, and it happens frequently. 

I mentioned this to my wife, and it turns out that she's occasionally experienced the same perception quirk.

I suffer from a chronic case of Tivo Induced Time Perception Disorder. Years of MP3, DVD, and VCR use never brought on this perception change, but something about the liberation of television fundamentally infected my brain.

Earlier this month -- January 4th to be precise -- I posted an entry regarding optimal software development practices (here in archived form), one of the most important points being that teams should "Focus On Results Instead of Effort and Sacrifice".

Focusing on results instead of effort and sacrifice can be realized in many ways; For instance by using the easiest possible tools and technologies that acceptably achieve your results. By cancelling long, drawn out meetings that everyone hates if the meetings don't achieve results. By ditching any process that is nothing more than cargo-cult remnants.

It's a simple perception change that forces one to evaluate the actual benefit yielded by extended efforts, rather than blindly applying brute force with hopes that it magically yields returns.

This rule isn't just for workplace practices, though, but applies to our day-to-day living as well.  For instance making a delicious cup of coffee.

I recently came across a widely referenced piece, "A Coder's Guide To Coffee", which details the various steps that one should take to achieve a drinkable cup of coffee. It's an interesting read, and serves as an entertaining bit of additional knowledge about the craft of brewing. Nonetheless, as I read it I imagined countless people creating subpar, or even just par, cups of coffee, confident that the additional care, concern, and manual effort they put into the effort guarantees them a better cup of coffee.

It doesn't.

In fact it could lead to much worse results, not to mention that it took a lot more effort to yield those worse results in the first place.

My Coffee Pedigree

Most of the time I drink packaged coffee, brewed in an often-dirty automatic drip coffee maker (it isn't the height of science getting water just below the boiling point, and in fact many automatic drips work by boiling water up from the reservoir, letting it cools the perfect amount while dispensing. In essence the water temperature is guaranteed perfect by the thermodynamics of the design). It requires close to no effort on my part, yet most of the time my coffee is (in my humble opinion) extremely good. For any normal coffee drinker it would be close to the "perfect cup", and unless you had dedicated your life to the classification of coffee, or you're on to drinking only coffee defecated from civets, you probably won't notice the difference from the most effort-encrusted specialty coffee. The only thing my coffee lacks is the placebo effect of imagined advantages.

Getting the "perfect cup" was incredibly easy: I found the perfect water/coffee ratio for my particular tastes, my cheap drip coffee maker does a very credible job (and provides water at the perfect temperature), and I brew small enough pots that coffee isn't sitting for very long before being consumed.

I tried a wide variety of grind brands and roasts, and eventually found a couple that are predictably good, so they're my staple. Occasionally I buy some of the "bulk" gourmet coffees (although the results there have been negative as often as they've been positive. The large coffee manufacturers seem to have the process down to much more of a science than the local coffee house).

Even the most common, most pedestrian, package ground coffee is made with 100% Arabica beans, so that isn't too much of a concern, and the whole Robusta red herring is a bit of cheap, disposable advice.

So without further ado. Here's the amazing magic of making the pragmatic perfect cup of coffee!

The Pragmatic Coder's Guide To The Perfect Cup of Coffee.

• Try various coffee brands until you find one that matches your taste. There is no "ultimate" coffee, and one person's winner is another person's dud. The major coffee brands use excellent beans, and have extremely tight quality control, so any illusion that it's a crapshot or that the quality is second rate is misguided. Of course you should care for the freshness of coffee as you would with any food product, ensuring it's in an airtight container in a non-spoiling environment.
• NEVER take anything from the pot/carafe while it's brewing, and apply corporal punishment to those who do. Most office coffee stinks because a jerk came and took a cup right after the brew started, taking with it most of the flavor. As grinds release flavor  second at a rate loosely like [Flavour Per Second]=1/([Seconds Into the Brew]^2), what's left is some discoloured water that smells like an ashtray.
• Try various ratios of coffee/water until you find what works for you. Many office coffee is supplied in little prepackaged packs that are too small for most tastes, so combine one and one quarter, or one and a third, or whatever quantity makes the perfect cup.
• Drink a batch quickly, and if it regularly sits then start brewing smaller batches. You can maintain the taste longer by brewing into, or transferring to, an insulated carafe.
• Never microwave coffee. Again there is no obvious reason for it - Microwaving is simply supposed to excite the water molecules, raising the temperature of the cup - but microwaved coffee always...ALWAYS...tastes terrible. If it cools too much, toss it.

That's it.

Focusing on hand roasting your beans, or manually brewing, is absurd when the overwhelming majority of the population can't even accomplish the basics consistently. Following those simple rules gets you to the point of extraordinarily diminished returns, and it is the Pragmatic Perfect Cup.

Of course you could hand craft your own gathering containers, walk 500 miles barefoot to hand pick only the cutest beans from the largest jar, brew with the most remarkably pure spring water after having it blessed by the saint of coffee in a pot made of the purest of silver, using beans ground with ancient Egyptian artifacts, but that doesn't mean that you'll yield a better cup of coffee, unless you're susceptible to the placebo false return effect.

Oh, and occasionally clean the pot. I think I'll go do that right now.

For quite some time I was an occasional visitor to Joel Spolsky's now-defunct ?off forum. I was even an appointed moderator for a while (a "green checkie") , but resigned the role given that I couldn't visit frequent enough to fulfill the mandate.

The forum covered a huge range of topics (it originally was created as a political discussion outlet during the 2004 US elections), only seldomly touching upon software development, so it was a pleasant distraction to refresh the brain with something different for a few moments. It was frequented by a group of top notch intellectuals, along with a very large population of lurkers, and featured a number of very fascinating and insightful discussions.

Some of the discussions were critical evaluations of pages people found on the wide open web, and often the subject of the conversation would follow the HTTP referrals back to see what was being said.

Many bloggers were pulled into the ?off loop this way.

This past Friday, one such blogger -- a relative newcomer to the forum, having been visiting us for under a year -- decided to use ?off, along with several other venues (including their personal blog), to announce their impending suicide. Despite some valiant efforts by several people involved (especially considering how cynical one becomes about the truthfulness of posts on such forums, and the difficulty helping someone in Chile from Europe and North America), the individual succeeded in their quest, making this a sadly "interesting story".

Given the perverted interest in such an event, the forum was being analyzed, and of course exploited, by bloggers and meme sites (and combinations thereof).

Then Joel decided to shut the forum down.

Given that a wide community of regulars and semi-regulars had developed, immediately the quest was undertaken to replace ?off, with a very faithful reproduction quickly appearing at http://www.crazyontap.com (apparently a couple of hours work). While we all casually comment about how quickly we could throw together solutions similar to existing products, "Almost H. Anonymous" carried through and delivered, and the results are quite impressive (most corporate teams would take a dozen man months to achieve the same task, remarkably. Not because they aren't good, but as a cost of some of the process and work patterns followed). There are efforts to open source both the code, and possibly the data, which could make for some interesting and innovative new solutions.

Definitely something to keep an eye on. Additionally there is another great migration route of many of the ?off visitors - http://www.ectopia.us. Also worth a visit, and it as well is a quickly evolving board.

I have been considering the possibility of yafla providing training services, developing and delivering programs here in the Greater Toronto Area (and globally where the monetary return makes it worthwhile), adding this service to the existing software development, outsource management, and consulting options. Not only is it an additional revenue stream, much more importantly it's another potential avenue for making contacts and getting involved as a vendor with new clients, creating opportunities to more easily offer our other services.

I've done a lot of group training in the corporate space, have been involved in quite a few tutorials and online training guides, and find it to be a very rewarding pursuit. Several of my associates have been heavily involved in the training industry during periods of their career. The possibility of hosting an "Advanced SQL Server" seminar or workshop, for example, seems very exciting.

We're very equipped to perform this task, and we certainly can do a better job than all of the trainers I've been exposed to. Our approach would never be to dedicate anyone to training alone (or even as a substantial period of their time), as continuing and up-to-date real-world experience would be absolutely critical to the program.

As such, I'd greatly appreciate any input anyone might have regarding the technical training industry, and how external training programs work at their organization. I know many mid- to large-sized firms have an "authorized training vendor", basically ensuring a universally weak level of training throughout their organization, and that could present a significant barrier to entry.