Advice to software development interns

I took on an 18-year-old as an intern for some Web development work. He had taken AP Computer Science, a Python programming course in high school, and Harvard’s CS50: “CS50 is designed not only for concentrators in computer science but also for non-concentrators. More than just teach you how to program, this course teaches you how to think more methodically and how to solve problems more effectively. As such, its lessons are applicable well beyond the boundaries of computer science itself. That the course does teach you how to program, though, is perhaps its most empowering return. With this skill comes the ability to solve real-world problems in ways and at speeds beyond the abilities of most humans.”

In addition to this academic training he arrived with a vast expertise on building Windows-based PCs, especially for gaming.

The assigned task was building a Web-based narrated slide show (previous posting on the subject) using this open-source SMIL-based tool as the building block. To accomplish this he had to learn much that was new, but nothing that was deep. For example, he needed to learn how to edit text on a Unix server (Emacs, of course!), enough CSS and JavaScript to understand and modify the open-source code, etc.

Here are some specific-to-programming items that could have made him more effective:

  • use Google and Web-based resources before interrupting the person who hired you, e.g., if you want to know how to do something in Emacs for which crib sheets are readily available on the Web and can be printed out
  • assume that the person who hired you will have superior strategies for solving problems but not superior knowledge of syntax
  • assume that you’ll have to teach yourself a new language or tool; “I need to spend the next 3 months taking a class in JavaScript” before I can be productive on this new assignment is not something an employer would expect to hear from a programmer. [It seems that his elite public high school and Harvard had both prepared him to be spoon-fed information; a typical assignment would include a couple of pages of code with a few missing lines to fill in.]
  • start simple and build out; if you can’t understand a file of CSS, for example, take all of it out and add it back in one line at a time; if you don’t know JavaScript spend half a day building small programs before trying to understand a larger program that you’ve downloaded
  • if there is a bug, strip the system down to the minimum number of lines of code that still exhibits the bug

Here are some general life-as-an-employee items:

  • If you’re cc’d on communications regarding meeting times with other people and need to talk to them or arrange something with them, reach out directly via email, cc’d your supervisor. Don’t use your supervisor as your secretary.
  • Don’t rely on your supervisor to keep schedules, remember tasks, etc. A senior programmer is not a secretary or project manager.
  • Use all available resources. Ask questions in Web forums, ask for help from anybody that you know that has relevant knowledge. The most successful workers are generally those who bring in expertise from beyond the organization.

What did I learn? That grit is perhaps the most important determinant of success as a software developer. The most effective developers simply won’t quit until a problem is solved. One reason I think programmers often stay up until 2 or 3 am is that it bothers us if something isn’t working. So we keep at it until we collapse. We call in favors from friends and colleagues for help if we are stuck. I would go so far to say that if a person can cheerfully walk out of the office at 5 pm without having solved any problems then he or she should probably pick a career other than software (Real World Divorce shows that there are a lot of easier ways to make money here in the U.S. and this posting shows that a not-very-driven-programmer will likely have a short-by-modern-standards career).

