self-taught devs who learned before the current tool boom: what habits kept you from copying without understanding?
Posted by NeedleworkerLumpy907@reddit | learnprogramming | View on Reddit | 85 comments
Asking this a little carefully because i know this sub has a hard line on certain tools, and honestly i get why. What im more anxious about is the beginner version of the same problem: grabbing autocomplete, snippets, boilerplates, starter repos, or tutorial code so fast that you can make stuff work and then cant explain what you wrote the next day
When i was starting, the most dangerous feeling wasnt being stuck. It was getting unstuck too fast. If i spent 45 minutes fighting some JavaScript bug, i usually remembered the lesson. If i pasted something from a snippet site and moved on in 2 minutes, it felt productive for a second, then the same idea would show up wearing a fake mustache and id freeze because i never actually learned it
My take rn is pretty blunt: help is fine, speed is fine, but if youre regularly accepting code you cant recreate from memory or explain line by line, youre borrowing confidence on credit. Beginners definately pay for that later. The stuff that made me improve was slower and more annoying, rewriting examples without looking, deleting working code and rebuilding it, forcing myself to predict output before running it, keeping projects small enough that i couldnt hide behind complexity. Annoying. But useful
For people who got thru the early phase without turning every roadblock into a copy-paste moment, what guardrails did you use? Not generic "practice more" advice, i mean actual habits that made you confront your own understanding instead of outsourcing it
ZYLIFV@reddit
You should get into the habit of breaking the problem down more and more until you understand why each component adds to the overall end goal of what you're trying to achieve. Do this and you'll appreciate clean and refined code much more than the slop AI spits out.
Alternator1994@reddit
As someone who learned how to code with The Odin Project, got the job, worked without AI for 2-3 years, and was enforced with use AI as much as possible and now educates juniors who got first job, hear me out.
Writting, reading, understanding and debugging code manually contributed a lot to my developer skills. With arrival of AI I noticed that my learning trajectory slowed down a lot. It got worse as soon as my company enforced us to use 100% of AI all the time, and are enforcing AI pull requests and AI code reviews. It's all just a hot mess and I decided to leave the company, to find something more meaningful.
What I noticed with juniors at that company, is the false feeling of accomplishment. They are shipping like crazy but have no idea what they are doing and what they are shipping. They would come to be like "Hey, Claude told me to do that. I don't know how it works but it works", or "Hey, Claude made this change, it looks stupid, what should I do. should I leave this at is?"
If you ask me, juniors should write all the code manually, and later be introduced to AI, but in a separate chat window where they still have to manually figure out where to put the code.
As soon as AI got integrated into code editor, everybody got false sense of capability and skill. I felt that too, but since I experienced timeline of struggling and doing code implementations manually, I understand the importance of doing it manually and the difference and how bad letting AI doing everything can be harmful long-term.
I'd say that AI would stop natural progression of juniors moving into mid positions now, and juniors are less hired anyways.
For self learners that have not started to work yet: Please do everything manually, cut AI from the start. If stuck at a problem, give yourself hour or two of struggling before reaching out to AI for a solution. This is only way you can grow as a developer. If you still decide to use AI, don't integrate it in your code editors like Codex or Claude Code for example. You will never get a job like that.
Accomplished_Let7429@reddit
u/NeedleworkerLumpy907 This hits hard because you nailed the actual problem. I started the same way, and honestly the turning point was forcing myself to write things twice. Not copy-paste twice, but actually rewrite from scratch the next day without looking at my notes.
The confidence thing you mentioned is real. You feel productive pasting a solution, but you're just borrowing understanding. What helped me was treating every piece of code like I had to explain it to someone else the next morning. If I couldn't, I didn't move on.
One habit that stuck: I'd delete working code and rebuild it. Sounds wasteful, but it forces you to actually learn why it works instead of just knowing that it does. Same with predictions before running anything. Makes you slow down and think instead of just iterating until it works.
Accomplished_Let7429@reddit
u/NeedleworkerLumpy907 This hits hard because you nailed the actual problem. I used to force myself to rewrite solutions without looking at the original code, and yeah it was annoying as hell but it stuck. The key thing nobody talks about is that speed feels like progress when you're learning but it's actually just debt. You can't explain what you built because you never built it, you assembled it. Comment-driven development helped me too, where I'd write out the logic in plain English first before touching any syntax. Forces you to actually think instead of letting your fingers copy-paste on autopilot. The pattern I noticed was people who got good weren't faster, they were just willing to delete working code and rebuild it from scratch to understand why it worked.
born_zynner@reddit
I have a bit of a different path that I took. I studied electrical engineering in a power systems focused program. I had 2 basic embedded systems courses and those were the only programming classes I took, but I enjoyed them and did some embedded for fun on the side every once in a while.
Well I graduated right around when covid hit so the job market was weird, and I knew i wanted to try do something embedded related, and luckily a good friend from high school was able to hook me up with an interview at an embedded consulting startup, and I got the job.
It was an insane trial by fire. I was put on my first project totally by myself. I had only ever touched C before. First project ended up being a Human-Machine-Interface which ended up being essentially embedded + full stack web ran locally. Actually a really really good learning experience. Of course I googled pretty much constantly. LLMs weren't a thing yet. Learned more in that 1st month than 4 years of school. I had to understand it because I was building the whole damn thing.
Moral of the story is learn by doing, get out of your comfort zone, use nicotine products and coffee if you need.
therealwhitedevil@reddit
Literally the fact that not once did I ever copy anything worthwhile that just worked…
I always had to make it fit into my project so I had to then learn it so I could make it work for my use case.
yaycupcake@reddit
If I don't understand my code, I just get annoyed. I'm very particular about how I structure things, from overall architecture to style choices to naming conventions. I don't like having loose parts floating around in my code so I have to understand it.
If it's my personal project, I heavily comment stuff that's actually important because I don't want to forget what it's here for. Yeah I know coding logic inherently but I want all the details. I'm autistic so that's just how my brain works. But because of that, if I didn't write the code, I need to still fully understand it so I can write all my notes, to keep everything comprehensive and cohesive.
If I'm working on stuff with other people I can't be as picky, but when I was learning at first (long before AI coding) it was the way I did things, so it's somewhat ingrained into me. If I don't understand, I ask questions until I do, or I don't use it.
bobo76565657@reddit
When I started programming there was no copy/paste and no internet. I did copy from books, but that means I had to actually read the book, and then type it in myself. It helps you learn faster. Books still exist.
desrtfx@reddit
When I learnt programming, there was nothing of that. There was no AI, there was no internet. All that I had was the BASIC (programming language) manual that came with my computer. There even were barely any knowledgeable people in my (rural) area.
So, the only way was to try and err and eventually succeed.
Struggling is the way to learn, not getting solutions served.
If you get a solution you have your problem solved, but will learn next to nothing from it and the next time you run in a similar problem, you will not be able to fix it.
Learning programming involves a lot of experimenting, try and err, failing, struggling, fixing.
It does not involve getting direct solutions. The "fast and easy track" doesn't work.
de_propjoe@reddit
There were magazines and books you could copy code out of. I learned BASIC by copying code line-for-line out of magazines. Saved them on cassette tape. When it didn’t work of course I had to figure out why, and sometimes that meant rewriting everything from scratch. I learned a lot that way. And of course I eventually started writing my own programs from scratch.
I just flat-out disagree that you can’t learn programming via copying or having “solutions served”.
Infinite_Tomato4950@reddit
still try and error is the way even with ai. like i have learned to use cc much better by just testing things and learning
Symmetric_in_Design@reddit
Yeah but you're still not going to understand your code nearly as well as if you wrote it, which is the point of the post. Using cc to code is a different skillset entirely
Infinite_Tomato4950@reddit
okay i get you
pm_your_unique_hobby@reddit
Ai gets me to a place where i can sandbox and grapple with concepts a bit quicker and easier, but yeah there's no substitution for grinding it out with the concepts and trial and error. Theres an increase for efficiency, but not for understanding... for me anyway.
jalagl@reddit
Same here, I had the Deitel and Deitel C/C++ and Java books, Kernighan and Ritchie C manual, a few other books, plus man pages and javadocs.
You had to figure things out on your own through trial and error, and asking/discussing with your coworkers.
Jolly_Drink_9150@reddit
Agreed, but if you are stuck on something for a week, i feel like finding a solution is just better? What's the point in struggling with something you can't complete? Sometimes finding a solution gives me new ideas and i implement the new ideas rather than use what was given to me.
Both are advantageous for sure, like if you are doing something that is very niche then a solution isn't going to be readily available, so you are forced to do it, which is fine as well.
syklemil@reddit
The point may be that your brain needs time to form the connections you need to be able to complete it. As an old blog post puts it:
desrtfx@reddit
If you're stuck for some time, move on and do something else. Quite often, the solution will come by itself.
There once was an exercise somewhere that I could not solve, no matter what. I left it, returned after some time, could still not solve it, left it, and roughly after four retries and a couple months I returned and solved it in less than 10 minutes. The exercise did not leave me alone and I wanted to solve it.
IMO, trying to bite through, with leaving it alone for some time, is the better way.
As I said, when I learnt, getting solutions simply was not an option. There were no solutions. The only way was biting through.
Today, also, persistence and the stubbornness to not give up are commonly lacking. Instant gratification in very short time is what people go for.
DonkeyAdmirable1926@reddit
I see your point but respectfully disagree a bit. I found that struggling knowing there is nobody coming to save you, helps finding it even after a month. My experience is that putting the problem away for a week, work on something else and then return, can work miracles. And you don’t forget the solution you found yourself
NeedleworkerLumpy907@reddit (OP)
Rebuild working examples from scratch without peeking, predict the output before you run and write a failing test first, delete working code and reimplement it in a different style, force yourself to explain each line out loud or write a one-line comment saying why it exists, disable autocomplete/snippets for learning sessions and timebox searches to 15 minutes so you dont bail to copy-paste, read the minimal source or docs for any library you copy (even skim teh source), keep projects tiny so you cant hide behind complexity, and yeah it sucks but youll definately remember it better
desrtfx@reddit
Did you even try to comprehend what I said?
NeedleworkerLumpy907@reddit (OP)
I did, youre wrong
desrtfx@reddit
If you did, why does your reply have absolutely nothing to do with what I said?
You just regurgitated what you said in your original post in a slightly different wording.
scritchz@reddit
Don't ask open questions if you shut down people who are answering genuinely.
NeedleworkerLumpy907@reddit (OP)
Im not shutting anyone down, youre definately overreading this
scritchz@reddit
No, I'm not. You're wrong.
NeedleworkerLumpy907@reddit (OP)
Nah, youre overreading it
DonkeyAdmirable1926@reddit
Are you here for answers or to disrespect people helping you?
NeedleworkerLumpy907@reddit (OP)
Look, Im definately here for real advice about not copy-pasting, not to disrespect people
MihaiBuilds@reddit
breaking stuff on purpose and fixing it. in industrial automation if you don't understand what your code does, something physical breaks. that habit carried over — I still delete working code and rewrite it when I don't fully trust that I understand it. annoying but it's the only thing that actually sticks.
WillAdams@reddit
For me it has been using Literate Programming:
http://literateprogramming.com/
Any bit of code has to have documenting text which is structured so as to make referring to it straight-forward.
UmbralFae@reddit
For me, I would copy, see if that solution worked, and then I would go step by step through what I'd copied to figure out why it worked then refactor as needed.
PradheBand@reddit
I had to debug enough code in my life that I know I must understand what I write or generate. Or what someone wrote if I'm reviewing.
Bitter-Reading-6728@reddit
what kept me from copying without understanding was a desire to learn to code. it wasn't until it was my job with deadlines that I resorted to occasionally copying.
StoneCypher@reddit
lol no, the people moaning about ai live and breathe stack overflow copy pasta
desrtfx@reddit
It absolutely has been the case. In the times before BBS and the internet people were on their own.
StoneCypher@reddit
i mean i'm from before bbses, and almost everyone i knew who "wrote games" were just copying the turtle graphics listings for the car game from the back of the atari manual and swapping out the image
nobody ever got as far as adding an obstacle to crash into
owjfaigs222@reddit
Well if you are learning, you purposefully don't want to check how to solve a programming problem in order to figure it out yourself. I made a lot of stuff from start to finish without copying any code, just a handbook. I think that gave me a lot of understanding I might have missed otherwise.
Witty-Afternoon-2427@reddit
Rewriting code from scratch without looking and forcing myself to explain each line out loud helped way more than just making it work.
ElectronicCat8568@reddit
When I started it was you, a language, and your ingenuity. I felt things getting disconnected around the time webdevs started laughing at people for actually building a feature instead of using a library. I associate the mass adoption of the term "don't reinvent the wheel" with the beginning of most new webdevs being worse at the job on average than their predecessors.
Phytocosm@reddit
Just an ounce of foresight. I practice to improve my skills, not to degrade them.
james_d_rustles@reddit
Just being genuinely interested makes it a whole lot easier to learn what’s going on. My field of study was mechanical engineering, I got really interested in arduinos early on. Learning something new usually started with thinking something like “wouldn’t it be cool if I could do x instead of y?”, that would lead to some googling and reading, I’d fiddle around and apply the concept to whatever I was working on.. it’s hard to be creative or add anything new if you don’t get what’s already happening, so it was just a natural process of reading and learning as I went.
Probably not the best way to learn since I feel like I memorized a good bit of syntax and like little mental snippets without fully understanding fundamentals like algorithm complexity and data structures and whatnot, but when I revisited those fundamentals at least I can say it was pretty easy to wrap my head around since I wasn’t simultaneously struggling to understand how to run a python script.
Honestly even these days, I feel pretty confident in my overall knowledge and there are times I’ll want to copy and paste something, but as long as we’re talking about relatively small blocks and whatnot I’ve found that actually typing it out line by line, even if I am directly ripping from a different source, forces me to ingest/understand what’s going on way more than simply copy pasting a whole section. It feels meaningless, but the typing is just a way of forcing you to slow down enough to actually read.
TLDR: find something you’re curious enough about to actually want to know more.
Jarvis_the_lobster@reddit
For me it was forcing a rewrite after I finished following something. Not from memory perfectly, just enough that I had to make decisions instead of tracing someone else’s footsteps. Also pausing every time I hit code I couldn’t explain and making myself answer "what would break if I removed this?" before moving on.
downshiftdata@reddit
A general lack of trust really helps here.
mxldevs@reddit
Starter code is fine: you get a working example and then you can see all the different parts that go into it.
Sometimes I do skip the understanding because the whole point of using the library was to not have to understand how to do it myself in the first place.
curious_dax@reddit
Tutorials get you syntax. You only learn to think by building something real. Start way before you feel ready.
National-Motor3382@reddit
the single best thing i did was keep a "confusion journal." not a learning journal, a confusion journal. every time something worked and i didn't know why, i'd write it down. then on weekends i'd pick one and dig into it until i could explain it to someone who'd never coded.
the other thing: i banned myself from tutorials for a month. sounds extreme but i was stuck in tutorial hell and didn't even realize it. i picked one tiny project (a CLI todo app) and only used docs. no youtube, no blog posts walking me through it. it was miserable for about 3 days and then something clicked.
also, rebuilding things you already built is underrated. take something you made 2 months ago and redo it from scratch without looking at your old code. that's where you find out what you actually learned vs what you just survived.
code-garden@reddit
Write the code into the file myself instead of copy pasting. Read the relevant docs. Try out different variations.
etoastie@reddit
Read the docs for the things you're using.
This goes for shell commands as well as code. If you see any function or library or tool you don't know, find the doc and read at least the stuff that's relevant to the call you see. But usually these docs have a lot more info around it and can be quite fun. As a fun example: if you haven't read the manpage for
cdin a modern shell, you're in for a treat, when I first checked it I learned like 5 new things I had no idea about.This has a few benefits. The first is that you learn the thing. The second is that you get more comfortable leveraging the documentation format of your tools, so when you need them you know how to use them. The third is that you also learn things that aren't directly related to your current task, but may be relevant later and you know how to find the refs when you need them. The fourth is that it gives you early warning on if the solution actually solves your problem, or if there's pitfalls that you may need to be aware of. I'm probably missing others.
jaynabonne@reddit
You will need to understand the code one way or another. At least, it's always worked out that way for me. If you have a codebase that you're dropping some code into, you need to be sure the code is doing what it purports to do. You can never be sure if you just take it blindly.
So, there aren't that many guardrails beyond "I'm not going to infect my codebase with something I don't trust."
And for me, it's not a question of memory. It's not a question of "Can I reproduce this?" If I'm looking it up - and it's not just some idiomatic query about "how do I do X in language Y" - then it's usually something I couldn't have created without looking it up to begin with anyway.
To give a concrete example, I was working with USB code in embedded Linux. You could probably spend hours perusing docs and still be no further ahead. But some code that does what you want - that shows how the pieces get put together - is invaluable. I found some code that did what I wanted, but there was a good chunk of it. So, I brought it over and not only began going through it line by line, I began adjusting it line by line, adapting it to not only my codebase's style but my own personal way of expressing what it was doing.
In the end, I had code that matched my codebase, that I had personally sent into my brain and back out again, and with two fewer bugs in it, as the original code had some issues.
Could I have recreated it at that point? Possibly. But there were a lot of details in it. Could I recreate it now? No. The point of it all is that the code embodied knowledge that I didn't have. I didn't have to have all of that be "knowledge in the head" when it could easily remain "knowledge in the world". But I had to vet the code and properly integrate it into both my existing code and my way of doing things.
I have no problem with copy/paste as a first step. But it's only a first step. You then have to take the code and make it part of your larger work and your larger consciousness. The final product is something you have to be confident of, and random code you find on the internet may or may not work as you want, or work in all cases as you want. You have to understand not only what it's doing (to some extent - I may not, for example, understand all the mathematics involved in a crypto algorithm), but you also have to understand what its limitations are. If you're bringing a new dog into your pack, you have to make sure it won't bite the other dogs' heads off.
In other words, you have to understand what the code does and what it needs.
(I first wrote code on an Apple II+ computer, before there was even an IBM PC. You learned from magazines, books and other people. And the mechanism for learning was usually expressed as code. You learned code by seeing code and then writing code. I think that is still true. You have a bootstrap issue where you can't just plod ahead and try to work it all out. You need enough knowledge to know what you don't know, and then the experience of looking up what you don't know. So, you have to start somewhere. Once it begins to make sense, then you build on that by seeing how others have done things. You adapt and adopt, both code and techniques. But if you don't know what you're using, then it doesn't gain you anything.)
Frolo_NA@reddit
TDD. writing the test before the code means you have to understand what you are about to write
FlatwormLonely6291@reddit
grug no get, grug no move on
AlSweigart@reddit
Typing the code instead of copy/pasting.
Ani-3@reddit
I have been successful learning by using it as a professor with office hours.
You have the ai prompt you and YOU write the code and submit it without getting even an initial framework.
If you don’t get it right ask why.
If you don’t understand why ask again,
Do not use it to give you the solution right away.
DonkeyAdmirable1926@reddit
I learned coding on a TRS 80. Basic in ROM, NewDos/80 and Assembler on disk. My learning tool was Rodney Zacks’ book on the Z80. Still have it, still works (both the TRS 80 and the book)
How I learned? Well, just started, feeling a god in a newly discovered universe and build, build, build. Failing all the time. Learning. Building more.
NeedleworkerLumpy907@reddit (OP)
That TRS-80 honesty is exactly it, I force myself to delete working code and rebuild it from memory, switch off autocomplete and type teh examples by hand, predict the output before running, write a single failing test first, and explain each line out loud to an imaginary rubber duck so I can actually say why it works, its annoying but it definately paid off, dont skip that part
DonkeyAdmirable1926@reddit
Why are you telling this to everyone who answers your question?
Mister_Uncredible@reddit
Because they're AI written responses.
NeedleworkerLumpy907@reddit (OP)
Im not telling everyone, im saying dont copy-paste code you cant explain
desrtfx@reddit
In every single comment you're regurgitating the same, like a broken record.
I seriously doubt that you even know what a TRS-80, or a Z-80 CPU are. These are things from the 1980s.
Don't pretend you know what people are talking about if you have no clue.
DonkeyAdmirable1926@reddit
I think you are telling people you asked how they learned. Call me overly sensitive if you like but I find it weird to respond in this way
Formal_Wolverine_674@reddit
I forced myself to rewrite any copied code from scratch and explain it out loud like teaching someone else before moving on
Aggressive_Ad_5454@reddit
I friggin' hate hate hate trying to debug stuff I don't understand. It's hard enough to debug stuff I do understand.
So I make sure I understand stuff. Good tools help with that.
NeedleworkerLumpy907@reddit (OP)
As you said you hate debugging, here's what I do: I delete working snippets and rebuild them from memory, write a tiny failing test to lock down teh behaviour and explain each line out loud (which sounds dumb but helps), if I cant reproduce it I treat it like homework instead of shipping it, and I force myself to predict the output before running, its annoying and definately slower but it teaches the mental model so the next time youre not stuck
aqua_regis@reddit
You did not even comprehend what the previous commenter said.
They did not say that they hate debugging. They said they hate debugging things they do not understand, which is completely different to what you respond to.
Stop babbling the same over and over and actually read and comprehend what people tell you, or are you just a Markov-Chain model that runs in ELIZA mode?
numbersthen0987431@reddit
When I copied code, I would leave comments about what each line/chunk was doing, so I would at least understand what I was implementing before copying.
NeedleworkerLumpy907@reddit (OP)
I wrote comments for each chunk, then closed the tutorial and rewrote the feature from memory while narrating what each line did out loud, its definately slower but i actually remembered and could explain it later
brandi_Iove@reddit
i genuinely want to understand what my code does. it‘s that simple. regardless of stack overflow back in the days or today’s ai, i want to know what’s going on, for several reasons.
NeedleworkerLumpy907@reddit (OP)
i talk through each line and say what state changes and why, then rewrite the example from memory, delete the working code and rebuild it, add a tiny failing test then make it pass so you see the output concretely, timebox any copy-paste to 5 minutes and jot a one-line note why i accepted it (if i cant explain it in 60s i trash it), and yeah i definately still do this on stuff at work
IHoppo@reddit
Has anyone explained to you how to write readable code? You shouldn't need to do this, just write your code in a readable way, then it all becomes easy to read. If you're looking at someone else's code and you don't understand it, then refactor it - even the simple act of using well named variables, classes and method names can take unreadable code into understandable code.
NeedleworkerLumpy907@reddit (OP)
For beginners refactoring alone often fails, so i timebox copy-paste to 5 minutes, rewrite examples from memory, add a tiny failing test and if i cant explain the code in 60s i delete it
IHoppo@reddit
It's always amusing when people ask for help and then let you know that your advice is wrong.
You have already said that your current methodology isn't working, why now double down on it?
NeedleworkerLumpy907@reddit (OP)
Those habits are guardrails that force you to explain code in plain terms (rewrite from memory, delete working code and rebuild, add a tiny failing test, timebox copy-paste to 5 minutes and jot a one-line reason), ive used them for years and they stopped me from cobbling together fragile crap i couldnt fix later, theyre annoying but they work, definately
IHoppo@reddit
Again, write the code using good naming practices and it not only all becomes moot, but whoever ends up looking after your code will be able to. You're introducing completely unnecessarily steps (although obviously write negative and positive unit tests).
Cole1220@reddit
Have you had it give you a slight wrong answer yet? If you have, the huge waste of time is enough to not let it be the copy-paste solution. If not, think about how you're losing your opportunity to come up with ideas and solutions, growing your knowledge base and skill level. I still use it for implementation help and alternate solutions and documentation lookup, but you gotta keep your own skills.
NeedleworkerLumpy907@reddit (OP)
I try to get into the habit of retyping any snippet by hand so you actually understand it, narrating what most lines do and guessing the output before you run it, then delete the working version and rebuild it from scratch later to see if i can reproduce it from memory, it sucked at first but it definately stuck better and now I use AI only for implementation details, dont let it become your crutch
erc2nd@reddit
An actual desire to learn and understand. A desire to one day be the sort of person who knows their tech truly inside out.
For a more practical answer: If genuine time crunch forces me to take short cuts, I literally write down everything I didn't understand and then go back to it as soon as I can to study it in depth.
UnfairDictionary@reddit
Interest in programming and curiosity/need to understand. My thirst of knowledge is mever ending and copying does not satisfy it or my creativity at all. I need to do it myself to enjoy it. Otherwise it is just mindless and boring.
IHoppo@reddit
Every language I've ever used (before the internet) had a book or 2 to use. Incredible that people in an industry supposedly full of high level thinkers forget about books.
NeedleworkerLumpy907@reddit (OP)
Books helped, theyre underrated
IHoppo@reddit
When they were all we had, they were good. Go pick up some old books - I.e. the K@R C book.
EtherealSai@reddit
For me, I accepted that certain things would need to be abstracted away from me for me to get work done. However, I tried my best to learn everything about the code I was using. The great thing about modern AI tooling is that it's easier than ever before to learn about what you're using/doing. It's a double edged sword though, because it's also easier than ever before to get work done without having learned anything about the code you're putting out.
NeedleworkerLumpy907@reddit (OP)
Agree - my guardrail was treating every pasted snippet like a quiz: dont merge it until you can rebuild it from scratch, write a tiny test that proves what each bit does, explain the flow out loud to a rubber duck (seriously spent like 3 afternoons rewriting the same small feature), and if you cant teach it in two minutes then youre borrowing confidence on credit, definately
EliSka93@reddit
I simply hate not understanding.
M_Me_Meteo@reddit
Write the code, never copy and paste.
I was a hobby programmer through the "copy the program from this magazine to make your own version of breakout" all the way up to the middle of the Bootcamp era, which is when I finally decided to "turn pro".
You read it while you're typing it. You learn while you're reading it. It seems like the idea of copy-paste is "I'll see if it works before I learn what it does" and my experience states that is the wrong way.
You have to understand the code, use your own personal opinions and emotions and feelings and logic and experiences to pick a solution and apply the code to the problem. If you solve the problem before gaining the understanding, the value proposition of actually doing the work to gain the understanding disappears.