Here are the top nine lessons I’ve learned over the span of a four-year career in the software industry.
1. Business needs first.
First and foremost lesson.
Maybe it's obvious, but It wasn't for me. You may strive to find an excellent solution and invest substantially more time than needed to make something work, but nobody needs it. Let's say that it's a dying project inside your company. It doesn't make any business sense to invest time and effort into it, but I would do so in the past. I would do the required refactorings to make it clean.
And it was a mistake, because the project did retire eventually.
You need to ask yourself constantly: Is it what business needs from me? Is it the most effective solution from a business standpoint?
2. Master your soft skills.
You need to understand that most of the management doesn't know the product on the code level. Metrics are better, but which one?
You need to bind any metric either to the amount of money your solution can generate, or the amount of money your solution can save.
It is a lingua franca with any business. I bet your boss will see your point.
3. Evaluate your budget, constantly.
Yeah, I know. It is not up to the developer to plan the budget. But you need to understand which amount of money is appropriate for a particular task. If it's unclear to you - ask your boss. He should appreciate such an approach.
Budget is not only your cloud bill. It's also the amount of your working time invested in any task. Keep this in mind.
4. Know that comprehensive tests are overrated.
The testing topic is raised in any company at any project every so often. I concluded that the only tests that you should have - automated ones.
These tests test end-to-end functionality, thus replicating user experience. Design them well and keep them clean.
It’ll also save your company a stockpile of money, depending on what you’re doing. And it will save you a lot of debugging time as well.
5. If you find yourself doing something over and over again - automate it.
It should be automated, whether your code editor chain of actions or your new microservice creation process. This way, you will accelerate the pace of your work and possibly set a hard guideline for your teammates, who will be happy with it eventually.
6. Standardize as much as possible.
It starts from code guidelines. The best practice for me here - adopt linters and adjust them depending on your team's needs.The same goes with Jira tickets creation process, documentation, notifications, new microservices creation, etc.
This way, you make it easy to work for anyone with any part of your project ecosystem because it follows the same rules.
7. Don't be afraid of entirely new technologies.
Don’t underestimate the importance of this advice. I started my career as a backend developer. Then I was forced to work with React and then with AWS.I had to accommodate all of these changes. But now have a pretty comprehensive skill set that allows me to solve problems that others can't.
With this approach, you will be able to switch your career path more easily.
In my experience and the knowledge of many of my colleagues, it's way more efficient to take the proactive approach in salary negotiation and come to management with an offer.
This way, you will be in a position of power and, regardless of the result of negotiations, you will still get your raise.
Depending on the outcome, it will be either your current company or a new one.
9. Dissatisfied? Get another job.
Last, but certainly not least.
You can find yourself to be unhappy with your job for many reasons.
In this scenario, I would advise you to land yourself in some different company.
This way, you will always be growing, instead of suffering in stagnation.
