Using Student Coders October 19, 2012

Over the years I’ve had experience with student coders from a number of perspectives:

• managing them
• training them
• using their products
• finishing partially complete projects
• debugging their code
• maintaining their code
• extending/expanding their projects
• being one

Recently I was asked ‘how do we use student coders/workers to develop our core tools?’. The answer is (as a general rule), if at all possible, don’t. Smart student coders can and do create many wonderful things, but usually they lack the context and experience to create programs and systems that are suitable for core use / mission support.

[ASIDE: Let me address first some of the common ideas that lead people to want to use student programmers:

– ‘anyone can learn to code’ : While that is true (and I actively encourage anyone and everyone to do so – I think simple coding skills/understanding should be a part of the core liberal arts education), quality varies. Anyone can write a novel (see NaNoWriMo), but not everyone will write a novel that you’d actually be happy to have spent several hours or days reading, let alone one that you’d want to sell as a publishing house or use as a teaching tool. Knowing how to code is a prerequisite to writing a good program, but is not in itself sufficient – people often focus on it because for those who don’t know how to code it is the most obvious barrier.

– ‘student programmers are cheap’ : This depends on the metric you use. Certainly they are cheap by the hour. They are less cheap by the line of code (or effective/necessary line of code). They are even less cheap by the successfully completed project (i.e. basically works and is used by people). They are yet less cheap over the project lifetime IF the project has an extended life (i.e. requires maintenance/updates, is extended, is used as the basic for other projects). Too often people see $/hour and don’t consider what one gets for that hour, or how much one will continue to have to pay down the line.

– ‘student programmers are available’ : This is hard to argue with – if your campus has a CS department then you’re guaranteed that there are students who know how to program, and even without that there are usually students around who are self taught or learned some programming in earlier school. That being said, there are lots and lots of professionals out there who can and do work remotely, so geographic proximity isn’t strictly necessary.

– ‘we have all these CS students around, and they have to be useful for something…’ : True, but they are _students_ still. They’re just learning the skills necessary, and are prone to experimentation, and/or to the I-have-a-hammer-so-everything-is-a-nail-effect. Just as you don’t want someone who’s just learning about metadata to design your catalogging system or someone who’s just learning to make engines to build the engine for your airplane, you don’t want someone who’s just learning about programming to build mission-critical/core application. Feel free to use them for experimental work, but don’t rely on them for mission critical, long-term elements.]

Over all, students coders are problematic because:

