Author: Jonah McConnell

As the title suggests, what you see above is most certainly a skill tree! Look at it in all its... uh... tree-y glory? Ok ok you got me, it's not much of a tree. It's awkward and uncomfortable to look at— I mean interact with. But honestly, it's ok because what you see there is only part of the overall picture. It may not look like a tree, but it's more like a seed. It is used to create the tree needed for the end result. For all its strange visual features and odd patterns, it might really become a more tree-like form in the end.

... Okay, yeah, I'll admit nothing in here looks like a tree either (not to mention the data is an entirely different class), so what do things have to do with one another? Both are part of an ongoing issue I seek to improve in my work. I'm not My end product is not approachable to those around me. When my work is intimidating enough that other programmers aren't even sure what exactly is going on, I've utterly failed in my communications. If I cannot get programmers to understand what I've created, how can I ever hope for artists, designers, or any other discipline to be able to use what I make in any way? In the case of the skill tree, while I poke fun at it, I don't have much plans to change how it is for the scope of this project, however, it does help to highlight a greater point.

If I were to make a skill tree system for designers, the columns and rows of data seen in the first image of this post would never fly. Hell, I'd probably be chased out of the room if I suggested using it with a straight face. And this is entirely fair. Lack of tooltips or other small hints aside, using something like that without large amounts of knowledge of its inner workings is daunting, if not downright impossible. As the one creating these systems and their accompanying tools, it's my job to make them not only get the job done but also ease the load of my teammates. While I may add small things to help with this, such as hiding irrelevant data when certain criteria change, or trying to use very transparent naming, I don't feel that's enough to make things easy for those around me; at least they don't work all on their own. The ideal solution would be to create some sort of visual graph system, ideally by piggybacking on the blackboard, or blueprint editors in some way to avoid authoring too many new systems myself. While retooling existing tools can be a time saver, it also means I must better familiarize myself with said underlying tools I've been using. In this way, my experience is greatly lacking, though that is something I hope to continue to address over the coming months.

Next comes my second example, which at first may seem counterintuitive. "After all", I can hear you say "It's Visual Studio, it just needs to be readable to the other programmers". You'd be dead on if that is indeed what you're thinking, however this code, despite my pride and my best efforts, is not all that friendly to guests. My eyes were reopened to this sort of thing while working with the group to begin reorganizing the code base. While at the beginning of the project, we had a rough idea of where we wanted to place certain things, this loose planning of course quickly broke down over the hours of working. Many folders at the root of the source directory housed only a single feature's worth of modules, while others held far too many. This led us to agree to move many of our files to better organize things for the future when we completed our build tonight. In this process, my editor lit up like a Christmas tree. Now very few of these were errors stemming beyond a simple fixing of a include directory. The rest however was my Linter, Resharper, having an absolute field day. What we expected to be a relatively short, half-hour clean-up quickly turned into three full hours of skimming and cleaning almost every module in the whole code base. Now while my changes were almost exclusively limited to adhering to naming conventions, fixing spacing, or const correctness, it still helped to remind me of the perspective of looking at unfamiliar code.

I often forget in group projects what it is to not, in some form, author a module of code. The biggest perk of being the one usually roped in to help with an issue another developer is facing is that you become intimately familiar with large swaths of the project at a time. I usually try to use this to the benefit of the group by developing a better understanding of the project at a more macro level. This often helps me feel more confident in decisions about architecting one feature or another. However, this has in a way numbed me to what it is to look at code with totally fresh eyes. I believe this is reflected in my code, in which I have left far fewer comments explaining its inner workings than I should. While I leave comments where I believe something may need to be looked at further, or try to use self-commenting naming, I still feel like a developer with no context would not be able to easily approach my code. Grouping and organizing code in intelligible ways can only go so far for a new person's experience. In the future, even if not commenting on the workings of individual parts of functions, I believe I could do better to at the very least provide a synopsis of the purpose of functions, classes, and structs, rather than just leaving someone to try to untangle the smattering of modules I have created.