Thursday, May 7, 2015

Explaining computer programming

Have you tried explaining what you really do at your job all day? Saying that you're implementing features and fixing bugs is kind of like saying a writer writes down sentences and will remove some that don't make sense anymore. It simply doesn't do the profession justice.

Simplify

Being able to explain something simply is said to help one's understanding of a topic. We could all understand software a little better, right? I've tried a few different things, one of them being that I get to make stuff up all day. Have I ever created a ClaimValidationProcessorFactory before and know what that is? Nope. I just made it up. And it's going to production. This explanation is a start, but I don't think it captures the scope very well. Understanding the depth behind being able to make stuff up, and having built off of others' made up stuff is vitally important to getting a good gist of what software engineers fight with on a daily basis.

Calvin Ball

Enter Calvin Ball. This is a simple to learn game that is very complex - you just make up the rules as you go. It's interesting because each new rule has to coexist or build off of the previous ones. If you have a rule that says you must hop on one leg and another rule that says you must hop with two, well that doesn't make much sense does it? The trick is extrapolating that a bit. In a non-trivial game of Calvin Ball (aka your app), the number of rules can easily be in the 100s. Knowing all of them at once is infeasible, but that's the demand that's put on you. Mess it up and you have moments where your players are told to do contradictory things. In software engineering we call that a bug. To help us out, there's certain patterns and conventions. You don't make _anything_ up. We know ClaimValidationProcessorFactory is a Factory, which carries a heavy set of assumptions on what a CaimValidationProcessorFactory does. If it doesn't, well, the original engineer needs their hands slapped. It happens far more often than you'd think.

Suppose

In the software world, things are composed of many layers. Each layer is a kind of thought that starts with "Suppose...". Suppose we have a state that has two possible values: on or off. Suppose we have many of these states in a series. Suppose these state series are used 4 at a time. Suppose we have a means of looking at one of these groupings of states and deriving an action from it. Suppose off off off on means "take the next two groups of 4, and add them together - assume them as numbers, and place the result in a known place". Suppose our series looks like this: "off off off on off off off on off off on off". You might say "oh I see off off off on a second time, so it adds again!", but that would be wrong. You must treat them like numbers. We supposed that already, right? We just described how machine language runs on a computer, which all of our software is based off of.

What it's not

Computer programming is not construction/manufacturing, despite construction related analogies we do all of the time (build, construct, factory, etc). If it does feel like construction to you, well, you're doing it wrong.

Ending thoughts

It's still considered cool to not be a "computer whiz" just like it's cool to not be able to do basic arithmetic to balance your checkbook... somehow. Taking some of the mystery out of what we do by giving a simple explanation without actually having to teach someone how to code could help us rope in more bright contributors and expand the industry as a whole. How do you explain it? Are there other things you see people equating it to that are simply incorrect?

Wednesday, March 11, 2015

Coding in Anger - Adventures in Quality of Life

During a tech meeting at work, my manager started off an explanation with "It's been a while since I've coded in anger, but...". This simple sentiment really resonated with me. Often times I've made the argument for particular choices that ultimately enhanced quality of life, but I've lacked the ability to properly articulate why those choices were beneficial even if the surface value seemed to be that it would make my life easier. That simple phrase has given me a lot to think about in terms of framing the justification here.

I've heard the argument that your user doesn't care about your test suite, or how easy it was for you to write something. While I think there's merit in such an argument, the black-and-white perspective of it simply makes it untrue. There's an implication that we should consider ourselves lucky when we get to do things like test drive, pair program, use good tools, and make good architecture. It's like we as engineers are compulsively driven to want to put things in nice and neat little boxes for organization's sake. When we can't do that or something disrupts the organization, we throw a tantrum because we're simply children. While I believe there are certainly cases where this applies, it's blatantly incorrect to paint all of us under such a stroke.

The thing is we get frustrated and angry at our cools, codebase, process red tape, etc because it hinders our ability to perform. If I'm too busy jumping through the hoops of broken framework X then that means I'm not delivering awesome stuff. Instead it usually means I'm writing harder to maintain code. When something is hard, it doesn't get done. Or at least it doesn't get done as much or as well. Sure, you can build entire empires on PHP, but by that reasoning it means the next grand project akin to the Pyramids of Giza can be done without any modern trappings, right? If logs, rope, sweat, and blood were good enough for them, then it must be good enough today, right?

A software shop should fight tooth and nail to stay on top of the curb. Does that mean we have to go back and rewrite? You betcha. But if our technical debt is reduced, if the engineers are able to get closer to the features or pull out 3rd party modules to assist in development, then isn't that a big win? Avoiding rewrites is a lost cause. How many banks are glad they are still running on COBOL today? Sure it was probably great at the time, but that time has passed. Everything we use now will eventually become archaic and dated. We may as well embrace the idea that code is a living document that needs small and big adjustments both over time. Does that mean we should jump on every shiny new framework the moment it comes out without evaluation? Of course not, but this entire "suck it up and get back to typing" attitude needs to go. Your user might not care if you're using punch cards to enter your code, but they certainly are going to feel impact of such a choice.

