The references your team keeps losing
"in one shared list instead of forty open tabs"
Engineering reading listshared
Frontend6
Backend5
Infra4
Onboarding3
One list, the whole team
Somebody asks which tool the team uses for error tracking. Three people answer, two of them wrong, and the real answer is a tab one of them closed in March. That is the whole problem, and it is not a documentation problem — your wiki is fine, your wiki is just not where anybody looks. A shared Glubler holds the references themselves: the frontend library guide everyone re-reads, the backend service someone found in a comment thread, the four links a new joiner needs before they can ship anything. One named place, kept by whoever uses it, and the answer to the question above is already sitting in it.
Shared, not inherited and honest about the gaps
Internal reference lists almost always die the same way. Somebody assembles one over a few months, it lives in their browser, everybody finds it useful, and it quietly becomes their list rather than the team’s — then it leaves with them. Putting it somewhere shared fixes the ownership problem and exposes a second one: a list only covers what its author happened to need. So treat coverage as something you check rather than assume, look at which role has nothing in it, and let the people who noticed fill it in. A Glubler is public unless you close it, which is what makes that possible without asking anyone for permission.
Coverage by role
Frontend6
Backend5
Infra4
Designnone
Gapnothing Design needs yet
Including the gap
Split it the way people actually ask instead of by when you saved it rather than one long column
A flat column of forty links answers nothing, because nobody reading it knows which six apply to the question in front of them. Split the same set into Subglublers named for the work — frontend, backend, infra, onboarding — and the question resolves itself, and so does the next one. It also makes the list maintainable, since a newcomer adding the thing they needed last week has an obvious place to put it instead of guessing. Grouping is not tidiness. It is the difference between a reference list people consult and one they scroll past.
Engineering reading listpublic
New joiner3 to start
New to Backend5 to read
Leavinglist stays
It outlives whoever made it
It outlives whoever built it every new joiner inherits the lot
Onboarding is where this pays for itself. Instead of six links in a chat message and a vague instruction to ask around, the new person opens one list and reads the three that matter on day one — then knows where the other thirty live when they need them. And when whoever assembled it leaves, nothing breaks, because the list was never theirs to begin with. That is the difference between documentation that belongs to a team and a collection of tabs that happened to be open on one machine.
Start a shared listReferences, not your own docs
Be clear about what this is for, because the word documentation invites the wrong comparison. A Glubler is not where your team writes things down — decisions, runbooks, onboarding steps and architecture notes belong in whatever you already use for that, and a list of links is a poor substitute for any of it. It is for the OTHER half: the external references worth keeping. The spec you reread every month, the guide that answered the bug last month, the tool comparison nobody ever got round to writing up. Those are websites, they live on someone else’s server, and they belong together somewhere the team can reach.
Four roles, four different lists
A frontend engineer and a data engineer need almost nothing in common, and a list that tries to serve both ends up serving neither. Splitting it by role fixes that on purpose: each person opens the one group that applies to them and closes the tab on the rest, which is exactly why they will come back to it. It also makes the gaps findable. When the data group is empty you have found out something worth knowing, and the fix is one person adding four links rather than a quarterly audit nobody scheduled.
FrontendComponent patterns
BackendMigrations, indexes
Belongs to the team, not to whoever made it
Every useful reference list starts as somebody’s private pile and stays that way until somebody deliberately makes it shared. The move is small — put it somewhere the team can reach, name it after the work rather than after yourself, and let people add to it — and it is the difference between a resource and an artefact. Nothing else on this page matters as much: a list one person curated is a favour, and a list the team maintains is something people can rely on without asking who to ask.
The first week, solved once
Onboarding is where shared references pay for themselves immediately. Six links in a chat message get read once and lost; one list with a small onboarding group gets opened every time somebody new starts, and it improves because the newest person is the one who noticed what was missing. Splitting it by role means each new joiner reads three things instead of forty, which is the difference between a first week spent reading and a first week spent shipping.
Found something better, add it
References rot, and a link that quietly went stale teaches people to distrust the whole list the first time it wastes their morning. A Glubler takes the fix in one step — glue the new site, unglue the dead one — and anyone can do it without finding the owner or opening a ticket. Over a year the list ends up better than the one you started with, which is the only sustainable way to keep one, and nobody has to schedule the tidy-up that never happens.
Glubler FOR
TEAMS
Not a wiki. The list beside it.
Keep your own writing where it belongs. Use a Glubler for the references your team keeps losing — grouped by role, shared by default, and open for anyone who finds something better to add.