Lessons from: Building Software

I have been dabbling with code for the past 10 years, at least. And for the past 4 years, I have worked with some of the best minds in the industry, professionally. During which, I kind-of had the front row seat, when things did not go well. Over the years, I have picked up some muses and principle here and there. This piece is just that. This is definitely an inexhaustive list and will evidently go through some revisions in future. But here is what I would want my future self to know (as of now).

1. Think of your end goal and derive a process to achieve it in small milestones. Then stop worrying about the goal and rely on the process. Otherwise every project feels like a unsurmountable mammoth.
2. Use the management layer to build and maintain the processes, not to keep tabs on people. Nobody likes being bossed around. Trust people with some responsibility and you could do away with frequent “Any Updates?” question. Works, mostly!
3. I like to compare management layer with fat in the human body, but not in a demeaning way. You need fat to function, but beyond a certain amount it hinders your agility. Question, with each layer of management, how much outcome is improved.
4. Be transparent and let the leaf nodes have all relevant information, that is where best decisions are taken. Both in armed conflicts and in software development, the people who are fronting it, have the best visibility.
5. Make the team, diverse! Not just gender or ethnic diversity but also experience diversity. People with experience tend to follow linear , well trusted path. But you need that rookie to question things, revise path and spark curiosity.
6. Experience is not equal to expertise. In the tech world, there is this over weighted showcase of years of experience, which is very myopic. Worthiness comes in various shapes and sizes.
7. We have infinite wishes and finite resources. And every decision is a tradeoff. If you want to prioritize performance of your software, you must be willing to expend in memory. For that, one always needs to establish priority of their goals. When you cannot have everything, you need to know what you want the most.
8. The answers to most question is - ‘Depends’. There is no linear path to glory, be willing to try and fail and build context of things what work for the particular case.
9. Thought over thunder. Give attention on how to do things before actually doing it. Sharpen your axe before cutting the tree. It will save iterations later. People are not resources. Stop calling them that. Your HDD is a resource, when it is exhausted, plug in a new one and it will immediately expand your storage. People are not like that, they are not plug and play.
10. Also human mind cannot multitask, it can switch context and appear to be handling two processes interleaved but it is degrading in quality. Give singular objective to developers, not multiple birds to shoot at.
11. Loyalty to a tech stack is like a pseudo relationship to with your celebrity crush. Instead use right tool for the right job and evolve ergonomically. Every choice has long term ramifications, it should be forward looking, not based on past opinions.
12. Technical decisions should be made by technical people, who have a skin in the game, even if it has business implications. Or there seeps the infection of tech debt, we all know what we have to pay later for it.
13. Be organic while complementing someone. Find the actual reason, and mean it in what you say. People and dogs appreciate compassion more than their superficial anecdotes.
14. Talk, let people vent and scream. Allow a platform to be authentic, not picture perfect. Half of the issues are easily resolved, if someone is just listening and nodding head. Someone will always be unhappy. Optimize to make them belong, not happy.
15. If possible, chose to slow down. Don’t be afraid of code freezes, it is prudent and overhyped to tape problems now and to revisit later. It ends up costing you more. And hard to justify to business why the effort is necessary.
16. It is okay to fail. But no one will pay you for a long list of failure. Timebox the trials, if it crosses the threshold, do it in a idiotic way. But the time-slice should not be so tiny that it prohibits experimentation.
17. Mentorship over training. There is no outcome of letting your team forcefully digest hours of mind numbing presentation. Chose to be an essentialist while leading people.
18. To human is to err. Mistakes happen, processes are designed to check those.