On HN, people have been asking why is small software corp faster than big software corp in writing code?
From my experience in working in a smaller org to a bigger org, most of it is from the testing, design and review culture.
Landing a commit in Small Corp
In small corp code review, I just grabbed a person to look over my code for 5 minutes, put their name in the commit as the reviewer, and then pushed after manually running some tests on my end. It would be rare that they would bring up objections. Doing large 1000 line commits would not be much of a problem.
There are no commit hooks. What prevents me from breaking stuff is not want to bug everyone else while master is red and the CI build breaks. At small corp, the amount of people was 2->10 people over several years.
A manual QA testing team would test a release branch cut a few weeks later.
Landing a commit in Big Corp
In big corp code review, everything builds & runs slower because the size of the codebase is significantly bigger. Then once I’m done my commit, I upload it to the code review system. That executes a bunch of pre-commit lints and tests, which I may break and have to fix. Once all of that passes, it uploads.
Once the commit is uploaded, a whole bunch of blocking reviewers get added automatically, the CI system starts building it and so on. I also need at least one person to approve my commit before it lands. People in big corp are significantly more picky about what you write in your code, and often there are quite a few revisions before I land. The stakeholder interaction count goes way up. If my commit is large, I would often be asked to break it up or the likelihood that people ignore it goes up. Stuff has to be cut up into small pre-chewed chunks.
Sometimes if stuff is controversial with one team, it can take a week or three for any specific diff to land, along with some face to face meetings to resolve the conflict.
Once my diff is approved. I submit it to a landing queue, which runs more tests. The landing queue is necessary because the rate of things being committed to the monorepo. If these more extensive tests fail or some sort of merge occurs, I have to fix the diff again and then submit again.
Now my commit has landed.
Overall the largest amount of time spent is writing the code and getting it approved.
Corporations are like Buildings
The way I like to explain it is the bigger a building gets, the more support infrastructure and ‘walking time’ is required to accomplish things. More and more floor space becomes devoted to hallways, stairways, elevators, HVAC systems, bathrooms and so on. After a certain building height, you get a phase change and it’s mandatory to start using steel and concrete vs. wood, which increases costs and time of building. Eventually you need to make a campus.
While a wooden studio apartment is very efficient to walk around in and cheap to make, you can’t put much in it. Same with tents. A large highrise can have all sorts of cool stuff in it along with nice views, and the concrete helps in suppressing noise from your neighbors.
Even More Stuff to do at Big Corp
There is also a bunch of other stuff that I haven’t mentioned that happens in big corp. Such as engineering design docs to alert everyone of a big change. That can take a week or two. Needing to sync with more stakeholders. The fact you have to ping people to do code review because everyone is busy and it’s an async process. A planning process that can take a week or two every 6 months. Performance reviews that can also take another weeks worth of work because you need a documented promotion process and so on.
I didn’t have to do any of that in small corp. It was significantly more casual, and the only team that maybe did planning work was a small team of designers that made the visual design of new app features. I didn’t have 1:1s in small corp, neither did I have a performance review process or work planning process. I just asked for a raise, talked about it for an hour with my manager and I got it mostly because I said I could get paid more elsewhere. Career development wasn’t much of a thing at all.
Now that may sound great from your perspective. But it also meant that there was little feedback given to me on how to improve as a software engineer, what my weak spots were, or if we should even be doing what we were doing. There is value in the design process, talking with my colleagues and my manager.
This design & planning process isn’t a waterfall process although. The plans often change as time goes on, and design docs are in an outline nature. Often many things don’t go through the design doc process, only larger projects that could effect a lot of people.
Don’t let that Scare you from Big Corp
Overall I like working in big corp vs small corp. There is a lot more thought and ‘engineering’ that goes into things. The expected pay outcome is significantly better than the lottery ticket that is most small corp startups. Work life balance tends to be better, and overall interestingness of the work is higher. There are entire categories of work that you can’t do at a startup that you can do at Big Corp. In small corp one of my major frustrations was a lack of ability to work on more foundational or infrastructural things, because the project you’re working at could literally be gone tomorrow.
People who complain that software engineers fly by the seat of their pants don’t quite realize that the price is not being nearly as ‘productive’ from a lines of code standpoint as you work on a far more heavyweight design, testing and review process. Space shuttle levels of quality in software costs a lot of time, and most businesses do not want to pay the price.