DEV Community: Doug Arcuri

Prefer Accommodating Over Accurate App Experiences

Doug Arcuri — Mon, 16 Oct 2023 13:42:58 +0000

Comedy captured the moment as I suggested a destination to the GPS app. "Navigate to such and such place." A five-second pause. "Something went wrong." I tried again, twice. "You will arrive in three hours." Smirking, I said, "Hehe, yeah, right!" I've been through this rodeo. "No way it's three hours, more like four and a half!" An unneeded reply chimed, "Sorry, I don't understand."

We hurried above the speed limit, got fast food, and hit sporadic traffic. We arrived in four and a half hours.

For me, these experiences are typical, having not improved in years.

Apps Prefer Accuracy

Being involved in software for a time, I've had the pleasure to work with brilliant technological and product people. And yeah, every team skewed toward the happy path, preferring accurate over accommodating.

Accuracy is demanded in our culture, driven by two points: the relentless pressure to release and moving on to the next thing. Failing gracefully is not on the incentive list.

Apps that are accurate perform discretely, abandoning the user experience during errors, which drives odd customer behaviors. Consumers utilize unconventionality to get what they need, such as unduly forced closing apps, clearing cache, reinstalling, tapping numerous times to get the reward, or a secret action to perform the transaction, fiddling with settings to achieve it. Or, in my case, knowing how to deal with a familiar skew of results.

These behaviors have become common, a badge of honor. For customer service, there is a growing backlog of complaints, low user ratings, and rising churn.

The result is a consumer that acquires pessimism, frustration, the burden of remembering unique tricks, being overcome with doubt, and, in time, abandoning the product for something else.

Nonetheless, many experiences suck, and there is room to improve.

Prefer Accommodating Over Accurate

If we reverse our thinking, preferring accommodating over accurate, it will positively change user experiences. For instance, choose to provide upfront rich information, being realistic of an Internet connection, and give the consumer confidence when the transaction has yet to go through but will as soon as possible. Mercilessly scrutinize the error paths, rooting out accuracy, and provide accommodation instead.

Yes, accommodating experiences costs development time and incurs intense technical complexity to achieve. There isn't an easy way around managing statefulness, and technological inventions are waiting to be found to blunt the digital trauma. But it's worth an inquiry within your team, especially if the app is in production and the rush to launch has easied.

I've seen it many times. When racing to get a product out, accommodating actions get cut out of scope as teams within repeat in chorus, "Nice to have!" Ask the question, "Why so?" If we don't ask, few experiences will become smooth, and cooperation in intra-app experiences will remain unexplored.

Fluid, accommodating interactions do not have to be something of science fiction in software. It is worth taking steps to improve the experience starting now.

Do Laundry During System Demos

Doug Arcuri — Sat, 30 Sep 2023 11:38:44 +0000

When I'm jammed on a technical problem, time evaporates. I'll bargain with myself on when to separate. After a lengthy back-and-forth in self-negotiation on "one more thing!" I'll go for a walk. Recovering from mental despair, walking helps my mind collect unexplored methods to attack the frustrating problem. I'll organize my bubbling ideas to rebuild hope that this intractable problem is solvable.

Moderate physical activity helps my mind focus, and studies have confirmed my experiences. At least for me, doing something physical unlocks new ways of thinking. Another great example is showering. My likelihood of achieving the desired outcome increases proportionally to my number of showers. Showering is a time to navigate said problem. I just have to watch for the incoming Slack message my manager desperately awaits an answer.

There is my ritual of making tea or coffee as a build proceeds. Better yet, speaking to myself out loud to a rubber duck to navigate logic. Sometimes, writing, typing, or talking to another human will help separate me from the frustrating problem. Yeah, there are many ways to unstick what is stuck. For me, it requires separation to refocus my approach. More importantly, I have to do something physical.

But what is my most productive activity? I look no further than doing laundry. Performing the folding, sorting, and stacking is a great way to organize my plan of attack on a frustrating situation. In my experience, it has dispatched all my technical and personal problems.

Funny as it sounds, there is no other place like speaking to my pile of warm linens as our system demo proceeds on Webex. The best ideas had come from here.

The Springboard Pattern

Doug Arcuri — Mon, 31 Jul 2023 12:35:53 +0000

How to build new features in isolation

A few years ago, at an agile demo, a stakeholder made a special appearance. The team was closing in on a minimum viable product. The demonstration focused on sound effects and animations. The group revealed a configurable animation board to demo the results quickly. The experiences were easy to launch consecutively, isolated, and variably configured. The animation board did not depend on the more extensive system, but the intention was to tie each animation later.

