Software Engineering Aphorisms-A Subjective take

In my career as a software developer, engineer, architect, tech lead and a wannabe hacker, I have gathered some subjective aphorisms. These are in no particular order, just a stream of unsorted and unordered thoughts.

Disclaimer: Few of these may sound trivial, cliched or even common sense. But I’ll reiterate them anyway. Also, these are my opinions and do not reflect those of my employer. Enjoy reading!

1. People tend to be aggressively (and sometimes unreasonably) optimistic about estimates when they are not the ones who will be doing the implementation (See Planning Falacy). This is important because in many software consultancies, there is an A-team of tech sales people who submit proposals and enamour the clients. They put in unrealistic estimates to win over projects. And then the delivery teams (sometimes teams of freshers) pay the price. This may work for gaining business, but not delivering it.
2. Your new project will always seem to have bad code. You will always feel you would have done a better job than the earlier team. But that may not be true. Never go with the first hunch when you encounter a new codebase. You will feel the urge to refactor things upfront. Control it and focus on delivering value and refactoring in the process. Refactoring as a part of fixing bugs/new features is ideal, rather than making the entire codebase pristine first. This is a good post to refer to for dealing with legacy codebases.
   All code is bad code, some is worse than others.
3. Smaller teams often move faster than the larger ones. Still, some managers still cling to the manufacturing mindset, adding more bodies to solve problems of schedule and scale. However, software creation relies heavily on communication, and each additional team member increases communication overhead in the human graph. Product companies leverage this efficiency, but it’s a flawed model for software consultancies or freelancers, where revenue often depends on headcount. For e.g. the Facebook photos team was a 30 member team, while Flickr team was 300+, despite FB photos accounting for 70% of social photos online (stats from around 2016).
4. Premature Optimization is NOT always the root of evil. When designing a new module or a system, always keep performance in mind. No need to do exhaustive profiling upfront, but understanding performance implications of decisions helps avoid simple caveats. For e.g.
   a. DDD and Microservices may dictate that a request flow through multiple layers of abstractions and aggregates, but it adds network latency. Tradeoff could be a poor DDD decision that is better performing.
   b. For any non-trivial computation/logic, data structures and algorithms knowledge is important. Say an in memory collection needs to be queried a lot, then a hash could be a better choice. Or for always getting the max/min value in a collection, a Heap could be used. If the same value is fetched multiple times from a collection, caching helps etc.
5. Reading code is as useful as writing it. Depending on the time you can extract from your work, spending time reading some open source libraries’ code helps forming concrete thoughts. It also allays the perfectionist inside you.
6. As software engineers and architects, we often immerse ourselves in the intricacies of code, algorithms, and system design. However, there’s immense value in venturing beyond the technical realm. Reading fiction, some self-help, domain books etc. helps with improving communication, connect dots across fields and broaden perspectives.
7. As Andrej Karpathy said in his latest tweet, ‘on shortification of “learning"’, watching learning videos is a form of addiction and avoidance from doing actual work. (The long tweet is worth the read).
8. Technical moat is not the same as commercial success. The TV series Silicon Valley demonstrates it well. Richard’s platform is superior to all others, but they don’t have enough integrations/stable platform, and ultimately it fails. Technical excellence is necessary, but not always sufficient.