Spectacle is KDE’s program for taking screenshots. I’d been pointed to its list of “junior jobs” – open bugs that should be fixable by new, aspiring, still-learning, wannabe contributors.
I chose one that sounded interesting and within my ability to fix. It involved adding a command to prevent the display of a popup window that confirmed that a screenshot had been captured. All the code was already in place; all I needed to do was add (or fix) that switch.
And I did that.
But then I started to do more. While fixing “nonotify”, I came across other functions that didn’t seem to be working, or not working properly. I proceeded to rewrite the help messages. I reworked and rearranged the input commands. I even added something I openly disclosed as feeling like a hack to make something else work.
I submitted my patch and waited for a reply.
And this is how I met Henrik. He’s what amounts to the project manager for Spectacle. Naturally, he’d be the one reviewing and approving my patch.
He reviewed it. But he didn’t approve.
I realized that I’d vastly overstepped my bounds. The bugfix assignment was a simple one. I didn’t stop where I should have. I got overly ambitious and added all those other “fixes” and “improvements”. Without a plan. Without understanding the bigger picture (no pun intended).
I was immediately intimidated by his disapproval. I felt like I was in over my head. I felt like a student who’d blown an assignment by not following the directions.
But it turns out that Henrik is actually a really good guy. We set aside the mess I’d submitted and he gave me other, simpler, tasks.
One was to figure out the cause of some warnings being generated by the automated compiler system. It’s name is Jenkins. Whenever a piece of KDE software is published, the Jenkins system compiles it, runs a bunch of tests on the code, and reports back all the successes and failures. It also logs any warnings – questionable code that could indicate a problem, but isn’t an error.
I looked at them and again thought they’d be easy fixes. Two lines of code needed, to wrap up and finish blocks of commands. I inserted them, compiled the program myself, verified there were no more compiler warning, and posted my fix.
Henrik took a look at what I’d added. He hadn’t had a chance to download my patch and try it himself, but he wanted to make sure I understood what I’d changed. I’m still learning C++ and how it handles common programming concepts. It’s different than other languages I’d learned. That’s where those warnings come from – program statements that aren’t errors, but are questionable and deserve review.
Henrik helped me understand exactly how this programming construct works (a switch/case decision block, for those interested in the gory details). He directed me to an online example and asked me to dissect it. I stated that one usage was incorrect and should be considered an error. Henrik reiterated that it’s not an error if the programmer wanted the end result that the code produced. It may not be good form or coded according to project standards, but it’s not an error. Hence the compiler warning. Not an error.
He also had me trace the sequence of events that occur in the program surrounding one of the warnings I’d silenced. It was an arduous task for an untrained C++ programmer, following the bouncing ball as it moved between blocks of code in numerous files.
But I learned the lesson Henrik was teaching me. It’s important that I understand the inter-connectedness of these programs. How all the various modules interlock to make a working whole. That I can’t simply drop a one-line fix into a big program. Maybe that warning is just a warning and the code is correct. Maybe my fix wasn’t appropriate.
We left things there and I went off on vacation.
I didn’t feel bad about this exchange at all. I’d been tutored by a senior developer, someone very familiar with the product being operated upon. He was patient and even light-hearted at times. But he was rightfully strict. He knew – better than I did – that you can’t just throw fixes out there and presume they’re correct.
As it turns out, my “fix” breaks the program. Henrik has left it up to me to find what I did incorrectly. He offered his help at a variety of levels, ranging from simply telling me what’s wrong to allowing me the opportunity to track down the problem on my own. It’s a generous and patient offer. Remember that I’m just supposed to be chasing down warnings, not fixing bugs. But by doing so, I apparently introduced at least one new bug – a real one. One that crashes the program, even though Jenkins wouldn’t complain about the code.
I’m up for the challenge. I think. Henrik is willing to help. I need to learn and understand what I’m doing. If I’ve got someone who’s willing to let me learn and explore, I’m going to take that opportunity.
I don’t feel intimidated any longer. Instead, I’m grateful for the mentoring. It may be unofficial and in the middle of live software updates, but I’ll take any lessons that I can get.
When I worked in engineering, senior people jealously guarded their trade and rarely – if ever – took the time to teach and share. Their work involved the secrets of the pyramids, and we junior people weren’t worthy. It frustrated me to the point of mental and emotional exhaustion.
But that’s not what’s happening in the KDE world. I’m participating. I’m definitely not getting everything right on the first try, but I have people willing to help me. And teach me. Who’ll let me learn from my mistakes without abusing or insulting me.
That’s the key of the free and open-source software community. It’s a community. Everyone’s a volunteer, from the project manager to the newcomer, wannabe bug-squasher. Share your finished product, share your knowledge of programming.
As it turns out, I’ve worked out a revision to an earlier fix for Spectacle. I believe I’ve solved the problem in the way Henrik intended. I wrote up my findings for him and am waiting for his comments before submitting my code.
I’m learning. We’ll see how well it’s going in the next round of review.