I always look at products as icebergs: the end user only gets to see 1/10 of it, while the bulk is buried deep down. And, while the process of creating a product is a journey that starts with an idea and ends with a useful tool, it has different stops along the way that forge the product. On a high level, these stops include planning, researching, designing, building, testing, and deploying.
As a software engineer with a messy brain, it was hard for me when I landed my first job 7 months ago to plan turning the design frames into actual code by myself. The reason for that was far off from being technical. You see, when your brain connects 3 million things together and jumps from one place to another, it is very easy to get consumed in all the details of the design and the flow. Not to mention the intricacies of connecting your back-end code to your front-end code and how to deliver a product that looks exactly like the designs while, ultimately, finding a way to solve the technical problem behind a product at the same time.
For me, the process has always been exciting no matter how scary it seemed at first. Just like turning on a flashlight in a dark room and slowly starting to explore every corner, the past 7 months have taught me how to build a product from design and develop it smoothly and optimally.
Here are the most important things I learned:
You might think that you are an engineer or a developer and all you need to do is just write your "hello world" lines and you will be done for the day, but this is beyond wrong. A part of being a good engineer is finding the best solution that will meet the users' needs; and trust me there is no way you will be able to do that if you do not understand what problem you are trying to solve and what the product is actually about.
Picture this, a client comes with a problem they are trying to solve. As an engineer, the first thing your mind will do when discussing the solution will be how to technically implement it. But by doing so, you are answering “How can we build the product?” and completely ignoring the most important question: “Why are we building this product?”
No matter how overwhelming the problem is, the smaller you break it down to, the easier it is to fix. So when you have a big feature to implement, break down all its small components, work around them and then connect them together. Divide and conquer :)
Especially if you are adapting Agile methodology. One of the biggest mistakes you can make when you are adapting Agile is misunderstanding its flexibility. Teams may get in the loophole of shuffling tasks around, that at the end of a sprint the outcomes are not as satisfying as they had expected.
It is very important to have a structure to work with. This, of course, does not mean you have to create a strict schedule (which leads me to my 4th lesson). Rather, outline your important features, and the big picture, and draw your path into completing the product.
As an engineer, whose mind sparks when I see an opportunity to be creative, I was always scared that I will land a job where I have a list of tasks to do without having enough space to express my creativity. Luckily, both the jobs that I have had so far gave me enough space to be creative. But along the way, I realized how important it is to find a balance between managing a project, and trying to be creative at the same time.
When you have freedom to develop, and input on design and the UX, your mind can really drift away to la la land. Just as having a rigid strict plan you need to follow is bad because it can kill creativity, ignoring project management and trying to reach la la land can also be bad. Just like the way you have to find a life-work balance and mind-heart balance, you need to find your creative-management balance at work.
Have you ever taken the wrong bus and then midway you realized you are heading in the wrong direction? Of course, you are going to have to go all the way back and compensate the time you wasted. This is what you will feel like when you start off without doing your research first.
This important piece should be considered within your planning. Before you start working on a project, you need to research which technologies and languages you are going to use. This will help you to not only build solid products, but it will also give you a better understanding of what to expect.
I know this might sound like a cheesy tip, but whenever you are drawing your deadlines, always leave a couple of days as a buffer in case something goes wrong because you do not know what might.