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.
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!