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.
