This post is meant to outline the sad state of software development in some big corporations. Its hard to put numbers but very roughly speaking for every changeset:

• Only 10% of the time is spent in coding the actual meat of the changeset
• 20% of the time is spent on getting compliance with the linter and writing tests. I am not against writing tests as long as they are useful. But here is the sad state of testing I have witnessed. The tests will mock responses of calls made to other services with the result that passing the test doesn’t really tell anything useful – it only tells the code will work correctly subject to the condition that the mocked response matches actual response in production. This condition is often true when the test is written originally but is quickly violated with time (could be within the next day 🙂 as more changesets are made. The test however continues to pass and worse gives a false sense of security and correctness of the code. For this reason I don’t like mocking. Now I know what I have described before is known as unit testing the code and one writes integration tests to test the interface between services. But what happens is enormous emphasis placed on writing the unit tests with 100% code coverage and no integration tests. In such a scenario the tests only serve as a burden with tons of mocks lying everywhere and making the codebase extremely ugly. The tests add no value at all as they only test trivial logic most of the time. Most of the time when there is a bug in production its because the code called an external endpoint and it returned a response not in the format the code was hoping for; and mocking completely hides this problem – again the reason why I don’t like it.
• Rest of the time (70%, sometimes even 90% or more) spent in CR waiting for feedback, getting in long discussions and making unnecessary changes (think as ransom) just to get someone to sign off. I can’t overstate how stressful and annoying this experience is [example]. These people exist in every company and its hard to avoid them [1]. Imagine doing all the hard work to meticulously test the code is working, linter is passing and then someone asking to make unnecessary changes and often expensive rewrites; because of the pressures of time, in the next iteration the developer would not spend as much time testing as they had done earlier. This actually increases chances of bug creeping in in subsequent iterations. There is a simple remedy to fix this problem which is to allow code to be checked in as long as it has one sign off. If more strictness is required, let it be checked in as long as # of sign-offs > # of rejects. This simple policy keeps the developers who like to bully others in check. But chances are the suggestion would be laughed off in a bureaucratic company where the bully developers use fear tactics to brainwash management into instituting a 100% sign off policy when it comes to checking in code. This is followed up with standard lectures on you should talk to X if there is a deadlock, why didn’t you talk/send a mini-RFC before writing the code etc. Of course the author has already talked to X, and X won’t listen. In such an environment the competency for success shifts from being a solid developer to being someone who is adept at dealing with people.
• To top it all off, some people have the bad luck of working under a manager who only sees the time required to write the code and cannot understand (or maybe they do, but they want to put pressure and squeeze you to the last drop) why its taking so long to complete tasks on the sprint board.

If you call yourself an Engineering Leader you owe it to your team not to let above happen in your org. Let Builders Build!