30 ms·

I have a parallel term I use, jiggle programmers. They can jiggle code around until it works, often working off existing code. They may become obsessed with ref

by dexwiz 4y ago

I have a parallel term I use, jiggle programmers. They can jiggle code around until it works, often working off existing code. They may become obsessed with refactoring because it's the only kind of programming they really understand. They usually cannot write code from scratch, or when they do it contains a huge amount of plumbing copied from other familiar codebases without any reason for its purpose. It's kind of like they can read a foreign language, but they cannot speak it. Or maybe a parrot who can produce the sounds without the meaning. I do think Google has caused some of this. But the other secret, I think it's how most people program by default. Animals largely learn by copying. The deconstruction of concepts to primitives, and synthesis of these primitives into new ideas if a very academic way to approach things. Centuries have proven this approach is superior, but it takes a huge amount of effort, and many things are lost in this process. (Ever do a physics problem with spherical cows?) With the rise of self-taught programmers, you will see more take this copying approach than the academic redistillation.

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.
- 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...
com2kid 4y ago
As someone who has kicked off multiple "from 0" projects, including a startup and been on the initial team doing an entire embedded runtime, Blank source files are scary yo. There are a near infinite number of choices that can be made when confronted with a blank file. And the ramifications of those initial choices will live on, possibly for decades! (I spent 10 years at Microsoft where it wasn't uncommon to come across 20+ year old code still in use.) More than once I've initialized a new project, started at my blank folder structure, and spent a few minutes thinking "here we go again".
- fotta 4y ago
  Sometimes I call this the “tyranny of choice”, tyranny is probably the wrong word but it sounds nice. It’s pervasive in lots of aspects of my life beyond programming, where I get anxious having to make decisions. I will drag my feet to have to make a final decision, even if it’s a restaurant choice. I’d much rather have the obvious right choice in my face than have to pick between multiple good choices. I face this same anxiety when staring at a blank source file too. (Yes, I’m working on finding a therapist, but even picking one gives me the same anxiety)
  - clairity 4y ago
    that’s usually referred to as the paradox of choice and is an active area of research in psychology and decision theory (economics).
  - galaxyLogic 4y ago
    It can be experienced in a lot of situations. Buying a burrito from Chipotle means you have to make lot of choices before you get your burrito. This means you become partly responsible for the quality of the product you pay for. If the burrito is bad, you are to blame because you chose the ingredients. I think that makes me anxious when in Chipotle's. In programming it does slow your progress if you have to frequently spend time deciding which choice is the best. Not only anxiety but also plain lost time.
  - InitialBP 4y ago
    Similar term although with a slightly different meaning that I use "analysis paralysis", when you get so caught up in trying to figure out the "correct" answer that you get stuck.
frickinLasers 4y ago
I think I would identify as a jiggle programmer. I was raised on a REPL, and in that case I find it pretty efficient, time-wise, to scribble something in the terminal, jiggle things around it until it works, and insert the working prototype into the program I'm working on. Programming isn't my day job, but I do frequently write code from scratch (and refactor it, heh). I interviewed for one entry-level programming position; they did not appreciate my technique.
- dexwiz 4y ago
  I think this approach is really common for programmers who aren't programmers first. REPL and Excel both really encourage this style due to their near instant feedback loops.
  - sn9 4y ago
    On the other hand, a generation of world-class programmers were raised on the REPL and interactivity (e.g., Lisp and Smalltalk programmers from the 70s-80s). And interactivity can be an extremely effective way of experimenting and learning how things work and fit together so that you can rapidly develop a mental model of your core primitives and how to put them together in different ways. It's also part of the appeal of TDD. Small iterative loops with rapid feedback.
anonytrary 4y ago
This is a simplistic reduction of what many senior programmers do. In my experience these so-called "jiggle programmers" are ones who actually ship code and meet business needs. Sometimes that's what we're looking for. We don't always want a fresh grad who is keen on implementing a completely useless system from scratch. We need people who ship.
- mschild 4y ago
  I think the big differentiating factor will probably be that "jiggle programmers" don't really know what they're copying or why something works. I'd hope senior programmers do.
  - paulryanrogers 4y ago
    We all jiggle a bit as we rarely have time to work through APIs and their dependencies down to the sand used to make the chips. Though I'd agree that no engineers should be copying code without understanding its intent and interfaces.
- hedora 4y ago
  This is why it's important to figure out what your core expertise is. If you're copying and pasting your core expertise from stack overflow, then, I hate to break it to you, but you'll never successfully differentiate your product.
  - BossingAround 4y ago
    Ah yes, because innovative software products invent new coding paradigms, which is exactly how they get to be so popular. That makes sense.
  - anonytrary 4y ago
    I'd wager that 90%+ of "tech" companies are hiring software engineers to "solve" technical problems that have already been solved in order to solve business problems that have not yet been solved. Very rarely do you see a startup hiring to solve brand new technical problems. At the end of the day, most engineering work boils down to implementing CRUD apps with textbook architecture.
jmcgough 4y ago
Green-field projects help a lot for getting over this mindset. Having to figure out the right patterns and approaches by myself then live with those decisions and have to improve them down the line taught me much more than extending existing patterns in a mature codebase.
at-fates-hands 4y ago
> They usually cannot write code from scratch True > I do think Google has caused some of this. I think it a lot of it is the frameworks and people constantly trying to shortcut the method of building something with code. We have so many frameworks, tools, plugins and other stuff that it makes it easier NOT to learn anything deeply any more. Pick a JS Framework and I'll give you a dozen plugins or tools that have already been built to write your code for you. All you, as a developer have to do is string them together. By building all of these shortcuts, no one really needs to learn Angular, you have their site as a reference and tons of material to help you. Developers actually learn in the absence of knowledge where they have to sit down and learn it without knowing there is a crutch or fallback if they get stuck. I think today's developers just get as far as they can and then start googling for a solution because they know that someone has already built a date picker in ten different languages, thousands times already. Why go back and reinvent the wheel when you don't have to? Because it creates lazy developers. An entirely other issue is why learn some framework inside and out if its going to be obsolete in a few years? Remember when everybody loved Backbone and Express? You tell someone in the Dev community today you use either of those and you'll get laughed right out of the bar. I think its just a lot of things that work against developers learning more than then they really need in any given situation.
soneca 4y ago
I jiggle code around until it works. But I am also very smart. If it doesn’t work by jiggling, I learn or invent a way to make it work. I am a self-taught programmer. I copy, but I also innovate. I don’t follow at all the academic approach (I never studied CS or was very good in school). But I don’t paralyze when I can’t find anything to copy from like a Roomba stuck on a rug. Do you have a term for me?
- dexwiz 4y ago
  I don't know you, but solely from this post I am going to go with "likely overconfident."
  - soneca 4y ago
    That’s fair. But I also know a lot about what I can’t do. I don’t have the knowledge (and maybe the capacity to acquire the knowledge) to work on really complex stuff. Like, solutions that work well on the scale of hundreds of millions of user (I work on web development for context). I also wouldn’t be capable of working on embedded systems or any system which just can’t fail. Also, academic research on computer science, as I lack much of the basics. I am happy building websites and web apps. But I am confident enough to know I can innovate and create complex solutions for the kinds of problems I face.
- goldenkey 4y ago
  Hmm. I'm smart and innovative too! I flipped my couch cushion over after my dog shit on it. Maybe we are both revolutionaries?!
  - soneca 4y ago
    Sorry, I didn't understand the underlying message that your sarcasm was intended to pass.
    - goldenkey 4y ago
      Maybe we're not as alike as I thought.
potatosalad1 4y ago
I'm a designer who codes in this way. I can mock out a bells and whistles prototype that appears to work splendidly enough to test with users, but in reality I'm just hooking together libraries and pasted code. I have been doing this for 10 years, enough debugging savvy to "learn" React in 2 weeks but do I actually know how any of it works on a deeper level? Heck no.
smsm42 4y ago
Jiggling is much easier. I could probably jiggle code in any reasonable programming language within a week or two, without knowing it beforehand. Less if it resembles any mainstream language I know. Building a project from scratch requires much more deep experience and understanding. And yes, I learn most effectively by copying too. Showing me a couple of working project and letting me implement a bunch of simple tasks by jiggling existing ones usually works for me way faster than throwing manuals and tutorials at me. Manuals have its place - when I know enough to know what to look up - and so do tutorials, but "learn by copying" is the most optimal way of getting bootstrapped for many people, including me. There's nothing wrong with that, if you don't stop at that stage but continue learning.
swat535 4y ago
I mean, why on earth would you not use existing infrastructure and always keep writing code from scratch ? If I see an engineer constantly do this, I would think that they are insecure and are constantly attempting to prove that they are "real" programmers (whatever that means). The way I see it, we are here to solve business problems and the chances of your problem being so unique that similar solutions don't already exist is rather low. Let's face it, the majority of software work is pluming work and wiring APIs these days. Very few people are tasked with implementing their own sorting algorithm and even if they are, you can bet that they will scaffold from another algorithm to get started.. Yes, one should not blindly copy and paste from Stackoverflow but researching, refactoring, thinking about the task at hand and using existing tools and libraries are all part of the process.
orwin 4y ago
Arg. I think I'm the opposite, but worse. I cannot finish a project. I took a 6 month sabbatical, started 5 projects, didn't finish even one. My last project i tried to use tracking/productivity tools, it doesn't change anything. I have the 'well, good enough' mentality with my own projects, and once i stop having fun coding i just stop. And start another project. My current project is boring (especially since i finished the code logic like 9 months ago), but since I'm paid to upgrade/deploy the stuff I'm not that disfranchised. (I won't lie and say I'm as productive, I'm clearly not) I don't think I'm really able to work alone or unpaid. Which is weird, because I really, really enjoyed the two dozen school projects I've done, especially those who took 2+months
valand 4y ago
From my observation, we programmers are supposed to have two non-discrete modes of programming: 1.) the trial&error (or jiggle) mode and 2.) the literate mode. Trial&error mode works well when working with randoms, e.g. exploration, research, acquiring information, identifying unknowns. Literate mode works well when working with exacts. Identifications for example produce exacts from unknowns. Enough facts enables you to build stuffs out of it like Lego. This is where literate mode works well. Jiggle programmers that does not quite grow out of their jiggling mode is because they stay in trial&error mode and does not slide slowly into the literate end of the spectrum. After acquiring some facts, they don't deduct or intuit from them. They don't attempt to philosophize a bit. A problem as simple as "how to do X after the window loads" for example, some programmer can find `window.addEventListener("load", X);` in stack overflow, but the main differentiator lies whether after fixing the issue, they care enough to at least wonder about what's the meaning of `window`, `addEventListener`, `load`, "why is the call shaped that way", "what is Event and what is Listener". Those who do slide slowly into their literate mode. It is also not less dangerous to be stuck in the literate mode. Although this happens rarer, often to more experienced people.
usrn 4y ago
Where are these jobs where you can write things from scratch? I do that on the weekends for free to recover from all the "jiggle" tickets I get in Jira. My impression is that a trend started in the 90s which has taken over the industry where programmers that are capable of building things from scratch and keeping everything in their heads are much less valuable compared to those who are "weaker" but much more capable of communicating and cooperating.
lkxijlewlf 4y ago
> I have a parallel term I use, jiggle programmers. They can jiggle code around until it works, often working off existing code. We're all jiggle programmers then. Once the applications architecture is established, we hang new feature on it by following that architecture. Very very few of us get to only write code from scratch every day. Most of the time, when I'm writing from 0, I'm working on a R&D PoC. If I'm not doing that, I'm jiggle programming a new feature into an existing architecture. > With the rise of self-taught programmers, you will see more take this copying approach than the academic redistillation. I was self-taught before university. I learned on a C=64 and then an early x86 back in the day. If you didn't figure it out on your own, you hoped you would see it in a magazine or book some place. I learned a lot about how computers worked at a fundamental level from the C=64. I don't think self-taught is the issue. I think it's how much the person really wants to know about computers and CS.

