Thanks to a glitch in the time-space continuum (which apparently operates on C code, who knew?), I accessed the following article, written by some random coder, from a version of dev.to 30 years in the future.
The most interesting part to me is the comment section on that article. Just goes to show you, the more things change, the more things stay the same.
Don’t reinvent the wheel.
I submit the aforementioned for admittance into the “Terrible Folk Wisdom Hall of Fame.” We bandy the phrase about as if it is holy scripture, but think about it…
How many times in the history of the world have we literally reinvented the wheel?
I first picked up programming in my junior year of high school — perhaps better understood as my second junior year, as a traumatic brain injury [TBI] two years prior had set me lightyears back academically, from 4.0 Sophomore and college-level reading to failing pre-K material. I had crawled, hand-over-claw, back to the same level of coursework I had once been able to work with. In the process, I had lost my ability to fully grasp the biological sciences I’d once loved, but I had gained a tremendous understanding of math. Along with it, I now had the ability to visualize algorithms in higher dimensions. I’ve had it compared to a superhero origin story, albeit without the tangible powers.
It was during this “second junior year” of high school, during which time I was playing around with Visual Basic, that I picked up a copy of Dreaming in Code by Scott Rosenberg.
In the very first chapter, Rosenberg describes something he calls “Software Time”…
Like it or not, IRC is still one of the predominant chat protocols in the computer industry. Hundreds of others have come and gone, but none have ever truly replaced it. It lacks the bells, whistles, and gongs of many other protocols, but that only seems to add to its value. It’s decentralized, virtually bug free, and it works with nearly everything, on any box with an internet connection.
That’s why this will always be true…
Nearly any healthy programming workflow will involve code review at some point in the process. This may be a Pull Request on GitHub, a Differential Revision on Phabricator, a Crucible Review on Atlassian, or any number of other review tools. But however you do it, not all code reviews are created equal.
At MousePaw Media, we have a strictly enforced workflow that includes a mandatory pre-commit code review. These have helped us catch many bugs and sub-optimal code.
Yet many interns are afraid to do code reviews, fearing they have little to contribute, especially when reviewing code written by developers who have been there much longer than they have! Meanwhile, the quality of code reviews – even my own – can vary greatly depending on many factors: familiarity with the code, time of day, time of day, you name it.
I should probably slap a huge disclaimer on this post: I helped write PawLIB, a new C++ programming library from MousePaw Media. It contains some of my favorite code I ever wrote. Besides wanting to build high-performance data structures, we really wanted to make C++ fun again.
Instead of trying to describe what makes the library cool (I’ve already tried in the official press release), I’d rather demonstrate some of my favorite little tricks.
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.