Hacker News new | ask | show | jobs
by simonw 2224 days ago
Something I realized working on a large internal codebase at a company: any line of code you write is liable to be copied-and-pasted at some point in the future.

And that's good! Consistency is a very valuable quality of large codebases worked on by many engineers.

If I want to figure out how to write a unit test for a service call, find an existing example of that pattern and copy that. Resist the temptation to invent a new, very slightly better way of doing that.

There's a big corollary to this: if you find yourself doing something for the very first time in that particular codebase, take the time to do it well. Because everyone else will be copying your code for the future lifetime of the project.

2 comments

I work at a FAANG with a monorepo (or nearly so). For anything that’s not blue-sky R&D, stalking around the codebase for working examples and patterns is a big part of the job.

I’ve felt that there is a potentially a role missing here: a kind of free-floating code librarian who is not attached to any particular team and could be called upon to perform basic research of existing patterns. Part of this role could be to maintain the kind of newbie-friendly documentation that tends to fall between the gaps of tool/infra/product teams. Maybe the job title could be “software informatician”.

> a kind of free-floating code librarian who is not attached to any particular team and could be called upon to perform basic research of existing patterns

I'm on board with this idea, as long as I don't have to learn Dewey Decimal Classification.

This is usually called an "area tech lead" in FAANGs and "software architect" in more old-line software companies.
I’m thinking of a more junior supporting role, separate from development and architectural design. The librarian doesn’t write the books.
I've never worked on FAANG scale monorepos, but in normal-sizer project, that would be one team leader.
I introduced a new way of doing unit tests at a client recently, and, sure enough, my unit tests were basically treated as a template. Everybody added their own spin to it, but the basic structure was the same. I was quite glad that I had suspected this beforehand and accounted for it.