How Skcript Stays Up: Development

TL;DR: The etiquette we follow to product top notch products

Karthik Kamalakannan
Sudo vs Root

--

This post is a part of Development, Deployment, Monitoring and On-Call (DDMO) series of posts from our Engineering team. Please feel free to follow the entire series here.

Building an idea and taking it to production is more than just opening up your favorite IDE and start coding or fix a bunch of bugs. There’s lot more to that. In this series, we will expose some of the techniques that our engineers use internally to produce quality products. The first phase that we would like to discuss about, is Development.

Our Development Techniques

At Skcript, we adopt some of the most efficient techniques during development to keep ourselves away from stress and enjoy every binary bit we are transferring to the computer. Here are some of the primary goals for us when we develop a product:

  • Maintain code quality like never before
  • The workflow has to be simple
  • Very minimal amount of status reports or reporting
  • Stress free

Keeping those goals in mind, here’s how we achieve it:

Pair Programming

There’s been a lot of debate around Pair Programming lately. Some developers love the idea, but some hate it. At Skcript, we are lucky to work with engineers who are on the same mindset to collaboratively code at our HQ. A lot of times, we pair program. And to be honest, that’s when a lot of quality code has happened. Here’s what we achieved when we pair program:

  • Top notch code quality
  • Super fun playing around with variables — Which in turn reduces stress
  • Lot of different ideas come up, reducing the amount of time we spend explaining the workflow of a particular feature

When solo programming, we get it reviewed

Sometimes, when we are deep into working on a feature that we love, we solo program. That’s when we get all our senses together and concentrate on writing the best code. But, to make sure we write the highest quality code, we get it reviewed with our very simple Git workflow.

Using Git for maintaining Code Quality

Since every single engineer is expected to meet a very high code quality, we were in search for a tool that could help us achieve that. But we never found anything more appealing than Github (We love Github like nothing else). Here’s how to use Github to maintain our code quality:

1. A descriptive commit message

Every single commit to our own fork will have a very descriptive commit message. This allows the other engineers to understand the commit better and go through the code and suggest some changes if necessary.

2. Reviews happen line-by-line

Maintaining code quality requires checks to be done on every single line in a diff. We take advantage of the comments in diff feature on Github to review the code. Just to make sure that we have a record of what is going on in that line. Sometimes, the entire team comes up to make sure only the best code is pushed to the master and works better than we expected.

3. Managing Branches

Though branches are considered to be the most important and useful feature of Git, for some weird reason, we are not big fans of maintaining build versions in branches. Instead, whenever there is a code version that we have to test out in staging, we have our own little servers running right inside our office, which helps us validate builds and run other checks. We think this is very important since the servers are always up to date and resemble the production environment very very closely. We have found this method (though its a bit time consuming) to be much more useful than managing branches and checking builds for bugs.

4. Maintaining very clean commit history

This practice has helped us a lot in the past and it is still one of the best things our engineers do. All our commit messages are descriptive and ultimately, this helps us generate release notes very easily every single week.

Our Git Commit Workflow

Since the beginning, we have been using Sandofsky’s Git Workflow throughout the company for code versioning. If you are interested in knowing more about the very simple and clean Git workflow, this is the place you should be heading to.

Next up

While this is a very quick overview of our development process, next up, we will be looking at our quick and easy deployment process we use to manage our servers across the world.

Originally published at blog.skcript.com.

--

--

Karthik Kamalakannan
Sudo vs Root

Co-founder & CEO of @SkcriptHQ. Building Hellonext.co. I write about building a bootstrapped SaaS business.