Developing Upwards

I've been working on a problem that's bugged me for about as long as I've used Python and I want to announce my stab at a solution, finally!

I've been working on the problem of "How do i get this little thing I made to my friend so they can try it out?" Python is great. Python is especially a great language to get started in, when you
don't know a lot about software development, and probably don't even know a lot about computers in general.

Yes, Python has a lot of options for tackling some of these distribution problems for games and apps. Py2EXE was an early option, PyInstaller is very popular now, and PyOxide is an interesting recent entry. These can be great options, but they didn't fit the kind of use case and experience that made sense to me. I'd never really been about to put my finger on it, until earlier this year:

Python needs LÖVE.

LÖVE, also known as "Love 2D", is a game engine that makes it super easy to build small Lua…

Here’s a hot take: disrupting coders isn’t all that bad.

Some disruptions are certainly bad but they usually aren’t. The coder community has overblown the impact. A disruption can be a good thing. How harmful disruption might be a symptom of other problems.

There are different kinds of disruptions. They are caused by other coders on your team, managers and other non-coders, or meetings throughout the day.

The easiest example to debunk is a question from a fellow developer. Imagine someone walks over to your desk or they ping you on Slack, because they have “one quick question.” Do you get annoyed at the interruption when you were in the middle of something important? You help out your teammate quickly and get back to work, trying to pick up where you left off. That’s a kind of interruption we complain about frequently, but I’m not convinced this is all that bad.

You are being disrupted but your team, of which you are only one member of the whole unit, is working smoothly. You unstuck …

React Contexts are the pretty little bows of the React world.

Here's a really quick example of the kind of messy code you can cleanup by using contexts, without dragging in a larger dependency like Redux or even Flux. Starting backwards with a diff showing lines of code I was able to remove:


All the properties I was able to remove were just pass-through. The Carousel component didn't care about any of them, but it had to pass through these callbacks so the multiple TaskList components inside the carousel could invoke actions. They were removed from the Component class itself, too, since it no longer needed to pass them through.

Where did they all go?


My ActionContext removed all the need for these passthroughs by providing a single simple helper method, action(), that components rendered under it can access.


I really enjoy the pattern of passing a single callback through a context and removing what used to be lots of callback properties. Of course, I could be using a proper di…

Code Reviews in a development team only function best, or possible at all, when everyone approaches them with respect. That’s something I’ve usually taken for granted because I’ve had the opportunity to work with amazing developers who shine not just in their technical skills but in their interpersonal skills on a team. That isn’t always the case, so I’m going to put into words something that often exists just in assumptions.
You have to respect your code. This is first only because the nature and intent of code reviews are to safeguard the quality of your code, so even having code reviews demonstrates a baseline of respect for that code. But, maybe not everyone on the team has the same level of respect or entered a team with existing review traditions that they aren’t acquainted with.
There can be culture shock when you enter a team that’s really heavy on code reviews, but also if you enter a team or interact with a colleague who doesn’t share that level of respect for the process or…

I made the unexpected move with a string of recent projects to drop Git to sync between my different computers in favor of OneDrive, the file sync offering from Microsoft. Its like Dropbox, but "enterprise."

Feeling a little ashamed at what I previously would have scoffed at should I hear of it from another developer, I felt a little write up of the why and the experience could be a good idea. Now, I should emphasize that I'm not dropping Git for all my projects, just specific kinds of projects. I've been making this change in habit for projects that are just for me, not shared with anyone else. It has been especially helpful in projects I work on sporadically. More on why a little later.

So, what drove me away from Git, exactly?

On the smallest projects, like game jam hacks, I just wanted to code. I didn't want to think about revisions and commit messages. I didn't need branching or merges. I didn't even need to rollback to another version, ever. I just …

I've done my first Ludum Dare Jam now, and actually my first game jam of any kind. Wow! I am so happy to have finally done this. It was a super rewarding experience and I want to share that, and my game, with as many people as will listen.

My game is Patient Out Of Time. It is an apocalyptic moody shooter about a doctor salvaging power sources from robots in the wasteland to keep the life support of his last patient running as long as possible. The hospital staff have all left, and they are the only two survivors. Keeping this man alive is all this one doctor has to keep him going.

It is a sad game, but it was also a lot of fun to make.


Here are some things I learned this time. I hope to learn more things the next Ludum Dare.

Little Steps Make Safe Steps I didn't have time for broken builds or half-built code I needed to fight my way back out of just to get the game running again. Every change I made had to be broken down into tiny, discrete non-breaking changes. Every step of…

