Some thoughts on Software Engineering

Picture credit:

I wrote down some quick thoughts on Software Engineering, to make some points at work! Took only half hour to write, so may not be very well formed opinions.

1. Separation of people and code!

Its never a good idea to identify a task or module with a person. There may be someone who started working on a module, but once checked into github, code belongs to the team. Everyone should free feel to improve and run any module.

One easy way to make this transition, is to give up personalizing code. Instead of saying, “give this json to person A”, we can say, “module X should consume this json”.

This separation of people and code will mean, no one person will be burdened with one task. Team will not be blocked by one person’s availability and work load. Besides, best way to learn new things is to run and improve other’s code.

2. Diversity of skills

Irrespective of one’s career goals, diversity of skills is important. From ML, to annotations, to UI, to soft skills (presentations, talks), everyone should try everything. Being stuck to a module and doing the same thing again and again, doesn’t help.

  • If one wants to be a Researcher, being able to whip up a UI, might make one’s work get noticed. So don’t just learn ML, learn UI too.
  • If one wants to be a senior Engineer, he/she is expected to lead the whole team, not just one module.
  • If one wants to be a Manager, one should know enough about each module, to evaluate options.

3. Engineers are supposed to be lazy.

We should never manually do something that can be programmed. We should never code anything without designing. UI being a tremendous time sink should never be coded without first drawing it on paper or blackboard. Computer Science is very much about optimization. Optimizing our own time is paramount.

And using a unix machine (linux/mac) and mastering git/vim/sed/awk, saves so much time that often, the only difference between a newbie and experienced engineer, is a working knowledge of git and vim!

4. But beware of premature and unnecessary optimization.

Premature optimization delays projects. We may not need an API when a flash app is enough. And some kind of optimizations are never needed. For example, we should never need hot-swap in a research project. One time tasks need not be programmed.

5. Say No.

Saying “No!” is a very important responsibility. No one can do anything “in parallel”. Engineering and Research involve Thinking and focus. Its always better to work on one task at hand, take it to the next checkpoint and then take up other things. When Engineers say “No” to task n+1 because they already have n tasks in their priority queue, it helps teams to set right expectations. Work can be more fairly divided. Deadlines won’t be missed.

6. Feature creep kills projects.

Features should be decided early on in the project. Once a deadline is set and work has started, team should ruthlessly refuse to take up any more features. A well made working version of a project is always better than a composition of poorly developed features. Refer to the picture above.

Blog at

Up ↑