While the team demoed, the stakeholder asked if we evaluate the animation board for further experimentation. With this feedback, the group noted the unrealized value and quickly wrote down what to explore next. Of course, this wasn’t the first time the team used the technique. We made similar discoveries in future demos. The team was aware the feature containment were incredibly powerful both for their demos and for product value.

For us as engineers, naming things is hard. Harder still is how to communicate something. To the above story, there exists no vocabulary to describe the effort of execution. There is no description for the iterative containment orchestration in software engineering.

So this is what I propose, a definition to describe the unique execution with its benefits and drawbacks. Developing and demoing in containment is an example of what I call the springboard pattern.

Let's describe what the pattern is.

What Is The Springboard Pattern?

The springboard pattern is known as a visual design pattern. Mobile operating systems that constrain viewing areas have used the pattern widely. The app launcher is an example.

Our introductory story and its animation board also fit this model. We can think of the animation board as the contained screen launcher and each animation as an organized app with its configurations.

When applied to software development, the springboard pattern acts as a guardrail to develop features in isolated pieces that are easily demonstrable on the platform. There are many benefits to engineering and product. The design is a way to execute both iteratively and incrementally operationally.

The springboard pattern is a way to keep dependencies in check and develop features on a cycle centered around product demonstrations. Here are the rules an engineer must follow while iterating.

The feature:

It launches from a board that includes other features.
Can launch quickly with minimum setup.
It can launch on its own and in any order.
The configuration is possible to launch in any state.
The feature resists larger system coupling and dependencies.

If we follow these rules during feature development, magic happens. Benefits include the promotion of modularity, testability, and build-time. Additional improvements include product ideation that is unrealized, engineer efficiency, and advantages of the framework. Let’s discuss these next.

Promotes Modularity

The springboard pattern insists on developing features in isolation from one another. In each design segment, the team must do their best to create a solution in containment.

Dependencies will always be present, but the layers separate the feature for demonstration cleanly. The feature should be modularized and independent. As the iterations continue and demos succeed, the springboard items integrate into the extensive system. As this occurs, the team should continue to resist coupling and ensure the feature code cohesion is high. From start to finish, each item should have a weak measure of connascence.

At any time during the cycle, pattern violation can diminish the return of the modularization. Therefore, the team must make prudent and deliberate decisions by leaning on tools of layering, wrapping, and flow of control using dependency inversion.

Supports Testability And Build Time

The development of a demonstrable item from the springboard demands testability. The unit tests will also serve as documentation of the module.

The concept of the springboard pattern is one that promotes testability. Its dependencies should be highly configurable. The feature should have available configurations available for its dependency injections. Thus this supports ease of testing and mocking of all situations of the component.

Build time also is maintained, and the complexity of the codebase is normalized with each feature. Incoming features can be flagged to be unbuilt by the toolset. Features that are rejected from demos are continuously removed.

Finally, a natural phenomenon of the springboard pattern can reveal diagnostic test tooling of that unique feature. The feature had started life without the extensive system. The springboard can make tools that test part of the feature in contra to the more comprehensive system as they are their subsystems.

Product Ideation And Engineer Efficiency

Opportunities happen when products are deconstructed into independent pieces. In the case of the introduction example, there appeared to be an unrealized product value in the use of an animation board.

Stakeholders refer to the features of their products as cohesive constructs and use vocabulary to describe them. Wouldn’t it be powerful to find the part without friction immediately? The springboard gives us a learning library and allows for cross-pollination between engineers and gives us a tool to locate each feature quickly.

As an additional benefit, the engineer’s work is always available for demonstration at a moment’s notice. An isolated solution offsets the typical cost of the time to prepare for the demo (you are giving time for the engineers to prep, yes?).

Mileage may vary depending on the domain and the reception from stakeholders. In the most pragmatic terms, products must predict less and experiment more. Having the features deconstructed and isolated may indicate a different outcome or a reconfiguration of that product value.

Framework Support

With the springboard pattern, there could be undiscovered efficiency benefits that coincide with features of the framework. The framework the team works with may vary. For this post, I’ll discuss Android concerning the use of a springboard.

Recently in the Android ecosystem, Google has launched Instant Apps and discussed at length the incorporation and break out of new concepts in the area called feature modules. As we can see from above, everything that is demonstrable to stakeholders should be modular and isolated. As development continues, insulate each feature from significant dependencies and optimize them for every feature. The product team may want to launch these features separately or together.

Another example of Android is the concept of isolated activities. Each activity should be able to launch in isolation, taking what it needs to survive an experience. If features are built-in isolated activities, reconfiguration of the pieces of an application is possible.

Finally, with the latest versions of Android, its tooling have significantly improved. Independent modules allow for building abilities, which significantly reduce build time. Setups that use a flavored code organization may cause building delays, especially if the product dimensions are extensive.

