I love your concept of humanized Charles and Henry! I think it's a pretty lit idea.😎

awaa thank you!! <:D

for some odd reason, i enjoy trying to base a character's appearance purely off their personality traits and such (when the character has a very undetailed appearance, like say, a stickman). it's pretty fun!

Constructive Ways of Managing Quite Long Development Iteration Times

So you're a brogrammer now. You sling some Python, or Coffeescript, or bash, or whathaveyou. Now you're contributing so some mighty project, and it is taking quiet a while (in developer time) to build. Maybe the compiler is slow. Or the CI server runs a bunch of extra checks. Or you're generating virtual machines that take ages to install. Whatever your project, it can feel agonizing to change a few characters, start a build, and have to wait a long time for the build to finish before you actually know if your code is working. If you're lucky, the build runs sucessfully and you now have a working system to share with others. If you're unlucky, the build dies half an hour from now, and you'll be tweaking some more characters, triggering another build, and by then you'll have lost quite a lot of productivity. In an industry of instant gratification, latency measured below human perceptive levels, actually making your own software can be a very different experience to using premade software. Expect more pain and bugs than usual. When you clock out of a hard day's coding, you may have only moved the progress bar a few ticks, while the rest of the open source community seems to whizz by at light speed. It feels like being stuck in a local Turing tar pit, where even the most incremental code changes take forever to test. What a bother! Might as well ditch software entirely and go back to Triceratops trolleys or however things were done before computers.

The good news is that, as bad as a post-fifteen-minute build may be for software development, it's neither atypical nor fatal to the success of a project. You think you have it tough? Hardware development cycles can take months, so practice patience young programmer. If you're stressing about fixing that null pointer exception before the hackathon deadline in time for a pizza break, consider how the foreman feels managing a condo. He doesn't even get the benefit of instantly wiping his workspace when something builds wrong. A foreman (or forewoman) has to spend even more time and money to tear down any mistakes during construction. You got it lucky doing your jerb from a coffee shop.

As I said, it's not uncommon to suffer egregious build times that take far longer than a few milliseconds, stretching instead into the quarter hour, half hour, or multiple hour mark. This happens for a lot of reasons, basically ineptitude in build design, which we won't cover in this post. There are plenty of steps an engie can take to optimize build times, and if you're the punk suffering from those build times, I'm sure you know better than me what specifically is soaking up your productivity. If you can fix that, you should. A good technical leader will recognize when project structure is limiting productivity, and will reward anyone who can reduce these blockages. The technicals don't matter so much as the political power to effect that change. That's all I'll say about that.

Instead, this post is about what you can do to get the most out of a sucky code-build-test-repeat loop, where you've exhausted the technical and political possibilities for improving the loop time. Aside from rewriting the project from scratch (probably in Go), what can be done to stay productive in this hellish environment?

Recognize your daemons.

Take stock of the applications, services, processes, and so on that are sharing resources with the building project. If you're playing around in Photoshop the same time you're running a graphical benchmark, that probably adds some extra delay on top of the baseline delay. Disable networking programs, menulets, anything that is stealing precious resources from the build.

If you're building locally, consider moving the build process to a dedicated remote server. If you're building remotely and the server is always stalling, replicate the build locally. Even odds that the build system is awkward and designed for local operation XOR remote operation, i.e. not for both. If you can unify the build system so that it can run more similarly and successfully in both environments, that will exponentially improve production reliability in addition to improving build times. Use Docker. Anyway.

Debug logically.

Richard Feynman is said to have fixed a radio just by thinking about it. Some shit like that. The point is, you spend time thinking about a problem before you go and solve it. Especially when the act of solving it takes way more time than thinking about it. Become the compiler. Practice those stupid Java puzzlers. Once you hit Build, it will be very many nanoseconds in the future before you can fix the code and build again, so make every build count. Specifically:

Lint your shit. Your text editor can warn you of build-failing code before you actually build.

Unit test your shit. When you add functionality, write a dinky little test that should fail if the function is at all inaccurate. Learn the syntax for calling specific tests rather than the whole test suite.

Automate that shit. If you're setting up a database every code-test iteration, find some kind of process so that the computer does the work for you. Doesn't have to be a perfect POSIX compliant shell script. It doesn't have to be portable across different user accounts. It doesn't even have to be command line driven, just as long as YOU can get it to run and do the things you need in a basically reproducible fashion. If it fails half the time, run it twice the times.

Master the code base.

Software is shit. There is a very good chance that the build error you see bears the most strained and tenuous relationship to the actual source of the error. I hope you never have to debug microservices. Jesus.

In any case, study not just the error messages, but the code base as well, including the history. Does git-bisect show a particularly bad sequence of commits? Does churn show an unusually in-flux file? Does git-blame show a logic bomb your asleep ass slipped into development months ago? Which classes are poorly documented? Which classes' documentation are LIES? Baz Luhrmann would have sung "Add... Print statements." if he wrote this shit.

Boldly experiment.

In science, some experiments are so sensitive that they take decades to complete. You can't push a rover to mars faster than the laws of physics permit. So when the project calls inherently for long turnaround times, the thing to do is to pack that bitch with as many experiments as possible. Collect soil samples, record atomospheric measurements, take photos, gather dozens of metrics. It's a big investment, so diversify the treasures.

Do not be afraid to try out ideas on the code. Fork it. Branch out. Tie it up in an FPM bundle. Delete the parts that you don't like. Fix multiple bugs at once, because it's better to find out that 4 changes don't work in 1 hour than to find out that 4 changes don't work in 4 hours. Change the code to fix the top error message, and the next dozen, before you hit Build.

Fuck commit hygiene. What a waste of time! Do your dirt in a feature branch and rebase for cleanliness once the build works. Swap out dependencies, even just different versions of dependiencies. Pin that shit. Lock it down. Distrust semver. Control your space, now you have all the time in the world.

They say discipline boosts creativity. Not fascistic hierarchical discipline, just the idea that supplying your own structure to your work can actually lead you naturally and unexpectedly to new ideas. Try programming without classes and objects. Try installing operating systems without a mouse. What kind of algorithms would still work for that problem without losing idemopotence? How freeing is a system with full POSIX compliance? How freeing is a system with no POSIX guarantees? Change the system to work for you, or else change yourself to work in the system.

It can get so droll hitting Build, looking up an error code, changing one or two lines of code, repeat, repeat, repeat. Take a coffee break. Do something else for an hour, even if it's just coding in a slightly different project. To be pretentious, let your subconsciousness solve the problem for you while you consciously attend to other tasks. That single threaded grind can wear you down, so I personally recommend pipelining your life with more than just the same old same old. One of my coworkers had a multiple monitor setup. The first monitor was for coding. The second monitor was for "bullshit", basically Internet memes. Find your bullshit Zen. You can be productive, even when the system seems to be designed against productivity. Lurk in IRC; solo coding gets depressing after awhile.

If you're suffocating from long build times, breathe. You are not alone. Build times can certainly be improved, but history indicates you'll be far more productive if you treat long build times as axiomatic, just part of the inherent nature of the work. You can pine for a time machine to fast forward the build, or work on unrelated tickets, or program defensively. Standing still is not an option, not for this blog.