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.
Write code that is monotonic (can only proceed in one direction) and uses immutable data structures. This helps in ruling out wide swaths of possible outcomes, e.g., with immutable data structures, the object will not change out from under your feet.
Structure your code so that pre-conditions and post-conditions are easy to conceptualize and verify. This makes it easier to reason about what your code will do in the event that it doesn’t crash.
Subdivide your code into atomic units that can maintain the invariants (things that should always be true no matter what). For example, with C++’s constructors and destructors, one can ensure that any memory an object needs only remains allocated when the object actually exists.
Build as many firewalls that prevent changes from propagating past a certain point. For example, a Nerve query can contain material fields (obtained from an API) and virtual fields (derived from material and virtual fields). The query planner computes the dependencies of query \(Q\)’s virtual fields, and adds them to a query \(Q'\) which is fed to the query executor. On receiving the results, Nerve prunes fields that weren’t in the original \(Q\).
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.
I’ve done fairly well in my MSFT career, but I’ve come across shooting stars that I’ll seldom see again. Most tend to switch companies within 3 years or so. Looking to figure out more of their mindset.
References
- 7 Absolute Truths I Unlearned as Junior Developer. Monica Lent. monicalent.com . Jun 3, 2019. Accessed Jun 6, 2022.
- Absolute truths I unlearned as junior developer (2019) | Hacker News. news.ycombinator.com . Accessed Jun 6, 2022.
- Why I Write Dirty Code: Code quality in context. Adam Tornhill. www.adamtornhill.com . 2019. Accessed Jun 9, 2022.
- New Grad to Staff at Meta in 3 years. Ryan Peterman; Evan King. www.developing.dev . news.ycombinator.com . Accessed Dec 24, 2024.
- Mistakes engineers make in large established codebases | sean goedecke. Sean Goedecke. www.seangoedecke.com . Accessed Jan 9, 2025.
- Mistakes engineers make in large established codebases | Hacker News. news.ycombinator.com . Accessed Jan 9, 2025.
- To be a better programmer, write little proofs in your head. Matthew Prast. the-nerve-blog.ghost.io . Jul 14, 2025. Accessed Jul 20, 2025.
uses CodeScene , which has hotspot detection and code-health metrics, and can be integrated into CI pipelines. It has a free edition for publicly available repositories. The pro version is €27 per active dev per month.