• they know only the most basic skills of programming; they can write code, but not appropriate and well-designed code
• they are slow (and thus costly) in terms of functionality per hour
• they are costly in terms of necessary oversight
• their products are very limited; hard or impossible to maintain, extend, and re-use, and they’re fragile
• they have no (or very few) project management skills
• they have an extremely narrow focus; they are not good about planning for or handling cross-system integration or edge cases
• they are very implementation oriented; they are not good product designers / they have a hard time viewing their project from different perspectives
• they don’t write good documentation [ASIDE: there are 4 basic realms of documentation you’d like to have for your system: coder docs (in the code, explaining as needed what a section/function does or generally how, and higher level descriptions of APIs and libraries; don’t accept ‘self-documenting code’, that’s like saying papers don’t need abstracts because someone can always just read the whole thing), system designer docs (what are the goals, what’s the general architecture and why, what are the system requirements and dependencies), admin docs (how does the super user/admin manage the system), and end user docs (how does someone use this program to perform a task / solve a problem / achieve a goal.]

[ASIDE: What does the programmer you do want to use for core programs look like? At a bare minimum
– knows multiple languages, and can explain the pros and cons of them (including the downsides of their preferred language)
– has had to maintain / improve / extend someone elses code; worked in a mature software environment
– has done some independent / solo projects from start to finish
– documents well in at least 2 realms
– understands what ‘requirements’ are, and request them (or a discussion of them) before work begins
– has some sort of personal project management approach, even if it’s just to-do lists in a text file; can articulate a plan for getting the project completed more or less on time and in budget, and/or can explain why and how it will take longer and/or cost more]

Generally speaking, if you have a small pool of money you’ll get better results hiring an experienced, good programmer for a short period of time rather than multiple students for a long period of time. If you can’t afford to hire an experienced professional to complete the project, it’s probably still worth hiring him or her to design and plan the project. However, sometimes you have no other options and you have to use student coders. How do you make the best of this situation? Plan to accommodate the worst.

10 Things To Assume When Preparing To Manage Student Coders

1. They only barely know how to code. Arrange references for them, and have (self-)training options readily available. Build time into the project plan for on-the-job learning/training. As a corollary of this, you need to know enough coding yourself to be able to recommend references and training options, and also to be able to speak to them in programming terms.
2. They all code differently. Set your standards before the project starts – you choose the language, the code style, any relevant packages / modules. Do NOT let them choose their own. (You may want the option of allowing them to make suggestions, then again, you may not…)
3. They have no idea how to define a project – they believe that the code is the entirety of the project. You’ll need to assign any additional work (e.g. documentation, media resources, etc.) as separate tasks. You’ll need to worry about design, defining functionality, setting requirements, etc.
4. They have no idea how to implement a project. They know the basics of coding, but they’ve worked on nothing significant outside a class assignment. This means you need to create a very highly detailed project plan with lots of small, discrete steps. Never give the students the project to do, instead just give them individual steps with deadlines. Check in OFTEN.
5. The students have no idea what an enterprise system is like. You have to introduce them to the idea of dev, staging, and production environments. You have to set up those environments and establish the processes for moving code from one to the next. Be very leery about giving the student the ability to put code on production.
6. They don’t understand the importance of source control, nor how to use it. Tell them what system to use, set up the repository yourself, and given them any necessary training on how to use it, and how to use it well/appropriately (e.g. use good commit messages).
7. They don’t collaborate. You must establish the protocols and environment which let them work together. Make sure they spend at least some time doing pair programming.
8. They do not know how to interact with end users. This one is tricky – you want to be involved in all end-user-to-programmer meetings/interactions, but you DO want those meetings/interactions to happen. The three main drives for coders are the abstract, artistic joy of creation, the fun of puzzle/problem solving, and the appreciation from people who use their code. Because of the tight controls that are needed for student coders to produce work that you can use, the first two are limited. Happy, motivated coders are better coders, so you want them to get a chance to be appreciated by the end users.
9. They have no idea how to end a project. You need to give them (and make sure they use) specific, concrete, measurable ways to declare the project (or step) done and move on to the next thing.
10. They de-prioritize project work, especially during the semester. You need some really serious carrots and/or sticks to compete against social life and class work. Failing that, arrange things so that you can get the most out of them when they do settle down to work. Provide a good, relatively isolated work environment (if possible don’t let them work in their own environment; explain to them that it’s not about trying to control them but instead about providing a clear, distraction-free mental space that enables and encourages focus and ‘getting in the zone’). Schedule fewer longer blocks of work time for them, even if the total time is less; 1 six hour block is more effective than 5 two hour blocks.
11. Bonus! If you do get/have a superstar student coder, they will be good at coding – give them free reign in that realm, but keep them away from larger system / project design. Also, they usually have not learned how to work well with other coders.

Project Design / Management Caveats

• Assume that the project will not be completed. The sub-parts of your project should be useful in their own right. Use a model of independent vertical slices for sub-parts rather than a core-enhancements approach – the core will not be solid enough to build upon anyway, and you want your different project pieces to be able to run in parallel with minimal inter-dependence.
• Assume pieces will break after completion. As much as possible orgizing your system / toolset as a collection of independent mini-projects so that one part failing allows the others to continue to be useful.
• Assume upgrades are not possible. Just give up on the idea of upgrading the system later – budget for re-writes instead.
• Assume any active maintenance will be very difficult and/or costly. Touch the resulting code as little as possible once things are running.
• Assume zero flexibility / extensibility. Plan to rewrite if and when changes/extensions are needed; treat each project as an experimental prototype which will need to be re-done from scratch to incorporate refinements.

Bright Spots

On a positve note, there are some things that student coders are especially good at – take advantage of these if possible (though I realize some of this conflicts to some extent with the above advice – managing anyone is a tricky balancing act) :

• They are REALLY good at learning new things – they’s been actively practicing that skill more or less continuously for 10-15 years. Experienced professionals are also pretty good at this, but they tend to be out of practice; students essentially spend 6-12 hours per day practicing learning and are definitely in that mode, while professionals learn new things as needed and/or interested but tend to spend more time refining the application of what they already know. So, don’t be afraid to toss something new at them and expect them to be able to get up to speed very quickly.
• They (and, honestly, probably most professional coders) are obsessive about the things they like. If the project is something that really grabs them, then they’ll spend amazing amounts of time and energy on it and everything associated with it. Sell the project to them, don’t just assign it to them.
• They are creative and unhindered. Give them some space in the project to play (i.e. not to waste time, but to try crazy things that you know are doomed to fail but that they might make work anyway).
• They gravitate towards the new. If you want your project to incorporate cutting/bleeding edge technologies, students are good at finding and using them (just be aware that those same technologies may be abandoned and/or changed beyond recognition in 6 months).
• They’re fun! Working with them is rewarding on a number of levels. They often have a wicked sense of humor as well. Leave room for levity in their work environment.
• They are sponges / mirrors. They will give you perspective on your own habits and traits.
• They are teachable/trainable. Beyond their ability to learn new information / intellectual skills, their habits, techniques, approaches, etc. can be improved – professionals are often pretty set in their ways.

Cultivating Your Student (and/or Professional) Coders

Here are some things you can do to improve the quality of a given coder over time:

• allow them time on the clock to learn, but give them a selection of specific topics and make them create something based on what they’ve learned – and don’t be afraid to assign them a writing project (having a Student Ramblings blog could be useful here). Some topics/learning projects:
  • various project managment techniques (agile, scrum, waterfall, etc.)
  • different languages (learn new ones and create simple programs in them, or do compare and contrast)
  • frameworks
  • design patterns
  • explore different skill sets (DB/sql, html/web, sysadmin, desktop applications, mobile apps, UI design)
  • IDEs – learn how to use one/several, explore the debugging tools, compare/contrast
  • regex
• make them write documentation
• have them work on someone else’s code
• have do debugging; give them end-user bug reports and have them find and fix the bugs
• have them do pair programming with a more experienced programmer
• have them do a critical analysis of the project process; get them to articulate both what could allow them to more effective and what/how things could improve the final product
• have them create project proposals and plans, including requirements and use cases (there’s a decent chance they’ll come up with something cool that you’ll want to have implemented at some point)
• put them in charge of other student coders
  • manager
  • teacher
  • code/design lead
• encourage them to participate in online coding communities; they should be unafraid to ask (or answer, for that matter) questions on the internet.
• have them explore the StackExchange site(s); make them get/have accounts there
• make them use project management tools; assign tasks, track progress, determine pay, etc. using a PM tool
• send them to a conference (if your budget allows – barcamps can be really cheap…)
• host/run a local mini-conference (or, more likely and easily, an unconference)