A perpetual issue with any organization of scale is consistency in documentation. Spoilers: No I don't have a good solution, still working on that.
With wikis there's always an issue with of keeping content up to date, preventing stales and bit-rot, versioning content, and one of the largest nightmares:
Consistency.
Consistency in naming, format, organization, style, wording choices, and more.
Good docs are danged hard to pull off, and one should never underestimate the effort it takes to curate them and make them into something truly great.
Tech writers aren't nearly appreciated enough in our industry for being able to translate complexity into clarity.
A tech librarian that can curate entire systems of documentation, help to organize standards, and give clarity at a company level.
The type of influence, charisma, company-level thinking, and leadership that takes is insanely valuable.
Quite honestly I don't think it's entirely possible to have this level of organization in docs without some seriously talented writers.
Engineers are not nearly as amazing of writers as they like to believe themselves to be, and cultural issues aren't their forte.
Anyways, point being, documentation and writing is hard to get right and I'm not nearly at a level where I have a good answer for it.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
I may well go ahead and create "Red in Fantasyland - An Illustrated Adventure into Category Theory". The trick is I kinda don't want to mention it's a CT talk, nor that it covers monadic concepts, as that spoils the fun.
That all said this is a talk I really want to give eventually but don't have a firm enough understanding myself quite yet to make it.
If I do make it I'll likely independently record and release it later, and hope conferences like it.
So what's the story here?
In the land of the lemurs I introduced a figure called the "Escher Cat" who's based on M.C. Escher and the Cheshire Cat from Alice in Wonderland. Frequently Escher is with his dear friend Indigo.
Worst: Algorithmic (CodeSignal, LeetCode), timed problems, whiteboards, reciting dictionary information, there's only one right answer questions.
I love problems which allow me to explore a space and have a conversation about what we're doing. Doubly so if the interviewer doesn't have one single answer they're looking for.
I especially enjoy if they're not severely time-boxed into hour segments. Very few think that fast.
This question has come up a few times, and while I've answered it in promo materials internally I've never actually written out publicly:
What exactly is it that I do at Square, and how did I get to be a Staff Engineer?
(thread)
General overview to start:
I help to lead the Ruby community at Square, and represent Square frequently in the industry through various forms of writing, conference speaking, recruiting, and more.
How did I get that position?:
I did a lot of Ruby, and I talked about it. I made opinions known, participated in designs frequently, mentored, and started emerging as a Ruby presence.
After some time a new team called Frameworks emerged and needed a Ruby lead.