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.”
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!
Things went a bit haywire for me recently. I pressed the wrong button on an OS repair and wiped out my hard drive. I managed (thanks to Testdisk on Linux) to get 80% of my files back.
With my files salvaged, I decided to rethink my computer setup. I’m not going to lie, I hate Windows 8, which I call “Windows Ape” (big, ugly, hairy, and takes up a lot of space). I’ve had an on-again-off-again relationship with a version of Linux called Ubuntu. Finally, I decided to give it the reins on my computer.
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.