It’s a surreal thought that I’ve been running MousePaw Media’s internship program for nearly four years. In that time, I’ve learned a lot about hiring, management, and training, often purely through trial-and-error.
We invest most of our personnel efforts into interns; it’s actually the only way into the company. By time an employee has completed the year-long internship program, we know they are ready for the responsibilities of a senior development position. Not only are they well-versed in our company’s practices and methodologies, but they understand what the internship program is about.
That second point is important: whether you plan it or not, your entire staff is involved with internship and employee training. By making the internship standard at our company, I know our entire staff is familiar with the challenges and expectations. They can empathize with current interns, and they know how to come alongside and offer support.
Today, MousePaw Media now has one of the most robust internship programs in the Spokane/Coeur d’Alene area. To date, almost a dozen programming students have graduated from our program, and many went on to full-time positions at other firms. About half of them, I’m happy to say, have stayed on with us.
Objectively, there’s very little difference between a successful internship and a successful training program. So long as the compensation is reasonable for the individual’s existing skill level, I believe any developer without an overgrown ego will be open to working through a formal training program at the start of their job.
I hope by sharing my experiences and hard-won lessons with you, you can ease the process of onboarding new developers at your company.
I spent a good part of this afternoon in a planning meeting with my assistant lead developers, Alex and Jarek. We hashed out a lot of details for the new year, not least of all, ground rules for adopting libraries.
See, we’ve burned a lot of man-hours in the past on learning libraries. One of our projects ultimately met its demise because of an infamous XML parsing library (which will remained unnamed to protect the guilty developers involved) – our project’s developer had to put in somewhere around 6 months of work to learn the library. Another of our developers, working on a completely different project, had to invest the same amount of time into learning the same library.
When you’re running a software startup that relies on six-hour-a-week interns, that’s time you can’t afford to burn.
As we recounted those facts at the meeting earlier today, I had a revelation. “Learning a library is a non-transferable investment.”
Programmers have an odd obsession with acronyms. We pepper our conversations with them until it sounds like we’re speaking a foreign language, and I’m not entirely sure that isn’t the whole point.
There are two rather pesky acronyms that, once uttered in general programming territory, will start either a heated debate or an all-out war.
Those acronyms are TMTOWTDI [There’s More Than One Way To Do It] and TOOWTDI [There’s Only One Way To Do It].
The old adage holds true – when you have a hammer, everything looks like a nail. The past ten+ years of the programming industry have demonstrated that in a most unfortunate way. We dynamically allocate everything.
One disclaimer before I begin: Dynamic allocation is an earth-shatteringly vital tool, without which most feats of programming would be at best impractical, and at worst impossible. Do not throw the baby out with the bathwater. If you’re writing any sort of serious software, you will have to dynamically allocate something at some point. The key is knowing, not if, but when to use dynamic allocation.
UPDATE: I want to emphasize that there is a definite case for phasing out C as a low-level development tool for new technologies. There are alternatives, including Rust, that can be considered. However, as long as C code exists, I believe my points still stand.
“Please don’t tell people to learn C. It’s our grandfather’s language.”
He wasn’t the first person I’ve encountered to make this argument, and I know he won’t be the last. It reveals a dangerous attitude which is increasingly prevalent in the programming industry, and I’m not the first to notice it.
Oh lookie, a new entry for The Field Guide to Common Nerds!
Over the past few months, I’ve become acutely aware of the species of programmer that drives the P. Newbieflamerous to attack. I’ve dubbed them P. Nogoogleus. This species appears on various programmer communities and tries to get more experienced programmers to write their code FOR them.
As fellow tech blogger Matt Gemmell wrote, “There’s an entire class of so-called developers whose first and final tactic when given a problem to solve is to simply ask for the completed solution elsewhere, commonly on web forums or other suitable help channels.”
And, ohhhhh BOY are there a lot of them.
I never really realized how quickly numbers add up when you’re dealing with exponents until today. I was trying out an idea in programming, but as soon as my estimations reached about 14 zeroes and my TI-83 graphing calculator threw an overflow error, I realized that I had a problem.
Perhaps I should explain…
After my code decided to be evil and stop working, I decided to take a couple of days and install some additional operating systems on my work computer for testing our project. It turned into a trip down Geekdom Memory Lane. (Anyone remember Windows 3.1?)
After spending hours trying to solve an especially difficult problem in programming, I decide to take a break and log onto a chatroom on a Christian radio station website, where I met a young man trying to solve an especially difficult math equation in his Algebra homework.
Half an hour later, 2/3 of the chatroom participants are trying to solve this equation, and we’re all getting confused. (more…)