by dexwiz 4y ago

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.
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...

com2kid 4y ago

As someone who has kicked off multiple "from 0" projects, including a startup and been on the initial team doing an entire embedded runtime, Blank source files are scary yo. There are a near infinite number of choices that can be made when confronted with a blank file. And the ramifications of those initial choices will live on, possibly for decades! (I spent 10 years at Microsoft where it wasn't uncommon to come across 20+ year old code still in use.) More than once I've initialized a new project, started at my blank folder structure, and spent a few minutes thinking "here we go again".

fotta 4y ago
Sometimes I call this the “tyranny of choice”, tyranny is probably the wrong word but it sounds nice. It’s pervasive in lots of aspects of my life beyond programming, where I get anxious having to make decisions. I will drag my feet to have to make a final decision, even if it’s a restaurant choice. I’d much rather have the obvious right choice in my face than have to pick between multiple good choices. I face this same anxiety when staring at a blank source file too. (Yes, I’m working on finding a therapist, but even picking one gives me the same anxiety)
- clairity 4y ago
  that’s usually referred to as the paradox of choice and is an active area of research in psychology and decision theory (economics).
- galaxyLogic 4y ago
  It can be experienced in a lot of situations. Buying a burrito from Chipotle means you have to make lot of choices before you get your burrito. This means you become partly responsible for the quality of the product you pay for. If the burrito is bad, you are to blame because you chose the ingredients. I think that makes me anxious when in Chipotle's. In programming it does slow your progress if you have to frequently spend time deciding which choice is the best. Not only anxiety but also plain lost time.
- InitialBP 4y ago
  Similar term although with a slightly different meaning that I use "analysis paralysis", when you get so caught up in trying to figure out the "correct" answer that you get stuck.

frickinLasers 4y ago

I think I would identify as a jiggle programmer. I was raised on a REPL, and in that case I find it pretty efficient, time-wise, to scribble something in the terminal, jiggle things around it until it works, and insert the working prototype into the program I'm working on. Programming isn't my day job, but I do frequently write code from scratch (and refactor it, heh). I interviewed for one entry-level programming position; they did not appreciate my technique.

dexwiz 4y ago
I think this approach is really common for programmers who aren't programmers first. REPL and Excel both really encourage this style due to their near instant feedback loops.
- sn9 4y ago
  On the other hand, a generation of world-class programmers were raised on the REPL and interactivity (e.g., Lisp and Smalltalk programmers from the 70s-80s). And interactivity can be an extremely effective way of experimenting and learning how things work and fit together so that you can rapidly develop a mental model of your core primitives and how to put them together in different ways. It's also part of the appeal of TDD. Small iterative loops with rapid feedback.

anonytrary 4y ago

This is a simplistic reduction of what many senior programmers do. In my experience these so-called "jiggle programmers" are ones who actually ship code and meet business needs. Sometimes that's what we're looking for. We don't always want a fresh grad who is keen on implementing a completely useless system from scratch. We need people who ship.

mschild 4y ago
I think the big differentiating factor will probably be that "jiggle programmers" don't really know what they're copying or why something works. I'd hope senior programmers do.
- paulryanrogers 4y ago
  We all jiggle a bit as we rarely have time to work through APIs and their dependencies down to the sand used to make the chips. Though I'd agree that no engineers should be copying code without understanding its intent and interfaces.
hedora 4y ago
This is why it's important to figure out what your core expertise is. If you're copying and pasting your core expertise from stack overflow, then, I hate to break it to you, but you'll never successfully differentiate your product.
- BossingAround 4y ago
  Ah yes, because innovative software products invent new coding paradigms, which is exactly how they get to be so popular. That makes sense.
- anonytrary 4y ago
  I'd wager that 90%+ of "tech" companies are hiring software engineers to "solve" technical problems that have already been solved in order to solve business problems that have not yet been solved. Very rarely do you see a startup hiring to solve brand new technical problems. At the end of the day, most engineering work boils down to implementing CRUD apps with textbook architecture.

jmcgough 4y ago

Green-field projects help a lot for getting over this mindset. Having to figure out the right patterns and approaches by myself then live with those decisions and have to improve them down the line taught me much more than extending existing patterns in a mature codebase.

at-fates-hands 4y ago

> They usually cannot write code from scratch True > I do think Google has caused some of this. I think it a lot of it is the frameworks and people constantly trying to shortcut the method of building something with code. We have so many frameworks, tools, plugins and other stuff that it makes it easier NOT to learn anything deeply any more. Pick a JS Framework and I'll give you a dozen plugins or tools that have already been built to write your code for you. All you, as a developer have to do is string them together. By building all of these shortcuts, no one really needs to learn Angular, you have their site as a reference and tons of material to help you. Developers actually learn in the absence of knowledge where they have to sit down and learn it without knowing there is a crutch or fallback if they get stuck. I think today's developers just get as far as they can and then start googling for a solution because they know that someone has already built a date picker in ten different languages, thousands times already. Why go back and reinvent the wheel when you don't have to? Because it creates lazy developers. An entirely other issue is why learn some framework inside and out if its going to be obsolete in a few years? Remember when everybody loved Backbone and Express? You tell someone in the Dev community today you use either of those and you'll get laughed right out of the bar. I think its just a lot of things that work against developers learning more than then they really need in any given situation.

soneca 4y ago

I jiggle code around until it works. But I am also very smart. If it doesn’t work by jiggling, I learn or invent a way to make it work. I am a self-taught programmer. I copy, but I also innovate. I don’t follow at all the academic approach (I never studied CS or was very good in school). But I don’t paralyze when I can’t find anything to copy from like a Roomba stuck on a rug. Do you have a term for me?

dexwiz 4y ago
I don't know you, but solely from this post I am going to go with "likely overconfident."
- soneca 4y ago
  That’s fair. But I also know a lot about what I can’t do. I don’t have the knowledge (and maybe the capacity to acquire the knowledge) to work on really complex stuff. Like, solutions that work well on the scale of hundreds of millions of user (I work on web development for context). I also wouldn’t be capable of working on embedded systems or any system which just can’t fail. Also, academic research on computer science, as I lack much of the basics. I am happy building websites and web apps. But I am confident enough to know I can innovate and create complex solutions for the kinds of problems I face.
goldenkey 4y ago
Hmm. I'm smart and innovative too! I flipped my couch cushion over after my dog shit on it. Maybe we are both revolutionaries?!
- soneca 4y ago
  Sorry, I didn't understand the underlying message that your sarcasm was intended to pass.
  - goldenkey 4y ago
    Maybe we're not as alike as I thought.

potatosalad1 4y ago

I'm a designer who codes in this way. I can mock out a bells and whistles prototype that appears to work splendidly enough to test with users, but in reality I'm just hooking together libraries and pasted code. I have been doing this for 10 years, enough debugging savvy to "learn" React in 2 weeks but do I actually know how any of it works on a deeper level? Heck no.

smsm42 4y ago

Jiggling is much easier. I could probably jiggle code in any reasonable programming language within a week or two, without knowing it beforehand. Less if it resembles any mainstream language I know. Building a project from scratch requires much more deep experience and understanding. And yes, I learn most effectively by copying too. Showing me a couple of working project and letting me implement a bunch of simple tasks by jiggling existing ones usually works for me way faster than throwing manuals and tutorials at me. Manuals have its place - when I know enough to know what to look up - and so do tutorials, but "learn by copying" is the most optimal way of getting bootstrapped for many people, including me. There's nothing wrong with that, if you don't stop at that stage but continue learning.

swat535 4y ago

I mean, why on earth would you not use existing infrastructure and always keep writing code from scratch ? If I see an engineer constantly do this, I would think that they are insecure and are constantly attempting to prove that they are "real" programmers (whatever that means). The way I see it, we are here to solve business problems and the chances of your problem being so unique that similar solutions don't already exist is rather low. Let's face it, the majority of software work is pluming work and wiring APIs these days. Very few people are tasked with implementing their own sorting algorithm and even if they are, you can bet that they will scaffold from another algorithm to get started.. Yes, one should not blindly copy and paste from Stackoverflow but researching, refactoring, thinking about the task at hand and using existing tools and libraries are all part of the process.

orwin 4y ago

Arg. I think I'm the opposite, but worse. I cannot finish a project. I took a 6 month sabbatical, started 5 projects, didn't finish even one. My last project i tried to use tracking/productivity tools, it doesn't change anything. I have the 'well, good enough' mentality with my own projects, and once i stop having fun coding i just stop. And start another project. My current project is boring (especially since i finished the code logic like 9 months ago), but since I'm paid to upgrade/deploy the stuff I'm not that disfranchised. (I won't lie and say I'm as productive, I'm clearly not) I don't think I'm really able to work alone or unpaid. Which is weird, because I really, really enjoyed the two dozen school projects I've done, especially those who took 2+months

