This is the first time I’ve worked full-time for a whole year and I thought to make it a reflection point in my career. I always thought that I will land a job at a company with established best practices on their development processes. However, so far I have not had that luck but that means there is a lot I have learnt along the way.
- Be the change that you want to see
There is no reason that the desired company culture shouldn’t start with you. Start writing the tests and setting up build tools on your assigned projects. Be visible and vocal about what you are doing and others will pick up on it. You get to sell your designed change by demonstrating the benefits first hand.
- Change requires support from management
As much as you get the buy-in from your colleagues, if management does not see and acknowledge the value in your proposal then your efforts will be moot. Something being best practice in the industry is not enough reason to adopt it. Especially when what you are proposing does not have a “direct” business value, you might get some resistance. You need to back up your proposal with research to get the sign-off.
- Technical debt should be part of team deliverables
“We will fix it better when things cool down”. One of the biggest lies we tell ourselves on projects. Then the codebase has some weird patch that can’t be touched without breaking the build and no one knows why. Take time to clean up that patchy code so that it does not becomes tomorrow’s problem.
Incremental upgrades are better than huge batch upgrades. Don’t wait until the tools you use are reaching their End of Life deadline to upgrade them. Using stable latest versions of a framework or libraries can also lead to better developer happiness which translates to better productivity.
- Contextual internal documentation is important
A lot of contextual information about a project/codebase can be lost if it’s only kept in the mind. Document the not-so-obvious and context specific content. This creates a reference point for future and also on-boarding new people. It’s also critical to document this stuff when it’s fresh in the mind otherwise it is lost when it becomes obvious.
- Documentation makes sense when it is visible and utilized
Sharing links to the documentation makes it visible and people are more likely to utilize the knowledge hub. People get to know where to go if it’s an already solved problem. This also applies to customer support interactions for your products. Sharing a link to the help section that solves their problem, let’s them know where to go when facing the same issue next time.
- Automation is critical for smaller teams
The fewer decisions you have to make the more energy you have for complex problems. Automating your tasks where you can clears up time and mental energy which can be utilized for other important things. Other people can utilize your automation or get inspiration for their workflows as well so it benefits the whole team to move efficiently.
- Source diving is a treasure trove of knowledge
Source diving frameworks and packages is a treasure trove of experience and learning. You get to learn to solve problems you did not know even existed. You get different perspectives on solving your current problems.
- Be visible and public about your contributions
Most of the time the decision makers only care about the end result. Your work or contributions might not always be visible or immediately appreciated. Try as much as possible to publicly mention your contributions. Others get to appreciate the effort that went into getting the expected result. The decision makers also get to notice you. Don’t down play your achievements because they have become normal to you.
- Learn how to say No
There are situations when you are swamped and another request would not be feasible. Or sometimes a client or management might come with an improbable or obscene feature request. Strategically saying no helps you stay sane and also manage expectations on project deadlines and deliverables. Saying yes to everything is a sure path to burn out. Down the line there is too much on your plate which affects your performance.
Top comments (4)
Technical debt should be part of team deliverablesThis is something I am also working towards making part of the culture at my workplace.
It can be a tough sell. Everyone agrees it's a problem but it's never made a priority.
I agree with everything you say. Unfortunately we live in an unpredictable world and the businesses we work for needs value to be delivered. This makes it hard to live up to all of these, I've found.
To highlight one point, I think the first one is the most impactful you can do. Be the change you want to see. Great advice! ☀️
Yeah, I still haven't found a balance as most of it usually feels like a "nice to have" and not necessarily important.