I’m less than a month at a new job and am struck by how hurried and demanding our world has become. Obviously cities are more rushed than small towns, and some jobs and industries are more relaxed than others. It should be no surprise then, that living in Sam Francisco and working in the tech industry, that I have found myself at the nexus of “now, now, now”. Or, perhaps even, “done yesterday!”

I’m still relatively young, and fresh out of college. This is only my 3rd job as a software developer, and maybe my 6th job ever, if you count working for my parents or tutoring in high school. I can definitely attest to the higher amount of pressure in my tech jobs. But even so, my last gig was remarkably lax for being a well trafficked website. There were deadlines and pushes, but there was an ebb and flow between projects on a tight schedule and those I could take my time with.

In that atmosphere, I was able to foster a sense of responsibility and ownership over my code, and my projects. I was actually impressed with myself. As I was beginning to transition out of my role and toward my new job, I went back do make sure my projects were documented & understood. Most of my code, which I had made & worked on solo, was really well documented and ready for hand off. It was a moment of pride seeing that I had taken the time to do it right the first time.

Conversely, my current job is caught up in the mentality of quantity of output over quality. “As quick as you can, with the minimal amount of effort & changes.” This means get it fixed, don’t worry about context or goal, just fix the micro bug. On the one hand, yes, by going ‘quick & dirty’ you can get through more bugs. But on the other hand, how many of those would have been prevented if we had taken the time to fully address the scope & context?

Regardless of which side is right, my mind and perspective is firmly planted on the “do it once, do it right” side. If I can spend a little more time and effort now to save the next person some frustration, why wouldn’t I? I took the time at my previous job to document my major projects while I was working on them. It didn’t cost me much to do it, but I certainly wasn’t obligated to. One might argue that by documenting my code, I was helping my future self when I had to return to debug. This is true, but its also a point of personal pride for me, that my code isn’t a complicated mess.

(I should concede that just because I think my code is organized & understandable, doesn’t mean it actually is. This is true, but at least one coworker commented that my code was very clean and clear when I was going over it with him. That doesn’t mean that some of my projects weren’t better or worse than others.)

I’m struggling with the concept of minimum effort. Especially when I recognize, “if we added a test for this, it’d be less likely a problem in the future.” There is a movement toward more tests & code coverage, but its slow to implement. And much of the existing code could benefit from consolidation & refactoring, if for no other reason than increased clarity during debugging.

The problem, is that I understand the need to produce. The longer we stall on new features the more money we are losing, but my fear is that, if we continue on at this demanding “faster, faster” pace, our product and its growth won’t be sustainable. We’ll be stuck under a mountain of bugs.