Remix.run Logo
jordwest 5 hours ago

I've worked in two different types of environments - one where what you said is absolutely true (most of my jobs), and another where it's not true and the quote holds up.

The difference, I think is:

- Code factories where everything is moving fast - there's no time to think about how to simplify a problem, just gotta get it done. These companies tended to hire their way out of slowness, which led to more code, more complexity, and more code needed to deal with and resolve edge cases introduced by the complexity. I can count many times I was handed directives to implement something that I knew was far more complex than it had to be, but because of the pressure to move forward it was virtually impossible to push back. Maybe it's the only way they can make the business case work, but IMO it undoubtedly led to far, far more code than would've been necessary if it were possible to consider problems more carefully and if engineers had more autonomy. In these companies also a lot of time was consumed by meetings trying to "sync up" with the 100 other people moving in one direction.

- Smaller shops, open source projects, or indie development where there isn't a rush to get something out the door. Here, it's possible to think through a problem and come up with a solution that reduces code surface area. This was about solving the largest number of problems with the least amount of complexity. Most of my time at this company was spent thinking through how to solve the problem and considering edge cases and exploratory coding, the actual implementation was really quick to write. It really helped that I had a boss who understood and encouraged this, and we were working on safety critical systems. My boss liked to say "you can't birth a baby in less than 9 months just by adding another woman".

I think most of the difference is in team size. A larger team inherently results in more code to do less, because of the n*(n-1)/2 communication overhead [1].

Recently I learned the Navy SEALs saying "Slow is smooth, smooth is fast" which I feel sums up my experience well.

[1] https://en.wikipedia.org/wiki/The_Mythical_Man-Month

sublinear 2 hours ago | parent [-]

I think your mind might be blown when you discover a third type of environment. It's neither a small shop of yak-shaving idealists, nor a desperate code factory.

The third environment is a large business maintaining services long term. These services do not change in fundamental ways for well over a decade and they make a shit ton of money, yet the requirements never stop changing in subtle ways for the clients. Bugs pop up constantly, but there's more than enough time to fix them the right way as outlined by their contract where expectations have been corrected over the years. There's no choice to do it any other way. The requirements and deadlines are firm. Reliability is the priority.

These are the stable businesses of the broader working world and they're probably what will remain after AI has driven the tech industry into the ground.

jordwest 2 hours ago | parent [-]

The second environment I was describing fits what you’re describing more than “yak shaving idealists”.

We were working on control systems for large industry that had to work reliably and with minimum intervention. A lot of these systems were being renewed but the plant was often 30+ years old. We were also dealing with quite limited hardware.