Programming Under Limitations

"Ideal" development isn't ideal

Let me clarify; writing code and developing software under ideal conditions is nice. When everything aligns and a project goes off without a hitch, I'm spoiled. When everything goes as expected, I can take a step back. I can plan my code and be meticulous. This occasional indulgence in meticulousness is essential to personal growth and development. But it isn't indicative of most real world coding projects. Most projects needed to ship yesterday, or at half the cost, or in Cobol. Whatever the project, there might be restrictions. And those restrictions will be less than ideal.

Yet these restrictions are what make disciplines like engineering and software development shine. It's why bridges, buildings, and space shuttles fill us with awe and inspiration. They're incredible because they were built under restrictions. Human ingenuity and problem solving shine forth with restrictions. This isn't to say that the burden of restrictions should be overwhelming. A death march or Herculean task doesn't provide any benefit. It hinders and jades as opposed to challenging and edifying. An ideal restriction should be surmountable given creativity and second order thought.

Again, solutions that involve throwing yourself at a concrete wall aren't solutions.

Squats and Oats

A good analog is weight-lifting. Safe weight-lifting involves a dose of introspection and being honest with personal limits. A proper lift needs both good form and enough weight to challenge muscles. There's a natural opposing dichotomy in this dynamic. Pushing boundaries enough to become strong without injury is key. The same is true in software development. There will almost always be a limiting factor. Learning how to surpass these limits induces growth in both creativy and problem solving.

And like weight-lifting, the individual needs consideration. This isn't to say that everyone can lift as much as Hafþór Júlíus Björnsson. I mean, look at that guy.

Seriously, look at that guy. Absolute unit.

Everyone has their own particular and specific limits. What Hafþór can lift is (definitely) not what I can lift. And it shouldn't be expected that we can perform to similar capacities. The same, again, is true for software development. The conceptual burden that one developer is capable of is not the same for other developers. And this isn't even taking into account that creativity and problem solving chops are context specific. Give me a project that involves some data processing using Node or creating APIs and I can flex big; no problem. Put me in front of OpenGL or anything related to graphics rendering and watch me sweat. I've never done anything related to rendering and it's been years since I've written C++ (thanks college). I haven't flexed those muscles. Ever.

An example

Please understand

The man, the myth, the banana-holding-glasses-wearing-programmer-turned-executive legend - Satoru Iwata. The late CEO of Nintendo and father to an incredible era of video games. If you don't know more of his story, I highly recommend checking it out. Like most of us, he started his career by working in the trenches as a programmer. Unlike most of us, he became an executive to a global company.

There are a few popular stories involving Iwata and how he overcame limits. To the joy of classic RPG fans everywhere, he saved Earthbound (Mother 2) from cancellation. The project was running overtime and over-budget. The O.G programming team was having a hard time getting things to work right. Iwata and his team at HAL stepped in. They were able to take over programming the harder parts of the game and save it from cancellation. Which is good; Earthbound became a touchstone for the RPG community, and it's legacy is still visible today.

Iwata also helped with the development of Pokemon Gold/Silver. Again, the project had some intense limits. It was overtime and drastically understaffed. There were only about four full time programmers at Gamefreak working on the project. They were planning on releasing a bare bones game. Localization was a 'dream within a dream' according to one of the programmers. Iwata was able to sketch out a path towards localization. The plan became a reality and Pokemon was able to have a global launch. Not only that, but Iwata helped Gamefreak use better compression for game assets. This is the reason both the Johto and Kanto regions made it into Gold/Silver. The man was able to fit a game inside another game inside a (maybe) 8Mb cartridge, and that in turn helped this generation of Pokemon become a much loved success.

Call me Candide

This is probably an overly naive and overly optimistic take. The persistant myth of man overcoming adversity is one I subscribe to; it's probably what makes me (and humanity) so stubborn. And I've seen this myth be dogmatically applied to the detriment of others.

To paraphrase Kenny Rogers, sometimes you gotta know when to hold 'em, sometimes you gotta know when to fold 'em. Giving something 100% effort and surpassing an obstacle is admirable and gives a pretty good high. But flirting with burn out, soul-sucking "crunch" times, and feeding people through the meat-grinder is bound to ruin the software development industry (just look at the current state of game development).

Ideal development isn't ideal; it can be messy, it can be hard, and it can take time. But it'll build you up.