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.
In my free time (yes, I actually managed to scrape some together!), I’ve started work on a project I’ve been planning for quite some time – building the music library application of my dreams! I picked up my favorite language, Python, and dove right in.
As to the GUI, I recently swore off GTK in all forms, after a particularly aggravating incident with my company’s Infiltrator game project. One of my IRC friends pointed me to Kivy, a modern GUI library for Python, and I immediately fell in love.
The challenge is, Kivy still has some rough edges which, while a potential source of frustration, also means lots of opportunities for adventure!
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.”
I recently undertook the challenge of writing a sequel to Charles Dickens’ classic story, “A Christmas Carol”. You may think that writing a short story revisiting some of the best known characters in English literature would be quite simple, but this has been the most challenging story I’ve ever written.
(You can download a PDF of the book for free at the bottom of this article!)
Before I explain why, I need to give you some background on why I started this project. Writing sequels to classic literature isn’t exactly common for me, someone who hasn’t ever written so much as a piece of fan fiction. (I tried once, couldn’t get past page two, and scrapped the whole thing.) I will admit, I’ve made up plenty of “fan fiction”, but it has never escaped my head onto the page. It’s just not something I care to put on paper.
The trouble is, I had a dream – one of those really awesome dreams that you wake up from and think “that would make a really cool book!” Of course, given fifteen minutes of daylight and a cup of coffee, the dream starts to look rather insane, and you decide not to describe it to your editor.
Three days of hard work has finally paid off! My company’s build server now allows Phabricator to talk to Jenkins, which in turn does all of its building on a VirtualBox.
The first half of that was easy, as Uber has a nifty little open source Jenkins plugin on Github for interfacing with Phabricator. The second half isn’t quite so obvious or trivial, especially if you’re not already a Jenkins expert.
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!
After he retired from superhero work, defeating criminals with crushingly obvious statements, Captain Obvious settled down and got a job in marketing. I know this because of a statement he wrote on a jar of peanut butter.
I think that actually says something about me, when I can go from peanut butter to retired superheroes by association. I wonder what ol’ Freud would have to say about that.
by Jason C. McDonald
Lefty McCorsky was quite possibly the best pitcher in minor league baseball. In fact, he might be the best pitcher in the history of baseball altogether, but none of the statisticians were ever present at our games to prove it.
As popular legend has it around here, before a batter has a chance to react to one of Lefty’s pitches, his curveball has already come around and smacked them in the back of the head.
Lefty was really the only redeeming element of our local team, the Thompsonville Pluckers. We didn’t have any stats on our team because, as it turns out, a zero-win record makes for difficult number crunching. Apparently you can’t divide by zero – at least, according to the local bookkeeper, the only person in Thompsonville to remember anything from math past basic multiplication. Of course, there are the rumors that he’s just avoiding doing the math, because he’s part owner of the team, and looking at the numbers depresses him.
Skills aside, we were a baseball town. You could find us in the stands every Friday night. The hot peanuts were worth the humiliation of our perfect losing record, and anyway, there wasn’t much else to do on a Friday night.