Development Team Membership : Part 1 – Moaning

I recently made the transition from Permanent Employment to the world of IT Contracting.  Along with this change, came a different role for me with my new client; a much more hands on position writing a lot more code which is exactly where I wanted to be!

I previously wrote a series of Blog Posts providing tips for Development Team Leadership, this has dried up of late due to my change in circumstance, however I would like to now start sharing some tips for Development Team Membership, having worked on both sides of the fence.

Don’t moan without a resolution

Moaning is great.  Everyone loves a good moan, myself included.  Moaning can be helpful and healthy, in fact indirectly it’s part of the agile feedback loop, what went well, what didn’t.  Accompanying this, should always be next steps; how to negate what grievances you may have.

There’s definitely a right time and a place for moaning sharing your observations in the context of your team, you’ll be best placed to know when this is, but it may typically be a team retrospective, a workshop on where your team is heading or a one on one, planned or impromptu session with your mentor/lead.

As a software professional, keep it impersonal.  You won’t want to come across as a bully, picking out specific people’s faults or shortcomings is never helpful.  Code reviews should be used to increase code quality, but be cognisant of their feelings and how you may be perceived.

Mr Muscle, loves the jobs you hate

You can’t always have the glamorous roles in the team, sometimes you just need to roll up your sleeves and get stuck in.  As a good team player you should have no qualms in doing the grunt work.  Grunt work leads to insight, and insight can lead to improvement in process.  Developers are lazy, and that’s no bad thing.  Do something once, do something twice and automate.

Don't skip Leg Day
Don’t skip Leg Day

Don’t shy away from hard work.

Improvements Log

You’re the one with the low level knowledge of your application(s), any potential improvements that don’t fit within the confines of the piece you’re working on should be logged, to be addressed at an appropriate time.

This will serve to broaden the teams understanding of how they should all be writing software, e.g. coding standards/patterns, and, in the same way that code reviews serve to manage quality going in to an application.  Improvements serve to keep the application up to date.  As soon as it’s committed, code becomes legacy, it’s a valuable resource and an opportunity to improve, it, and yourself as time passes.

An improvements log can serve as a satisfying alternative to a good rant.  Log it and move on, your lead should be monitoring the situation and pushing things forward.