Endlessly Curious

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.