DEV Community: Aaron Ransley

The Woes & Reliefs of Technical Recon

Aaron Ransley — Wed, 27 Jul 2022 22:52:00 +0000

Let's talk about "velocity", crunch, and old habits. There is a particular habit that inspires this note, which is a tendency to:

Sprint ahead as work begins. Use time to gather insights. Sometimes prototype solutions unprompted. Amass many questions related to unknown quantities - often referred to as "opens."

I've developed this habit by working in environments where planning, execution, and testing are all delegated to me as a "solo developer."

The term Technical Recon seems to fit best when describing this approach. In the past, this technique has helped me to build trust with non-technical stakeholders. I have also used it to encourage consideration of systems and edge-cases earlier. This has generally enhanced the fidelity of development estimates around effort.

And yet, Technical Recon can cause friction when applied out of habit. Particularly when the stakeholders for a project are technical experts themselves. You run the risk of shifting focus to non-issues which you may not comprehend. It can also be disruptive to production efforts.

Over the years, I've become more hesitant to apply Technical Recon during projects. My reasoning follows:

It can be stressful. The phrase "save the gas for when you need it" seems pertinent. Pushing toward complexity is sometimes necessary, but not always. For example, Technical Recon can be very useful when estimating high risk implementations.
It can derail personal focus and leave known quantities neglected. Over-application of Technical Recon has led to less-than-robust implementations of simpler systems. With attention spread too thin, more complex code becomes a "fan favorite". Known quantities become an afterthought. This is sometimes necessary - when timelines are hyper-aggressive - but it runs contrary to my love of robust software engineering.
It can be disruptive to the greater team. Asking team leads increasingly obscure questions. Proposing esoteric problem solving during focused meetings with teammates. It feels more healthy - both socially and technically - to have a shared set of immediate problems to solve. An insular set of long-term "maybe problems" are less suited to team discussions.

The remedy for these types of issues - strangely enough, as I've found - is to do less and think less. Space can still be reserved for Technical Recon - even as projects are in mid-production - but they can become team efforts. Once complete, the focus can shift back to immediate problems.

Since recognizing the existence of this habit and making a more focused effort to relax into the process of engineering a project, I've discovered a healthier balance in my day-to-day work as a developer.

I highly recommend considering whether or not you are taking part in Technical Recon as a force of habit.

Perhaps you have a tendency towards habitual exploratory research as well? Is it perhaps a survival mechanism that developed as a result of wrestling with hidden complexities in the past? Or, maybe you are just drawn - like a moth to a flame - to the most complex aspects of a development project.

In any case, growing awareness around habits like these can be a wonderful way to unburden yourself and increase mental bandwidth.

the journey to accessible websites — coming soon

Aaron Ransley — Thu, 10 Mar 2022 05:02:37 +0000

Discussion: Physics Sandboxes vs. Deterministic Event Timelines

Aaron Ransley — Wed, 09 Mar 2022 00:02:12 +0000

I wanted to ask a question I've always wondered about to the larger crowd of gamedevs out there:

Why is there often a disconnect between the movement / locomotion systems that a player interacts with, and the ones used in cutscenes or other in-game events?

This is a super open-ended and broad question, so I'll give some examples:

As a player in a game with a 3rd person action RPG style camera system, I run to a ledge and press the jump button.

My character is propelled upwards and then falls to the ground below.
The speed at which I feel rise to the apex of my jump and the speed at which I fall to the ground are consistent with jumps I've made in other areas of the game.
Everything feels grounded and consistent.
Nice!

As a player in a game with a 3rd person action RPG style camera, an in-game event begins.

An NPC spawns on a ledge above me and moves towards the edge. 1. They jump off the ledge, but rather than rising to the apex of their jump and falling to the ground at a consistent speed, they seem to travel more quickly or more slowly than I would as a player.
The NPC appears stiff, glued to a precalculated path, their animations playing out at whatever speed will guarantee they travel from Point A to Point B in exactly 1.2 seconds.
Do the physics calculations in this world not apply to them as they do to me?
I feel pulled out of the world and hyper aware of the "gaminess" of what is happening on screen.
Bleh.

