71–80 of 524 posts
One can only dream everything had documentation as great as i3wm's as a bare minimum.
My current employer was sold to me as a "high documentation" place. What it means in practice is that if you're trying to do something there are 5 outdated documents describing the decision making process for how the project was run, and no documents about how to actually use the resulting software. Occasionally if you ask how to actually do a task in Slack someone will yell at you that you should have searched for a…
> Confluence There's your problem. The only use case for Confluence is when you want to hide information, but credibly claim that it's documented.
It is such a stupid idea that it makes me question leadership.
Some things are good to document there, but generally, if you're documenting code, you should do it in the code.
Sounds like this works great for them, and an awesome environment to be a part of. However I'd be very curious to see how this evolves as the company grows. Personally, I am skeptical that this is sustainable in the long term. In my experience, most people are a) bad at writing and b) hate reading. And as a company grows, and the number of documents that need to be written and read explodes, this work pattern eventua…
So I just write crap as well.
What about the low doc, low meeting culture
What is an example of that working? Just code that speaks for itself? How would you ever know why something was done?
You can't avoid all meetings, but you can keep them few and small.
Earlier quoted context omitted.
What is an example of that working? Just code that speaks for itself? How would you ever know why something was done?
You ask someone in slack. If that isn't sufficient, set up a small 1 on 1 meeting to discuss. You can't avoid all meetings, but you can keep them few and small.
Marvelous is also about to face a significant stress test with the holiday season, both from retail usage of their product and from vacations of their employees. I wonder how routinely highly-documented the agendas will be when competitors start sniping their biggest clients as their service crashes from overcapacity.
Reversion to the mean is coming — what would be interesting would be to hear successful strategies to resist it.
Earlier quoted context omitted.
Why? I think this sounds great.
Read an amazon 6 pager... then try to write one, about anything. and then invite all of your co-workers to pick apart every single line of your document.
Sounds like this works great for them, and an awesome environment to be a part of. However I'd be very curious to see how this evolves as the company grows. Personally, I am skeptical that this is sustainable in the long term. In my experience, most people are a) bad at writing and b) hate reading. And as a company grows, and the number of documents that need to be written and read explodes, this work pattern eventua…
Earlier quoted context omitted.
Do we work for the same company? :P Confluence has been the bane of my attempts in finding any relevant docs. Which one is the source of truth? Which one was a draft written by an overly eager to make a first impression, new employee (who is no longer with the company)? Don't even get me started on saving meeting notes to confluence. These days, I maintain my own knowledge base on Obsidian. If there's ever any confus…
Do you have any tips on how to maintain a developer's own knowledge base in Obsidian? I also use Obsidian but I currently use as more of a dumping ground.
Toplevel: - Work -- Job A: -- Daily notes -- Services -- Auth --- overview --- login flow -- Client -- Logger -- Job B: -- Daily notes -- Architecture -- node -- react -- etc
(edit: sorry about the formatting)
As the scope of your work expands, you add another sub-directory or file where necessary. Once it starts to grow in size, you can start making insightful connections via [[keyword]].
Furthermore, you can pretty much take this knowledge base with you, wherever you go, by uploading the vault file to your google drive and accessing it locally via SMB. Automatic save/backup.
"High-documentation" isn't the cure, either. Just write quality software with well-defined interfaces, minimal dependencies and smooth building processes. I want to be able to build the thing without frustration, to start playing with it in order to learn its internals and debug it. Only then can I be comfortable enough to start implementing features and changes.