Game development is hard. I mean, really hard and everyone knows it. You probably won’t finish your game. You probably didn’t finish several games before it. You’ll probably start some more games you’ll never finish. The thing is, not finishing the games isn’t the only reason game development is hard. Let’s learn from some of my failures so far.
Taking Time From Your Family is Hard
Putting it like this sounds kind of distasteful. Yeah, if you’re working on your game in the time you aren’t at your day job, there’s a good chance you’re taking time away from precious family time. You’re missing evenings with your wife. You’re skipping days with your kids growing up. If you don’t have a family in your life, you’re opting out of time with friends, watching movies and reading books, or even just playing games, the same medium you obviously care a lot about.
Making games takes a lot of time. You think you know that, but it takes more time than you already fear. Double that number in your head. …

We live in a hobby-rich world. There is no shortage of pastimes to grow a passion for. There is a shortage of one thing: time to indulge those passions. If you're someone who pours your heart into that one thing that makes your life worthwhile, that's a great deal. But, what if you've got no shortage of interests that draw your attention and you realize you will never have the time for all of them?

If I look at all the things I'd love to do with my life as a rose bush I'm tending, I realize that careful pruning is essential for the best outcome. This is a hard lesson to learn, because it can mean cutting beautiful flowers and watching the petals fall to the ground to wither. It has to be done.

I have a full time job that takes a lot of my mental energy. I have a wife and a son and family time is very important in my house. I try to read more, and I want to keep up with new developments in my career, and I'm trying to make time for simple, intentional relaxing t…

In software development, slow solutions can be worse than no progress at all. I'll even say its usually worse and if you find yourself making slow progress on a problem, consider stopping while you're a head.

Its easy to see why fast progress is better: either you solve the problem or you prove a proposed solution wrong and find a better one. Even a total standstill in pushing forward on a task or a bug or a request can force you to seek out new information or a second opinion.

Slow solutions, on the other hand, is kind of sneaky. Its insidious. Slow solution is related the Sunk Cost Fallacy, but maybe worse. Slow solutions have you constantly dripping more of your time, energy, and hope into a path that's still unproven, constantly digging a hole. Slow solutions are deceptive, because they still do offer real progress. It is hard to justify abandoning it or trying another route, because it is "working", technically.

We tend to romanticize the late night hacking…

Off And On Again is a series of light puzzles. You must turn all the lights on, but you must do so by flipping them in patterns. If you turn one light on or off, you'll be flipping lights around it, too. If you can find the right combination, you'll brighten up the board and move on to the next challenge.
This was more than just a game. This was a public project in putting light on the hobbyist game development experience. Created over 25 hours, every single minute of the development of Off And On Again is available as part of a YouTube series Let's Make A Game. If you're interested in learning from this process and seeing what came out of it, you can watch the entire creation of Off And On Again and then play the game for yourself.
The Series: https://www.youtube.com/watch?v=jlFKDVs9l3Q&list=PLg8XhO9Ilwl9Bw9h5wimuRgx5VrK3D-Kb

The Game: https://play.google.com/store/apps/details?id=com.stonebirdgames.OffAndOnAgain

For a few weeks now I've been posting new episodes of a YouTube series I've been doing this month called Let's Make A Game. Now that I'm most of the way through the project, I wanted to think a bit about why I'm doing this, what I think people might get out of the videos, and what I hope to get out of it for myself. The best way I know to do that reflection is to write about it, and to share those thoughts.

So, Why am I YouTubing an entire game development project? Why would I put myself out there so publicly for anyone and everyone to look over my shoulder for twenty-five straight hours as I stumble, typo, and mistake my way through a skill I'm still learning and still very green on? And, why exactly would I think anyone cares enough to watch me code, mostly in silence, for twenty-five hours?
Why would anyone care to watch?The truth is, I don't really expect anyone to. And that's okay. Part of this project required that I be okay with my own definition o…

Interested in my process for making a monthly game? I've got two new episodes up of my series Let's Make A Game! for a total of eight episodes to enjoy, so far. The project should include a total of 25 episodes by the end of the month.
Let's Make A Game! Off And On Again Episode 12Let's Make A Game! Off And On Again Episode 13
If you want to start from the beginning, you can find a playlist of all the current episodes with all the future episodes added when they're available. Of course, you could also subscribe to my Stonebird Games YouTube channel.

Interested in my process for making a monthly game? I've got three new episodes up of my series Let's Make A Game! for a total of eight episodes to enjoy, so far. The project should include a total of 25 episodes by the end of the month.
Let's Make A Game! Off And On Again Episode 9Let's Make A Game! Off And On Again Episode 10Let's Make A Game! Off And On Again: Episode 11 If you want to start from the beginning, you can find a playlist of all the current episodes with all the future episodes added when they're available. Of course, you could also subscribe to my Stonebird Games YouTube channel.

