Ember's Ethos Zone

I like to do things a certain way, and I hope this gives you a bit of insight into how and why I create things.

Helping Ethos

I like to help people :3

I've spent over 3 years on Discord channels providing help for Godot, GB Studio, Blender, and Source SDK.

Writing Ethos

Are you writing something for other people to understand? Then you should be writing something that's easy to understand. Even for a complicated topic. Even if the circumstances make the action difficult or frustrating. These are exactly the best places for writers to bust out the Simple English guides and write like a good programmer comments things.

It is on all technical writers to write things that are explicit, and clear, but not complicated. No task has to feel complicated if it can be broken down into more-manageable steps. Segmenting several into different sections helps align with the way humans benefit from breaks. Performing the actions can be difficult, and balancing your attention span between a guide and a task is the real challenge. In my mind, this is where tutors, peers and other aids can help make sure you are doing the task you're interesting in doing. If I won't be able to remember what something I'd written in 10 years was supposed to mean, I don't consider it well-written enough.

I think the biggest hurdle in good writing is length. Anyone can write a short sentence. Some people can write incredibly long-winded guides (myself included) but few people can get across the right amount of necessary information without diverging into something that confuses or dawdles. It's important to be explicit, but I think we have lots of great means for dealing with long pieces of information. Footnotes are great. Breaking up a paragraph so each "first sentence" starts with something critical makes instructions nicely readable for skimmers and second-time readers.

It's all a form of communication which is central to what I enjoy doing. I love communicating through graphic design, games, music, conversation, and writing is no different. I truly care about being understood and creating something meaningful with what I say, so I take great care to make sure I write it well, too.

From writing a lot of documentation, I've also read a lot of documentation. There are a lot of words I'd love to never see in any piece of technical writing ever again, especially in any set of instructions. They are:

I think these are unhelpful and suggest that the task at hand should be easy for those that are able and experienced. I feel that this happens a lot when experts are writing guides on tasks they consider simple. Even when the task is commonly-thought as simple (say, using Windows Calculator) you never know who is going to be reading a guide, and what experience they will have leading up to this point. The reader could be a 60-year-old who is learning to do more complicated math for the first time. The reader could be a 20-year-old with learning barriers. The reader could be a 7 year old who can read but has little experience to go off of. I think marketing claims should stay apart from technical instructions.

I never want to trust press conferences that describe specifications of phones as being "easily adaptable" and "dynamically driven to smartly deliver content to consumers" because these types of sparkly sentences contain no actual information about what the technology does.

Anyways, some of these words I think could be replaced. Here are some suggestions for ways to improve your use of these words I've previously mentioned. These replacement words are:

Coding Ethos

Yeah coding!

I am incredibly confident with Godot Engine's GDScript (a python-like language).

  1. Have explicitly-named variables, don't rely on 1 or 2 letter standards
  2. Unless it's "i" because I just love the little glyph, it'll always have a place in my heart. I can't stand to not call my for iterator "i" it's just so CUTE
  3. Comment what something does and why it is here
  4. If the majority of an "else" statement is 500 lines, use "if x then return" instead

I'm still not great at committing just one thing at a time though

Creation Ethos

My goal with any of my personal projects are not to profit off of them, but rather to express myself in a unique way. I love to find and create workflows that are fulfilling and rewarding. I also love to share the ways I do work in hopes of showing others how they can achieve something fulfilling as well.

I use these projects as a way of building my skillset, but I also aim to create something extraordinary, whether by my own hands or alongside a team of friendly people.