As a player, I'm zooming around the world of Destiny 2.

I'm on my sparrow, a space-magic imbued mount that has S+ tier game-feel baked in every way.
My field of view changes as I speed up.
I turn and opt to engage the "cornering" button which modifies the sparrow's friction in the environment.
I snap around a corner and press another button to hop off my sparrow.
The momentum of my action launches the sparrow into a nearby wall, and then it falls down a chasm.
I'm so immersed! So present in the game world!
Nice!

As a player, a new "Public Event" starts in the shared game world of Destiny 2.

A "move the payload" prop appears and I hop onto the object.
It's velocity immediately changes from 0 to 100 [insert units] per second.
Ooof, that was a bit jarring.
My field of view does not change while on the payload, despite the speed change.
The payload comes up on a corner and rounds it. It does so with absolute precision, a clean 90-degree arc.
There is no banking of the payload; it does not "lean into" the turn.
An obstacle ahead blocks the path, and the payload stops suddenly. The velocity changes from 100 [insert units] per second to 0.
There is no momentum or sense of physicality to its movements.
I'm pulled from the game world and note the disparity between my actions and those of the props in the world.
Yuck.

Hopefully these examples are illustrative enough to paint the picture I'm trying to communicate. With my understanding of game development systems, I imagine a lot of these disparities are due to developers needing to ensure the determinism of these systems that interact directly with the player.

The Jumping NPC

The NPC needs to spend only X number of seconds in the air, so their act of jumping off a ledge isn't calculated via the physics constants in the world but is instead calculated in a way where gameplay programmers can ensure Actor A can reliably navigate from Transform B to Transform C without unforeseen physics sandbox issues.

The Stiff Payload

Along with the needs of the above w/r/t avoid physics sandbox issues, the payload needs to arrive at each checkpoint in a fixed amount of time. It is simpler to attach the payload to a path and have it advance at a fixed speed, ensuring it arrives at the appropriate time and triggers the next set of event behaviors. The payload does not slow down if it hits a player or a physics prop; it triggers collision on other objects but is not influenced by collision itself.

This all seems to suggest that determinism is the motivating factor here.

In all honesty, my question is almost entirely answered by now, just by typing this all out, but I'd still like to pose it to anyone who may want to weigh in with anecdotes or wisdom:

Why are some systems of a game setup to A) live "in the world", with full collision and kinematics, whereas others seem to be B) built almost like "event timelines" that play out in a predetermined way?

My gut tells me: cost and scope.