Interested in my process for making a monthly game? I've got two new episodes up of my series Let's Make A Game! for a total of eight episodes to enjoy, so far. The project should include a total of 25 episodes by the end of the month.
Lets Make A Game! Off And On Again: Episode 7Let's Make A Game! Off And On Again: Episode 8 If you want to start from the beginning, you can find a playlist of all the current episodes with all the future episodes added when they're available. Of course, you could also subscribe to my Stonebird Games YouTube channel.

My game development video project, Let's Make A Game, is still underway. There are three more episodes available, for a total of six episodes released so far.
Let's Make A Game! Off And On Again: Episode 4Lets Make A Game! Off And On Again: Episode 5Let's Make A Game! Off And On Again: Episode 6

The game is shaping up well, and I'm getting a better handle on how to put together the videos. At the end of this project, I expect to have two useful results: Primarily, a finished game that's actually going to be fun to play. Secondly, but actually more important for me,  I'm hoping that the structure and transparency of building the entire game while recording will help me learn to better focus, budget, and scope my game development projects.
From here on out I'll continue to post a weekly update of the new videos to this blog, but you can subscribe to my channel if you'd like to see the videos sooner.

Let's Make A Game! I've been making games to one degree or another for a few years, and I've really gotten into a rhythm in the last few months. This month I'm trying a new experiment and posting the entire process of building the month's game development project. I'll be publishing a stream of every single step I take in the process, broken down into 25 one hour episodes.

I'm doing this for a few reasons.

Firstly, I'm doing this for myself. The one hour sessions and the focus recording gives me on the task at hand are helpful. I think this is an interesting way to go about a project. I'd also like the strict schedule to help me study and learn more about the aspects of budgeting and scoping game projects that I have too little experience to be very good at.

Secondly, I'm hoping someone out there gets some value out of this. My skill level as a game developer is still pretty low, but maybe its helpful for someone to see how someone learns to sol…

I was really excited about the One Game A Month challenge as soon as I heard about it.
For about two years I've struggled in fits and starts to make my way into game development. This hasn't been productive in any of the ways I hoped when I started. Its really difficult to be fairly experienced as a developer, which I believe I am in my day job as a web developer, while struggling really hard at an area in which your experience just doesn't exist.
Its like being a pilot who doesn't know how to drive.

But this challenge provided a new breath to this little hobby of mine. It gave me a scaffolding to experiment, to learn, to reflect on finished projects. I had spent far too much time on game projects that stretched on far past their exciting phases, bogged down by bad decisions and regret.
And it has worked.
I have a lot to learn. I have a lot of experience to gain through trial and error and mistake and discovery. I have a lot of fun to be had making more small games t…

Every developer finding their way around ReactJS is going to come across CSS Transition Groups sooner or later. These helpful components built by the ReactJS team but distributed separately help to manage animations related to adding or removing elements from a list. This is important in ReactJS, because the virtual DOM reuses nodes as much as it can, meaning what seems like a new element but really be reusing nodes underneath. You can read all about the ReactCSSTransitionGroup at the React documentation, but I want to note about one way you might trip integrating it with your project: building vendor bundles for your dependencies. If you use Browserify to bundle your own code and its dependencies for distribution, you may be using the vendor bundle pattern. This is the practice of separating your distribution into two bundles: one containing your dependencies, including ReactJS itself, and one with your own project code. This is a good pattern because you can rebuild just your proje…

I like to think I'm a good web developer. Getting here was the result of experience, practice, and constant curiousity. Lately, I've wondered if the passive nature of that curiousity has run its course. The pace and breadth of changing technologies as a web developer can be both breathtaking and overwhelming at times. What do I need to know about WebAssembly, WebGL 2.0, or the differences between Browserify and Webpack? Do I need to know about any of them at all? How do I learn enough about each just to understand if its something I need to understand even more deeply? Beginning an effort to make that ever driving curiousity more directed, here's a list of things I don't know enough about, but would like to study better. WebpackI know that Webpack can replace Browserify and recently have understood it may replace some (or all?) the ways I use Gulp today. I don't know if the change would impact more projects beyond the build scripts or how much time or effort would …

I’ve become a much better developer than I was when I began working professionally a decade ago. I feel confident enough in my abilities to recognize that I have improved the breadth of my skill set and the depth of understanding I’ve built in the areas I have poured the most focus into over the last few years, especially. One of my strongest, most developed abilities is the ability to recognize and pick apart my own skills critically. I feel good that I can say this is not Impostor Syndrome, something that has certainly afflicted my professional career for most of the years I’ve been at this. What this is, rather than irrational undervaluing of my skills, is finally getting to the point that I realize I’ve spent years getting better passively and accidentally, and I need to develop my skills into the future actively and intentionally. So to start this new focus on developing my skills, I’m writing this as a starting point, an exploration, and an invitation to anyone who identifies w…