My biggest flaw as a programmer is shipping things.
If you participate in the major game development communities online, you’ll see the same problem. We’re obsessed with making games, but we can’t seem to finish them.
This blog ‘series’ is an attempt to push myself through an easy project for 30 days. It won’t require the polish and dedication of making a game, but it’s a small brick in the foundation I’d like to lay.
Then comes the games. For years, I’ve told myself that “I don’t need to remake the simple classics. I’m smart enough to make games from my own unique ideas!” (hint: I was wrong)
Pong, Snake, Pacman, Tetris, Bubble Bobble. For now, those seem like good targets.
Start small. Focus. Ship. That’s what I need to get good at.
Why is it so rare to see references to documentation that supports the decisions of the tutorial-maker?
It’s already bad enough that we’re expected to basically copy and paste code, we also have to take the author’s word for it that they consulted the spec and are giving sound advice.
If you write a programming tutorial, please consider going the extra mile. Link to the specification, and explain why you’re advocating writing particular lines of code. It will ensure that the readers actually understand what they’re doing.
I’m not sure why I keep coming back to Twitter. It’s difficult to think of any good reasons to use it.
While trying to write this post, I’m realizing that I don’t have anything interesting to say about leaving Twitter, but I told myself that I would write a blog post every day for a month.
Now I’m questioning whether I should be writing blog posts or not.
Should I even be questioning these things at all? Why do I keep questioning my questioning? Is this all a waste of time?
Let’s say that I give up all social media. The point would be to fill that time with productive work. Making things is far more important than reading tweets all day. But, will I actually fill the time with work?
I hope so.
Getting into a flow state is the holy grail.
It’s been a while since I consistently found flow while programming. The distractions around my work have built up quite a bit lately, but the kids are going back to school soon.
There are a few prerequisites. Stuff like challenging yourself (not too much), limiting distraction, and focus. Most of that is pretty simple. Just do what you have to do.
Pre-work rituals can be particularly interesting. If you signal to your brain that you’re ready to work, you’ll have an easier time getting to flow.
One or more of these just before work, and only before work, can help facilitate flow:
- Put something on (hat, glasses, etc.).
- Use a particular room.
- Say something to yourself out loud.
Something is wrong with our software. Bugs, poor performance, privacy leaks, etc. There is plenty to complain about.
What if we focus a bit more on maintenance instead of innovation?
What if we delay new features until our software works the way it’s supposed to?
It’s not going to happen on a large scale. Too much money is involved.
However, I’m glad that communities like Handmade Network exist. Keep fighting the good fight.
You may have heard the term ‘phantom limb,’ but have you heard about the phantom beard epidemic? Hipsters everywhere are rushing to urgent care to complain about PBP, or phantom beard pain.
The pain is mostly emotional, although some cases are being reported with physical pain near the base of the chin. In my case, there is no physical pain, but the emotional pain is more severe.
I recently lost about four inches of my soul. I pray that you never have to experience such a tragedy.
The overly general idea is that merely practicing isn’t enough. We need a way to measure progress, and we need feedback on how we’re doing. Sounds simple enough.
How does this work for programming? Well, I’m not sure yet. When I want to learn some new programming stuff, I search for a well-written tutorial, and follow the instructions. From there, I should have the knowledge to start my own project using what the tutorial taught me. That’s in an ideal world, but it rarely works like that.
So, I have this idea. Step 1: run through the tutorial without deviating. Step 2: start the tutorial over, but write the code yourself. Do your best to ignore the code samples, and see if you can do it all again with the concepts you learned.
Progress is measured in how many steps you can complete from memory (hopefully demonstrating your understanding of the high-level concepts), and the feedback is your working program, written by you, rather than regurgitating copy pasta.
Time to experiment.