Before we conclude, there are drawbacks to consider.

Drawbacks

There are possible drawbacks to this mode of execution. The team will have to make decisions that make the most sense to steer clear of over-engineering.

The springboard approach may:

Violate YAGNI — “You ain’t gonna need it.” The team should build what they need, and not a single line more.
Accelerate decisions — deferring architectural choices is an excellent strategy to keep complexity manageable. Operating this way may force challenging code decisions sooner.
Increase complexity — additional logic to support layering and modularization may increase development time.

However, keep in mind that the cost paid will most certainly provide a cost-benefit for code that is consistent and adaptable. Adaptability needs room to breathe. The code and products deserve that breathing room.

Now let’s wrap this up.

Spring Into Action

Developing for isolation and modularity is a practice all engineers should strive for. However, there had not been a pragmatic approach to these concepts and a way to describe how to execute on them. It is assumed engineers build this way, but the reality is that they do not.

The springboard pattern in software development finally gives us a word to communicate our intention both in software execution. When adhering to this pattern, we manage complexity and increase optionality. As described above, the benefits are plenty, but be aware of the cost of drawbacks.

The springboard pattern takes effort and drive, but the benefits could be incredible to the team and their products. Center the way around the team demos and adhere to it.

Reply All Considered Harmful

Doug Arcuri — Wed, 31 May 2023 11:55:46 +0000

Learning from sending thousands of emails

Lately, I’m writing fewer emails at work. To me, email authoring can be torture. It’s the time-sunk cost of carefully crafting the message. And when I do send an email, I avoid Reply All. If possible, I would like the conversation to be between just us.

Over the years, my perception of how to use Reply All has changed. Earlier on, my understanding of its intoxicating power invoked a sense of urgency to all those addressed. But after being scrutinized in these exchanges and me targeting others, it has soured. Mix this in with selectively adding in authoritative figures; I now consider it harmful for the outcome of the ask and the long-term relationship for those involved.

You and I But Rarely Anyone Else

While participating in Reply All threads over the years, I’ve learned the concept of a directly responsible individual who is accountable and owns a possible outcome. And when replying all, this can muddle who is directly responsible for the ask. And suppose the message is poignantly addressed to a particular person. In some business cultures, the receiver may find it combative, comical, or downright ignore the ask while having an unfamiliar audience watching them. The perception of resistance is real when trust does not exist between them.

Reply All has the potential to scorch-the-earth. For select email clients, it is a dangerous default function. I’ve seen it become the nuclear button when context-sensitive information was released to an unattended audience. While I won’t reveal the example to protect the innocent, exposure to sensitive information clearly destroyed trust through teams and leaders. The result: potential sales loss, team members distrust, and leadership perceived as evil. It had been inadvertently misused in a downright embarrassing way. Yikes.

But it’s not all bad. There are good points to Reply All that are helpful and effective. An essential function of Reply All is to broadcast information, not directed to the individual but the group interested in the information. Where there is a call to action, this is acceptable if all recipients are a trusting team.

And job roles that require the use of the tool extensively, connecting disparate groups or gathering more perfect information that is useful for business outcomes. But in my opinion, these moments in time are rare. They are better served elsewhere, such as in physical proximity, a direct instant message, and thoughtfully crafting a smaller target audience for a higher percentage of success.

When I use Reply All

I’ve summarized when I typically use Reply All. While it is a tool I avoid, there is utility.

When the information is vital to a broad audience without commitment to a call to action.
When a call to action is essential to a trusting group of individuals.
When urgency is needed to a critical item that requires escalation in good faith.

When I Avoid Use of Reply All

More importantly, here are my reasons why I do not use Reply All.

Avoid detailed information being released to an unintended audience.
When the information is essential, a call to action is required, but the directed individual is not trusted.
When urgency is needed in an unjustified or repetitive matter.
Removing someone's voice by prematurely adding high-level authority to a fresh unresolved matter.
Replying to a long threaded email to obtain visibility without adding value.

I’ve sent many emails in my career, and now Reply All is one of those tools reserved for exceptional cases. I prefer to defuse, whereas I understand the individual who can help myself, my team, and the project and product. I continue that conversation privately. Once we have closure, it’s fused back into the Reply All as broadcasted information.

While this may seem like common sense, this was a long journey for me to understand. I’ve reflected on my abrasive Reply All exchanges. Whether it’s a company of hundreds of thousands of people or just a startup between two, it’s always a conversation with another person. To me, it’s better to discuss with the individual to build a relationship and obtain results with time privately. And then give them chances to do their craft before the proverbial balloon is popped. The people I work with have come to respect this approach.