While the game-feel and satisfaction of interacting with systems of type A) is unparalleled (think Rockstar's Red Dead Redemption 2, or Arkane sandboxes like Dishonored / Prey), it creates an enormous soup of variables and testing edge cases. Type B) is simply cheaper to implement, more predictable and more easily reasoned about during development and QA cycles.

Jeez, anyways, this is a huge post now so I'm going to sign off on it for now.

Very much looking forward to hearing from folks who have come across these decisions themselves in their games (2D, 3D, VR, I imagine these decisions aren't unique to genre or technologies) and hope to learn more about how y'all make the choice between interactivity + emergent gameplay vs. predictability + guided experiences.

Request for Opinion: Modal UI Archetypes & Naming

Aaron Ransley — Wed, 02 Feb 2022 19:44:42 +0000

i am developing a modal system in my application, and i want to define a taxonomy for different archetypes of modals.

so far I have:

utility modals: those which are invoked only briefly, are generally smol + direct, and aren't addressable via URL
detail modals: those which are invoked to support a deeper workflow (e.g. editing a record, display medium-length content) and are presented as 50vw flyouts. may or may not be addressable via URL

the thing I want to come up with a name for is: "detail modals that can be invoked from more than one context and may have differing URLs based on the invoking context"

e.g.

detail modal supporting OperationA on RecordB, launched from ContextA

vs.

detail modal supporting OperationA on RecordB, launched from ContextB

i'm specifically looking for a succinct "name" for these types of Context Aware Detail Modals (this being my current "best name")

would love to hear your thoughts on if there's something more clear to describe this behavior

Finding a Sense of Impact in Web Development

Aaron Ransley — Thu, 19 Aug 2021 02:02:42 +0000

How does one align themselves with projects that speak to their core beliefs? Is it naïve to think this kind of balance exists, or that it is achievable while working for someone other than oneself?

Whew. This is a tough one for me.

For some context, I work at an advertising agency that specializes in high-visibility, "boutique" digital experiences. That is to say, high-budget websites. I am a Senior Developer focused on frontend development, working alongside ~8 other developers with varying specializations and backgrounds.

But back to the topic at hand: how do I find a sense of positive impact? Positive impact on the agency I work for; positive impact on the clientele for a given project; positive impact even on the world?

I occasionally have the privilege of working on a project with noble aspirations; a desire to address the injustices of the world. This is rare. Most often, I feel at-odds with the values that many clients bring to the table, and in turn I feel at-odds with contributing to their success.

From private equity firms run by old-money millionaires, to exorbitantly priced hotels, retreats or resorts, there is a distinct impression that these companies and organizations do not exist to better our planet or society, but instead exist chiefly to turn a profit from those with disposable income to spare.

To further complicate things, these projects stand in stark contrast with the immense joy and fulfillment I feel when helping fellow team members. Whether it is through building a new technology or tool that improves their day-to-day life; through teaching and mentoring; or by advocating for a teammate, this kind of work is at the core of what I feel to be impactful.

When the cards fall in such a way that my chief responsibility for given project is not "build the site so the client is happy, don't think too much about the company behind the curtain", I come alive with a sense of pride and belief that my work is creating the impact this company value speaks to. In other contexts, this is not so much the case.

But it is still such a mystery to me... These questions have been keeping me up at night lately.

And so I'm writing this to see if there are others out there who feel the same way; who have the same questions or perhaps have walked this path before. What are your solutions, your technologies, your mindsets? I would love to know how you find a sense of impact in the vast landscape of web development.

Please leave a comment if you have thoughts you would like to share. You can also find me on Twitter as @aaronransley, or shoot me an email.

Impactfully,
Aaron

What Is It Like to Write Code For a Living?

Aaron Ransley — Thu, 17 Sep 2020 05:02:00 +0000

Having been employed as a programmer for ~14 years, the following is a stream-of-conciousness breakdown of my experiences. Buckle in for some random tidbits and read on!

Ensuring Specifications

While they can be very brief, I always strive to have at least some kind of specification from the stakeholder or client to work towards. The rule of thumb is "as long as it offers some form of a finish line, it's good enough". I can always eek by with less-than-ideal levels of detail.

Often, work is broken down into milestones where I'll round up with a stakeholder and verify my work so far against their desired goal(s).

Here, things can pivot or change in direction, and the most important aspect of these kinds of meetings is capturing any new direction. Remaining flexible & understanding shifting goals can sometimes be tough, but it pays off to not get too attached to any early development efforts.

Tracking the Work

I'm always using an issue tracker like JIRA, Redmine, Trello, etc. In rare cases work will be tracked exclusively through Slack or a series of phone calls, but even in these cases it can be helpful to use a personal task tracking solution to keep things organized.

Ensuring that change requests are tracked in these systems is critical as well. It's helpful when another dev needs to come in and take over work & understand how specifications changed over time, but also for stakeholders to understand the impact of changes on budget, delivery timelines, and so on.

Doing the Work

Making sure I have uninterrupted hours for just getting things done is essential.

A typical cycle I might find myself repeating for any project is:

Planning; sketches in a notebook or online flow-charting system
Writing the code (notice how everything else is in support of this humble list item?)
Debugging using proper tools. This is huge and in my later years of development I've come to recognize how proper debugging tools can save you immense amounts of time. Use breakpoints, work smarter not harder, etc.
Googling problems or error messages not covered in documentation.

Speaking of problem solving and Googling...

Googling Things

One of the most common gate-keeping strategies in tech is to insinuate that "real devs don't need to Google stuff every five minutes" — this is false and ridiculous.

We only have so much mental bandwidth, and focusing on the abstract problem at hand should comes, while implementation details come second.

I spend an enormous amount of time reading documentation for language features, individual open-source packages, paid vendor libraries, API specifications, and so on. I Google for error messages and strange behaviors I'm not expecting. This is clutch.

Without many hours of writing the same kinds of code over and over again, there will always be a need to reference documentation and external knowledge.

Testing, Implementation, DevOps

I'll regularly push code I've work on to remote environments for staging and verification. I manage code and supporting assets in source control (e.g Git, Perforce) for a project; checkouts, merges, commits, and the like.

Occasionally, there might be responsibilities for setting up hosting environments for web frontend/web backend services, configuring databases, or working within various services specific to domains, DNS, and so on.

Verifying functionality once code or product is running on a remote environment is important. The goal here is to primarily avoid a "Well, it works on my PC!" mentality. I think it's key to take ownership and ensure things are working in a context outside of local development.

Research, research, research!

Much of my time is spent Googling and just hanging out online. While it's a part of pretty much any career in tech these days, it's not always about solving direct problems on Stack Overflow or a in a technical Slack group.

I'll spend time reading postmortems from large industry projects, articles about new technologies or techniques, as well as more broad concepts like systems architecture and how each "brick" of a large programming project can come together to form the grand masonry of the finished superstructure.

Experimentation

Spinning up personal projects to explore a new technology or technique is something I find myself doing often. It has the potential to really put some wind in my sails during a lull at work, or when the project(s) I'm working on are very rote; I like new things!

It's easy to feel like there's just too much to do, and not enough time. Keep an eye on self care and don't burn out!

Pros & Cons

Likes

Creative opportunities. There are many ways to solve a single issue, and finding the optimal route to a solution is engaging and rewarding.
Programming is powerful. There is so much that can be automated or enabled by coding. The applications for these skills are really broad, and expertise can travel across all kinds of industries.
In the mix. Unlike some disciplines that come either before or after a project's production phase, development often occurs in the heart of the pipeline. This makes for lots of collaborative opportunities, chances to right wrongs, push functionality towards it's best possible incarnation, and so forth.

Dislikes

Chiefly technical. Despite there being creative opportunities for implementation, development exists in a realm where the "correct" outcome can be expressed with cold, hard logic. This leaves less room for creative expression, which can be draining over time.
Rote. Once you're comfortable with a given problem domain, writing code can become little more than wiring together known quantities. Access API X, verify outcome Y, output result Z, and so forth.
Toxic gatekeepers. While this kind of thing can be found it almost any industry or career path, I feel pretty strongly that the expertise and esoteric knowledge gained during a programming career pushes people towards these tendencies.
- More times than I can count, I have encountered folks who are more interested in being the keeper of knowledge than a purveyor of solutions or collaboration.
- Avoiding this can be difficult, and I often want to escape to a more subjective discipline when faced with team members or clients like this.

In Closing

While I love the pragmatic approaches necessary to be successful in development, I long increasingly for work that allows for more subjective expression and offers more opportunity for emotional storytelling. These days, the realities of programming full-time have inspired me to begin thinking about a shift in focus. Perhaps away from technical expertise and more towards technical writing, documentation, or educational materials.

In any case, I am sure my development experience will enhance whatever I find myself doing next. It's a wonderful set of skills to have cultivated over the years.

Please reach out if you have any questions about your own journey in programming or beyond. You can find me on Twitter as @aaronransley, or shoot me an email!

Comfort in Collaboration

Aaron Ransley — Mon, 11 Nov 2019 23:57:37 +0000

The teams where I am happiest are the ones that employ regular, thoughtful pauses. After a moment, an astute project manager might ask what a quiet member of the team thinks. They answer with the insight the discussion needed, and the ball rolls on.

These are teams where hypotheticals are encouraged, and people can think aloud without worry of being "in the weeds."

Cost, complexity, and scheduling are shared pillars that everyone should have the ability to question. In doing so, understanding between team members is reinforced, and the project's deliverable is likely made stronger as well.

The Antithesis

Nothing is more contrary to a well-oiled project team than ego. To be in a room—or on a call—where you feel only the loudest and biggest are heard is the death of honest, open collaboration.

In my experience, many managers (project or general) do not feel comfortable with the uncertainty necessary to facilitate open, non-judgemental meeting spaces. To realize bulleted points in an agenda cannot be developed for each moment of a conversation truly is a tough pill for many to swallow. The result is project teams (and entire companies) assembled largely from people who are forced to over-promise, under-question, and scramble to deliver.

Ask yourself:
Do you wonder if you will be unfairly judged when asking a question on your team, or any of the teams you're a part of? If so, your energy is being dangerously rationed. The actual problem your team is there to solve has become secondary to appearances and politics. Not to mention this sort of thing suggests deep toxicity in the workplace.

Teams that are filled with members who don't ask the questions they deeply want to are tragic. If these patterns go on long enough, team members who were once curious can lose sight of the questions that mattered to them in the first place. They go "heads down", and promise to "circle back" at a later date. Fear like this has no place in the workplace, and no one should be made to feel so small.

Be Golden

If you're a part of a team that suffers from these dark patterns, consider these strategies. Even if you aren't in a position of leadership, there is almost certainly a way you can help steer things in a more positive direction:

Adopt a position of renewed curiosity. With the purest intention you can muster, try asking some hypothetical questions during the least tumultuous moments of a meeting.
Gently ask the quietest person in a meeting what they think.
Eschew titles and seniority in favor of curiosity. Ask the newest member of a team what they think about a longstanding issue.
Send out an email with meeting notes, asking for feedback on topics that may have been hurried over.
Be liberal with your @mentions in Slack or other chat tools. Encourage conversation and set an example of inclusion.

And of course, if all else fails, or if you're simply ready to move on: search for a healthier place to work. No one deserves to be unhappy, especially when the grass is truly greener.

Remember that it's never too late to take a step towards joining the hundreds of thousands of people (citation needed) who recognize that kindness and curiosity are the fuel for greatness.

❤

Blogging despite fear of Twitter Cool Guys using 1) lists and 2) GIFs

