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.
