4 ms·

I wonder if the real problem isn't that a lot of corporate engineering teams are becoming less literate then they were in the age of typewriters and overnight m

I wonder if the real problem isn't that a lot of corporate engineering teams are becoming less literate then they were in the age of typewriters and overnight mail. Big problems have been tackled by large geographically dispersed teams dependent entirely on written communications in the pre-internet past so for today project teams to depend solely on being able to talk face-to-face to every member of the team at a regular basis might be more of a new problem then an old problem exposed by the digital age. It could be that search and tagging is not an actual replacement for the archivist specialization and that we in order to relearn the art of running large project/organizations need to reintroduce dedicated archivist and technical writers to the process. It could also be an consequence of how people are taught as maybe the practice of small fast projects lead to people and organisations who never really learn how to record ideas, debates and information.

kayodelycaon 5y ago
The pace of development is a lot faster. The pace of writing has not. Documentation is now much more costly as a percentage.
Viliam1234 5y ago
It is part of the "agile" culture -- by which I mean the popular bastardization created by incompetent managers and incompetent developers, where anything resembling strategic thinking is dismissed as "waterfall" i.e. something the cool kids would never touch. From the incompetent manager's perspective: Typing code is productive work, everything else (such as writing documentation) is not. I am paying you for implementing features for the customer, not writing notes for yourself and your team. From the incompetent developer's perspective: Hey, my idiosyncratic code is self-documenting, and if people do not understand something, it's because they are stupid. Also, more job security is good for me.
kodah 5y ago
Corporate programming is typically bent towards feature delivery and managing patches. Only feature delivery requires managing a project, but it's not new development scale. It involves one or two engineers at most, and anything that requires greater resources than that are looked at skeptically. It's my opinion that this puts us heavily out of practice. Instead, I'd like to engage in work that is outside of our core business. I want to build our own dev tools at times, I'd like to run our own infra rather than toss it at Amazon, Google, or Microsoft and point the finger when it breaks. Having to work outside of a product we know inside and out, domains we're already very familiar with, will improve residual skills like documentation. The repetition of doing and the variety in what we do makes skilled and well-rounded engineering teams imo.
giantg2 5y ago
Speed is the issue. If IT is a cost center, the business doesn't see the documentation and don't care about it. They want the next feature. At least that's how it is at my company.

kayodelycaon 5y ago

The pace of development is a lot faster. The pace of writing has not. Documentation is now much more costly as a percentage.

Viliam1234 5y ago

It is part of the "agile" culture -- by which I mean the popular bastardization created by incompetent managers and incompetent developers, where anything resembling strategic thinking is dismissed as "waterfall" i.e. something the cool kids would never touch. From the incompetent manager's perspective: Typing code is productive work, everything else (such as writing documentation) is not. I am paying you for implementing features for the customer, not writing notes for yourself and your team. From the incompetent developer's perspective: Hey, my idiosyncratic code is self-documenting, and if people do not understand something, it's because they are stupid. Also, more job security is good for me.

kodah 5y ago

Corporate programming is typically bent towards feature delivery and managing patches. Only feature delivery requires managing a project, but it's not new development scale. It involves one or two engineers at most, and anything that requires greater resources than that are looked at skeptically. It's my opinion that this puts us heavily out of practice. Instead, I'd like to engage in work that is outside of our core business. I want to build our own dev tools at times, I'd like to run our own infra rather than toss it at Amazon, Google, or Microsoft and point the finger when it breaks. Having to work outside of a product we know inside and out, domains we're already very familiar with, will improve residual skills like documentation. The repetition of doing and the variety in what we do makes skilled and well-rounded engineering teams imo.

giantg2 5y ago

Speed is the issue. If IT is a cost center, the business doesn't see the documentation and don't care about it. They want the next feature. At least that's how it is at my company.