From Dev to Prod

Once a dev guy and now a product dude.

I studied computer science and started my professional life as a developer, coding for a long time. Every developer, even a junior, knows the basic fundamentals of solid development, basics like encapsulation, reuse, language best practice etc.

Since I began paying attention to product aspects when designing and planning, I noticed that even though it’s the first time I was doing the whole process, for some reason i felt quite familiar with the process of thinking and working from this vantage point.

These are my main development basics, which have become valuable in all around product management.

Encapsulation : (information hiding)

Encapsulation in development is when a piece of code shares only information that the coder decided that will be visible (and usable) for other pieces of code, meaning that it can do a lot of things but only give the relevant data to the code that asked for it, hiding from the rest.

When planning a feature, I find myself starting with many elements for interaction with the user. Throughout the thought and design process, I remove more and more elements, finding the most accurate and minimal set of elements that the user will understand and will help him in completing the flows.

While doing this process over and over, it struck me that I can use the same patterns of coding I used in the past for encapsulation, like starting with many functions and then combining them together for clearer and more direct responses for who ever called them.

Reuse:

Code tends to get bloated overtime. This is why we try to make everything reusable. When I read my code, if I can find similarities among parts, I try to merge them into one piece of code that can handle calls from different parts of the code.

When I design a feature, I look into the design I already have. The user will feel comfortable using a product that has the same style across features. Familiarity is important and makes the user feel comfortable along the way. It also makes the design easier ☺.

Abstraction:

“An abstraction denotes
the essential characteristics of an object that distinguish it from all
other kinds of object and thus provide crisply defined conceptual
boundaries, relative to the perspective of the viewer.”

— G. Booch,
Object-Oriented Design With Applications, Benjamin/Cummings, Menlo
Park, California, 1991.

For me, the design guideline are kind of an Abstraction layer. There is set of characteristics that are valuable for the whole product design. Other parts or extensions of the product will use it as well, and the design boundaries and red lines will be defined by the guidelines.

Inheritance:

I’ll make it simple for the those who don't code, here’s a simple explanation of what inheritance is as a concept. Think about a car. A car is a vehicle. It has wheels, windows, a steering wheel and doors. Most vehicles have those characteristics but not all are cars… a tractor can have more wheels and no windows, but we know its still a vehicle.

We can say that the lowest common denominator tractor and a car have in common is a steering wheel.

That’s inheritance; using same common features but allowing dividends for specific ones.

The same can be applied with thinking about design and styling. They all have common grounds that I have and need to use, like colours and fonts. But every part (feature) can also have specific characteristics like size, position shapes etc.

Polymorphism:

This is a pure concept for development, meaning defining an object that is not type aware, leaving implementation for objects that want to implement that object. In other words, an apple and a banana are both fruits but can be eaten differently. One has to be peeled first (I hope you peel it as well).

When planning a part of something I often use the same design but with different flows. In doing that I keep the user familiar with the new process although it’s a different one. A real life example is using animation effects for sliding up and down with a bar or header. Even the smallest animation can be annoying and when having multiple animations on the same place. The user can get really annoyed and confused. So what I do is use the same animation styling all over, which is like keeping the same effect or marinating the same speed for all animations.

If the user is not annoyed with the first animation he will probably accept all others as a part of the flow. He or she will recognize the animations as a part of the process and the whole experience.

mmm…

All of these basics represent some of the principles of OOP (Object Oriented Programming). Shifting to the dark side of the product revealed to me that I was somehow ready to handle those aspects more than I thought.

The way I work every day is defined by this way of thinking. In essence, this is the way i operated for years.