Choices
Our job is making decisions, learning from them, and slowly making fewer mistakes until we become good enough to guide others.
Image by macrovector on Magnific
As a part of our jobs, we make choices every day. Some of them are quick ones like what colour a button should be; while some are larger ones that have long term impact.
Decisions we take early on usually have a small blast radius, they impact smaller subsets of people or systems. As we grow, the blast radius increases & our decisions start affecting more. It is crucial to get into the habit of calculated decision making early on to avoid unforeseen tradeoffs when the cost of being wrong is much larger.
Some examples of this I learnt from:
- Choosing to distribute on a platform which your dependencies do not officially support, may cost countless engineering hours every release.
- Moving from session-based authentication to JWTs can prevent an expensive rewrite once services need to become independently added or decoupled.
Cutoffs
Two times your best guess plus some buffer works only if quality is a focus. If not, your time estimate is often tied to how soon a stakeholder or customer will run out of patience.
Image by macrovector on Magnific
A release date, a demo date, a code freeze date, so many different cutoff dates. We try to set these to feel a sense of control in the bureaucratic machinations that enterprises eventually become. Too often we see quality being dropped to match these cutoffs.
We engineers like to obsess over the quality of the code and the architecture. But, is there always a correct answer?
For a startup yet to get going, and on the verge of bankruptcy, speed matters much more than quality. For a mission critical system like healthcare or banking, correctness is the most important. Most companies fall somewhere within this spectrum of quality and speed. Even within the same company, different teams might lie on different ends of it. Where your team lies at that point should be a large part of most decision making.
- As a company grows, deadlines should grow too. Processes expand, new tasks get added, new people, responsibilities, checks, and compliances. The same deadlines with more things to do often lead to things being done worse than before.
- Assume something will go wrong, always. This will keep you sane when it inevitably does, as well as your deadlines honest. This will afford you the luxury to choose speed or quality instead of being forced to choose speed.
Claude
At what point did we become comfortable replacing human single points of failure with non-deterministic software acting as new single points of failure? At what point did we become okay with rushing into things without asking the right questions?
I have 2 stances on LLMs. Morally, I absolute hate the resource usage, IP violations, market conditions, and end goals of LLMs. Let's focus on the technical stance in this post.
As a tool, LLMs and coding assistants are brilliant, probably one of the most impactful software changes of the decade. I would describe them as "amplifiers". Obvious amplifications include costs, speed, lines of code, CVEs. They also amplify the less obvious things - time to get a feature to production, tech debt, the knowledge gap between people who work on a ticket and those who didn't, etc. Economics of tokens, cognitive decline and an increasing dependency on the tools are questions that are being increasingly asked for a couple of months now. We need to also start asking the question "is this amplification required, useful and manageable for us?" a lot more than we currently do. This amplification makes a good engineer, better, but a bad engineer a larger problem to the team.
About this series
Monthly learnings will hopefully turn out to be a journal of my life in the software engineer journey. I started this series when I was a full time SWE for 2 years, rather than as a fresh grad because it felt more appropriate. It will help future me - to look back at when I need to as a record of how far I've come and as a refresher. Some of these will be technical, some non-technical and some of these ramblings might not be related to the job at all.
Top comments (0)