4 ms·

This post talks about a team role that has been called the "librarian". Some of the software engineering literature proposed that a team of three can be most pr

by jll29 6y ago

This post talks about a team role that has been called the "librarian". Some of the software engineering literature proposed that a team of three can be most productive as a pair supported by a librarian that writes useful library functions. I have been in teams where we carried out projects, and each project's codebase re-invented a lot of functionality (e.g. converting HTML to plain text, tokenising an English sentence). Of course I proposed a librarian role, which as the article contends is suitable for particular personalities. In a group of, say, ten or more people there is a room for that kind of specialisation (librarian, sysadmin, statistician, ...).

celim307 6y ago
We have someone on our team who maintains and develops a repository that is basically ran as a OSS project that directly services our main product. It’s wonderful. With guaranteed longevity and having internal devs as the customer, things like on boarding are a snap. The documentation is comprehensive and there’s a slack channel monitored 24:7 for questions and onboarding.
hardwaregeek 6y ago
Yeah, it's similar to the toolsmith position in the surgical team model that Brooks espouses: https://wiki.c2.com/?SurgicalTeam https://wiki.c2.com/?SurgicalTeam Of course there should probably be a toolsmith at the team level, but also at the org or even company level to avoid the re-inventing problem you mention.
dgb23 6y ago
I really like this term! Because it implies that Fred is not just doing refactoring, optimization and automation work but also writes new code that others use/interact with (hopefully with sufficient documentation). Also because I'm often this kind of Fred, sometimes because it is expected of me, sometimes because I just have a natural urge to do so. However with the caveat that I also complete features and projects as is the nature of my work. In the past I was _too_ Fred-like, but with experience comes pragmatism I guess. KISS and YAGNI are the mantras that keep Fredism at bay. A simple yet effective technique to fight Fredism when inappropriate is to just write things down in plain $Language and keep going with your feature/ticket/task. It also helps in another way: Sometimes the first instinct is not the right one so you avoid premature optimization etc. by sleeping over it, bouncing it off your collaborators/team and so on.
zem 6y ago
when i worked on a team of 10 people this is what i did (and, fortunately, got a lot of appreciation for it). i extracted a common framework from a bunch of separate subprojects, refactored the subprojects to use them, and then spent my time writing useful common functionality while the rest of the team worked on user-facing features. now that i am in a team of 3 there is a lot more of "everyone does a bit of everything", though fortunately all three of us are enthusiastic about keeping the code clean, testable and well-factored.
8note 6y ago
When you say librarian, I think of a team member who knows the code base and reasons why the code base is the way it is. Maybe historian is a better name though
- PaulStatezny 6y ago
  > knows the...reasons why the code vase is the way it is I try to document (in code) a lot of that "why", so that the answer doesn't need to be passed around as tribal knowledge. If you need a person around to be able to explain the project architecture, it's probably a sign that you need more/better documentation. Just my 2 cents.
  - piva00 6y ago
    I do the same, any kind of minimally unexpected code gets its explanation as a comment if the code can't be clear about the why. I like to leave a comment with what is happening, the background for it and any kind of gotchas I'm aware at the time. This has saved countless man-hours for my teams, including myself when refactoring part of the codebase a year or so later, having a nicely written rationale behind some weird-looking code gives me not only peace of mind but a lot of trust in the rest of the team.

by jll29 6y ago

celim307 6y ago

We have someone on our team who maintains and develops a repository that is basically ran as a OSS project that directly services our main product. It’s wonderful. With guaranteed longevity and having internal devs as the customer, things like on boarding are a snap. The documentation is comprehensive and there’s a slack channel monitored 24:7 for questions and onboarding.

hardwaregeek 6y ago

Yeah, it's similar to the toolsmith position in the surgical team model that Brooks espouses: https://wiki.c2.com/?SurgicalTeam https://wiki.c2.com/?SurgicalTeam Of course there should probably be a toolsmith at the team level, but also at the org or even company level to avoid the re-inventing problem you mention.

dgb23 6y ago

I really like this term! Because it implies that Fred is not just doing refactoring, optimization and automation work but also writes new code that others use/interact with (hopefully with sufficient documentation). Also because I'm often this kind of Fred, sometimes because it is expected of me, sometimes because I just have a natural urge to do so. However with the caveat that I also complete features and projects as is the nature of my work. In the past I was _too_ Fred-like, but with experience comes pragmatism I guess. KISS and YAGNI are the mantras that keep Fredism at bay. A simple yet effective technique to fight Fredism when inappropriate is to just write things down in plain $Language and keep going with your feature/ticket/task. It also helps in another way: Sometimes the first instinct is not the right one so you avoid premature optimization etc. by sleeping over it, bouncing it off your collaborators/team and so on.

zem 6y ago

when i worked on a team of 10 people this is what i did (and, fortunately, got a lot of appreciation for it). i extracted a common framework from a bunch of separate subprojects, refactored the subprojects to use them, and then spent my time writing useful common functionality while the rest of the team worked on user-facing features. now that i am in a team of 3 there is a lot more of "everyone does a bit of everything", though fortunately all three of us are enthusiastic about keeping the code clean, testable and well-factored.

8note 6y ago

When you say librarian, I think of a team member who knows the code base and reasons why the code base is the way it is. Maybe historian is a better name though

PaulStatezny 6y ago
> knows the...reasons why the code vase is the way it is I try to document (in code) a lot of that "why", so that the answer doesn't need to be passed around as tribal knowledge. If you need a person around to be able to explain the project architecture, it's probably a sign that you need more/better documentation. Just my 2 cents.
- piva00 6y ago
  I do the same, any kind of minimally unexpected code gets its explanation as a comment if the code can't be clear about the why. I like to leave a comment with what is happening, the background for it and any kind of gotchas I'm aware at the time. This has saved countless man-hours for my teams, including myself when refactoring part of the codebase a year or so later, having a nicely written rationale behind some weird-looking code gives me not only peace of mind but a lot of trust in the rest of the team.