Challenged to grow
I have come to the realisation that the most experienced person in a group is not usually the person getting the most benefit in terms of skills or experience gained when working on a collaborative project. In fact the more experienced the individual the less benefit they stand to gain, the inverse is true of the less experienced individuals who due to their low levels of experience have the most to gain.
This balance can be seen in most projects involving more than a couple of participants. A team’s experience distribution can typically be visualised as a pyramid with the most experienced individuals at the top of the pyramid and the most numerous and least experienced group of individuals at the bottom. There is the occasional team where the experience pyramid is inverted but I have yet to have the opportunity to work with such a group.
The experience composition of a typical team usually works quite well, with the more experienced members directing those that are less experienced than them. This helps to explain why the more experienced you become the more time you seem to spend in meetings planning, discussing and thinking about the design of the product.
The breakdown of the project tasks based on individual experience levels also means that each individual should be supplied with tasks that are mostly within their capabilities. Some stretch tasks should also be set (with sufficient support from more experienced team members) to ensure each individual continues to develop their skills. This should mean that the tasks you work on should be within your capabilities and as your capabilities increase so should the complexity of the tasks you are set, to prevent stagnation.
It should be noted that if an individual fails at a task then their next task should be something that is well within their capabilities. To do otherwise is to risk a loss of confidence, as multiple failures in a row can seriously undermine an individual’s confidence and ability (see negative reinforcement). This is why most modern coaches will not allow their athletes to finish a training session with a failure.
Tasks that stretch or challenge you as an individual are a good thing but they should not be forced upon you and they should not be chained together, some respite is required between challenges. More experienced team members are an essential resource to those undertaking stretch tasks due to the advice and moral support they can offer.
Large project experience prior to first job
One of the things that universities don’t typically prepare students for is working as part of large teams e.g., ten or more individual developers. This under exposure to the large team working environment usually means that although a potential candidate is a good programmer, they may be totally unprepared for the typical large project which involves large numbers of: people, meetings, sub-teams, politics, not to mention stuff actually related to software development like large code bases, test suits and voodoo based build system configurations. This is usually part of the associated training cost when taking on a new junior or student programmer.
People Stuff
The people side of a large project can be a rude awakening to most new developers, as usually most university courses don’t include large scale project work involving more than a few students. This is a serious issue as the usual team size outside university can be quite large and not being prepared for that sort of working environment can be a disadvantage. Working within a small team of developers does not usually have enough of a communication overhead to sufficiently prepare a student for the experience of working in a large team. The higher the communications overhead inside a team the more formal and heavy weight the methodologies have to be implemented for the team to remain productive. This usually means more meetings, status reports, chains of command, negotiation between sub teams, and more internal team politics than on a small team.
Programming Stuff
The differences between a large and small project can also be a large shock on the programming side, suddenly new developers go from small projects involving just themselves or a few peers to projects involving multiple small teams and consisting of many programmers. This has many implications including:
- Much much larger code bases which require a skill: finding things in the code base is now a serious challenge and can become a larger time sink than actual programming.
- Coding standards are usually a must for large projects to allow programmers to be able to understand the source code easily and to attempt to keep interfaces consistent across the whole project.
- Larger code bases mean large source control repositories, which also required navigation and knowing what files to sync to.
- Larger build times, large projects usually don’t build as quickly as small projects even when using distributed build systems like IncrediBuild.
- Getting the build environment for large projects set up on the developers computer can be time consuming and very fiddly depending on the amount of undocumented build system voodoo required (my personal rule is to allow up to two days to get a project building on a new PC).
- A larger team and more people relying on a stable build means more formal programming, source control check in and testing methodologies are required to prevent the team’s progress grinding to a halt due to broken builds.
Getting experience
I think possibly one of the best and easiest ways a new developer can get exposure and experience working in large teams before joining industry is to get involved in open source projects e.g, the Ubuntu operating system or any of the many varied projects of Source Forge or Google Code. Open source projects by nature tend to share the same properties as commercial development teams, plus they are free to join and provide useful experience in working in large team environments.
I’d love to interview a candidate student placement or junior programmer with open source experience, as that means there is one less thing we need to teach them. So far I’ve yet to have such an interview.
Programmers Ranks
After discussing the differences between programmer ranks this week with a more junior co-worker, I thought this would make a good post as it seems to be something that is not spoken about much. This I think is not very helpful for junior programmers looking to develop themselves. Generally there are roughly three ranks of programmers: junior (beginner), programmer (intermediate), senior (advanced) and then lead programmer (advanced plus people skills). Some companies use different names for these ranks or have a few more specialised ranks e.g, Co-Op or student programmers but so far I’ve generally found the ranks to be somewhat similar in terms of what is expected.
Junior Programmer
The junior programmer is the lowest rank in the programmer family, most programming team’s populations usually consist of about 25% junior programmers. This is where everyone starts out in the industry. Junior programmers are primarily implementers of other peoples designs and are usually heavily supervised by more senior team members. It is usual for programmers to remain at the junior rank for a few development cycles as they mature and gain experience.
Programmer
The rank of programmer is the middle rank of the programmer family, most teams usually consist of about 50% programmers and as such this is usually the most commonly encountered rank of programmer. Programmers are veterans of the development process and are expected to be able to design and implement features given a feature brief, some contacts, some supervision and peer (or senior) review of their designs. They are also expected to be the first line of support for junior programmers, helping with problems the juniors cannot solve.
Senior Programmer
Senior programmer is effectively the highest rank for a programmer, as a lead programmer is really a specialised senior programmer. Senior programmers usually make up about 25% of a development team, this is mostly due to a few factors: they are rare (every team wants them and they take a long time to develop), cost (this amount of talent is not cheap) and individual preferences (they cannot be easily forced to do something they don’t want to do). Senior programmers are veterans of many many development cycles and as such have experience of just about every type of project, working environment and methodology. This depth of experience is their strength: they typically have a few more junior programmers under their supervision, vet design documents, solve the hard problems that bubble up from the lower ranks, act as diplomats coordinating with other departments and generally providing guidance and a calming influence when things go wrong. In terms of work, senior programmers are expected to conceive of, design, prototype, implement and review whole systems or domains of a project and to set the direction of the domains they are responsible for without supervision. Productivity wise a senior programmer can be worth several lesser programmers in terms of output, quality and direction.
Lead Programmer
A lead programmer is a highly specialised senior programmer. The easiest way to describe a lead programmer is that if the project fails it is their fault, at least according to managment. So a lead programmer is the programmer that is responsible for the overall project design, planning, direction, progress and ultimate sucesss. This role usually requires more people and planning skills than the senior programmer role, so where a lead programmer can have a break from leading for a cycle and act as a senior programmer on some other leads project, a senior programmer cannot always act as a lead due to a potential lack of the nessessary skills. It must also be pointed out that some senior programmers don’t want the responsibility, high amounts of planning, meetings and people skills required by the lead roles. Such individuals prefer to stick to programming and are in no way less valuable than a lead.
Effectiveness Vs Communication Load
As the above graph demonstrates, there is a practical limit on team size before the communications load required to keep team members in synchronisation begins to significantly reduce individual team members performance. The usual method for combating this trend is to partition large teams up into smaller teams to reduce the communication overhead per individual.
Source ‘Agile Software Development’ by Alistair Cockburn page 160.
Software Development: planning Projects Software Development
by Daniel
leave a comment
Estimation and self delusion
Here is an interesting exercise for you to try next time your estimating something e.g, task duration.
- Write down your initial off the cuff estimation, without thinking about the estimation in any detail.
- Think some more about the task and how long it could take if everything went wrong (within reason e.g, discounting riots, natural disasters, coups etc) then write down your new worst case estimation.
- Think about how long it could take to do if everything went right and write down your best case estimation.
Since I first started performing the exercise on myself and team members when estimating I have noticed the following:
- That answer one and three are almost always nearly identical and that answer two is usually significantly different on average from answers one or three.
- Those planning based on estimates prefer accurate estimates to an immediate answer: especially as the immediate answer is usually significantly inaccurate.
- I don’t like causing myself massive stress by making inaccurate estimates that I then have to try and meet and I’ve met few people who enjoy self inflicted stress.
- It is acceptable to ask for some time to think about estimates, even if it feels awkward at first.
- Thinking about similar tasks you have done in the past can be a very useful tool to help contextualise your estimation, if you don’t think about previous experiences you can walk into the same miscalculation again and again…
Project Inertia
The beginning of a project or piece of work has always been one of the hardest times, I’ve found. The actual act of going from nothing to something is deceptively difficult and it doesn’t seem to matter if the project in question is an essay for university, a program to write, a DIY project or some art/craft piece. I always seem to hit a point early on where I’ve researched the topic, gathered the initial materials and am effectively ready to start but I don’t.
I remember noticing this at university when I always wanted to start work on a project early, however I found I would only actually start work once the time pressure of a deadline became large enough to spur me into action.
I think there are several reasons why actually starting work on something is hard:
- Degradation: Prior to starting work on something, the gathered materials are organised and pristine, it can be hard then to actually start working with these materials, especially if you are a beginner or novice in this type of project as you are aware that there is a high likelihood that the finished product will not be to the same quality as the materials that went into it e.g. it is possible to draw a stick man with the finest oil paints on a high quality canvas.
- Commitment: Starting work on something can be seen as a semi public statement that you are about to attempt to actually do something instead of just talking about doing it e.g. once you’ve got paint on the canvas your going to be asked what/how/who you’re painting.
- Measurment: Actually working on something opens up you and your work to potential observation and criticism by peers which can be intimidating e.g. how well you can actually perform can now actually be measured based on the evidence from your project instead of just how well you claim to be able to do it.
In fact, the reasoning behind the content of my first post on this blog was an attempt to start this blog with both a high quality and relevant post on project inertia, as I have been meaning to start writing for over three months now but had not gotten started. However as Newton observed once something is going it is easier for it to continue rather than stop (and vice versa).
I just hope I can build and maintain sufficient momentum to keep this going.