15 thoughts on “Advice to software development interns

  1. Phil wrote:

    The most effective developers simply won’t quit until a problem is solved. One reason I think programmers often stay up until 2 or 3 am is that it bothers us if something isn’t working. So we keep at it until we collapse.

    The wife of one of my co-workers once told me that she enjoyed being a programmer’s wife a lot more when she realized it wasn’t the *same* program that didn’t work every day when he came in the door looking discouraged and saying, “My program doesn’t work.”

  2. While these suggestions are helpful to any new programmer or employee, it sounds like you hired somebody with insufficient qualifications to perform the job at hand without providing the necessary mentoring that is expected in a relationship between a business and an intern. Some advice to people who hire software development interns:

    – Properly screen your candidates to ensure they have enough foundational experience to build up the necessary skills to fulfill their job.
    – Make sure you are able to readily provide resources for the intern to draw from. An intern isn’t just cheap labor, it’s a mutual relationship where you actively help to train and grow the intern’s skills.

  3. Strongly agree. Would only add one point. As a programmer matures, they need to develop a sense of when it is best to walk away from a problem and come back to it later with a fresh outlook. Particularly as an employee, being able to walk away at the end of day preserves your sanity and keeps you from being exploited.

  4. Agreed except for the long-term career prospects; the qualities that make young software developers attractive for web contract work (speed, self-sufficiency and competence) come from routine and knowledge of specific tools.

    At some point between twenty and forty, these qualities start to become liabilities for a career programmer; even self-sufficiency is dangerous, as corporate environments tend to favor people who communicate a lot, regardless of whether this communication is productive.

    A lot of these forty year-old twenty-somethings seem to end up self-employed, making money from companies that have critical systems that depend on a narrow skillset they happen to have.

    And a lot of them end up unemployable, not because they’re “not very driven”, but precisely because they still work as if they were twenty years old.

  5. > That grit is perhaps the most important determinant of success

    I’m gonna disagree and say the most important factor is an engineering degree (a real one, not a self-appointed “software engineer” or “network engineer” title). The key difference is that all engineers had to survive a statics course where they learned to methodically analyze complex problems. They start by learning how to balance forces and vectors, and end up being able to determine the loads on every member in a bridge.

    Time and time again I’ve seen proper engineers outperform others developing software, especially with large systems. Too many devs try to do too much at once, or keep randomly poking things until the desired result is stumbled onto. I’ve also read praise for liberal-arts-turned-programmer geniuses, but never actually met one of these unicorns. For dev or analyst roles I try to hire real engineers (their sub-discipline seems to matter little) first.

  6. JGalt: that cracks me up. When I was managing developers full time my best programmer was a college dropout from Louisiana and one of the worst was from India’s version of MIT. Maybe if we had been in the compiler business or something like that things would have been different.

  7. Hi Phil,
    I believe that’s good advice for an intern for almost any job. I would add one important thing:

    For an intern who is learning/researching/debugging some tasks, make sure to set time limits and figure out task dependencies to maintain a reasonable level of progress and productivity. If not enough progress is made, it may be time to reach out to someone.

    There must be a balance between spending time figuring everything out on your own and making productive progress, even if the learning experience is valuable. After all, you may be duplicating considerable effort that was already paid for by a senior developer. A “small annoyance” to that individual could very well save some number of days of lost productivity.

    I had an experience a few years ago working with a legacy C++ COM component written in DirectX for MPEG thumbnail generation. My team was trying to use C# COM Interop to re-use the component to batch-generate thumbnails. The original, lone developer of the code had long moved on to upper management. The component would not function correctly with the COM Interop within a .NET service context.

    The project manager wanted a “pure” .NET solution, so I gave myself two days to troubleshoot it to get it working with the .NET COM Interop. My conclusion was that the COM component had to be instantiated as a separate process outside of the .NET context to function correctly, and that there was no other work-around. The project manager disagreed and asked me to reach out to the original developer about it. It turns out the original developer confirmed my findings. They had went through the same troubleshooting for a different .NET project and came to the same conclusion.

    In this instance, only two days were lost to troubleshooting, but the desire to “stay on it till it’s done” can keep you treading water for a while if you are not careful 😀

  8. High school programmers typically lack project completion skills. And are likely to overestimate their abilities. And have no professional experience, obviously.

    A new programmer with Python experience might well be flustered by idiomatic JavaScript. It’s a weird language: prototype-based, kind-of-imperative yet sometimes functional, and has an obtuse type system. All loosey goosey.

  9. > The most effective developers simply won’t quit until a problem is solved.

    If you are one of the few who have a stake in the product, as at a start-up, this might be reasonable (it might alternatively be a tautology). The other 95% (?) who are salary-only employees might wonder why they should perform extra unpaid work their employer.

  10. LordP: you’ve highlighted another good reason to choose a different career, e.g., emergency medicine or some other shift work job where you don’t have to take work home. A programmer whose resume reads only “occupied cube for precisely 40 hours/week” is not likely to find work outside of government or government contracting.

  11. what’s wrong with aiming for efficiency in one’s work? if we’re dealing in absolutes, let me say no one who stays up regularly past midnight is an efficient worker.

    how many people are productive in mentally demanding roles working upwards of 40 hours a week

  12. what’s wrong with aiming for productivity in one’s work or, dare i say it, a work-life balance? if we’re dealing in absolutes, i’ll claim no one who regularly works past midnight is an efficient worker.

    and how many people are productive in mentally demanding roles working upwards of 40 hours a week? i’m talking about the real world here, not the supermen of the internet

  13. Perhaps, next time the employment offer should be contingent upon successful completion of a 4-6 weeks unpaid trial-internship. It is unlikely an 18 yr is making a living with this opportunity anyway. This post & comments reminded of a the kindergarten experiment- have kids draw/do crafts they seem to enjoy and they continue for hours, offer them a reward – and they quit the same very activity shortly after. It is all about the intrinsic vs extrinsic motivation after all. Interestingly, I now recall a story my husband shared (a PhD trained organic chemist with two post-doctorates) about a Harvard chemistry faculty member – s/he only takes a new post-doc in the group when the candidate has demonstrated sufficient motivation to be the group member. That is done via paying only part of the interview travel expenses and asking to write a fully fledged research proposal first. No guarantees to be hired.

Comments are closed.