And for those in the past who have suffered from my nefarious Reply All dealings, I’ve learned to do better.

Software Development Is Unlike Construction

Doug Arcuri — Tue, 16 May 2023 10:34:09 +0000

A Short on the Reasons Why

TL;DR: Construction is a poor metaphor for software development due to its non-linear nature, difficulty maintaining insight, disagreement in measuring, and its conveyor belt of opinionated approaches. There may be better analogs.

Our family recently completed a straightforward home construction project. We took down walls and extended our kitchen into an open floor concept.

The project process and progress was clear. We initially worked with an architect by drawing up plans. We then worked with a government agency to critique and approve those plans. Finally, we worked with the implementers in three phases-first, demolition and preparation. Second, structural, plumbing, and electrical. Finally, exterior cover and finish. At each point in time, the agency would review and approve the work.

The project made me reflect on my profession. While building construction metaphors are often used to describe the software development process, this is not how it works. Here are the reasons why.

Non-Linear and Mutable in Nature

Construction can be highly linear. It follows a well-defined sequence. There are points in time where diversions are required. Sometimes plan alterations are made when plumbing specifics need adjustment. Structural maladies are discovered. Or when safety realities must be mitigated when dangerous electrical splice boxes are found. With software development, there is no defined sequence and no silver bullet. We tend to run in different directions. We shore this up with the typical "sprint zero" and include numerous inspection points. We shorten the loop of the process and respond to items in that loop.

Software development is a creative endeavor that is non-linear. It is fostered by discovery with no clear middle, beginning or end. Re-work is continuous.

Insights Are Opaque

Construction progress is straightforward and visible throughout. Software development is abstract and invisible. We use demos, tools, and dashboards to make visibility available to our stakeholders and teams. At best, it is opaque and requires extraordinary effort to maintain visibility. The tools lack cross-cutting dissection, rely on imperfect telemetry, and inference in our tooling is nascent. This leads to difficulty in making appropriate decisions at proper times, leading to waste, poor software cohesion, and delayed delivery.

Our mental model of software projects have misconceptions. The reality is that the model is varied from contributor to contributor more than we think.

Disagree on Common Measures

Construction requires building in a way that is acceptably safe and predictable. There would be no way a two-story home could stand if its main structural beam were removed. However, we would be surprised at how software development projects across the finish line with malformed structures. Software development processes, development practices, and principles attempt common ground between engineers, but there is little agreement. A continuous debate has created a void of common measures, therefore, to less predictability and safety.

It is as if on the proverbial blueprints no one can agree to a consistent scale measure.

Individual Personalities Prevail

Construction is physical in nature, with clear constraints. Many past learnings have reinforced agreed approaches. But software development is not a mature industry, and therefore we do not follow a clear approach due to disagreement in measures. There is a high-level diversity in thought and approach based on assumptions. We are all exploring and learning together. There are spheres of influence that represent numerous philosophies. Opinionated decisions are made externally and brought in internally. At best, we have team-scrutineering based on perceived external community validation.

Unlike construction, software development has many voices pushing and pulling the community in different approaches. The question is, who are we listening to and why?

Conclusion

Our home construction project ended on time and within budget. However, this cannot be said for a majority of software projects I worked on. What is clear are the above items. Invisible details, glued together non-linearly by smart, opinionated individuals.

If construction is such a poor analogy to software development, other human endeavors may be more closely relatable. Scribing, music composition, gardening, and philosophical activity may have better analogs. The reasons why require study, and I will leave this up to the reader.

What are other differences between construction and software development not outlined here?

Meta Skills of a Software Engineer

Doug Arcuri — Thu, 27 Apr 2023 10:51:10 +0000

Learning Through Books on Correctness and Pattern Recognition

Recently, a friend asked a question about the particular skills possessed by software engineers.

What are the unique skills that software engineers practice?

Drawing from my experience led me to an opinion. I enjoy the meta of programming. The skill of learning the meta, or how to do what we do better, includes reading many well-known books in context. I took specific examples of what I read over the years, applied it to my observations practicing in the field, and I answered in a way that I believed was most pragmatic.

Me: In my opinion, if we think universally, I would say it is the practice of correctness and pattern recognition. These are some of the skills that are unique to software engineers.

Let's exam these skills to add context.

Correctness

Correctness is very much related to how and why we build things the way we do. In organizations, it is most closely associated with the accuracy of what the business must solve for its customers. Well written software follows this thinking.

Correctness is how correct the "how" is so that the solution for business can continue with high reliability. It is a balance of strategy (designing) and tactics (execution). The examination of the how's how in a vacuum appears well in chapter four of Programming Pearls - Writing Correct Programs.

