Perspectives on Software Engineering

On the Clean Code Movement

Good enough is good enough. The architectural choices and bugs in the implementation tend to be more impactful, so focus more on those.

Be conservative in what you consider technical debt. It should be something that slows down current/future changes, and not code that doesn’t “feel nice”. A code base that is free if technical debt is likely over-emphasizing polish over delivery.

Abstractions and indirections in the name of future-proofing tend to be wrong especially when treading new paths, where you can’t reliably predict the future. A lot of value is in knowing the design guidelines well enough, that you know when/if to deviate to better suit the current problem.

Code history can be used to determine hot spots (which tend to be updated frequently and therefore should be clean and well-abstracted) and the long tail (where we can take shortcuts without much cost).

Code Contributions from Senior Devs

Being a senior dev takes more than just programming prowess. Other skills are communication, defining the problem, dependency management, sharing context, project management, estimation, collaborating with non-dev peers, etc..

Re: experienced devs drafting the approach, and leaving it to the junior devs to write the actual code. The senior dev might not have enough coding time, that their inconsistent coding efforts are harmful to the project. Reviewing the resulting PRs is more impactful.

The skill of experienced devs is far more helpful when it can be applied to large parts of the code-base, and hence the meetings get folks on the same page. However, companies may tend to being overly bureaucratic that communication quantity is overstated.

Working in Large Codebases

argues for consistency over trying to make your small corner of the codebase nicer than the rest of it. Large codebases have landmines that have been accounted for in the old code; you cannot split up a large established codebase without first understanding it. “Consistency for consistency’s sake” is usually a misinterpretation of “Consistency because there are reasons for the way things are done and you don’t understand those reasons well enough to diverge”. Copying for the sake of consistency only works if you actually understand what it is that you’re copying; otherwise, you’re cargo culting.

Misc

Aim to be in a supportive team. The feedback (e.g. in code reviews) will accelerate your learning by a lot compared to coding on your own.

Over-documenting tends to lead to staleness. Tests or other forms of automation are less likely to go out of sync with the actual code.

Right org, explosive growth phase, and a manager who saw something in me before I saw it myself. When you can complete your normal workload with 70% of your time, the extra 30% becomes your multiplier – use it to develop the perspective of someone a level above you; see more. Focus on problems, not technologies. Build goodwill early by helping others.

References

1. 7 Absolute Truths I Unlearned as Junior Developer. Monica Lent. monicalent.com . Jun 3, 2019. Accessed Jun 6, 2022.
2. Absolute truths I unlearned as junior developer (2019) | Hacker News. news.ycombinator.com . Accessed Jun 6, 2022.
3. Why I Write Dirty Code: Code quality in context. Adam Tornhill. www.adamtornhill.com . 2019. Accessed Jun 9, 2022.
4. New Grad to Staff at Meta in 3 years. Ryan Peterman; Evan King. www.developing.dev . news.ycombinator.com . Accessed Dec 24, 2024.
5. Mistakes engineers make in large established codebases | sean goedecke. Sean Goedecke. www.seangoedecke.com . Accessed Jan 9, 2025.
6. Mistakes engineers make in large established codebases | Hacker News. news.ycombinator.com . Accessed Jan 9, 2025.