Product Engineers: It’s a thing

Are you a computer engineer? Do you fancy your code should look like an art? Do you think complex systems should be built? Do you think everything should go through process? If answers to all the above questions is, YES!, then you should definitely read ahead.

There are two types of engineers and you can be both, Batman also has two personalities:

  1. There are engineers who solve really hard engineering problems like., developing a new programming language, security protocols etc.
  2. There are others who build things with available resources.

Why this classification? Because it defines the expectations and priorities. If you are working at a company then you are being paid for the knowledge you have to build things that make company successful and as much quickly as possible. Your prioritisation decides will the company achieve what it needs and how quickly.

Now what does your company do? The chances are it is building products/services for people to consume. People who doesn’t know your “technology”. The success means for such a company is to win the market and be the sole provider of the product and service. And building things takes time, hence the idea of hacking or hackjob or jugaad. That’s what product engineers do.

Product engineers make things that work as fast as possible because the end goal is not the engineering but the product. A product that works. The user does not care about the complexity of the engineering. It can awe them but primarily, it should work like it is supposed to. It is the engineer’s job to make sure of that.

Product engineers solve engineering problems when the uptick for business is greater than the time spent in dealing with it.

Won’t it lead to mess? It will. Deal with it. No, I am not just brushing this problem off. I have a solution for this.

Whenever there is a lean time solve this problem. Organise everything. This is an iterative process. This strategy must sound like getting stuck in loop and yes, team will get slowed down over-time. Take some time out when it is absolutely required like too many errors happening, code maintenance has become a real issue, it is taking longer to do a five minute hack-job. Because it must be understood that the goal is different. Goal is to make the product win, right now.

Product Development: Design is more important than you think

Programming is just another tool like hammer or plier the only difference is that lot of it is mental while lot of work with hammer is physical. But this doesn’t mean that we should be using U-shaped hammer, that would be really stupid. The reason behind the design of the hammer is Force that can be produced by swinging it and it doesn’t require complexity, a simple piece of wood and iron head works. Programming should also be like that, having reasonable design.

Design is not abstract. It also has rules, just not as clear to everyone.

In my early days, projects used to have messy programs but nevertheless they would just work fine. A function here and a function there with arbitrary code inside them that would just work. At that time, goal wasn’t writing the best program but to make the project work. The feeling that I have built something. As I have practiced more and more and built something for longer term made me realise that program should also have design. It should be simple and follow a pattern.

Patterns are like musical notes, once you get hold of few you can imagine what can come next.

See the picture at the top, that’s what most programs look like. We all write something which ends up looking like that. Functions getting called and written at arbitrary places, passing data and modifying at unknown places and sometimes there is a legacy code which just doesn’t let you write improved version because it’s just too much work. Hence, design is important. In programming, it is called design pattern.

Design pattern helps in structuring of code in such a way that if you know how one piece of the code works, rest can be figured out. They are inspired by real-life structures and manufacturing system. Visualising code as a physical system is of great help as brain can easily consume the information and can draw parallels. Design patterns are available for all languages (google “<language> design pattern”).

The other paradigm of programming is anti-pattern. Anti-pattern is a solution that seems to be working but is counter-productive. When working on a solution like this, it can be perceived that the solution can be easily implemented but when approached it becomes highly complex, confusing and probably inefficient. A programmer must study both aspects of the programming language, not only will this help in writing better code but in framing better solutions. The complexity of solution is often related to the design we have in our head and having structured thoughts leads to better and quick implementation.

The other reason why our programs should have a good design is the cost of maintenance. It may seem like that the cost of writing code that works is less but over the period it will end up costing more. Once there is a bad code in the system, it will continuously need fixes and rework which ends up costing more than it would have otherwise. The cost is not only money but time as well, which is far more important. But you should not go to the other extreme as well and write the great code because making it perfect is nearly impossible, it will always have shortcomings. A good code is which anyone can read and doesn’t require frequent maintenance.

To read more: Source making or Design Patterns by gang of four for languages like C++, Java, Python etc.