#culture
5 posts

Staging environments are too important to be overlooked: here's why

Staging environments can reduce the errors occurring due to unmet dependencies. They reduce the impact or number of errors in your product and result in indirect cost savings.
Read more

Staging environments are too important to be overlooked: here's why

  • Data sets tested locally are usually an unrealistic representation of what is in production and can expose users to potentially breaking changes.
  • Staging environments can reduce the errors occurring due to unmet dependencies.
  • They reduce the chances of incorrectly merged changes getting deployed to production and save you from potentially rolling changes back or hotfixes.
  • They reduce the impact or number of errors in your product and result in indirect cost savings.
  • Using staging environments can result in a higher degree of quality assurance.

Full post here, 7 mins read

Prototyping vs. production development: how to avoid creating a monster

The ability to rapidly iterate, receive quick feedback, and keep costs relatively low are the three main priorities during the prototype phase. In the production phase, it is all about keeping the user, their needs and their environment in mind.
Read more

Prototyping vs. production development: how to avoid creating a monster

  • The ability to rapidly iterate, receive quick feedback, and keep costs relatively low are the three main priorities during the prototype phase.
  • Even in the prototype phase, write tests for vital pieces of code.
  • If your prototype starts turning too buggy, slow down and tighten your code. If you are constantly missing deadlines, simplify your code to improve the pace.
  • In the production phase, it is all about keeping the user, their needs and their environment in mind.
  • Users want products to be flawless and fast. Have well-defined code standards, review processes, and quality assurance testing process.
  • Be thorough with your documentation if you don’t want considerable code rewrites.

Full post here, 16 mins read

How Shopify scales up its development teams

When scaling up development teams, the first folks to recruit are the recruiters themselves - specialists who understand the company culture & team’s exact needs.
Read more

How Shopify scales up its development teams

  • When scaling up development teams, the first folks to recruit are the recruiters themselves - specialists who understand the company culture & team’s exact needs.
  • The number of on-boarded folks on any team is greater than or equal to the number of those still onboarding to ensure enough market & product context.
  • Set a clear baseline for teams about how they will plan their work and track their progress, what are the tools and technologies they will use etc.
  • Be very open about technical designs and code changes
  • Use tooling to codify best practices
  • Use pair-programming to share experiences
  • Conduct frequent retrospectives

Check out the full post here.

7 min read

Programmer’s discipline

Programmers face inherent challenges of programming - ambiguity, complexity, integration, and paradox - while building solutions for hard problems.
Read more

Programmer’s discipline

Full original post here

Sidu Ponnapa has spent much of his career scaling the 'people side of tech'. He has helped seed and scale GojekTech from 1 million to 10 billion GMV in the last 4 years. In this post, Sidu expounds on how can team leaders & decision-makers bounce off programmers’ discipline to build & scale effective organizations. Programming is inherently difficult. Programmers face inherent challenges of programming - ambiguity, complexity, integration, and paradox - while building solutions for hard problems.

To reduce the difficulty of problems, programmers break things down into ‘systems’, and define how they engage with these systems through ‘disciplines’. Many of these disciplines are a perfect fit when dealing with the problems inherent in scaling businesses. Because all competent programmers are experienced at designing, building and running large, complex systems, they are excellent sounding boards when developing non-tech systems.

8 min read

Pairing vs. Code Review: Comparing Developer Cultures

In pairing, everybody on the team gets better together because of constant communication. In teams that follow the practice of code review, there is a motivating pressure to perform well for the review.
Read more

Pairing vs. Code Review: Comparing Developer Cultures

Full original post

This post was written by Paul Hinze 6 years ago when he changed jobs and transitioned from a dev culture of pair programming to that of peer code review. He shares a balanced perspective on both these practices.

In pairing, everybody on the team gets better together because of constant communication. Junior developers can be trained easily by giving them an experienced pair; best practices, knowledge, new tools, and techniques spread naturally & quickly across the team. It is not all sunshine and rainbows with pairing though. It can lead to over-diluting core talent which can kill both productivity and morale. When it comes to tackling the larger problems of system design and architecture, that require more deep thought or creativity, pairing can be detrimental to progress.

In teams that follow the practice of code review, there is a motivating pressure to perform well for the review. There are no barriers to take on deep thought problems. As code reviews are asynchronous, there is a lot of work schedule flexibility. Code reviews can be strategically distributed to ensure that more experienced developers always touch certain kinds of code reviews which provide additional quality control and protection against bugs landing in production. However, in teams with code review processes, you can feel lonely, zone out for long periods and run late on deadlines. If code reviews are not done with a tight cadence, they can become bottlenecks

10 mins read