...keeping code simple is usually the key to correctness.

- Jon Bentley

Pattern Recognition

Pattern recognition strongly ties to the organization of that correctness by creating the necessary abstractions and component boundaries. Pattern recognition leads to concepts of reuse to modularize and isolate code. We monitor duplication, find areas that can be reused, and refactor complicated parts of the system. It is what software engineers do well. Our attention to that detail is vigilant. We recognize knowledge as it is created over and over again. Then we simplify.

Pattern recognition is discussed at length in the community, and there are many sources to read up on their techniques. The origins where I learned about this skill reside in chapter two of The Pragmatic Programmer - The Evils Of Duplication.

Make it easy to reuse. DRY - Don't Repeat Yourself.

- Andrew Hunt & Dave Thomas

A Teachable Moment

Once I gave this response, my friend followed up with another question.

If correctness and pattern recognition are these skills, how do you teach them?

Of course, my answer was simple enough.

Me: Locate these books, set the environment, and work through by showing examples. Set the expectation of learning and practicing these meta skills while delivering value to business. Why? Complexity. This is the best investment of learning the skill of balancing complexity that I know of. It also results in engineers who become more confident over time.

My mentoring focuses on these books and these particular skills. But it made me realize there are few out there that invest heavily in the meta, apart from doing the work without realizing it. The vocabulary of the meta is something I have an interest in. My writings on problem decomposition (correctness) and organization (pattern recognition) in the real world were difficult to see when in the heat of delivery.

At about the same time writing this brief on these skills, I received a book recommendation. A professor at Stanford has been teaching a course on the meta. His study resulted in an edition of his course findings. I was shocked when I found out that he has the same gripe as me. I purchased the book and devoured it from chapter thirteen, A Philosophy Of System Design.

Engineers tend to be very detailed oriented. We love details and are good at managing lots of them; this is essential for being a good engineer. But, great software designers can also step back from the details and think about a system at a higher level.

- John Ousterhout**

Conclusion

In my opinion, correctness and pattern recognition are skills*** that software engineers should strive to understand and do well at. The result is higher quality software. All other unique skills, if there are others to categorize, may very well be based on these. I invite others to share examples of meta-skills they have practiced over time.

Fundamentally, correctness and pattern recognition have tie-ins to outcomes of complexity (also known as cognitive load). There needs to be a way to balance both intelligently so that we mitigate complexity. In essence, this is why these skills are, in my opinion, the distillation of what we do.

* What is interesting about correctness and pattern recognition is they also have a strong association with practices around machine learning.

** If you want to know more about what John is doing, take a look at his video.

*** Engineers should also practice high levels of learning and communication. These concepts aren't unique to software but have strong associations with the sciences.

Technically Considered Writing

Doug Arcuri — Thu, 30 Mar 2023 16:04:36 +0000

Write to document what you're doing now, finding relief from its gripping subject. Set a publishing date as motivation. And where there isn't inspiration, tinker with the process of writing. Undoubtedly the muse will return in what you'll do later.

What you'll write will become fuzzy. Re-read your past writing to remember where you were and laugh with the people you shared it with. Writing transmits a once-lived perspective and style.

Writing on a matter is a loop that spirals in your mind. But not after publishing it. When moving to the next, which will inevitably occur, the previous writing is a compressed artifact for a future reader of your earlier thinking.

Were you clear? Did you write?

Dev reader, you came for write engineering: Here's how:

Higher-res version here. Subscribe below!

Video Gaming Concepts For the Uninitiated

Doug Arcuri — Tue, 28 Feb 2023 11:59:38 +0000

Watching my children play provides exciting observations. Their behaviors are organized into distinct concepts. I'll tinker, associating their manners with unrelated ideas. Then, it came to me. I crave comparable actions while playing video games. In this write, my goal is to label them.

As an uninitiated developer who could not hold a candle to gaming theorists, I believe the following behaviors make gameplay fun. At the same time, the results trigger my children's laughter at loftier decibels while at play. My fascination is this question: Do these behaviors transcend to video game mechanics, delivering higher fidelity?

The List of Uninitiated Attributes

Physical possession of objects - holding on to things is an essential ability. While video games have inventories of collecting possessions, few have allowed players to hold onto the objects in space. Grabbing onto two items is better. How about even more?

Picking up objects and throwing them - while holding things is excellent; picking them up and manipulating them in space is perfect. Why not throw them at something? Better strength means adequate velocity. Start laughing because there is plenty to throw.

Damage and destruction of objects - objects are damaged if enough force is applied. Things can be destroyed too. Of course, laughter increases with the amount of destruction, to a point before it becomes out of hand. Specific items can be destroyed in video games, with lots to explore.

