BECOMING A DEVELOPER AND BEING A STUDENT
06/23/2017
About nine years ago, I formed Hunt Mountain Software and started to become a software developer, not just a programmer. One of the surprises of doing this is that it has helped me to better understand the graduate students that I advise in my day job as a professor of geology, and what they face.
Several years ago, I was at a breakfast meeting of associate editors for a scientific journal. One of the editors told a “can you believe this?” story about a mistake one of his graduate students made. It seemed like everyone laughed or shook their head in exasperation. Tongues clucked. Another editor told a similar story, and got the same response. That led to another story, and another. Finally, a quiet voice from the end of the table said “That’s why they’re called students. They’re learning.” The stories stopped.
It’s easy to forget what it’s like to be a graduate student. Each of those editors around the table was also a professor, and some were not too distant from being a student themselves. Perhaps the forgetfulness is just that, short memories. Perhaps it comes from learning so much so quickly that the days of confusion are too distant. Perhaps it comes from feeling superior for having learned so much. Regardless, it is too easy to forget what it is like to be graduate student, of being at the start of all that learning, of having the insecurity of knowing how little you know compared with those around you, all of whom seem so smart and so confident.
Becoming a developer has helped me, now more than 25 years after earning my Ph.D., to understand again what it feels like to be new at something and not yet having the confidence that comes with mastering a subject.
Although I had written scientific programs since I was in graduate school, taking those first steps towards becoming a software developer changed my outlook. There was so much to learn. There were data structures and algorithms, and conventions for naming and code structure. There was refactoring, and the multiple rounds of it required as your understanding of your code grows. There was object-oriented programming, which I tackled for the first time, and the necessity of understanding an object graph and the proper responsibilities of objects. There was the intricacy of Xcode itself, that essential tool for writing Mac and iOS software, and the need to understand that rich application in far more detail than I had before. There was the debugger and how to gain insights into your code more efficiently and more thoroughly than by sprinkling in print statements. There were unit tests to ensure that my code worked under all conditions, and that it still worked when I changed things. There were the issues of user interface and user experience, that not every user was likely to understand intuitively what to do with an app. There was version control, at first simply being able to save the state of my app, later being able to revert to a previous state of my code, and still later, being able to branch and experiment with confidence. Still later was having an online repository for my code. There was marketing and website design. There was code signing and its cryptic error messages. More broadly, there was finding help to problems I faced and knowing how to sort out good solutions from the bad.
It was so much to learn, and looking back, I was often confused in those first few years where a problem might lay. For so long, certain subjects might as well have had a sign that said “There be dragons there” because I found them so intimidating that I stayed away. Radical changes, like restructuring an entire app, were frightening prospects. Code signing in particular felt like a magical incantation.
Over time, two things helped. One was keeping notes. When something went wrong during code signing, I wrote a log of the error and how I fixed it. Nothing fancy, it was just a text file. With time, I saw patterns, and I recognized the fix. The second was writing code, a lot of it. Converting all of my apps from Objective-C to Swift immersed me in code, and practice really did make perfect, or at least something closer to it. Slowly at first, then more quickly, I got better, and my confidence grew. That confidence reminded me that some things are hard, good advice that Aaron Hillegass emphasizes at the beginning of his OS X books.
For several years, I’ve attended the local CocoaHeads chapter, and most nights, I felt like the graduate student, soaking up what these impossibly talented minds presented. It’s been great, but I couldn’t imagine giving a presentation. A month ago, the opportunity presented itself. The previous month was a presentation on Swift on the server, and I saw that it was possible to run Swift on a Raspberry Pi. Having had experience with the Pi, I offered to give a talk on the internet of things, using Swift, Raspberry Pi, and sensors. It went well, and I felt like I had arrived, a feeling I remembered from giving talks as a graduate student.
I now see my graduate students in a new light. They’re also learning an enormous amount in a short period. It’s not just that their classes are new, but the software to do their research, how to structure a research project, and even having a systems for completing the many individual tasks had to be solved at the same time. For my students, field work brings its own challenges: trying to interpret often poorly exposed structures in rocks, long hikes, hot days, maintaining a reasonably comfortable camp, and taking care of yourself under difficult conditions. It culminates in writing up your research, likely the longest document they’ve ever written, and presenting it at meetings to other scientists who need to learn quickly what you have done. Many students are also teaching introductory labs on top of all of this. Like being a developer, it’s so much, and it comes all at once.
It is no wonder that errors creep in with the inexperience, lack of confidence, and even just fatigue. It is remarkable that they don’t happen even more often. I look back on that editors meeting and see that at least one other person at the table understood: what is needed is empathy. What graduate students are doing is not easy and they are learning. Instruction, advice, support, and empathy — that’s what they need.