Codementor Events

Building The Forum

Published Jul 03, 2017
Building The Forum

It is said that the individual craftsman in medieval times could only get his job done because he kept in mind the cathedral. So it is when someone asks you two write a thingie that allows the user to select from a set list a newly minted "Project Type" we should consider the cathedral of code we're contributing to and mill our select box with that in mind.

That's all well and good but there have been occasions where I've been working on a cathedral, the colleague to my left thinks we're making an underground bunker and the guy on the right is working of the blue prints for a modern sports bar, so to speak.

The problem here is code concepts are not like architectural blue prints. If we're in a discussion about code development strategies then we could all have a completely different visual metaphor bubbling away in our mind's eye. After all what does a bunch of coded data manipulation layers look like, visually, anyway. Whatever it does look like I hope it's nothing like the VR operating system from the Michael Douglas picture Disclosure.

But, hey, no one ever got what they wanted by reeling off a list of things they didn't want.

How, then, can a team of devs end up on the same page. I contend that the only sensible way is through regular progress meetings.

And there's the deadly word. Meeting.

All the advice handed out ever about meetings tends towards letting people know how to have fewer of them. It's always been my opinion that it's not the number of meetings that's the problem, it's the fact that most meetings are the wrong meetings.

A manager of mine used to refuse attendance at any meeting that he had not received an agenda for. This was an excellent strategy and a great start to making meetings more effective. Meetings in business where the idea is to review where we've been and what we're going to do next are tricky to get right, but not impossible IMO.

The problem areas are tight on developers when everyone sits round to consider "What kind of thingie are we building anyway?" My first experience of being the senior dev on something came unstuck precisely because of this. I printed out 60 pages of carefully constructed documentation and handed them to the colleagues who were supposed to be following my lead on the project. I decided against painstakingly picking apart the docs because it would be a "waste of time".

This was a shame because I could have done with learning a few things as a result of that meeting that never happened:

  • The docs weren't very good.
  • Nobody will be able to keep 60 pages of docs in their head while developing.
  • Nobody will read 60 pages of docs if they don't understand why they should
  • The docs do not, will not, speak for themselves

What I needed was to precis the 60 pages, find the key point of the development and open the floor to building a scheme of work, a workflow, a coding strategy that everyone on the team could get behind.

Unfortunately I've never specifically been the lead on a project again. And this is part of my frustration. I have managed to work out belatedly that I should have been the lead on projects. But nobody ever told me again, hey, you're up front on this one, not unless I've been working by myself.

It's a by-product of a communication-phobic atmosphere I find in most development workplaces. Everyone's keen to cut the meeting, postpone it, come back to it later, because everyone's doing fine without the meeting, it'll just slow us up and we have targets to meet that the meeting won't help with, right?

It's wrong. It's always wrong, but it's so wrong that even to explain why it's wrong would take a meeting all by itself. These meetings that get cut often don't have agendas wouldn't have been meaningful and are probably better off being dropped. All that means is that everyone was too lazy and too ill-informed to make the agenda for the good meeting. No one wanted the pain. That includes me.

We should all be looking for that opportunity to spend the good half-hour planning without a keyboard and it should happen frequently. Because just pretending like you don't need to all work together is a great way to ensure that you won't.

Discover and read more posts from Leo Stableford (Eno M Koney)
get started
post commentsBe the first to share your opinion
Show more replies