valand 4y ago

From my observation, we programmers are supposed to have two non-discrete modes of programming: 1.) the trial&error (or jiggle) mode and 2.) the literate mode. Trial&error mode works well when working with randoms, e.g. exploration, research, acquiring information, identifying unknowns. Literate mode works well when working with exacts. Identifications for example produce exacts from unknowns. Enough facts enables you to build stuffs out of it like Lego. This is where literate mode works well. Jiggle programmers that does not quite grow out of their jiggling mode is because they stay in trial&error mode and does not slide slowly into the literate end of the spectrum. After acquiring some facts, they don't deduct or intuit from them. They don't attempt to philosophize a bit. A problem as simple as "how to do X after the window loads" for example, some programmer can find `window.addEventListener("load", X);` in stack overflow, but the main differentiator lies whether after fixing the issue, they care enough to at least wonder about what's the meaning of `window`, `addEventListener`, `load`, "why is the call shaped that way", "what is Event and what is Listener". Those who do slide slowly into their literate mode. It is also not less dangerous to be stuck in the literate mode. Although this happens rarer, often to more experienced people.

usrn 4y ago

Where are these jobs where you can write things from scratch? I do that on the weekends for free to recover from all the "jiggle" tickets I get in Jira. My impression is that a trend started in the 90s which has taken over the industry where programmers that are capable of building things from scratch and keeping everything in their heads are much less valuable compared to those who are "weaker" but much more capable of communicating and cooperating.

lkxijlewlf 4y ago

> I have a parallel term I use, jiggle programmers. They can jiggle code around until it works, often working off existing code. We're all jiggle programmers then. Once the applications architecture is established, we hang new feature on it by following that architecture. Very very few of us get to only write code from scratch every day. Most of the time, when I'm writing from 0, I'm working on a R&D PoC. If I'm not doing that, I'm jiggle programming a new feature into an existing architecture. > With the rise of self-taught programmers, you will see more take this copying approach than the academic redistillation. I was self-taught before university. I learned on a C=64 and then an early x86 back in the day. If you didn't figure it out on your own, you hoped you would see it in a magazine or book some place. I learned a lot about how computers worked at a fundamental level from the C=64. I don't think self-taught is the issue. I think it's how much the person really wants to know about computers and CS.