5 ms·

Jiggle programmers isn't a type of person, it's a phase juniors go through. There's a lot of stuff to cram into your brain as a junior, and when you don't have

by tinco 4y ago

Jiggle programmers isn't a type of person, it's a phase juniors go through. There's a lot of stuff to cram into your brain as a junior, and when you don't have a complete model of how things work it can be basically impossible to come up with an approach that has a chance of working on the first try. In my opinion the way to get them through it is loads of pair programming and stopping them and reminding them they haven't stopped to think about the entire context when you catch them doing it (or when they come to ask for help in the ideal case). I'm not sure if I ever went through this phase, but not everyone has the luxury of developing their programming skills at a leisurely pace from highschool all the way through college.

bpodgursky 4y ago
I do not think this is true. Strong junior programmers usually fail by rewriting everything from scratch, having no concept of DRY, libraries, or how to effectively break logic into methods. But inability to generate their own code is not a common failure mode! It's only weak junior programmers (that is, people who simply are not going to become strong developers) who approach a problem and, in the absence of the ability to write code from scratch, try to find something to copy-paste.
- 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)
- tinco 4y ago
  Strong/weak is definitely another axis. I'm not sure they could never be strong developers. I'm not saying they couldn't generate code at all, just that the first couple approaches they write miss fundamental constraints causing the code to either not work or have horrendous properties, and they sort of jiggle their way into something that works. Sometimes the initial tries come from a Google result, sometimes they came up with it themselves, the important part is they don't fully understand the code in its context. Anyway, regardless of whether they're really strong or not, the couple I've mentored have become tremendously valuable to my company, with performance outstripping my own (I think because of the higher tolerance to shitty repetitive frontend work).
- Brian_K_White 4y ago
  I think you have something there.
wink 4y ago
I wouldn't necessarily attribute it to juniors, it's the same if you're using a language you're not familiar with or haven't used in years. Sure, technically you are a Junior again if you use a new technology, but assuming the MO of the language is not completely unlike one you're familiar with (for example OOP vs functional vs whatever). I mean, at least that's what I need to do - but maybe "how was this syntax again?" paired with "I don't like these docs" might only superficially be copy/pasting from SO, because you know what you're writing, but you don't have the words of the language...

by tinco 4y ago

bpodgursky 4y ago

I do not think this is true. Strong junior programmers usually fail by rewriting everything from scratch, having no concept of DRY, libraries, or how to effectively break logic into methods. But inability to generate their own code is not a common failure mode! It's only weak junior programmers (that is, people who simply are not going to become strong developers) who approach a problem and, in the absence of the ability to write code from scratch, try to find something to copy-paste.

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)
tinco 4y ago
Strong/weak is definitely another axis. I'm not sure they could never be strong developers. I'm not saying they couldn't generate code at all, just that the first couple approaches they write miss fundamental constraints causing the code to either not work or have horrendous properties, and they sort of jiggle their way into something that works. Sometimes the initial tries come from a Google result, sometimes they came up with it themselves, the important part is they don't fully understand the code in its context. Anyway, regardless of whether they're really strong or not, the couple I've mentored have become tremendously valuable to my company, with performance outstripping my own (I think because of the higher tolerance to shitty repetitive frontend work).
Brian_K_White 4y ago
I think you have something there.

wink 4y ago

I wouldn't necessarily attribute it to juniors, it's the same if you're using a language you're not familiar with or haven't used in years. Sure, technically you are a Junior again if you use a new technology, but assuming the MO of the language is not completely unlike one you're familiar with (for example OOP vs functional vs whatever). I mean, at least that's what I need to do - but maybe "how was this syntax again?" paired with "I don't like these docs" might only superficially be copy/pasting from SO, because you know what you're writing, but you don't have the words of the language...