This post isn’t specifically about the project I outlined in the first post, but it is a persistent problem I keep running into, even though I know the problem is there.
I am working on a tutorial for Ray Wenderlich and I have been running into issues with it.
My issue is that I have program-specific logic. I am creating a very simple game, but one thing I didn’t think about was the fact that you have to explain every little thing to the application. There are so many connections your brain makes automagically that a computer doesn’t know. You have to figure out how to tell the app how to think. This is the underlying issue in machine learning, but on a much larger and complex scale.
One reason I wanted to do a game application over a more useful type of application is because of application specific programming logic.
One thing I find frustrating, that is actually a feature of iOS, is how many frameworks there are. Sometimes I feel like when I am writing an app that you are choosing a framework, reading the documentation, and then just setting a few properties on that framework to make your app do something. So like, if you are doing something in SpriteKit, you’re choosing the image for the sprite, then you choose where it’s boundaries are, and you set a bunch of properties on the SKSpriteNode.
I have found that I get into a mindset where I feel like the only tools I have in my toolbox are ones that are pre-baked by someone else. If there is’t a framework for it or a property for it, it doesn’t occur to me that it can be done. The app is basically a giant state machine where your Swift/Objective-C code is just some glue holding together a bunch of pre-baked parts.
Whenever I am presented with a problem that requires a lot of program specific logic, my brain freezes up. It gets used to the idea that I just go pull a piece of code out of a box and it does what I want it to do. When I have to actually engage my brain in figuring out what my application has to do it’s like exercising a muscle I forgot existed. It’s incredibly weird.
I know that all of programming is supposed to be about figuring out what you want the application to do, but most of us don’t think that way. There are so many fucking blog posts by people trying to come with convoluted reasons to create hieroglyphic looking Swift closures that you need a Rosetta Stone to interpret. Most blog posts and tutorials are around talking about the components of a framework and not what you can do with it. Every game development book I see talks about how to use the tools of something like SpriteKit or Unity, but not how to think through how you would solve a problem.
The thing that prompted my last blog post was my expressing frustration that programming books talk about tools but not how to use tools to solve problems. I got a bunch of sanctimonious assholes telling me that if I read a book on algorithms it would somehow magically solve all my problems and telling me that if I read a half dozen different books that somehow I could cobble together all of the stuff I need to do what I want.
I think there is a better way.
I feel very frustrated that we, as a community, don’t talk more about how to think through how to solve a problem. Yes, there are multiple ways of solving a problem. So why not talk about it? Talk about how you tried a few different ways and you ultimately chose one specific way because it was the shortest or the most maintainable or the most reusable, etc…
We don’t do this because it’s hard.
It’s a lot easier to write a blog post saying you did something simple with SpriteKit that looks super impressive but doesn’t give anyone a visceral understanding of what they can do with it.
One reason I am running into problems learning Metal is because I don’t know what I am supposed to do with it. Almost anything I need to do in Metal can be done with something like SceneKit. I keep trying to learn the framework with no context as to why it’s important and what problems it solves. I get people hassling me by telling me it’s up to me to figure out why it’s important and that’s bullshit.
Programming isn’t an objective thing where every single app is a special snowflake. They all require us to think through why we’re doing what we are doing. I have fallen into a pit the last year where I have just automated that process in my brain where if I encounter a situation that doesn’t fit into a neat box my brain can’t deal with it. That’s fine for most of what most employers need, but I don’t want to be like this anymore.
I miss thinking about how to solve problems. I miss working on a portion of a project where I actually get to touch things and see how they connect rather than being told to pay no attention to the man behind the curtain because the code base is so fucking massive and poorly documented that no one knows how it works.
I am trying to shake away my mental cobwebs and remember that programming doesn’t have to be an automated process or something where you get into a pissing match with other people to make the most convoluted code you possibly can without breaking the compiler.
One of the goals with this series of blog posts is to explain a problem I am trying to solve and walk people through my thought processes in the hope that we, as a community, put more effort into talking about how we approach problems rather than seeing who can be the first person to get something running on the Apple Car, whenever it comes out.