Versatile software engineer with a background in .NET consulting and CMS development. Working on regaining my embedded development skills to get more involved with IoT opportunities.
Learn to make a persuasive business case for your proposed solutions. The coolest technical implementation doesn't mean anything if you cannot convince your superiors that it's a good investment and that it will make everyone's lives easier.
Automate repetitive tasks. You will learn a lot in the process of automating the task, and it will save you time in the future to work on more interesting ideas.
Ask why. Why did the system fail? Why didn't we get any alarms from our APM system before it crashed? Dig a couple layers deep when things go wrong to understand the root cause of the issue. Similarly, bugs may be symptoms of much more serious issues in the codebase that need to be discovered and dealt with.
Write good documentation. Preserve knowledge within your organization and make the onboarding process suck less for the next person who comes along.
Choose your battles wisely. There's a million things you could fix in some code bases, but what will deliver value now? You can't debate the merits of every fix, sometimes it's fairly evident that code needs to be fixed but the timing isn't right. You can only crusade for so many causes without wiping out the enthusiasm of your coworkers and supervisor, so make sure to get them involved with the cause when it really matters.
Stepping back and asking why is a hugely important skill to have. You may be able to say "This broke because xyz happened and we can fix it easily", but ask "why did xyz happen?", "Did xyz cause anything else we've not discovered yet?", "How should we handle xyz in the future?", etc. This applies to all sorts of work in development and doesn't stop at code.
It's also worth repeating that it's repetitive tasks that should be automated. We all know that one person who spends hours automating something which could have been done manually much quicker, and their automation is never used again! Unless you're doing it purely as a learning project, I would recommend only automating tasks that are done frequently, or tasks which are done occasionally, but would benefit from automation to reduce human error.
When writing documentation, don't be afraid to write partial documents as it can be off putting if you think you need to document an entire process at once. You'll find some notes are better than no notes.
Put your documentation in source control! Not only does it protect the history, it also helps make it accessible to other members of the team. I've implemented a build pipeline using Azure Devops and DocFX, where once changes to documentation are committed to the Git repo, the documentation website is rebuilt and deployed with the latest changes.
Excellent list! Agreed on all points.
Stepping back and asking why is a hugely important skill to have. You may be able to say "This broke because xyz happened and we can fix it easily", but ask "why did xyz happen?", "Did xyz cause anything else we've not discovered yet?", "How should we handle xyz in the future?", etc. This applies to all sorts of work in development and doesn't stop at code.
It's also worth repeating that it's repetitive tasks that should be automated. We all know that one person who spends hours automating something which could have been done manually much quicker, and their automation is never used again! Unless you're doing it purely as a learning project, I would recommend only automating tasks that are done frequently, or tasks which are done occasionally, but would benefit from automation to reduce human error.
When writing documentation, don't be afraid to write partial documents as it can be off putting if you think you need to document an entire process at once. You'll find some notes are better than no notes.
Put your documentation in source control! Not only does it protect the history, it also helps make it accessible to other members of the team. I've implemented a build pipeline using Azure Devops and DocFX, where once changes to documentation are committed to the Git repo, the documentation website is rebuilt and deployed with the latest changes.
Thanks for sharing all these important points!😊 You should create a separate blog post from them 😊📝