401matthall

Why am I struggling?

2024-02-12T00:00:00Z

I've been really struggling to get into the right head space to complete a ticket at work. It's not a terribly complicated ask. It's just an export of a flat-file with very clear specs for 5 record types. It'll need to be connected to the front-end GUI so a user can trigger the export and select what records should populate the flat-file. I have been struggling for days to get into some kind of groove with this thing. What is it about starting that is so damn difficult?

It finally hit me this evening. Like standing on a dark stage when the single follow light illuminates and it's pointed right at your face.

!!ZAP!!

Oh... I can't iterate on this.

Why can't I iterate on this?

I don't have a single meaningful test for this code.

I don't even have a completed front-end to back-end loop that I could test manually.

If I can't verify my progress how can I move onto the next piece, method, module, etc. with any confidence that all my previous work... Works? I know better than this. There's not a chance that I'm going to build the needed test scaffolding around this service and it's related views. Not on my timeline and not with this application. Our application is written in such a way that makes meaningful testing extremely costly to do and maintain. So, for the most part, we don't do it. I'll wait a few minutes for those of you who've started to convulse or swear violently to work through that. It's a choice and we pay it's costs every day. At any rate, I am in a position to short-cycle the remaining smaller methods that'll do the majority of the work in this service. Then I can wire up this backend service to the GUI and start seeing a file be generated. Then I can finally start to validate the work I've done thus far.

This probably would've been something I noticed much sooner if test-driven-development was how my current company worked. I probably would've noticed this much sooner if my primary paradigm for working was test-driven-development. My current company doesn't do this and the upfront cost to change the pattern is more than is willing to be paid. I am very much putting this reminder on my whiteboard, though.

Testing, in any form, is the crux of developing confidence in your work. The structure and focus that test-driven-development brings to your team and your code is extremely valuable. If it's not available to you all hope is not lost. You can write tests after the fact, with known costs and skew because the test did not define the initial work. You can test manually in most cases. It's tedious and we're fallible but having confidence around the work you ship is worth it.

Game Design as it applies to Application Design

2024-02-11T00:00:00Z

I play a lot of computer games. I'm not a 'mainstream' gamer but I play a lot of computer games. I have literally spent thousands of hours playing games. Particularly the ones that are made up of simple, clear systems that allow for emergent gameplay. I love the systems in simulations. I love tinkering and modding those games to push the systems to their limits. I love watching systems interact with each other. Sometimes I think of it as a digital ant farm.

At some point the, obvious-in-hindsight, idea occurs to me that game design and application design borrow from each other heavily. There's probably a heap of value to be gained by understanding game design. Like many software developers and engineers I know, I got into software to create things. Simulated systems and games were definitely on that list. I simply never studied game design before. To that point, I've barely scratched the surface of studying application design.

I've decided to really live in the space of life-long learning. This week I picked up a copy of Designing Games: A Guide to Engineering Experiences by Tynan Sylvester. If you've never heard of Tynan Sylvester that's alright. The internet is a big place. He's the author of a game called RimWorld which is rife with the simple systems that lead to emergent gameplay I mentioned earlier. I've held off on getting this book for years, honestly. I kept thinking it was going to be a how-to guide to game engines or something along those lines and that's not what I'm looking for. I'm much more interested in the philosophy of design. Turns out philosophy and psychology of game design is exactly what Tynan has written. I've only just skimmed chapters at this point but I'm so excited to dig into this material and continue to refine my understanding of humans, their needs, and how to serve them better as a software engineer and developer.

I don't like writing code...

2024-02-10T00:00:00Z

I've been struggling with this thought for a long time. I've been convinced that I don't like writing code. Perhaps, I'm not meant to write code. Other people seem to be so much more prolific at it. They generate reams of code and move through their work at a good clip. Observationally, I'm the 'problem', right?

Maybe. Maybe. However, upon some recent reflection I don't think I am. I'm not sure there is a problem.

I finally decided I don't like writing code like other people I know. In my previous post I noted that I find I often think obliquely compared to my coworkers. This has a direct impact on how I think about my code. I wrestle with my code, I struggle to surface clarity as much as possible in my code. If this sounds like an attempt at a brag it's not even remotely that. It's my thought process while I'm working.

