Respect - The Currency of IT

Just ready Jeff Ello's article The Unspoken Truth About Managing Geeks (thanks to Michael Feathers for tweeting it.) Jeff talks about the stereotypically negative behaviors of software developers and how organizations can deal effectively with these behaviors.

The part of the article that I found most interesting is the discussion of respect: how to earn it, how to keep it, how to lose it. I can attest to the fact that respect is the number one factor in my reactions to those I work with. I have worked with a team lead who was pushy, bossy, rude and consistently corrected my code and coding style (he even took away my mouse because it was a crutch.) Why did I put up with it? Well, he was an order of magnitude better than I was and I wanted needed to learn from him. I would go home from work mentally exhausted from paired programming, but at the end of several months, I felt like Neo in the training construct: I knew TDD. I knew how to separate concerns and used dependency injection and refactor bad code. I had never have learned so much so quickly in my previous 7 years as a professional coder. The best part was that as I began to actually understand the concepts, not just the forms, he listened to me and talk to me as a peer. I was gaining his respect. Had the company we worked for managed their finances better, I imagine I would still be working and following the lead of this great developer today.

Contrast that with another job where I worked for a team lead who had completely stagnated. He would quote from books that he studied at university 15 years earlier as though they were the final word on technology. He clung tightly to his outdated data and information. While a fun guy to hang out with, he never earned the respect of the team and, though regularly promoted, he has become completely irrelevant to the ongoing development efforts of the company. In large part, my departure from that company was due to the fact that I couldn't bring myself to respect the leadership team. They would regularly make deeply technical decisions for the teams for which they were completely unprepared (and counter to the advice of the expert developers on those teams.) The advice from on high was often illogical and sometimes contradictory.

All in all, the idea that technical prowess leads to respect and respect leads to effective cooperation rings very true to me. I feel as though reading this article has helped me more fully understand my own psyche and motivations in the workplace.

Comments

Post a Comment

Popular posts from this blog

TFS to SVN Conversion with History

Recently, the team I was on wanted to move our source code from Team Foundation Server to SVN for reasons that had almost nothing to do with source control directly. This would be a pretty simple operation, but we didn't want to lose access to the history when the operations team turned off the machine running TFS. We couldn't find any direct paths for moving history from TFS to SVN, so instead we chose to use git as an intermediary. Here's how we did it: Step 1 - Install the tools Install msysgit: http://code.google.com/p/msysgit/ Install git-tfs: https://github.com/git-tfs/git-tfs Step 2 - Pull TFS history to local git repository git tfs clone <tfs-project-url> "$/<tfs-project-name>/<tfs-project-folder>" <localfolder> example: git tfs clone http://tfs-001:8080/tfs/projectroot "$/Reference Architecture/ReferenceArchitecture" RefArch Step 3 - Initialize git-svn * User Lower Case - Caps will make it fail! * Change direc...
Read more

Simpler Tests: What kind of test are you writing?

One common problem that I see in test suites is confusion about what each test should cover. This confusion often leads to tests that are either too broad or too focused to accomplish the goal of the author. When writing a test, it is important to think about what kind of test it will be and the constraints that make that type of test effective. There are a few broad categories of tests that I keep in mind to help focus my testing: Unit Tests Also called micro tests, unit tests form the foundation of any good testing strategy. These are tests that test a single class or method in isolation from it's dependencies. Mocks and stubs help us isolate the code under test and make our tests more focused and expressive. A test that touches any external resource such as the database, the file system, a web service, etc is never a unit test. The primary purpose of unit tests is to validate that the subject under test is functionally correct for the expected inputs and outputs. Additiona...
Read more

Architecture at different levels of abstraction

Image
This week I am attending the O'Reilly Architecture Conference in NYC with my team and I had the pleasure of attending a two day training on Building Evolutionary Architectures presented by Neal Ford and Rebecca Parsons . During this session, on of the things we talked about extensively was coupling. We looked at dependency maps for different architectural styles including the big ball of mud . We saw something like the following and almost everyone agreed, "That is a bad architecture." Big Ball of Mud This reminded me of something I has seen elsewhere before, and after a quick search, I found it: Amazon and Netflix Death Star Architectures The ball of mud is considered obviously wrong by most architects, but the death star seems to be held up as an ideal by just as many and likely most of the same architects. Why is this? Are afferent coupling (inbound dependencies) and efferent coupling (outreaching dependencies) only important at a certain sc...
Read more