DEV Community

Cover image for Do not reinvent the wheel
Conti for Product Hackers

Posted on • Edited on • Originally published at avelasco.dev

Do not reinvent the wheel

There are times when you feel like a god because you think you can build anything, technically speaking, and sometimes you feel useless because the product owner needs you to find a solution for a specific problem and, instead of using an already mature and developed third-party product, you find yourself in your own development roadmap for a similar tool, built from zero. So your frustration grows because you think you have the skills to build that solution, but delivery timing would be out of question since the value needs to be delivered the following week.

As a developer your lines of code value is null, the real value is in the mental process where you imagine and chain those lines of code to approach and solve that problem.

does the approach need new lines of code in your project? Good, have you estimated the hours needed and the cost of them? also good? Do it or not.

is it possible to integrate a third-party tool to solve? Good, is it too expensive and it's better to develop it in-house? also good? Do it or not.

I just want you to be able to view out of the box and try to avoid thinking in the lines of code you are going to type while the Product Owner is talking about the issue itself.

Need examples? Let's go.

Controlling the DOM

Control your DOM
Your product team needs a way to manage (adding/removing) third-party scripts on the site to avoid adding issues to JIRA and going through the whole CI/CD process. Give them Google Tag Manager, train the people who are going to manage it, setup a solid permission scheme, and not also you gave them power and a solution, but you positioned yourself as a reliable problem solver that is able to look above the keyboard.

Growth teams use experimentation as a tool to validate hypothesis to a problem they need to solve, and most of the the experiments needs to be deployed within the apps/site. You would lose almost you whole productivity if every experiment had to go through the whole CI/CD process. You can show them Google Optimize or Optimizely to allow them to experiment without interrupting the development workflow.

Delivering

CI/CD Deliver
I can build you a CI/CD Pipeline using AWS Code Deploy and Pipeline, linked to a cluster of machines behind an ELB, with auto rotation for them, highly monitored in Cloudwatch, bla bla bla... I really can do that, but is it necessary to overkill every approach with that?

We already have teams of developers around the world that belong to product teams such as Vercel, which is very curated and mature. Give those colleagues some slack, investigate those kind of products before onboarding into an endeavour you do not know you would come back safe and sound.

Building

Building
Do you have the resources to build a Magento or Prestashop from the ground? Think it twice please, perhaps you should try services such Shopify in the first attempt. I am not saying that M&P are bad solutions, I am saying that you need people behind those platforms to maintain and develop them properly.

Need a landing page for your product that is going to last one month? Try tools such as Webflow. Time and resources to build a very good HTML and CSS are not free,
your front-end expert would be the one reviewing the job done by other person with that tool instead of being the person building the landing page from zero.

Do you want to validate an idea using a mobile app? Right now there are several services to build them without coding, such as Glide. I know, I know, a native app is going to be perfect every time from here to Mars, but I am testing with that MVP if I need to hire, or not, a true expert.

Automations

Automations
Tired of build lambdas, api gateway endpoints, webhooks, listeners... to allow users enjoy your automations? Show them and let them play with automations in Zapier, Make and Twilio. Your job here is to apply a reliable security policy when using credentials/oauth to avoid misuse within the automations.

This has been a small batch of posible third parties that could lead to you reach your goal or validate ideas faster, without using nor interrupting your main work force.

Images attributions:
Business graph photo created by jannoon028 - www.freepik.com
Volume button vector created by upklyak - www.freepik.com
Covid delivery photo created by freepik - www.freepik.com
Joiner photo created by jcomp - www.freepik.com
Ai brain photo created by rawpixel.com - www.freepik.com

Top comments (2)

Collapse
 
jonrandy profile image
Jon Randy πŸŽ–οΈ

I disagree. It really depends on the situation.

Not everything has to be a product, not everything has to be finished, not everything needs to be useful.

Sometimes there is nothing more interesting than reinventing the wheel. You get to learn all about the subject in detail, understand how stuff works, and maybe even find a way to make a much better wheel.

Programming can be an end in itself, there doesn't necessarily need to be a goal. Without wheel reinvention, we'd still be stuck with the crappiest wheel in existence.

Collapse
 
conti profile image
Conti

I do agree on your disagreement, the situation itself leads you to different approaches.

In my daily basis I build "disposal" code that is used to validate ideas or hypothesis, which lives at max for one month, and programming it is not the goal but the transport to accept or discard approaches.

Big part of that "disposal" code can be done by using third-parties, and those third-parties can be used by non-tech colleagues to accelerate the process of validation. These situation allow us (devs) to focus in even bigger and complex "disposal" code where the real value is.

Although our workflow is far from the classic development approach, I am happy to be living the experimentation since it forces you to be more time-efficient.