3 ms·

Companies are starting to behave as primary schools: let's start study groups! Let's do some tech talks! Let's do hackathons! As a professional developer with

Companies are starting to behave as primary schools: let's start study groups! Let's do some tech talks! Let's do hackathons! As a professional developer with some years of experience in this industry, I call this BS. Companies even put this kind of "events" in their job offers (as if that would attract people!). Let me do my job, if I need to collaborate with people of other teams, I will do so; if some knowledge "needs to be share", then I will do so... I don't need your support, company X. Many of the people I have met in the past (senior engineers) consider these kind of events as huge red flag.

adkadskhj 5y ago
I think i'd agree. I detest documentation that can't be automated in some form, as it will bitrot so fast it's nearly worthless imo. As an example, we're a young company with some very old-school devs. Devs that would FTP push directly to prod and never commit to Git. To mitigate friction on transitioning these devs to more mature practices, management went heavy handed with documentation. Step by step instructions on how to commit, how to name your branches, how to hotfix, etc. Well guess what? Our practices our different now. Our branch names differ, our git host is different and requires different practices. All the screenshots are out of date. The text is littered with old references and old practices, spread across a dozen documents. In my experience trust in this sort of documentation is _easily_ lost. Lost trust means that a developer won't bother looking, and will end up asking a senior about it anyway. On the flipside i love documentation that can be automated, filled with tests, etc. I use a Rust framework called Mdbook, which i include tests in to attempt to ensure when the schema or API changes, the tests fail so the dev remembers to update the documentation. Not perfect, but at least the tooling helps humans be better.

adkadskhj 5y ago

I think i'd agree. I detest documentation that can't be automated in some form, as it will bitrot so fast it's nearly worthless imo. As an example, we're a young company with some very old-school devs. Devs that would FTP push directly to prod and never commit to Git. To mitigate friction on transitioning these devs to more mature practices, management went heavy handed with documentation. Step by step instructions on how to commit, how to name your branches, how to hotfix, etc. Well guess what? Our practices our different now. Our branch names differ, our git host is different and requires different practices. All the screenshots are out of date. The text is littered with old references and old practices, spread across a dozen documents. In my experience trust in this sort of documentation is _easily_ lost. Lost trust means that a developer won't bother looking, and will end up asking a senior about it anyway. On the flipside i love documentation that can be automated, filled with tests, etc. I use a Rust framework called Mdbook, which i include tests in to attempt to ensure when the schema or API changes, the tests fail so the dev remembers to update the documentation. Not perfect, but at least the tooling helps humans be better.