Willy Mills was Innolitics’ first employee. He was brought onto the team due to his deep technical expertise and to provide advice and feedback on how to run the business; Yujan and David started Innolitics after graduate school. Over the past five years Willy has been key part of our technical and business growth. He retired this February; we’re excited for him and sad to see him go. This article is a fun retrospective of his time working with us and includes some of the nuggets of knowledge that Willy has shared during his time at Innolitics.
During a 10x meeting where we discussed developer setups and productivity tips, someone recommended using an extra monitor to improve a developer’s productivity by reducing the need to switch windows. Many developers probably have one or two additional monitors. Willy introduced his workspace: 8 monitors in total, each having a designated role in his workflow.
With this many monitors, alt-tabbing between windows is but a thing of the past.
Throughout Willy’s time as a developer, he has been an avid bug-catcher of both small living creatures and the engineering variant. As part of his farewell, he shared a list of some of his favorite “bugs”.
From Willy himself:
A bug is a condition where software that should work, doesn’t. That is a logical contradiction. The only valid conclusion is a false assumption exists. This leads to the debug mantra: “Something you know ain’t so.” Some of my favorite false assumptions:
Line printers print the text you give them. False. The early ones, pre-ASCII, used the first character as a command.
The keyboard in front of each monitor is connected to the same computer as the monitor. False. This created some seemingly impossible modem behavior when two computers tried to communicate.
The packet you received is the packet that was sent. False. A “While You Were Out” note sharing application caused all the employee names to change to “G. Dog”. There was a security application called Guard Dog that was changing the content of packets to prevent private information from escaping the company network.
Software cannot literally burn up your motherboard. False. A few poorly designed boards went up in literal smoke when a particular device driver got extra busy. I worked for the team that made the driver. We were told in a stern memo that all inquiries on the topic were to be handled by the public relations department. But on my monthly trip to visit the home office my manager gave everyone on the team a t-shirt that said “Be nice to me or I will make (product name) fry your motherboard.” This was so contrary to the stern memo that I concluded my trip report with the line “For security reasons, all further communications will be by t-shirt.
Your own eyes won’t lie to you. False. An Innolitics customer complained that the rotating 3d image of a mouse had the right kidney on the left side. But if you closed your eyes briefly while imagining the mouse rotating in the opposite direction, then opened them again, the mouse would reverse rotational direction and the kidney would swap sides. The bug was a wetware problem in the human brain.
Lessons learned 🔗
Throughout his time at Innolitics, Willy has been a fountain of knowledge and experience. Below, we share some of the lessons we have learned from Willy.
Get paid to learn 🔗
Willy shared with us a jocular resume that included the highlights of his career. Through the document, the phrase “get paid to learn” appears no less than ten times. Although the document was a humorous parody of a professional resume, this concept of getting paid to learn is quite important.
Working can often, if not always, be a learning experience. Thus, if you’re going to spend the majority of your life working, you might as well learn as much as you can during the process. Obviously, being a working professional generally requires an existing level of proficiency, but there is always a way to improve your knowledge and skills, especially in the software industry where new and improved technology is introduced constantly.
Keep a personal wiki 🔗
In the professional world, one tends to accumulate a lot of data and information after years of work. Sometimes, there are bits and pieces that may be important to reference in the future. I had once asked Willy if he knew any resources regarding the setup of a Mirth server, now called “NextGen Connect”. Within a minute, he found and shared links to a number of sites, adding that he simply did a keyword search through his personal wiki.
At first glance, this just seems like something achievable through a Google search. In software development, there are obscure bug fixes and complicated dev environment settings hide in old forums and may take hours of extensive searching to find. Bookmarking the URL in a personal wiki can help you (or even others) avoid repeating such searches months or years after the first, and storing files, links, and notes in a personal wiki can be useful in organizing large amounts of data and filtering out relevant info.
El Matador 🔗
Yujan, Willy and I shared the pensive good fortune of lunch at a famous Mexican restaurant in Colorado. Any restaurant named for its founder imbues a certain pride and, once you know, you say it in hushed tones. Willy had driven hundreds of miles, and we didn’t talk about that at all. On his way out the door, somebody asked, “Are you going to Efrain’s?”
When talking about small, technically intricate things, it’s easy if a little tedious to tie the conversation up with precision. What was the precise solution to achieving the satisfying level of realism for model railroad details? Precisely how many pairs of a limited run of sneakers are available for lucky collectors? Efrain’s offers no substitutions and didn’t get this way by putting dishes on the menu with wide tolerances. I ordered the ribs—unprepossessing at first, but a real trial by capsaicin you’ll eventually never give up.
So, we talked about the difficult things that make big differences. The aspects of preparation learned as a short-order cook that surprisingly characterize a good project manager. To describe a good programmer, what we’re missing when we mistake patience for other, more marketable traits. Someone willing to sit through a problem until it’s provably solved.
The power law in the paperless office 🔗
We should listen when someone tries to point us to the simpler solution. It’s your job to sell that, to calm down the person asking for complexity. If you do your job well, the spectacular engineering failures will happen elsewhere. Why are these aphorisms? What makes them conditionally true with experience? Picture yourself programming with punchcards—do you have what it takes to port your skills from a hole puncher to a terminal, and then to a flickering raster? Those aphorisms came through the revolution.
Willy reminds me of Whitfield Diffie, apparently propelled through a rustic school system by stratospheric test scores. Willy had the perspicacity to demonstrate he could self-govern what he should study. This is, I think, the single most determining factor of success, and it’s how those aphorisms get credibly passed from one individual contributor to another.
Enjoy your work 🔗
Whenever Willy spoke to me about a project he was working on or a bug he was investigating, he had this kind of giddiness, like each problem was a Christmas gift or something. That really made an impression on me, and I think I have a greater appreciation and thankfulness for getting to solve puzzles for a living now because I had the opportunity to spend time with Willy and see how much joy he derived from it. I think all of us take joy in our work, but sometimes we need to be reminded by someone else just how great it is to do what we do.
A Farewell 🔗
Willy has been an integral part of Innolitics; many of us have become better developers and people from our interactions with him, and the company as a whole has gained so much from our most senior developer. We wish him the best in his perpetual weekend and hope his retirement is everything he wants it to be and more.
