Burnout No More Woo And Progress Snapshot

It feels SO GOOD to finally feel the magic of all things development wise, inside and outside of work.

Getting here kind of meant letting go of all the self-inflicted pressure to document every little thing in this journal (useful, but draining), and also the pressure to be able to just get better as quickly as possible.

It also meant letting go of the self-inflicted pressure o get better mental-health wise as quickly as possible, and to just slow down in all areas.

Despite having nearly five months going easy on all of that, I've learned so much and made way more progress than I would have otherwise.

I finally feel confident test-driving programs and thinking more in terms of objects instead of procedural logic, which has been a goal of mine throughout this entire journey. A was right when he said that even if you don't get something now, eventually dominoes will start clicking into place and all the things that didn't seem to make sense enough to stick will start appearing as the new web of knowledge starts coming together. Kind of like a house that's in constant dissarray with stuff everywhere, only for everything to suddenly float into their proper places. A backwards memory castle.

I'm most proud of a small studio game project I built in Ruby, using the concepts I learned in the fantabulous Pragmatic Studio Ruby course.

The repository for it is here: https://gitlab.com/EssentialistDev/studio-game, or you can download the gem directly: gem install studio_game_2021-1.0.0.gem

Building this game was the first time I felt like I could test-drive and build things with lots of simple interacting objects, refactor to make things even better, and publish it as a well-documented Gem. All of those things make me extremely happy.

Things I feel better at (or learned)

• Tests are really empowering. I made lots of silly mistakes, or broke things because I didn't anticipate the consequences of a refactoring or new feature. The tests caught all of these things immediately. The benefit of this beyond debugging is that it's made me much more mindful in my approach.
• An "aha" moment happened when I was struggling to figure out how to test that the game had been played for a specific number of rounds. I realised that I was trying to test the block (loop), instead of what actually changed as a result of running the loop (player health). I can test the things that happen inside the loop block, or the before and after state of something that is influenced by it. Testing the block is like testing that Ruby itself works.
• I really loved learning about adding example code at the bottom of class/module files to demonstrate how they worked, but wrapping them in an if __FILE__==$0 block which means that the examples only run when you run the specific file they're in directly, not via a different file that requires it.
• Similary, it was cool to find out that adding $stdout = StringIO.new inside of a before block in the RSpec test files suppresses any puts code, so that it doesn't get printed to the console when running tests (interrupting the nice row of green lights). A says that it's bad practice to have to suppress puts in the tests anyway, because puts should be something that a front-end specific thing does. The main code itself should just return the info, and something else can display it in whatever format it wants. It's helpful to use when building toy projects to learn Ruby better though (in my opinion).
• There was an example in the Prag Studio course where they created a variable purely to make the test-expectation easier to read. So instead of writing something like expect(something).to eq(150), you'd write expect(something).to eq(@initial_health + 50). A small thing, but that was another joy moment.
• Another major skill I picked up was how and when to use mixins. Mixins are modules containing a collection of behaviours (methods) that you might want to reuse across classes. You can then include the Mixin in the class you wat to use the methods in, as if those methods had been defined in the class itself. The PragStudio instructors said that you can identify good canditates for a module by identifying something"able" behaviours in a class. A Player class for example contained lots of methods for printing out different kind of stats. These represented "printable" behaviour, but as they were all about printing stats, I created a module called "GameStats". Later on, I created a different module called "Printable" for non-stats printing behaviour, "Playable" to handle things a player could do (like get blammed or w00ted or know if they are strong or not) and a few others.
• Following on from the above, understanding how to use mixins better also made it easier to understand whether a class should be broken down into multiple classes. It makes it easier to see what belongs together. It makes it easier to think in terms of objects better.
• Related to mixins, it was cool to replace instance variable references in mixins to more generic references to preserve encapsulation.
• I also loved learning how to override built in methods like sort (say if you want to sort something by size instead of alphabetically when calling the default sort method), or like the name= method which lets you override the built in Ruby attr_accessor which uses that method under the hood to rename things. This lets you process (format) the name in some way by default when you rename it. For expmple, names are automatically capitalized when you create objects with that name (in one of my programs), but the formatting that applies in the initialize method doesn't apply when renaming things unless you override it to do so.
• It was also really helpful for me to learn how to create a well-formatted gem. What was really good, was that this was left right until the end of the program. So the structure started out with all the test and production files in one place, then at the end we created the gem specific file structure (bin, lib, spec) and moved the files to the appropriate places, then updated the path information. This was much easier to process, and to understand what was going on in seperate stages, than it has been in the past when I've tried to start off with that structure in place.

Writing out all of the above, it's more obvious how the dominoes have fallen into place for me a bit. Because I struggled with most of those things, or plain just didn't know how to do things like mixins.

I have a solid foundation where I feel comfortable jumping in and writing test-driven programs without feeling overwhelmed. This is partly why I've been so excited that I've struggled to sleep some nights, because now it feels like it's possible to use this as a launching pad to keep getting better without being overwhelmed 24/7.

Thoughts on what's next

I still have the "blocks" and "Rails" courses to go through, but I want to spend some time solidifying everything I've been empowered to do in the ruby course. That will make everything else more useful to when I get to it.

Here are some of the things I'm thinking about spending time on:

Personal Techy stuff

• Play with all of the methods in the Enumerable module in ruby. This will really help with blocks and make it less likely that I'll spend time re-inventing the wheel.
• Work through the Effective Testing with RSpec book. It's really important to me to improve my test-driving skills. Now that I feel comfortable with the basics, I want to further grow that skill.
• Work through the Text Processing with Ruby book. Lots of motivations for this one. It sparks a massive amount of joy and I just want to play with it. I want to learn more about IO for building better command-line applications. I also love using Vim text-processing commands and think this will be really helpful for that too.
• I have a bunch of side-project ideas that I'm working on tiny bit by tiny bit to solidify concepts, and also just because it's fun. But those are not my priority.
• Then the remaining blocks and rails courses on Pragmatic Studio.

Work Techy Stuff

• Pair to get things ready for the next demo. Need to wire in a bunch of forms and get the data persistence sorted out. Currently using an object store in Local Storage. We also want to move to a progressive web-app so the qpack works offline in the brief moments chefs lose the connection in giant cool rooms.
• Guard two-three weeks to reduce technical debt on the front-end. We're now using the nice new styleguide but using lots of the old one in places, so want to consolodate those. I want the components to be like mini layouts, whose only job is to position elements that we reuse from the styleguide. I think the spaghetti mess of styles can be reduced by 80%, which will be a massive weight off, and much more fun to use.
• Go through the Jobs to be done framework. It seems like it'd be right up D's street. He's working on the stories and scenarios at the minute and this seems like a helpful tool to try out to help with identifying needs without thinking in terms of software.
• Do a second Wardley map to see how the pieces have evolved since two years ago. Was reminded the other day as a couple of things we predicted as likely on that map happened.

It's so hard letting go of all the gazillion other things I want to invest time in (like SVG animation), but it's nice to be able to choose skills that can help empower me in areas that are important right now.