Something I’ve seen many people struggle with is the ability to take constructive criticism, and inversely offer it.
Giving Constructive Criticism
I’ve previously recommended being free with advice. An extension to this, and a vital leadership skill is the ability to critique a colleague’s work without causing offence. Obviously being rude about someone’s work will alienate them and earn you no favours, but it’s often the case that a colleague won’t quite have understood the direction in which you wanted them to head with a certain task. There’s a couple of things personally you can take from this :
- What do we need to do to get back on track, and how can you get this point across?
- What can you do to better explain what you wanted next time?
If you’re going to offer constructive criticism you must have a plan formulated for the first point. It’s no good saying “that’s not what I wanted”, then not being able to communicate a correction.
Constructive Criticism is a reality of doing code reviews, it’s arguably the whole point of doing them, but make sure that you are able to articulate clearly what you expected in a friendly manner, a Blame Culture is bad.
The second point is also key, giving constructive criticism is also an opportunity for you to recognise areas where in future you perhaps can negate the need to offer any by providing more clarity up front.
Taking Constructive Criticism
People who live in glass houses shouldn’t throw stones.
Slightly altering the meaning of that proverb here but as we’re advocating offering constructive criticism, it’s also vital that you have the ability to take it. As Scott Hanselman points out You are not your code.
It can be difficult not to take things personally, but that’s exactly what you are expecting others to do, on this basis, you must be able to decouple yourself.
The Agile feedback loop, to look at it from a slightly different angle is exactly this. Your product at the end of a sprint needs transforming to deliver what’s expected at the end of the next sprint, this will generally encompass changes to existing work and, again from a slightly different angle, the Constructive Criticism will be offered at the Product level from the Product Owner, instead of at the code level from a colleague.
I worked on a project that was initially delivered by a number of teams. As time went by the product was delivered, matured and stabilised. The teams were merged, staff were reassigned to other projects and what was left was a relatively small single team of developers.
Now, each of those original teams picked their own ORM to use :
- Entity Framework;
- a dash of PetaPoco;
- a hint of Dapper.
To add to this, there was also a mix of test frameworks :
Functionally this worked without issue, all the ORMs have their place, and the use case was actually slightly different for each of them, but it left the single team of developers spread fairly thin in terms of what they were expected to know and be able to work on at short notice.
In this situation it is a good idea to come up with a strategy of what your roadmap would look like in terms of what technologies you want to use going forward. It’s likely going to be unpalatable to chop and change the software that is currently in Production to the extent that you would probably like to, be pragmatic about it. To use the cliché “if it aint broke, don’t fix it”, but as soon as you “have the bonnet up” (another cliché), there’s your opportunity to reduce the breadth of technologies, and allow you and your team to focus your efforts.