The Not So Small Things of Developing Software

Reflecting on my software experiences, I've formed a list of deep curiosities. Here is my list of all the not-so-small things I learned about creating software.

Defaults rule the perceived experience - what comes shipped in software is what sticks to its adopters. I've learned what is preset in software, such as settings and default preferences, shapes a first impression. That impression predicts an excellent experience from a flawed one. Adopters of my software rarely see past the defaults. Those who do are my power users.

Rubber ducking clarifies intent - when I speak to a rubber duck about issues, it solves my problems. When it doesn't, I'll take another step, talking to another human about what I am to do. Performing these two actions has a consistent effect. It increases the odds of achieving what I've said, solving the problem in a shorter time.

Communicate using video often - a problem discussed in a conversation needs context. Today, sharing motion capture has become effortless. Why not cut a gif or movie of the observation sooner? Since I've used gif creation, it has helped me cast a broader net to solve my problems faster.

The most straightforward answer is the right one - debugging is a process of deep information gathering and logical deduction. If my approach goes "off the ranch," I'll tie back the fantastical thinking (or blaming the framework) for such woes. Instead, the solution to my problem is a straightforward answer.

The answer comes the following day - while rubbering ducking above is half the strategy to unstick my problem, the other half is to step away and let my mind stew. The solution to a problem will come the next day. Whether in the shower, exercising, or chewing breakfast, an explanation from yesterday's woes will bubble up.

Deprioritizing quality for delivery - when revenue is on the line, humans will set an immovable date. Next, consistency and quality will forgo their priority in delivering software. So when delivery is declared, its scope, but precisely, quality, is at stake. Said plainly, not everything worth doing is worth doing well, which is a difficult lesson for me as a former perfectionist.

Instability at the edges - when I develop software, the middle parts of the system are stable. Instability lies in the edges, the seams, and the software setup. Therefore, I test software presets to ensure edge cases are tested thoroughly. Assumptions of the state should remain explicitly protected, meaning I clarify the default state.

Scripting things remain essential for automation - writing manual instructions is a step toward automation. I've achieved this by do-nothing scripting, a great way to capture actions performed in an environment. Taking the scripts I wrote, I'll hammer them into a future pipeline to build software in continuous integration later.

A route to innovation is through tooling - creating tools for software engineers is a perfect environment to develop novel solutions to common problems. Tooling demands invention since it's hermetic to a problem that needs solving. Interestingly, since the tool's focus is the immediate resolution of someone's pain, there is a higher chance of discovering an untried solution.

Naming and grouping things remain complicated - aliasing software components requires a choice of cute versus descriptive. I've participated in teams of senior engineers where services are tagged "creatively." While labeling does not have an answer, organizing those names is clear. Grouping by concern, not by type, is an excellent strategy to keep my sanity in check.

Grains of salt in applying quality acronyms - my engagement in pursuing quality software contained acronyms over the years. DRY, YAGNI, AHA, TDD, and PAGNI, to name a few. While all these are reasonable guidelines, easing their application in construction is a route for sanity. Over-application of such methods leads to developing into a corner. It's a matter of judgment and moderation. If I had to haul them all away, the one I would keep is KISS. Over-complexity destroys clarity.

Interviewing requires specific practice - interviewing is a core part of maintaining my career. My interviewing experiences have been challenging. I've succeeded, but in others, I have failed, sometimes humiliated. While every interview I've participated in was fair, some felt like intellectual hazing. I say this because the complex challenges raised in discussions do not appear on the job. So practicing is a skill set in itself.

Distance between teams breeds contest - having experience working with collaborative teams over the years, I've witnessed that distance equates to competition. As isolation increases, so does the perception. It takes filling the gaps between people to void the disharmony. But I learned sometimes I could not smooth out the edges, a reality of participating in a group of software engineers. I had to let go.

Remote work is a mental game - I support remote work and its flexibility for engineers to do their job well. Just like interviews are a skill set, so is working remotely. Lately, the impact of a world-shifting pandemic has caught up to me. My journey has been a long adventure of becoming productive in the new environment.

Support systems become collateral to burnout - it was uncomfortable when I was engaged in a time-consuming project for months. Wrapping software engineering into a career is a recipe for experiencing burnout. I found it crucial to find a support system to lean on. Software engineering requires deep thought. With its intensity, my support system had become collateral. To put the brakes on solving issues, I purposefully said no.

The urge to become an expert gardener - while plenty of my contemporaries swear by the craft, few want to quit to become an expert gardener (or farmer) due to exhaustion. At a point in my career, I see a precise repetition of events. Planning, developing, testing, and shipping software. Specifically, dealing with the politics in-between with a growing list of shelved projects. It may be time for me to take up gardening. :)

Conclusion

While this list is a living document, it captures my not-so-small things about software creation. While developing software, these essential concepts are front of mind while creating solutions. In time, embracing them will lead to further discoveries. I am sure I missed a few other core concepts, which I will add later.