Hiding without others knowing - also known as stealth, this concept has the stimulating effect of protection. Cloaking oneself leads to laughter. Being hidden provides a feeling of opportunity. Games have analyzed this concept over the years, but there is much to explore.

The permanence of objects - objects which remain strewn across an area is an expression of disorder, especially if these objects are revisited later. Going back to what was placed earlier is of interest. Things are rarely accumulated in video games, as resources are reclaimed.

Repeat and retry - nothing gets the kids going, like reprising one of the items above, doing it repeatedly. The same goes for these concepts in video games. A solid rewind/repeat mechanism is yet to be developed, but ideas have been tried.

Full brights and environment - nothing gets the kids laughing if there is play at night, in the snow, or an environmental change. Environmental space is the same as in video games. There are copious amounts of effects. Recently, glowing objects, or full brights, are often used for improved visual style.

The fluidity of movement - my kids climb to inaccessible areas. They jump around and laugh when their perspectives are altered, looking upside down! The same goes for video games; lately, games have opened up into fantastic "acrobatics," "parkour," vertical play, moving fast, and flying upside down. There are mechanics left undiscovered.

Chaos in quantity - increasing the number of objects makes kids go nuts. Think of a ball pit where there are thousands of similar items. So in video games, in a gray box or sandbox, with lots of abilities to spawn them. Chaos mode, where objects are at insane levels, makes for an exciting, time-consuming experience.

Pretend building - nothing gets my kids minds flowing with ideas when they pretend to build. Either sandcastles or pillow forts, it's a lot of laughter with creative imagination in mechanics like substitution and world-building in the small. The same sentiment stirs within video games. Making things virtual is a captivating topic worth investigating its value.

Mutator configurations - kids have a way of inventing the play in which they engage. They make things up, configure their toys in a particular way, or change the environment with unique abilities such as copious amounts of pretend lava. So too, are nice to have with video games. Changing up its composition is a must-have. Unfortunately, games limit their options.

Playing with others with invented rules - is an unmistakable quality explored intensely in video game communities, so playing with others increases the fun factor. By keeping score, kids form play rules in which inspirit the experience and bring out their disagreements!

Is it Fun?

From here on out, adults invent intricate rule sets, ending my list. Those were my observations about video games, my kids, and what I crave while playing. But how do you quantify fun? Having these qualities alone does not equate to joy. A combination of them will provide incentives.

I'm sure I missed other attributes which are a part of gaming elements. Of course, numerous mechanics are well-known within the community. My goal here was to list out these observations. How they connect will be a topic I'll explore as I find other patterns.

Goodbye to Saccharine Feelings of Clean Code

Doug Arcuri — Tue, 31 Jan 2023 12:10:43 +0000

A surprisingly soured reaction has come over me. Lately, feeling giddy about sweeping up code is absent. As time accelerates hyperlinearly within my text editor, the bursts of dopamine are no longer an assertion of knowing. I'm middle-aged without its small pleasures.

I'm giving up on clean code and consistency, coming full circle in a game of sparking joy. If I feel good about mopping up code, I'll remind myself that it's time extinguished, which steals from what needs doing. Whatever I'm working on will be sullied over or thrown out, anyway.

Editor's note: Feel free to share this rant in your next code review.

The Not So Small Things of Developing Software

Doug Arcuri — Thu, 19 Jan 2023 11:51:14 +0000

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.

Find Career Freedom With A Daily Code Workout

Doug Arcuri — Mon, 31 Oct 2022 12:12:26 +0000

There are two main modes of physical exercise, aerobic and anaerobic. Aerobics train the body to maintain output throughout distributed muscles. Its goal is to preserve oxygen levels along a strenuous distance. Anaerobic exercises target muscle groups under resistance repetitions until the muscles cannot perform further. The goal is to improve the energy output of the muscle target by tearing and rebuilding. Both modes have benefits associated with peak performance.

Dealing With Software

Software engineers perform their craft in a similar matter. If one squints, the resemblance of aerobic exercise is to solve problems, such as taking on an unformed concern and unraveling it. However, engineers cannot complete the activity because they need specific "muscles" to command, which lack the strength to achieve the required endurance.

Engineers perform targeted "anaerobic" workouts to improve problem-solving endurance to achieve better aerobic results. But why perform exercises and spend time doing what seems trivial? The answer is simple, freedom to solve problems. As a benefit, career options will expand when we gracefully perform various computer science skills. We choose where to spend time motivated by solving interesting problems.

Targets

