3 ms·

> But inability to generate their own code is not a common failure mode! This has been my experience too. It's also common (maybe even nearly universal) for de

by cwalv 4y ago

> But inability to generate their own code is not a common failure mode! This has been my experience too. It's also common (maybe even nearly universal) for devs to go thru a stage where "rewiting" feels like the path of least resistance. This is usually (not always) wrong, but until you've ramped up in several very different codebases it's difficult to see how something so foreign can end up being as productive as what you're used to.

tinco 4y ago
From my experience that's the "final" phase of being a junior. Where you're perfectly capable of coming up with architectures, considering functional constraints and relationships to hardware. Maybe such a junior is fresh out of university, or has spent 3-5 years working programming jobs after high school. They'll have their head full of fresh strong opinions on what's good, and have had some experience with what happens when things go wrong, and maybe mistake code they don't understand or find hard to follow for bad practices. I'd also wouldn't frown on just calling them developer. They just need a senior developer to tell them not to rewrite everything.
Brian_K_White 4y ago
I've done it. For me it is when I don't actually understand the thing someone else wrote. It's messier than simply that too. Even though I may be the inferior coder to them, I am not necessarily without any capacity to reason and improve on something. So what happens is I pick something up that someone else wrote, and I see things I think should be done differently, and much of that is probably perfectly true and correct, as far as it goes. But also, even while some of my ideas were correct and better than what's in there, at the same time it's also true (ends up turning out to have been true, but I only recognize it later) that much of what I didn't like and ripped out and re-wrote, was actually just me not actually grasping the thoery of operation of the original code. My new replacement may still work and may even look more organized or more easy to follow, but turns out not to handle some edge cases the original code not only handled, but did so in some elegant trick way that isn't obvious from reading it, but ends up handling more conditions in fewer lines, fewer cpu ops, fewer memory ops, fewer db/net calls, etc. I live with myself by deciding it's good enough that I at least recognize this process and am generally improving day by day. That has to be all anyone can really expect.
orwin 4y ago
But isn't this stage supposed to be over after school? I mean, i was pushed towards rewriting everything during my school days. We even had a graphic library with 3 functions: create windows, erase windows and paint this pixel. Rewrote printf, malloc and consorts. Once i was allowed to use glibc trees, map and hashtables, i never wrote an already existing function (maybe a ring buffer and a weird linked list)(and rewrote a scikit image filter because I was too dumb at that time to read changelogs and GitHub issues)

by cwalv 4y ago

tinco 4y ago

From my experience that's the "final" phase of being a junior. Where you're perfectly capable of coming up with architectures, considering functional constraints and relationships to hardware. Maybe such a junior is fresh out of university, or has spent 3-5 years working programming jobs after high school. They'll have their head full of fresh strong opinions on what's good, and have had some experience with what happens when things go wrong, and maybe mistake code they don't understand or find hard to follow for bad practices. I'd also wouldn't frown on just calling them developer. They just need a senior developer to tell them not to rewrite everything.

Brian_K_White 4y ago

I've done it. For me it is when I don't actually understand the thing someone else wrote. It's messier than simply that too. Even though I may be the inferior coder to them, I am not necessarily without any capacity to reason and improve on something. So what happens is I pick something up that someone else wrote, and I see things I think should be done differently, and much of that is probably perfectly true and correct, as far as it goes. But also, even while some of my ideas were correct and better than what's in there, at the same time it's also true (ends up turning out to have been true, but I only recognize it later) that much of what I didn't like and ripped out and re-wrote, was actually just me not actually grasping the thoery of operation of the original code. My new replacement may still work and may even look more organized or more easy to follow, but turns out not to handle some edge cases the original code not only handled, but did so in some elegant trick way that isn't obvious from reading it, but ends up handling more conditions in fewer lines, fewer cpu ops, fewer memory ops, fewer db/net calls, etc. I live with myself by deciding it's good enough that I at least recognize this process and am generally improving day by day. That has to be all anyone can really expect.

orwin 4y ago

But isn't this stage supposed to be over after school? I mean, i was pushed towards rewriting everything during my school days. We even had a graphic library with 3 functions: create windows, erase windows and paint this pixel. Rewrote printf, malloc and consorts. Once i was allowed to use glibc trees, map and hashtables, i never wrote an already existing function (maybe a ring buffer and a weird linked list)(and rewrote a scikit image filter because I was too dumb at that time to read changelogs and GitHub issues)