When I write code I try to do a number of things: solve the stated problem (usually from a trouble ticket), make my changes simple to understand for someone else, and make my changes simple to change in the future. I actually consider the last two items far more important than the first. This is because I work on legacy projects. Projects that have been around for 10 years or more. Projects with geological layers of code. If you've worked in a project like this before you already know what I'm talking about. If you haven't worked in a project like this don't worry you will and it's a Learning Experience.

Legacy projects, in my experience, are all about maintenance. Code that's been fine and untouched for six years is, without warning, now failing in the most absurd way and it's not obvious why. It turns out what should've have been an unrelated change in another service affected the outcome of a calculation in the six year old code because they were coupled in an obscure way. After hours of work you find it, untangle it, and decouple those two pieces of code. Why were they coupled in the first place? Expediency, inexperience, inattention? All valid, it happens. It is nearly impossible to anticipate how code will be used in the future. I'm not working to future-proof my code, I'm working to make it simple to see how my code works and make it simple to change. The idea that Change is the only constant in software is becoming my personal mantra.

Maybe I do like writing code. I love building rules that define how a thing works and then codifying those rules into whatever language I'm working in. I love when my codified rules are simple, as simple I can make them. I love when for just a few minutes there's a moment of clarity in my mind and the code on my screen captures that. I love when I come back to code I've written years prior and it's still clear what it does and how I can change it, not because I remember the code but because it's as simple as I could make it at the time.

I love writing code.

It's the cognition, stupid.

2023-01-30T00:00:00Z

I encounter many wonderful, helpful people in my day-to-day. They love to share productivity tips and I'm always happy to hear them. I think on occasion people are offended to find out I haven't implemented any of their ideas or suggestions. My peers seem to be confused when I haven't adopted the latest shortcut, key-combo heavy IDE or Vim or Emacs (I'm absolutely not having an Emacs v Vim conversation). I'm always fascinated by how much focus is placed on physical action.

So many people try to help under the impression that my primary struggle is the speed at which I can get information from my brain to my finger tips/code editor. In my case, the limitation isn't the speed at which I can type syntax. In fact, often times taking the time to type all of the syntax including the boilerplate helps me to focus my thoughts. It's taken me a long time to start to understand how differently I think compared to my peers. I'm not slow-witted, I don't think slow. I do organize my thoughts slower than most people. This isn't slow thinking, however. This isn't a lack of articulation or practice in communication. It's a deliberate exhaustive effort to organize my thoughts before I communicate them to avoid confusion for myself and for my audience, even if that audience is only my code editor. Incomplete thoughts aren't thoughts at all for me. They're fragments I don't know what to do with and the effort of hanging on to an unintegrated thought is cognitively expensive. This process is, in fact, work for me. The compulsion to integrate the thought into my existing framework is overwhelming.

I'm not failing to type syntax because I don't understand the concept. Rather, I haven't attached all the floating pieces of data to an existing node yet and I'm trying not to lose them. Once everything is connected to an existing point of information I can proceed with the next step which is usually speaking or typing. While I often appreciate the attempts to be helpful the help often fails to address the point of conflict or 'slowness', my brain, not my code editor.

Thinking is a from-scratch exercise most of the time, at least it is for me. In order to ponder a thing I have to build up a framework either from my memory or my immediate environment (what I can read, hear someone saying, etc) this construction of a framework often takes time and effort on my part and it may appear as though I'm not engaged in the immediate goings on (to some degree, I'm not) but without taking the time to do this I simply can't participate in a conversation, meeting, pairing-session, etc.

What does it mean for how I work and how I'll work in the future? It means I probably won't try to learn new physical patterns to speed up my work. I find the majority of my work is cognitive. Additionally, I'm not certain working faster is to my benefit and probably not to the benefit of whatever I'm working on.

Does this mean that shortcuts and key-combos are bad? Of course, that's what it means. Shortcut and key-combo users are bad people, they don't give their pets the love and attention they need, and they chew gum while talking in a conference call.

First!

2023-01-28T00:00:00Z

First posts are the worst. They're the worst to write. They're the worst to read. They're usually brimming with enthusiasm for the New Year because when else does someone start a blog or write a second First Post. Ugh.

I'm not going to do that to you. I'm not going to do that to me. I want to give informal writing, with an attempt at doing so regularly, a try. I want somewhere to put my thoughts and opinions on things. I want somewhere to exercise my thoughts. That's really what I find writing useful for. Testing, challenging, clarifying my thoughts.

Annnndd we nearly wandered back into the pretentious part of First Posts. That was close. When did we stop adding two spaces after closing punctuation in a sentence? I miss that other space.