As engineers, we continuously aim for perfection. The drive to deliver the perfect product sometimes defines how good we are as engineers. We often discuss and fine tune the term and the essence of our product’s perfection. Some claim that a perfect product is one that handles all the edge cases, works flawlessly, and can do everything. Others assert that the perfect product is the one that is simply ‘good enough’ for the customer, as it delivers what the customer wants and needs and doesn’t invest time in irrelevant esoteric features. But what about the road to building your perfect product? Shouldn’t that be perfected as well? Sometimes we don’t really invest in how we create those perfect products and how we write those amazing pieces of code.

Customer first

There’s no doubt that the top priority you should consider when writing your code or developing your product is, without a doubt, your customer. Your product is developed for someone and that someone might be your customer who is willing to pay for it, a whole community of people who will use it without cost, or even only for yourself. You will do anything to deliver the best product possible to your customers. 

This means that when you consider each step in the development process, the top priority that should be on your mind is your customer. But what about you? Are you thinking about yourself? Do you consider yourself a priority in the development process? Well, probably not. You don’t matter as much because the customer is the most important element to consider. Because, well, you know, “customer first”. Let’s take a step back, though. Is this really the case? Do you and your team only need a laptop and an endless supply of coffee? Or maybe is it time to start thinking about yourself too and where you (yes, you, looking at you) fit into this process and actually, dare I say, improve it?

Do it for the customer

Whenever I want to spend money on a new tool for my team and me, I need to explain to myself (and of course, my CEO as well) why I need to spend the money. After all, the customer is first, and we already spent a good amount of money on the must haves for creating a great product: the newest Macbooks, the Jura (see it below in all its glory in our new offices) and the freshest coffee beans. After all, we’re not building software for the sake of building software and for the sake of adopting the coolest newest tools. No, we’re building software to sell it and to change how developers work. So why do we need to invest in a new tool? Why spend a lot of money on a new APM? Why shell out thousands of dollars for that top of the line IDE when I can use VIM? 

As far as I see it, the answer is pretty simple and it returns to the “Customer First” idiom. We need to invest that money, not for ourselves, not for the employees, not for security, but rather we need to invest that money (and time) for the customer. Yes, you read that right. Invest in yourself, for the customer. Because the more you invest in yourself, the better you are, and ultimately the customer will receive more. So yes, go out and live your best life.

What’s good enough for the customer?

We are no longer in the era of “fire and forget” product delivery. When a customer chooses your product, he isn’t just choosing to use your product, but rather he is also choosing you. When you buy a smartphone, you don’t just buy it and forget about the vendor. You buy that smartphone because you also consider the support, the user community, future software upgrades, security updates, the application store, and the entire ecosystem behind it. Sometimes, this is why you’re okay with paying more because you know that the vendor will keep delivering for you. 

This is the first and most important reason as to why you should invest in your own processes and your own tools. You do it not just because you create awesome products, but because your customer expects that you will keep on delivering. 

When you or your manager ask yourself, “Should I really be investing time and money on a new tool?” or “Shouldn’t I be investing time in a new feature for the customer?”, try to imagine how your customer will react when you’ll be explaining to them how you will improve the quality and velocity of your product delivery. Will your customer appreciate the improvement of the process?

Starting from scratch or creating a relationship

If you are yet to release a product and don’t have any customers, then I’m guessing that you probably think I’ve been speaking nonsense up until here. Thinking that you need to push forward as hard as you can while ignoring the road there might be a good strategy for the short term. However, if you’re using the wrong tools – or not using tools at all – then you might be creating a great technical debt. This can mean that once you have a customer and you won’t meet their expectations, there’s a chance they say farewell sooner than expected. 

Additionally, when looking at the long term, since you do want to ultimately deliver a product to your customers, the one thing that you don’t want -and can’t afford – to lose on the way is your developers. Using the wrong tools can cause fatigue and frustration among your team and you might find yourself without a team before you can even deliver. Don’t think about investing in the best logging service or the best debugging tool as for your employees, but rather as how you’ll be investing in it for your customer. This is because you want your employees to deliver the best product that they can and be as productive as they can for your customer.

Treat yourself for a better road

At Rookout, we have invested a significant amount of time into making our product as easy to integrate and use as possible. We aim for our customers to use our data collection and debugging tools as part of their daily routine. We tried to make our UX as familiar as possible for developers so that diving into a debug session will be a breeze. Yet, when our users hear about “remote debugging” and “production real time debugging”, they sometimes take a step back. Their first response is either “I don’t have the time or focus to learn something new” or “I’ll just add logs or ssh into that machine”. But, does your customer really want you to be SSHing into a production machine? Even more so, are you even allowed to do that? Does your customer appreciate the fact that you won’t be able to collect logs and find a bug while you have a code freeze? So we have just the solution: invest in yourself. Treat yourself to some magical debugging tools. Trust me, your customers will appreciate the results.

You’re not alone

Adopting new technologies, new methods, and new habits is quite difficult. No wonder weight watchers and other support groups exist. It is hard to make a change and you need people around you for support. Adding an open-source tool to your workflow is similar. When you add an open source tool into your toolbox, you’ll have the open source community to help you out (pending availability, popularity, and even how different your environment is from other peoples’). 

At Rookout, we believe that the path to the perfect product is just as important in the product itself. That’s why we have invested a lot of time in both our documentation and our detailed deployment examples so that the journey to using our platform doesn’t have to feel like that. But if you’re having trouble adopting our tools, please remember that there’s a team of engineers that are more than happy to assist you. We know that trying something new is sometimes challenging – and just a tad bit scary – and we’re here to help out. Ping us on support@rookout.com or even use our app’s built-in chat.