2 ms·
> As a developer, I much prefer to write code than read other people’s code. But most projects I work on involve other developers so it’s hard to avoid. Often I
by bmitc 4y ago
> As a developer, I much prefer to write code than read other people’s code. But most projects I work on involve other developers so it’s hard to avoid. Often I find it really hard to quickly parse other people’s code
Another solution to this problem is documentation, which is as much about coding as coding is.
If code was named well instead of using shortened and abbreviated names which serve zero purpose, documented well, and crafted well, then you wouldn't have these problems and wouldn't need machine learning to hack away at explanations. The one thing software doesn't need is more layers between what a person thinks the code does and what it actually does.
- mrexroad 4y ago> The one thing software doesn't need is more layers between what a person thinks the code does and what it actually does. I get what you’re saying, but also can’t help but think how glad I am to not write assembly anymore. It’s abstractions all the way down anyway. If adding more layers can lower the barrier to code, the I’m all for it — and yes, including all the baggage it’ll bring along. It’ll suck for a while, but it’ll eventually empower a newer generation to do things they otherwise couldn’t have.
- bmitc 4y agoIt's not necessarily the layers of abstraction. I would consider this to be a layer of indirection. A human writing code, then a machine learning algorithm learning from other human written code, and then another human using that machine learning algorithm to understand the original code seems like a rather needless and inefficient layer of indirection.