Wednesday, September 21, 2011

What am I looking for?

I'm editing this post over time - it's in chronological order - latest last.

20110921:   I'm looking for work.  Here's what I'm thinking would be ideal (this changes because I learn something new on every project - I'll keep this post up to date):

A long term (contract or perm) engagement with a team working on legacy apps.  That's where the real challenge is - greenfield is easy.  I'm dead serious about this.  I know: every developer wants to get in on the ground floor of the next big cloud/social/multiplatform/HTML5/your-hot-language-here killer app.  Not me.  I do that at home.  At work I want a challenge of a particular type: the combination of technology and social interaction that is Agile and the jungle of legacy code.

Notice I say "team".  Ideally this would be a functioning XP team (if you think I'm talking about an old but still kicking OS, our relationship is already in trouble).  Or - better: a newly formed team in an organization that sincerely wants to go Agile and understands that Scrum is about management, not development:  XP is a Agile methodology for developers.

I recently had a disastrous stint with a company that did not understand Agile.  I was actually told not to talk to other developers about what I was working on, because they were "busy".  Right.  These folks misrepresented themselves as open to Agile.  They weren't - or more charitably, maybe they just didn't know. Oh sure, they had daily standups.  But in terms of development process they were mostly in the Cowboy/Hero mode.

As a matter of fact, I'm a terrific team member and mentor.  I always work Test-Driven (TDD and BDD) even if nobody else is, but I'm glad to show teammates how productive it can be - I gained some converts on the project I'm now rolling off.  (If you have a problem with TDD/BDD - again, our relationship is already in trouble.)

I am absolutely not interested in being an architect, QA tester, business analyst, DBA, Websphere administrator, etc., etc.  I'm a software developer:  J2EE, DotNET or Rails, frontend, middle or backend - ready willing to learn new OO or functional languages and frameworks and work in new domains.  (Of course, as an XP developer I have done all of the jobs above - as part of my normal development duties.)

Yes - I need to put food on the table and in bad times I take bad jobs.  Fortunately this is not a bad time.  But you'll have to be honest with me:  if you think Agile - XP in particular - is a bad idea, or it's being forced down your throat by Corporate and you'll show them!, better you don't even phonescreen me.

20110922:  Did I mention that I live and work in Chicago and will not travel or relocate?

20111011:  Kent Beck recently said a lot of what I'm thinking  in My Ideal Job Description.

20120609:  After a year as the primary developer on Northern Trust's highest profile application (Goals Driven Investing),  I've learned a lot about teams, code quality, process, etc. in a corporate environment struggling to become Agile.  One lesson: how quickly a greenfield app becomes a legacy app when ACPs (Alien Cowboy Programmers) are involved. Will be posting more on this soon.

20121201: Not much to add except:  TDD is non-negotiable.  I will not work in an environment that does not allow developers to work this way.  It's a matter of safety, both for the software and its developers.

20150212: Learned more about flexibility on my current project.  It was led by a developer (call him G) I consider a genius - no college degree,  self-taught programmer, cool, rational, well-read in Agile and modern OO concepts and a down-to-earth manner.  G had set the project up to use a kanban board - I had never worked in that mode, but it feels much more agile than fixed iterations.   

I think the coolest thing about G is that he has no fear.  After a zillion years in this business, I believe fear - usually unconscious - is the biggest obstacle to productivity and rationality.  Of course, that's pretty much what Kent Beck said.

G isn't into pair programming, which was too bad - we developed a tendency toward silos.  (That may have been caused by the rest of the team not having a complete and simple mental model of the codebase. G has the whole thing in his head.) But we did evolve a practice of handing off subtasks when a story turned out to be bigger than expected.  This is a form of knowledge diffusion that’s not as powerful as pair programming but much more organic and efficient than code reviews.

The success of the project led to G being picked up by the client as an employee, and gradually pulled into other projects.  I suspect this will lead to what Uncle Bob calls rot in the codebase, because no-one else has the complete picture.

No comments:

Post a Comment