Alt + Control

my rants on programming, software development, etc.

Work Environment

| Comments

Disclaimer: I work in India. So my opinions and perceptions are solely based on socio, cultural, economic relations of Indian software industry. Needless to say, your mileage may vary.

I have started my career in 2008. And ever since “workplace environment” or “culture” is always a fascinating topic to me. In these close to 8 years, i have changed five companies. I have seen caustic environments to more developer friendly environments - a full spectrum.

Having said that, my experience made me form certain opinions regarding the workplace or culture. Here is my ideal working environment should be,


  • A team member should be given emotional safety net to speak the truth about project without resorting to ad-hominem attacks.
  • Some kind of code of conduct policy.
  • Arguments in a team are healthy and good indicator of functioning of a team.
  • A Benevolent Dictator of Life - BDFL to resolve ambiguities in code, technical decisions.


  • Joel score of minimum 10.
  • Code formatter tools - Since i work in python we genreally flake8 and importanize tools. You can find formatting tool for your favourite language.
  • Continuous integration is a must and Continuous delivery is being optional since it is a business decision.
  • No tautological unit test cases. The problem with unit test cases is when you introduce the mocking framework, programmers tend to write unit test case for each and every function which leads to they becoming tautological with overuse of mocks in the code.
  • It is very easy and good to implement unit test cases for a library, but for an application which contains and uses various libraries, I gravitate more towards integration test cases.But these take lot of time. Like everything in a project, you make these part of your schedule.

Code Review

  • I am against two level code review process, because the earlier caught the bug or change in design, the better for all stakeholders. One level of review process but with very good reviewer.
  • Some kind of mention-bot to assign the PR to a reviewer.


  • Enough build machines to press the build button and quickly get the feedback. I don’t understand the fetish to build locally, raise a PR once all test cases pass on local. These days, computing power is cheap, programmers are costly. So it is always good to raise early PR and start building it. Ofcourse, this does not mean we encourage sloppy coding.