I’ve been fairly heavily involved in a corporate development environment for the past few weeks, on-site for a large part of that time.
This differs from my normal modus operandi, in that usually I’m doing a half-dozen different projects in various stages of completion at any given time of day, and from various venues around town.
Having to report to a set place – in this case, a cubicle – to do one thing and one thing only for a predetermined set of fixed hours was needless to say a bit of a challenge for me.
Not because of the office in which I found myself or the people that I worked with – all great, by the way – but because after twelve years of self-determination and self-direction, it is very hard to let someone else “drive” and to sit in the passenger seat.
Plus, I’m someone who can’t stand inactivity. In a corporate development environment, there is often lots of slack space between the bouts of activity.
Most of this slack time is dictated by process (approvals, specifications, version control, build cycles, testing) and really can’t be hurried along – it takes what it takes to get certain things done. And I mean this in a very GOOD way.
I don’t really consider myself to be a “Cowboy Coder” – that is to say, a developer who prefers working alone, or goes “dark” disappearing for days on end and magically appearing with working solutions, eschewing things like documentation, process, and code reviews. On the contrary, I have been the director at a couple of companies where I walked the corporate development “walk” for years on end.
If I say which mode of development I believe to be the best I’ll surely start a shit-storm of protests from each side.
All I’m really doing here is just observing that I noticed how much my own personal perspective has veered over the years, because of how my development business operates, versus working in a large company where personal accountability is secondary to development process in general.
And I must say, I prefer being able to hold a single developer accountable, present company included, for their code and development practices. It is how I judge my own effectiveness, and how I judge the merits of other developers I engage for hire or work with.
I’m certainly not saying that this doesn’t happen in larger companies – it does. Over time, developers in larger shops know who produces great working code and who the dead wood developers are. It’s just that the consequences of being a dead wood developer in a large shop are usually not very punitive and in many cases largely ignored owing to the fear of losing even the smallest of productivity garnered by the under-performers.
As a result, over time, most companies wind up with a large cadre of very average developers.
Gerald Weinberger wrote about this some twenty years ago (I’ll have to find the reference – brain too addled at the moment) and I have found it to be true in my first hand experience.
Having a large group of Cowboy Coders (or even one in most cases) on your team is also less than desirable.
Who wants to work with a team of guys and gals who thinks they are right 100% of the time and everyone else are idiots? (OK – those of you who work with Doctors and / or Lawyers really don’t have to answer that – it’s a rhetorical question). High maintenance employees, while capable of spectacular results, often are the Barry Bondses of the Corporate World.
Sometimes, it’s just not worth it to put up with their shit just to meet a deadline (sometimes it is – knowing the difference is what makes great businesses and business models).
If I get a little time later in the month, I’ll try to wrap my head around making this a more cogent exposition. For now, you poor mugs are left with this mess.