Aaron Ransley — Tue, 16 Jul 2019 20:02:47 +0000

I wish it was easier to come up with something to write about! I have a blog over at aaronransley.com/blog that I'm trying to get off the ground, but it's tough to find topics to write about.

My process typically goes something like this:

I want to write, and share with the world!
Oh, I'll write about XYZ from work!
Wait, I can't really share that because it's Company Secrets.
Maybe I'll write about this cool tech I used!
Ok, now to just make it abstract enough that it isn't Company Secrets.
Hmm, this is really watered down.
These 19 other blog posts do a much better job of explaining this concept.
I shouldn't waste anyone's time. 😢

Next, I'll pivot to something more pet-project in nature:

I want to write, and share with the world!
Oh, I'll write about XYZ personal site!
Wait, this project is so simple that it doesn't warrant a blog post.
I should work on more important side projects, things with value!
Wow, that would take a lot of time. I spend so much time at work on Company Secrets.
Am I wasting my life working on things I can't share?
Oh look, 14 new tools from prolific makers on Twitter!
I'm not smart enough to fit in. 😢

Ok, one last try. Maybe I'll write about this very thing! Everyone has feelings, right?

I want to write about how I want to write but can't quite get there!
Ok, here are some Real Thoughts in lists. This is good, I am being honest.
Wait, this honesty stuff isn't as easy as the LiveJournal days.
If everyone sees this, will they think I'm a 0.1x Beta Professional?
What if I keep adding items to this list, to make it—like—a thing?
Hmm, this is kind of working. I'm almost to 8 items.
What if I just pressed Publish and didn't worry about it?
Then I'd have done it! I'll have written and shared! 😊

Am I really going to do this? Why is it so scary?!

Let me just preview things here... Is my Markdown formatting working OK?

What about the Hot Takes from The Internet?!

Whatever, here we go.