The core engineering workout is a process of concentration and effort. It requires about one hour of practice daily. If every day is too rigorous, exercise this workout every other day to let the mind rest. Rotate a reduced set throughout the week. Either way, working to solve known problems builds muscles in the brain, particularly the neocortex. Like code katas, these exercises target building muscle memory.

Temporal - relating to temporary space. Holding items in mind is a skill that practice improves.
Spacial - relating to visualizing how these exercises interrelate with data.
Oral - rubber ducking through the problems challenges better communication. Think: how can I teach this to someone?
Recollection - these workouts target a wide range of muscles, memorizing essential patterns. Repeating them leads to working efficiently within an integrated development environment.
Abstract - Learning something new. Discovering a new workout, we add new computer science fundamentals to expand our knowledge.

The Workout

Like a physical exercise regime, these exercises require a warm-up to get the mind thinking clearly in the space. More profound activities ensue. After a certain amount of rotations, results include solving complex problems in less time. Craving to perform will follow, such as desiring spicy food from our TRPV1 pain receptors.

Warm Up (5 minutes)

Create an array, fill it with random integers, and print it to the screen. Or execute the Fibonacci sequence recursive and iteratively.

Sorts (10 minutes)

Exercise integer sorting in progressive order of difficulty. Bubble, Selection, Insertion, Shell, Merge, Quick, Heap. Finalize with binary search iteratively and recursively. Describe the Big O-notation as well.

Maps / Hashes Or Stacks / Queues (10 Minutes)

Create a naive hash table and basic hashing to avoid collisions. Or build stack/queues with challenges of finding the minimum on a stack, etc.

Trees Or Double Linked List (10 Minutes)

Create a binary search tree by inserting nodes, printing traversals, and deleting a node. As an alternative, create a doubly linked list. Insert, delete, and print in both directions.

Graphs (15 Minutes)

Create and traverse graphs using breath-first and depth-first search, or experiment with the Dijkstra and A* algorithm.

Alternative (15 Minutes)

Solve a question from the cracking the coding interview problem openly. Adding these random questions to the workout will inspire you to think differently and amend the repetitive nature of the previous exercises. If solving canned problems is not attractive, build something variable that utilizes these skill sets.

Conclusion

A disciplined workout is key to a healthy engineer, whether a leader or an individual contributor. The goal is discipline, first to remedy the repetitions by gradually improving the time to solve. Once achieving results, "aerobic" problem-solving exercises will come naturally because conditioned muscles are present to execute well.

There is a certain satisfaction to these exercises. Why not strive to be a well-rounded engineer? If one hour seems lengthy, reduce the set, building toward a new goal. Most importantly, push hard at the end of the exercise to finish well. Add a few more counts at its conclusion to improve the results!

SemVer is Dead. Long Live SemVer!

Doug Arcuri — Tue, 18 Oct 2022 10:59:10 +0000

This post is my opinion on versioning software. After a questioning dive into acknowledging fantastic alternative schemes, it introduces latestVer, my myopic software versioning technique. Please share with your friends!

Often, a swell versioning scheme appears on a link aggregator. I mutter, "yeah, that's great." Then I'll add it to a collection that has become a shrine of excellent thinking. In between, an opinion will come along on approaching versioning. Of the few posts I read, the cargo cult of versioning made me rise off the chair and clap—until the author recanted the phrase I enjoyed.

You could even remove the version altogether and use the commit hash on rare occasions when we need a version identifier.

Sigh, correctness, but is there truth behind the author's words?

What's Versioned Out There?

Fast-forward years from the write-up, SemVer 2.0.0 remains the standard. Things stay as they are—a journey to communicate the intention of a change in a tangle of dependencies. If one is a maintainer, one receives pokes about improvements. If a manager, their game is to reduce risks. If a lead on a passion project, eighty-four versions of the software have elapsed on a Saturday, with one hundred seventy-nine regressions, which no one will find. And if an adopter updates a library, it's typically to the latest, knowing the risks even with a suite of ten-thousand tests.

Since I am a consumer of someone else's work (like everyone else), I'll avoid bumping the library today or bump it slightly through constrained pinning until I must update it to the latest. I don't have much time to decode the version numbers. It's a linear function where risk increases with time. Each bump means a subjectively more perfect implementation enveloped with possible dreadful outcomes.

So with versioning stuff, it depends on the intent of the change. Numbers don't communicate intentions well. Even when Rich Hickey says, "change behavior, rename!" it often fails to decode the message. Regardless, I'll pin versions in the hope no one will force me to update until I don't have the option. I'll throw my hands up, declaring that nothing is complete in the software, even when someone else states it's complete. If finished, the code expires because labor is consistently involved, costing scarce human, social, or monetary capital to keep it running. We are all at the mercy of becoming outdated.