Something to consider.

Wednesday, December 3, 2014

Javascript - Retro is in vogue

8 months experience (which you might say more, given the OT that was put in) using Angular.js apparently is enough to make you a guru in development shops that are new to it, as that is now my role at a local gig in Portland. They've decided to transition me to full time from contracting, so I must be doing something right.

Javascript hasn't changed much since I learned bits and pieces of it years ago. It started getting pretty fancy when jQuery was hot, but now that we have full MVC(ish) stacks in Javascript, I must say doing client side development is pretty awesome. Is it without problems? Of course not, but as a JS developer I get to live the dream of a thick but universal client that runs on any device that matters, but keep the server away from buffering giant HTML files and having to handle flow through a series of dynamically generated web pages. Now I get to think in terms of web applications. No more redirects here.

Javascript still has many blemishes. 'use strict' helps a lot, but there's still many gotchas. I've come to stop hating Coffeescript, even though it still feels pretentious. I recommend it now to teams, but if it doesn't stick, no skin off my back. As I learn more about Javascript and its quirks, I want to start turning more and more flags off the jshint settings.

My most recent personal project has been to take my Roid Miner game (formerly Star Skirmish) and convert it to full-on Javascript. My familiarity with Angular, Node, and friends had given me affordances I didn't have when working purely in Unity. It also made me turn up my nose to a lot of the hoops I felt I was jumping through in Unity. A recent update of Unity caused me to lose all of my data in my Scriptable Objects which I had labored intensely to make good editors for. Combine this with some prior experiences where Unity simply lost data while making changes to objects, and this distrust made me decide to abandon Unity's serialization in favor of something I could trust, and something I could easily publish in a web-friendly fashion. As a result I replaced large portions of the editor with an Angular app in a short amount of time. At the end of that road I still wasn't happy. In my prior job doing educational/impact game development, we started using Angular in an embedded browser inside of Unity to do the UI, and it was amazingly awesome. HTML, CSS, and Javascript all have their problems, but at this point everyone knows them. Making game UI using a web stack is pretty easy and flexible, it turns out - and the best part is you don't have to write some poor approximation of html/css to accomplish it.

After some consideration, I decided to abandon Unity altogether and start picking up Three.js. I'm still very far away from something useful with it, and there's a ton of stuff I'd have to write just to catch up to Unity's capabilities, but the cool part is I've already embedded Three.js in my existing Angular game editor. The game and the editor can kind of be one in the same if I choose it, and I think that's what I'll do. I loved the talk by Bret Victor and I always wanted Unity to do some cool live-updating stuff. Unity just doesn't have good hooks for that kind of thing, but with this editor I'm free to build that up as I wish. I have a lot of work to do just to get back where I was, but this is an exciting time.

Hopefully I can start making some more posts. Some technical, some not. I'd love to get back to doing a weekly post.

Saturday, December 8, 2012

Portland, Oregon

As of next week I'll be in Portland, Oregon. I've wanted to live there for some time but kept getting reeled into interesting things here in Phoenix. I also have some good friends there as well that I've done great at keeping in touch remotely. However, the main reason for moving is because the wife just can't handle the climate here, and basically stays locked indoors for 8 months out of the year.

I was willing to let go of my current and awesome job doing educational game development for ASU to make this move, but was really sad to do so. I expressed interest in working remotely and they decided to allow me a trial for two to three months. Needless to say I'm pretty stoked. This is just about all I could ask for in terms of employment and location of living. Working remotely has its benefits as well - no more commutes, I can play games at lunch if I like, etc.

I will be moving away from a lot of really good people, but fortunately most of these people I know personally I can spend time around in various ways online or even at work. I know that's not quite the same but it's certainly better than nothing.

With a job in tow the move is something I'm really looking forward to, and it's only a week away. Now if only I could get packing!

Wednesday, May 9, 2012

Star Skirmish

After some crazy work hours I'm finally able to put some time into my own game a little here and there. Destroxels is feeling really difficult due to how complicated networking can be. I'm trying to make a simpler single-player game. A single player game needs AI and dynamically built games seem like they would be easier in 2D, so I decided to make an asteroids rogue-like. Let's see if I can do anything useful with it.

You can check out the game itself at the Star Skirmish page.

Wednesday, September 21, 2011

Peaks of DOOM

Using the awesome power of Perlin noise, I bring forth the Peaks of Doom!
Watch your step!


Thursday, September 15, 2011

Destroxels Update - More artwork

Not a whole lot this update, except for unifying the theme of the game a bit. I've added better rockets, a good rocket launcher model, and some spiffy particle effects. I think the rocket launcher is done now.
Voxelized Explosions