../ram/blog/posts

Developer Friendly site built using my own Static Fire Generator

Developer Tooling

I am in this IT industry for 17 yrs now. I worked in both startups and enterprise. I started my career as developer. I was a backend developer to be precise. I personally love to deliver my code quick and with quality. Have an ability to write and test code with ease. So that I wont be disturbed after hours. I want to have my life. I guess we all right ?

Over a period of time I realized very companies or clients I worked with invest or take developer tooling seriously. Many consider that as an expense, when they go ahead and spend on other aspects of IT project. I personally believe, unless you invest in developer productivity, any amount of process is bound to fail or don't give expected outcome. Ideally, we would like a single script to download, install all required tools in local machine. Clear document almost spoon feeding the set up. A fresher to a project should have a seamless onboarding experience.

All the required approvals, groups he need to have access to should be addressed or documented. End of his first day, he should have his developer environment ready to go. He spend next 2 or 3 months exploring the code base and possibly contribute some code or able to create a PR. Developers to their end should document or report any gaps in the document. This enhances the document or make this a living document.

If you are still on-prem, there should be reference document to show how production environment is setup. I have seen clients where developers don't know how their applications are deployed. This leads to many assumptions like I have access to a file system or particular resource or assuming certain guarantees. Always know the production environment. Seniors in the team should take effort to document them and keep it updated. Network diagram is another aspect one should know which helps to have for reference. Edge computing, where you deploy what. Remember chaos engineering where you fail particular part of a system to see how other parts of system reacts. This brings out gaps or vulnerabilities in your system. Not that it happens but we should anticipate and be ready for it.

Developers should always look for avenues to automate. They need to avoid all manual work when possible. If you see something being repeated all the time, automate it.