But we, as a community, try to do better. I'll continue to search for a modern version scheme that communicates sounder. So this got me contemplating. What is out there, encoded in its thinking? Let me share my incomplete child list of SemVer, the current defacto versioning standard. I will share brief opinions about them. By the way, I love all of these and tip my hat to these thinkers.

Label	Depiction	Introduced	Where to Use	Reality
SemVer	The "Standard"	2013	At the Job	Here to stay
BreakVer	Clear intentions	2014	Not at the job	Patches can break things
RomVer	Human in the highest	2015	Not at the job	To err is to break some APIs
CSemVer	Limits are good	2015	Not at the job	SQL statements in versions
SimVer	Clear statements	2015	Not at the job	Even closer to reality
MonoVer	Fewer placeholders	2016	Not at the job	The fewer numbers, the better
ComVer	Clear statements too	2016	Not at the job	Confused with simVer
CMSVer	Specific to content	2017	Not at the job	Only if dealing with a CMS!
WendtVer	Tens, tens, tens	2018	Not at the job	Odometer goes on and on
Zer0Ver	Cool, lots of zeros	2018	Not at the job	Defines the incomplete nature of software
PandenticVer	Sigh, no	2018	Not at the job	Politics, I guess
ChronVer	A life on a calendar	2019	Not at the job	What month is it?
CalVer	Make me remember the date	2019	Not at the job	Technology marches on
FibVer	Matches the agile thinking	2019	Not at the job	Too many flashbacks to interviews gone sideways
SentimentalVer	Become a stoic	2020	Not at the job	How I feel about my failed essays
HyVer	Good	2020	Not at the job	Closer to reality
HashVer	Not very clear	2020	Not at the job	A good choice for lots of commits
MakeVer	For the C/C++ crowd	2021	Not at the job	Headers for versioning
GitDateVer	Make me remember the date	2022	Not at the job	Makes me feel old
SemancatVer	Love those cats	?	Not at the job	I'm allergic to cats
SetVer	Set patterns	2022	Not at the job	Wildly satisfying
LatestVer	The reality	2022	At the job	Cool, this one is mine

Introducing LatestVer

For the authors above, while having good intentions, new versioning schemes are at the fringes. I've rarely seen these in the wild, maybe zer0Ver or calVer, smiling when I do. Creating a new versioning system requires creative thinking and invoking a community change which takes exponential marketing. SemVer surrounds my work, and I'll label my libraries the same. But there is something meta that occurs as I interact with the labeling. Something first-ordered.

As an adopter, I do not sweat over minor versions. It's always about the best, the latest, the major, and the now. If I am building something new, I shop for the latest. Since dependencies are a land of extreme abundance, it is unlikely I will pin my hopes on an out-of-date library. So, while I construct in a "shiny thing" matter, perhaps what is happening in my trenches is occurring elsewhere. As a consumer, I choose the latest version while making a new thing. Otherwise, I place myself, the team, and the project in explicit protection until the pinned forcefield depletes, and I must do something. There is rarely an in-between. SemVer is correct thinking, but in this consideration, anything that increments on the far side is what matters to me.

So what is this pattern? Let's call my realistic library versioning scheme latestVer. LatestVer is a simplistic approach to versioning. Choose whatever system—numbers, dates, or hashes. Let's call it a LABEL. Then ensure the adopters follow the latest version. The reality is that consumers will be looking elsewhere anyway, challenged by pull requests of technical superiors, or dealing with well-intended contributors. Whatever happens, the author and adopter must bump up to the latestVer before an ever-present dystopian cybersecurity vulnerability future. Implementers, including myself, will not have time to understand what has changed until getting into the weeds. When I unpack the work, the latest is what matters.

LatestVer is a shortsighted but truthful versioning scheme. As an author, it encourages "accretion" as Rich Hickey said. As an adopter, it is my reality. Understandably I cannot speak for all since there are strict guidelines for implementing dependencies in different environments. But for those in my part of the world where philosophies are unrestricted, it's a general heave-ho, and latestVer's motto captures the mood well.

If I'm not on latestVer, let me get there soon. Otherwise, I'll be forced there as a priority by something out of my control. If unfixed, I'll drop the library for its alternative. And when building anything new, it's always the latest.

Seldom do I have to cherry-pick a specific "in-between" version that will raise a project from a sinking hole. A feeling sets in while I do it, corresponding vaguely to purchasing something expensive but of little value. Feeling regret, I'll bootstrap my way to the latest, finding the courage to drive in the newest version of their shiny thing at the cost of my mental labor. In the end, it feels so good to have something new.

I love latestVer because it's my reality of the working software. Do you experience the same? If so, I wrote its specification to rally around.