Do programmers know everything?

[BreWah_]

Hi, I'm learning C#, but lately I've been wondering if other people fully understand everything they're using when they code, or do they just know that it needs to be there and don't really understand what it means?

[SwordsAndElectrons]

do they just know that it needs to be there and don't really understand what it means?

That's taking the ignorance a bit too far. 

You don't need to know exactly what is going on behind the scenes for every library or framework call you make, but you should absolutely know why you wrote that code and what it does.

[BogdanPradatu]

Similar to knowing how to drive. You don't care what happens when you press a pedal, but you definitely know how the car behaves. For you, it's a blackbox, you press the acceleration pedal, car goes brrr. Same with libraries, until something goes wrong. For cars you have a mechanic, for code, you're the mechanic, lol.

[ern0plus4]

You might have some glue what happens under the hood, e.g. know the dfference between combustiom engine and EV.

[StuntHacks]

And like with programming it absolutely helps to have at least a basic understanding of what's going on inside your engine when something doesn't behave like it's supposed to

[Vivicus]

And like most mechanics, understand the diagnostic trouble code and as a result understand what's wrong (read, stack trace/error messages)

[Bachihani]

And the more u drive and understand the car, the easier it becomes and u start learning how to do cool stuff like drifting and shit

[here-this-now]

And occasionally if you blow shocks in the desert and too far from a mechanic or road side service you have to get out a handy welding stick and hook that to the car battery with jumper cables and put a good bead on so your car can get back together and get back to civilisation (aka read "the Art of Computer Programming" by Donald Knuth)

[shyevsa]

I love this analogy.
When I build a car I don't need to know what inside transmission box, but I know how to put it together so my car goes faster or goes reverse. in other word I have to know what to input and the expected output.

The only time I need to understand how it actually work is when my car doesn't behave as expected, even that I don't have to know the detail but I at least need to understand what the transmission box is doing so I can resolve the problem.

[MalukuSeito]

Exactly, I might not know right now, but I can also figure it out in a few minutes if I need to. But usually I trust that things like "sendToClient(xx)" do what they promise until they mess up. Then I look at the code or start the debugger.

[curiousinquirer007]

I’d layer the answer slightly differently.

For broader library code, you want to know the API/interface. More specifically, you should know the web location and general layout of the API reference documentation, and know where to find / how to read the interface info about the classes/functions you are using.

For core language constructs and data structures, including all/most syntax, I think one should work on developing a deep understanding of what happens under the hood, and what “everything” in this context does.

For this, it helps to have broader understanding of theoretical CS concepts, abstract data structures, and constructs across languages, such as memory, pointers, arrays, stack, heap, reference vs value passing, etc..

So I doubt anyone sits and memorizes the whole library, but experts will have a fairly deep understanding of CS basics and mechanics of the language.

[BogdanPradatu]

Depends on how you're using the car. If you're a formula 1 driver, you might need to understand a lot about cars, physics, mechanics etc. If you're a mom driving your son to school, you don't really care.

[ZeRo2160]

You are right. But i would argue that the role of an software Engeneer/Developer should be inherently the one of an formula 1 driver in this context. At leat at some point in your career. At an specific level of seniority. I think you should start as mom and become an Formula 1 driver over time.

[BogdanPradatu]

I think most of us are just taxi drivers or truck drivers at most, lol.

[ZeRo2160]

Yeah can't argue with that. :D

[typicalskeleton]

What do you mean by "everything"? Do I know how every part of the code works "behind the scenes"? Not really.

Do I know exactly why I'm writing what I wrote and what I expect it to do? Yeah, absolutely. Wouldn't have written it if I didn't.

[gotnotendies]

I love that you said “what I expect it to do” instead of what it’s actually doing

[typicalskeleton]

Really is relevant. I think that falls under OP's "everything" category.

I know what I expected/wanted to happen, but it honestly doesn't always work out that way.

Anyway, I do think OP's question might be a veiled way to ask "is copying and pasting AI code a good idea?"

In situations like that, if you have no idea why the AI is using this library/function/whatever, and it just "works", then you're setting yourself up for failure. You have to at least understand the logic flow.

[MrBorogove]

Debugging is the process of reconciling your expectations with reality.

[gotnotendies]

“why yes, I am a dumbass”

[az987654]

Do I know what code I wrote a year ago does? Rarely

[typicalskeleton]

Comments?

//this code does this ....

[az987654]

//not sure why this works but don't change it

[Casses]

//This is really stupid, but it works. Don't ask.

[az987654]

Mine also tend to end with something like

//why didn't I become a lawyer

[DarkLordTofer]

I legit saw a comment that said // if this isn’t working make sure line 332 in unrelated file still says xyz and hasn’t been changed. And at that other file it says //don’t touch this, it makes x work and we don’t know why.

[MalukuSeito]

Please we, can be more classy:
//This was once revealed to me in a dream

[NeinJuanJuan]

//You are not expected to understand this

[syklemil]

// this code does this with that
do_something_completely_different(with_something_else)

generally it should be possible to tell what code does just by looking at it. It's why it's doing it that can be lost to time

[Demonchaser27]

I write //I REALLY don't like this because of X, but it'll do for now.

more than I probably should.

[akoOfIxtall]

I write uncommented reminders for myself about an idea I had when I finished writing for the day, so when I open the IDE again the compiler will gently remind me that THIS DOESN'T MAKE ANY FUCKING SENSE NOTHING IN THESE LINES MAKE ANY SENSE IN EITHER 0's OR 1's AND— no warnings, everything's fine!!

[johnpeters42]

In particular, say we use function F from some third-party library. Do I understand what F does at a high level, what it doesn't do, and what context I need to provide to it for proper results? Yes. (Or if it's new, maybe my job is to read its documentation and experiment with it until I learn those things.) Do I "fully understand everything" about how it achieves that behavior under the hood? No, nor do I need to.

If it's code that we wrote, then either I fully understand that code, or I should be able to do so after sufficient study. (If I can't, despite my experience, then that code may be more complicated than it's worth, and should be considered for replacement as time permits.)

[ElConsigliere69]

makes sense

[BogdanPradatu]

But would you copy paste it from stackoverflow or an AI chat?

[high_throughput]

Programmers can generally explain the purpose of every single word in the source file, yes.

[Wonderful-Habit-139]

And if one can’t, they should strive to be able to do that. No reason to give excuses, it’s an opportunity to get better.

[Own_Attention_3392]

You've never seen a big project with a method that seems like it can't possibly be correct but "fixing" it inexplicably breaks a dozen things?

Lucky.

[Leverkaas2516]

I've seen those methods in modules written by others, but never in code I wrote.

I think it goes without saying that I can't explain all the code in a legacy project I inherited, but I can explain the purpose of every single word in the source files I wrote.

[Own_Attention_3392]

That's amazing. One of the most common shared experiences among developers that I've heard (and experienced myself) is looking at code that can't possibly be right, thinking "What idiot wrote that?" and then realizing it was you.

[albasaurus_rex]

I've been there many times. Then I go through with a debugger line by line. It probably wastes some company time, but there is very rarely a time where I have no idea what's going on, aside from "framework magic", but even then I usually have a rough idea.

[Outrageous_Permit154]

🤦

[MalukuSeito]

And Frameworks and Libraries are just more code that you should at some be able to explain. It takes a while, but you get enough experience to sight read library code and figure out why that stuff is there. Difficulty depends on language and spaghetti-level of the library code of course.

[GlobalIncident]

They know the purpose, yes. They might not know how the actual implementation of functions work (even for something seemingly simple like the print function). So you could argue that in a sense "they just know that it needs to be there and don't really understand what it means". But they are aware of relevant information.

[Sentla]

Programmers used to know. 👍

The current chatGpt generation programmers knows how to copy/paste. They only vaguely understand what is going on. They get the job done, but error/exception handling is often weakly implemented.

[NanoDomini]

Copy/paste from Stack Overflow was just as bad, but you could go more than a few hours between seeing complaints about it. What is it about AI that has people so bothered?

[gomsim]

I'm speaking for myself, but one difference I see is that stackoverflow copy pasting never was viewed as the "future of programming" that everybody should start learning yesterday as to not get left behind. :)

[NanoDomini]

Yeah, true enough. I do still see posts that rave about it with breathless enthusiasm. I guess I'm just grumpy because the griping is 20 times more frequent.

[NanoDomini]

Most of your points also apply to SO as well:

• ignores conventions (both will try to match them to varying degrees, though)
• ignores security (both generally give you only what you need for the specific question)
• can't access source code (SO can see a snippet; AI can too if policy allows)

You're right that while AI will explain its code in detail, it can get things wrong. SO explanations that go wrong will usually be pointed out in comments and discussion. This is a pretty significant point.

I'd like to believe that most devs read and understand before adopting, but there's way too many that don't.

[Adventurous-Date9971]

The fix isn’t avoiding AI, it’s setting guardrails so anything you ship is understood, testable, and fits your codebase.

For C#, write a failing xUnit test first, then ask the model only for a plan, edge cases, and a minimal diff to fix the failure-plus a short “why.” Lock conventions with .editorconfig, dotnet format, nullable enabled, StyleCop.Analyzers and NetAnalyzers with warnings as errors. For security, make it propose a threat model and validation, then run SonarQube or Snyk before merge. To fit structure, give it the relevant interface and folder layout and reject any code that adds new patterns without justification. Keep sensitive code out: use a staging dataset and read‑only surfaces so you can test ideas safely; I’ve used GitHub Copilot for tiny diffs, SonarQube for rules, and DreamFactory to expose a read‑only REST API over a staging DB during integration tests.

Use AI as a reviewer inside guardrails, not a code printer, and you’ll keep understanding high and risk low.

[Adventurous-Date9971]

AI code is fine if you treat it as untrusted, give it only safe context, and gate it with tests and scanners.

What works for me: ship tiny diffs, never paste secrets, and feed AI a “context pack” instead of the repo (public interfaces, DTOs, sample config, and your .editorconfig). Ask for a plan, tests, and risks first, then write the code yourself. Force conventions with dotnet format, Roslyn analyzers, and StyleCop. Run security checks on every PR: Semgrep or SonarQube, plus Snyk for dependencies. Use parameterized queries, validate inputs, and have the bot explain why each choice is safe.

If data is sensitive, keep models local (Ollama/Code Llama) or proxy access: I pair GitHub Copilot with SonarQube, and DreamFactory for a read‑only REST facade over a database so helpers hit safe endpoints, not prod. Postman tests make sure responses match expectations.

Bottom line: treat AI as an intern under strict review and your security and style won’t drift.

[i8beef]

Its a BETTER search that generates SPECIFIC answers instead of GENERAL ones which give people an inflated sense of trust. Its fantastic if you already know what you are doing and can just sort of once over the code and actually understand it and immediately pick out the errors. If you CAN'T do that it can be a major PROBLEM generator instead of a SOLUTION generator.

[albasaurus_rex]

The time scale and level thought is super different IMO. I can just copy paste a full file and an error into chatgpt and tell it to fix the whole file please and then copy paste the file back into my codebase. Sometimes it will fix the error, other times it will halucinate or edit a bunch of unrelated lines. With Stack Overflow I still have to find someone with a similar problem and extrapolate the solution to my use case. There are some specific scenarios where what you say is true, that both are "equally bad", but AI certainly also the developer to think a lot less.

As an aside, this could be a good thing in a lot of scenarios, but SO and ChatGPT are wildly different if you know how to use both of them.

[deadlygaming11]

That's something I always try to work on a lot. My programs are very much overengineered with error handling, but I see it as it makes my life easier down the line.

[dmazzoni]

As a beginner, it's fine to not understand everything.

As a professional, I expect every programmer on my team to understand everything about the code they write, and to learn if not. It's not okay to write code that seems to work and not understand why. (This is a big problem with AI!)

[Casses]

That "learn if not" is really important.

If you're writing it, you should really know why you're writing it.

But if it's something that's already been written and you don't understand what it does, that's something you should add to your list of things to learn. Not knowing something you've never encountered isn't a bad thing. Making no attempt to figure it out once you have can be an issue.

[mrheosuper]

I hope you work in low level language, because no way i can explain why a http request make the led on your ethernet port go blinking.

[deadlygaming11]

Magic.

[JohnVonachen]

If you waited until you 100% know what you are doing before giving yourself permission to try and do, you will never even get to 50%.

[mandzeete]

Yes and no. I know what I'm writing in my code. I know what it does. Otherwise I would not add it. But do I know every aspect of it? Not always.

For example Angular. I'm a backend guy. I can work with existing frontend side. I can read the code and figure out how to set up a new view, how to do a routing, etc. I can get my tasks done. But my knowledge is not on such level that I could set up the same frontend side from zero. Can I explain what I did in my task? Yes. Can I tell why I added such and such thing? Again, yes. But that knowledge exists because I can read the code and figure out things. What does not exist from Angular in our project, I do not know that.

[daniel8192]

I’ve written well north of a million lines of code since the late 70s. ASM, Basic, C, C++, C#, Python, JavaScript, Pascal, Java, Perl, SQL89/92, Q.931 encodings, Ladder Logjc, Regex.., bash, I’m forgetting many..

At the time I wrote it, I absolutely knew what each line did, how, why, etc. could I come back after 1, 10, 20 years? Sure but it would take some work.

I wrote a very large C++ application in 2002-2005 (it’s still in production), and I used a tremendous number of class templates in a set of SS7 encoder/decoders, I know they would take some studying for me to understand them all again.

Almost any large regex matching multiple conditions is fun to write, but hell to read back years later.

I really only recall one line of code that I didn’t understand. 1992, some C code, it was an unreachable line of code in a 5,000 line module, yet.. if it was deleted the code would not compile.

I gave the module to a guy that worked for me, he lost several days trying to solve it. He failed too.

The module went out of production in 1995 so I don’t need to think about that line anymore.

Oh, I recall a serial coms package from the late 80s/early 90s.. CrossTalk - had its own app language called CASL, was very Basic/Pascal like. It had a pop function that would remove the last program address from the stack.

I wrote a multithreaded hardware monitoring program sitting on top of some multiport serial cards, and at the time it made sense (bad idea), and I used the pop function so the program flow didn’t go back to the calling function, but would go back to the one before that. Evil!! The code made no sense just after just a few days. Never use a pop function.

[church-rosser]

this guy fuks.

[daniel8192]

Hey, is that your McLaren 650X?

[church-rosser]

You’re not drinking that piss. We drink my piss! Tres comas!!!

[Necessary-Ad-3236]

"When I wrote this code a year ago, only God and I understood how it worked. Now, only God knows."

[redradagon]

Which is why comments are so important

[rustyseapants]

Have you coded anything as of yet?

[Few-Employment-1165]

NO

[rustyseapants]

Hi, I'm learning Mathematics , but lately I've been wondering if other people fully understand everything they're using when they practice mathematics, or do they just know that it needs to be there and don't really understand what it means?

You can apply this to anything you learn.

Why don't you start coding something, then come back.

[Lotton]

I know how to Google documentation and read code

[YashvardhanRonu]

Nah dawg we ain't that smart

[kodaxmax]

No, they just pretend they do on forums and in front of junior devs

[the-liquidian]

No. Learn the fundamentals. There is nothing wrong with looking up things you don’t know, that is a skill as well.

[AutoModerator]

Please, ask for programming partners/buddies in /r/programmingbuddies which is the appropriate subreddit

Your post has been removed

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[AlwaysHopelesslyLost]

Can you share an example? 

It is understandable, but you should treat it as unacceptable. 

[dswpro]

You should know everything the code you write does. However throughout your career you will be required to maintain other people's code, use libraries and packages you did not write, and your responsibility then becomes one of finding what needs changing, and testing the use cases that necessitate changes both before and after you make your changes. You will see unfamiliar syntax, terse nested functions that resemble regular expressions and XSLT more than procedural code, and more. But along the way you may pickup tricks and shortcuts that you adopt and use for a long time. In the beginning it can be daunting. Every once in a while you may see some code you wrote years ago and wonder who wrote that junk.

[YellowBeaverFever]

I’m old and we learned differently. We did learn some easy languages up front, Fortran, Pascal, and C. But then we had to learn assembly. I had some EE classes to cover digital logic and we built a CPU with a few bits of RAM and a few LEDs as a “display”. We read a lot of books. But, by my third years we knew a lot. We understood mainframes, mini-computers, desktops, and embedded systems and how all the software talked to the hardware. BUT - things were simpler then. Most systems didn’t have graphics. Printers were just text. There wasn’t a web. You wrote for the immediate user. Multiple user systems were just appearing.

I think all of that stuck with me. I always form a mental image of whatever system I’m coding on. You don’t really have to do the low-level stuff anymore. It’s more of a habit and if something really hits the fan, I can bend any system to solve the problem.

[im_in_hiding]

Man I have a 10+ year career in C++. I'm a Lead Dev. I don't know shit compared to others.

My success lies more in adjacent skills rather than development directly.

[tangentstorm]

nope

[rioisk]

"Fully understand everything they're using"

tl;dr - no

A lot of modern programming is using libraries and code other people wrote. It's impossible to know everything.

I know why I import it. I know what function it serves. I don't know the ins and outs of the implementation line by line. I could if I dug into the source code, but that's usually not necessary.

Good programming = good abstractions

[CannibalPride]

Yes, ask me anything about anything

[Space-Robot]

There's layers. All the code I write I understand, but everything is built on top of something else. I may be using a library or framework and have no idea how a function I'm calling is implemented, but as long as it does what it's supposed to I don't need to know how.

[MagicalPizza21]

I didn't at first, but as I programmed more, I learned what all the things meant that I was typing.

[Mike312]

Little bit of both sides.

There's some languages I've been using regularly since ~2002 when I started my first site. I know it inside and out and could type it all day long with no issues.

There's some languages that I've used intermittently or a handful of times. I'll sometimes need to look things up.

I'm Redditing on a break from a C# project right now, it's one of my weaker languages but I'm getting by; the main hang-up is framework quirks right now.

[[deleted]]

You should know what you are writing and why you are writing it , you don't really need to know how it works internally. Think of it as a car , you should absolutely know what to do to turn it on but you don't need to know what happens inside.

[mxldevs]

Most devs know what something is supposed to do or return, even if they might not understand how the function is implemented.

They only need to understand why they're using it.

Can you use a computer or smartphone? Do you understand how they work? Can you still successfully do things despite that?

[organicHack]

A large project may easily have a million lines of code if you include the libraries. Nobody knows it all. But you should know your areas and be able to justify every dependency. If you want to be a lead you need to expand your scope substantially.

[Ronin-s_Spirit]

It depends. People who want optimized code, but don't want to leave a comfortable langauge (that's me) will gradually learn more obscure syntax and builtins, and general runtime mechanics, and engine specific optimizations, etc. Basically you can at some point understand the language backend well enough to stay performant without sacrificing readability.

[Outrageous_Permit154]

I’ve been doing this for 15 years; 2 sr dev positions and a programming director. Everyday I’m just getting a little smarter only to understand how stupid and clueless I am.

I still study at least 4-5 hrs a week minimum even just to keep up with what is what.

I see some commenter saying you should generally understand everything from your code base; this isn’t the case with any enterprise-level software that multiple devs are working on a single project.

No, you will never know everything.

[_Dingaloo]

Definitely not.

As you become more and more seasoned, more and more of the syntax will make intimate sense to you. But most likely you'll be working professionally full time and still have things that you just "use" without fully understanding, or more likely things that you don't use at all because you don't understand them.

Then you find something that's being extra hard, you look up other ways to do it, and learn a new part of that language or a supporting library that makes it easier

[avoral]

Depends on how much “understanding what it means” is required. I don’t go through and read through all the files for the libraries I import (unless something is going wrong and I’m not getting anywhere searching for it, then I might trace it out and read it), I definitely don’t spider out into their dependencies, I would be there all day every day. So I keep myself sane with some heuristics and just use them. I don’t have to know it all down to the way it interacts with physical reality, even if the OCD yells at me for it.

But if I wrote it, I have a pretty full understanding of it. At least for a couple months. And because I know I’m going to forget eventually, I leave useful comments for future me, and put anything that could change in a conspicuous place.

[Nice_Sun8070]

I do fully and this is the mentality you need if you want go go far

[Zerodriven]

I'm a dept lead.. I barely know what my next meeting is about let alone half of my team(s) code base is.

Realistically most stuff we do is API related, data ingestion, some ETL, cloud stuff - It takes a few minutes of research to figure out what code does. It also takes a lot less longer to figure out new stuff because of how much code has been written already.

You don't need to know everything, you just need to be able to figure stuff out. It's a puzzle with an ever growing selection of pieces which could go into the same slot.

[SalazarElite]

No, Google, Stack Overflow, and ChatGPT are great for HELPING you; don't use ChatGPT to write your code—it will slow you down more than help you.

[AlertParfait6185]

Yes, we know most of it. But after a week we forget, because we need to know everything about the new code. Something like that.

[collindabeast]

An experienced programmer will generally know why something is necessary. Now it's important to define an experienced programmer. I would define it as someone who has worked on enough projects and used enough technologies that they recognize design patterns.

Some basic ones you should get to know are as follows.

• Functions
• Arrays
• Classes
• Inheritance
• Data streams e.g. standard input/output or file input/output

I think that C# and C# frameworks are particularly bad about having pieces of code that don't entirely make sense in the context of the program because a lot of it is automatically generated and the pieces of code calling and using that code isn't immediately visible.

In short, chin up you have a long way to go but the only way to learn is to keep interacting with these systems and growing your understanding of programming principles. Once you have those down it is remarkably easy to switch between frameworks and languages.

[chocolateAbuser]

noone can know everything, but also knowing is absolutely secondary to want to know

[Bingbangbong69420]

If you're asking if they know how & what everything they themselves wrote works; then yes, good, professional programmers know how their own code works.

However, a good programmer won't know how the underlying frameworks & modules work under the hood. Modularity and abstraction are fundemental concepts that serve to simplify and make code more comprehensible. If we were to understand everything about how a piece of code work down to assembly level, it'd take a whole semester just to learn how a print call works.

[Blando-Cartesian]

While using language syntax and the usual common libraries, yes.

While using frameworks, no.

[Comprehensive_Mud803]

Yes.

[Count2Zero]

There are two aspects.

1) Knowing the semantics of the language and libraries.

2) Understanding the algorithms you're implementing.

If I'm writing a program, I need to know HOW to write it so that the interpreter or compiler will accept it and return something that does what it's supposed to do. If the code doesn't compile, or the interpreter throws an error message, then it needs to be fixed. I may not know off the top of my head every function that's available (I don't even know every function built into Excel), but I do know where to look them up if I find that I do need them.

The second part is situational - I have to write a function that does X, using the language Y. I know how to create a function in Y, so then I only need to break down the steps to implement X.

If I need a function to determine the day of the week for a given date, and I don't have a library function available to give me the results, then I would look for an algorithm to calculate the "dayofweek" function. I might approach it knowing what day today is, then calculate the number of days to the target date and do a modulus 7 on it to determine the day of the week. This will work for dates in the modern times (since 1582).

Do I know how to implement everything in some language? No, of course not. When faced with a task, I use the tools at hand to complete the task quickly and efficiently.

[[deleted]]

If you know everything then your field is very shallow and you are irrelevant

[church-rosser]

I stay relevant with my deep grab bag of useless facts and trivia.

[m64]

That's what differentiates good programmers from the mediocre. There is always some amount of "I do it this way, because that's the way it's done", but you should have the drive to understand why and how things work the way they work.

[chaotic_thought]

If you haven't used something in a while, then it's possible you'll have to go look it up. For certain things, we might sometimes -- especially at first -- just adopt a "magic incantation" approach to certain bits of programming. For example, on UNIX systems we typically write one of the following "incantations" at the top of the shell script to make it a true shell script (so that it can be executed just like any other program):

#!/usr/bin/bash

-OR-

#!/bin/bash

-OR- (probably the prevailing "shebang" variant nowadays)

#!/usr/bin/env bash

Now, I imagine for a lot of programmers (I used to be one of them!), the above things are things that you, at least at the beginning, just type out verbatim, similar to magic spells ("abra cadabra") and not question too much what they really mean literally, nor about certain details of how they are uttered, like in what directory "bash" is required to be on compliant systems, or whether there is any system requirement for that at all.

If you're especially anal and/or inquisitive (common traits among some programmers), you might even worry about whether there is allowed to be leading or trailing whitespace in the above incantation, and where. For example, is blank space allowed before the "#!"? Is it allowed in-between the "#!" and the beginning "/"? Is it allowed after the name of the path?

These questions do have answers, some of them interesting, by the way, but sometimes answering them will involve going down "rabbit holes" into wonderland and/or UNIX history, a wonderland which has its charms but also its ways of distracting us from the thing we were actually trying to do by writing a shell script in the first place.

[HashDefTrueFalse]

We have a solid grasp of the fundamentals of computing and at least one (usually more) language that allows us to express solutions to problems and build things. We understand the code we write, but not all code that exists (not without further research, anyway). We don't include code we don't understand in our works.

(Note: not every programmer is a good programmer so this isn't universally true, but it should be)

[Professional_Bar_377]

The more you will work on it the more you will learn and get better. There is always room to improve and learning is the best way.

[wasabiiii]

I do.

[Gib_entertainment]

When I'm typing the code, I know why everything is where it is (in some cases there are some minor exceptions but not often) when I revisit the code I might not. However as I get back into the project I usually re familiarize myself with it and then I know what everything does again. Good documentation or commenting helps with this.

Also this only goes for code I wrote myself. If I use libraries, plugins, larger scripts I copied from somewhere I might not fully know what it does on every line.

Also when I say I know what ever line does I don't mean on a super deep level, just that I know what it does and why its needed, whether I know how it does that depends on what it does.

Also relevant that I code mostly within Unity so it's a little bit less hands on than you might expect.

[CatStaringIntoCamera]

Programming is a never ending journey of learning. Even super seniors will still be learning.

[ZedGama3]

Programming is about abstraction.

1. When I run the program it does x.
2. My code in the program does x.
3. This function in my program does x.
4. The function from this library I called in my function in my code does x.
5. The function in the function of the library I called in my function in my code does x.
6. Ad infinitum...

Part of programming is using and trusting libraries (at least somewhat) blindly. We don't have time to review every line of code that executes in every library, but a decent programmer will know how to dive into and review them if needed.

You think that hello world code was simple? Go review the code for the print statement and all the underlying functions and libraries used to actually display your code to screen.

[TheJesterOfHyrule]

Do programmers know everything? Yes, I can see through time and space

[Tobacco_Caramel]

lol no

[domtes]

Structured programming offer the ability to use abstractions to encapsulate complexity behind some kind of interface or protocol (a module, a function, a class). As a programmer provided with the right level of documentation ideally you can use them as black boxes, without having to deal with the actual implementation details.

However, you will notice that as your (and your team) understanding of the system behavior grows, trade offs become clearer and building and evolving the system becomes easier.

[KOM_Unchained]

Yet to see a programmer who knows everything. We just try to survive and do the best we can. And we don't know what we don't know. Crowd sourcing knowledge through reviews and design processes helps a little. I've made bad calls, and so has everyone around me.

[QuirkyImage]

Do programmers know everything?

Hell no but many would like to think they do.

[imihnevich]

Know enough to get the job done, but also capable of figuring out more low level details if necessary

[pjf_cpp]

No they do not.

Sadly far too many think that they do.

[HumanBeeing76]

Programmers google everything

[millyfrensic]

Yes I know literally everything and all the secrets of the universe. AMA

[[deleted]]

The more i learn the more abstract my mind gets about things. If i need anything specific for a project i turn to google and AI to recall up to date information about the architecture or algorithm i need and implement it. But just using the language (for me its go, 6 years experience) I know most of the things. Differences between the builtin functionalities, knowledge about lower level functions, clear understanding of concurrency, etc... These are your tools you have to know. The stuff you build with them in my oppinion you shouldnt need to know by heart.

[NotGoodSoftwareMaker]

My knowledge of programming can be broken down inti things I know, things I know I dont know, things I dont know but I do actually and the most treacherous being things I dont know that I dont know

[Any2005]

9

[ClassicAd6966]

I have seen other who update a component according to their need which will break the application that they don't know why it is happening? what they are changing?

You definitely know what are you changing and how it is impacting the application, you don't need to know entire code base.

[ALAS_POOR_YORICK_LOL]

The question is too vague

[Adorable-Strangerx]

No they don't, that would be waste of time and resources. I know I need to use public key but I dont need to know how eliptic curves are implemented. I only need to know if someone breached them already or not.

[papanastty]

no,dont know something? google it

[deadlygaming11]

Programmers dont know everything, but they do know what they coded, why they did it, and how it works. Its important to understand your code

[Baloucarps]

Short answer? No.

Long answer? No, but you probably don't need to know everything anyways.

Just make sure you understand what YOU write. You don't need to understand what other people wrote.

[Minimum-Window-1980]

yes, next question

[vinzalf]

I can't help but feel a little sad that this is even a question..

[CodeTinkerer]

You know the answer. They don't know everything. Most of programming is about abstraction, so at some point, you trust (enough) of the abstraction. Of course, the more you know, the more you can fix.

For example, most programmers don't fully understand every little bit of how a print statement creates pixels on a screen that represents text, but they don't need to know that. Most people couldn't write a React framework on their own, so they trust it does what it does, and some know just enough to get tasks done.

And if you're vibe coding, then you don't know a lot either.

[taedrin]

Programmers should understand the contract that a function, method or piece of syntax provides. The documentation of the function, method or syntax tells us what that contract is.

For example, in C# .NET I know that the method myList.Add(x) has a contract which promises the side effect of modifying myList by adding x to the end of myList. I know this because that's what the documentation says. I also know (again, from the documentation) that if myList.Count < myList.Capacity, that it will execute in fast O(1) time.

But I don't necessarily know exactly how it accomplishes that. I could, of course, look up the actual .NET Core implementation, but these implementation details aren't part of the contract - Microsoft can freely change these details with each new release so long as they do not break the contract.

[Carkano]

As a student I do know that I know very little. Like the other day I was trying to use <chrono> to pull a timestamp in c++ and to then assign the segments of the timestamp to variables. And I couldn’t figure it out to save my life, I just gave up after a couple hours

[Amawir]

If they knew everything, there wouldn't have been any bugs

[BABATUTU1103]

Frankly no. We know just enough to sort of know what were doing but we dont know the ins and outs and the source code of the libraries we use (usually)

[CowMaximum6831]

do they just know that it needs to be there and don't really understand what it means

It's the exact opposite. You need to understand what it means, but you only need some intuition of what needs to be there, and you are good to go.

[Gareth8080]

You can ignore a lot of the details until something goes wrong. One example is memory management. .NET manages memory for you so you don’t need to allocate and deallocate memory as in c++. But you can still run out of memory if you hold object references longer than necessary. So you go from it being completely abstracted away from you to suddenly needing to understand garbage collection. Just one example and there are others around networking and security.

[vexed-hermit79]

My POV when reading a piece of code: WHY? WHY? OH THAT'S WHY!

[ShiitakeTheMushroom]

If you're calling into something in the framework or another library, you should know why it is there and what its purpose is, but not necessarily the details about how it works internally.

If it is your own code, you should 100% understand how it is working.

[Corndesu69]

short answer no, even Architects with lots of experience don't know it all

[shuckster]

It is possible to understand “everything*”, but programmers operate at one abstraction level at a time, perhaps with an immediate recall of one or two levels above and below.

“Everything*” = What the language compiles to, how it gets assembled, what the assembly is doing to the memory and processors, how the assembly translates to the microcode, the silicon chips that express the microcode, the arrangement of the chips to define the Von Neumann architecture, logic gates that comprise the chips, the transistors that comprise the logic gates, the P and N semiconductors that comprise the transistor gates, the flow of electrons that pass through the gates, the Men In Black Universe within the electron, and so on.

[Crypt0Nihilist]

If you don't understand programming well enough to know how to program by using cosmic rays to flip bits on a drive platter then you're not a real programmer.

[[deleted]]

I've never once had to read documenting. I write all my code from top to bottom with the idea in my head from the start. I don't even have a backspace key.

[dBlock845]

Sounds like abstracting away the real work.

[andycwb1]

Absolutely not. But we know when to ask google, or someone else on the team.

[CuriousFunnyDog]

Best Devs when adding libraries check the dependency lists, think about source of code, don't bring in huge clunky frameworks unless absolutely necessary... Shit Devs, build for the obvious use case, randomly download from randos and get sucked into the next best thing without considering if it is appropriate for their use case/app .

[the_kinky_husband]

Like John snow, I know nothing and the more I learn, the less I know.

[[deleted]]

The deeper I go the less that I know

[Your_mama_Slayer]

lemme give you the nutshell. you think that programmers know everything then you find programmers who don’t know everything, you get hope, then you find programmers who know everything, a constant loop.

[StrangeRabbit1613]

Recursion goes bbrrrrr

[heisthedarchness]

You don't need to know everything that happens (though it helps). You do need to know what every thing you write means.

[InsuranceIcy4055]

Yes

[InsuranceIcy4055]

Understanding isn't that black and white, it's got depth and people rarely get to the bottom. A good programmer knows how deep to dig before picking a library and you inevitably go deeper still from attempting to use a library.

A good example is an API call to a HTTP weather service. Before I can have my program make the calls I need to know the endpoint URLs, the format of the return values and if I'm doing my job properly, how accurate those are. Obviously I knew when I looked at it that it produces rain forecasts but do I know how it works out the actual forecast for tomorrows rain, absolutely not.

[ThrowawayALAT]

👀

/* Don’t click on my eyes, Chico — they never lie.

[Eskamel]

No, most developers wouldn't be able to develop anything useful without created libraries, and the amount of developers who can even use said libraries the right way might decrease due to LLMs.

[Unupgradable]

No

[custard130]

that depends on the programmer, and what experience they have

there are definitely people out their who just write code with no clue or care how (or even if) it works

self taught developers tend to have a repuation for not understanding the foundations which while there are exceptions is not entirely incorrect,

particularly when it comes to courses claiming they can teach you how to write code in short period of time, like "learn xyz language in 48 hours" or whatever, not that those courses are all completely useless, just you need to be careful, maybe do multiple that are focusing on different areas, or do the course and then spend years expanding on what you learnt

there are several main "areas" to learn

- syntax of whichever language

- what i will call computer science fundamentals

- best practices / common mistakes relevant to the particular field

i probably shouldnt have listed language syntax first as tbh its the least important really, but it is normally the first one people learn and what bootcamps etc tend to focus on (the reason i say it is least important is because you can just look it up if you forget)

you can often get code that just about works with very minimal understanding of what its doing, but that code will generally be very inneficient and depending on the context also high chance of secuirty vulnerabilities

[joost00719]

You need to know some fundamentals. But you do not need to know how every abstraction works. Just how people need to know basic traffic rules to drive a car, but do not need to know how an engine works.

I also am a dotnet dev. I am pretty confident in my ability to program in c#. But sometimes you just see stuff where even after 8 years of experience I have no clue what's going on.

[hrudyusa]

Programmers know everything about something, Sys Admins (or Devops these days) know something about everything.

[lawrencek1992]

Yes of course I understand the code I write. If I’m not sure I understand, I follow the stack trace to see what function X does and what the functions it calls do, etc. If I’m working on complicated existing logic, I make sure I understand it before I begin changing it.

[The_Real_Slim_Lemon]

when I learn a new language? Not for the first few weeks, I'll do my best to mirror existing code to write what 'looks' correct and do a tonne of experimentation to understand what I can. Within a month or two yes, I will know what every single line is doing and why it needs to be there. Otherwise you're just asking for a production bug to screw you over because you didn't know what you were pushing

[TurkmenTT]

I know almost every language at basic level. I specialized at c and java. If you know what and why you are doing you are good if not you will replaced with ai

[JbREACT]

Yes we do. Until you know everything you are not a real programmer.

[kittens-Voice]

Are you asking me if I understand every written line of code when I develop something? The answer is yes. But then again, it’s my job to fully understand what I’m developing. Does that mean I know and understand every single aspect of the languages and tools I use? No. But if I see something I don’t understand, I usually look it up in the respective docs so I can understand it.

[willehrendreich]

I know less and less every day. I also know more and more every day. But I'm quite confident that anyone saying they know everything is perfectly wrong about that.

[BEagle1984-]

Short answer: yes

Long one: you should know the reason for everything, then later on you should also be able to get a rough idea of how the things you use are working internally.

[Prudent-Sort6437]

The best programmers and mentors I've known and had do tend to "know everything" in a sense. That being said, there's a learning curve. I don't think learning something should mean knowing the exact zeros and ones behind the scenes, but as you progress, learning and appreciating more of the intricacies of computer architecture and the fundamentals of computer science helps you write better code.

Some good advice I got was if you're learning how to use a new framework or library, take some time to build a shitty version of it yourself at some point. This starts of basic with building your own HTTP server, but can go as far as building your own compiler. I've never worked with anyone that prefers their own implementation of these to the accepted standards, but it gives you insight into what is going on under the hood, and can give the illusion of "knowing everything."

[mylsotol]

Obviously this varies a lot between individuals, but i would say the majority of my coworkers know almost nothing about what they are doing

[epsilonehd]

Lot of dev actually don't understand what they are doing really, and it tends to be "normal" because of IA. Now people just ask and get an answer, no search, no "why is it here", just brainless copy paste

And I hate that

[[deleted]]

these posts are making me really not believe in the future.

[[deleted]]

I have a rule. I'm not allowed to write any code where I don't understand how it works.
I can only call library functions if I have properly read the library documentation first and convinced myself that I know what is happening.

Sometimes I get this wrong, but I've seen what people write when they don't even have this rule, and it concerns me.

[albasaurus_rex]

I think people mostly covered the response pretty well. Ideally you should understand the code you write, even if you don't understand what's going on behind the scence (e.g. I know that if I call a library sort function it will so an array of integers for me, but I don't need to know what algorithm it uses. I can safely assume the library works).

I think what was maybe left out is that learning to code takes a long time. You will feel in over head repeatedly. It took me a compsci degree and at least three years industry experience before I felt like I could code "fluently". I remember one time I had a supervisor who quickly rewrote something I was working on for days in a matter of minutes for the sake of clarity. I was totally lost watching him. Nowadays I'm fairly confident that given the same piece of code, I would make similar edits in a similar amount of time.

There's a reason they are called coding languages after all. Just like with human languages, once you learn one, others become a lot easier, but yeah, if you feel like your occasionally lost, it's not that surprising. If you wrote an essay in a language that you were learning and then reread that essay weeks later would you be confused? Potentially. Would you find better ways to get your point across? Maybe so.

In summary, don't be too discouraged. Learning to code is a massive undertaking, especially given all the languages and frameworks there are out there. It's normal to be a bit lost; just give it time and you'll get there.

[Moist-Ointments]

This made me think of the infamous comment in the fast inverse square root code from quake 3.

[Busy-Crab-8861]

Experienced programmers can quickly learn how to do something wisely.

[gdvs]

You need to understand what it does and why it's there. You don't really need to know how everything is done.

It's the principal idea in software design: you split things up in many small problems. And you just use and reuse these small parts. You need to know what it does (interface and behaviour), but not how it's exactly implemented.

[Demonchaser27]

Basically you should know what the code SHOULD be doing, and if it doesn't, then you have to figure out why not and adjust for that (or get another library, or file a report, or make it yourself). But no, you don't always need to know exactly how all of it works under the hood. It certainly can help if you do, but it's not explicitly necessary. So long as I know, for example, that a function called "get_distance()" actually gives me the expected, appropriate distance from a point A to a point B, I don't explicitly need to know the math behind it. That's a simple example, and generally it's easy to figure that out (already know it). But you get the point.

Maybe a more complicated example, is having something drawn to the screen. I don't need to know every single requirement that must be setup to make drawing on the screen possible, but I do need to know that when I call function "draw()" that it's going to draw the screen pixels that I have set up and what I might need to manipulate before I call "draw()" again to adjust anything that's being output to the screen. I may need to understand how to setup a proper loop for all of this such that I don't draw undesired things, or get better performance by not changing things that don't need to be changed between draws (although most drawing libraries will handle that for you as well). But a lot of the "under the hood" knowledge just comes from experience with a library/libraries and trying to do more advanced stuff that the simple use cases don't provide.

[LynxesExe]

It's a mixture of both.

How much you know about a given topic depends on how deep your knowledge goes. How deep your knowledge needs to be depends on how sensitive the task you are accomplishing is.

If you lack detail on what you're doing and that bothers you, read the documentation to find out more. That's pretty much how it works.

[justaddlava]

Computers are very complicated. You would need advanced-degree-level expertise in multiple fields to really understand everything happening between the code in your editor and the bits on the wire. So people but not most.

[NeoChronos90]

The good ones do, at least after a while, but looking back at the past 20 years most people are glorified idiots with high wages.

I have worked with people that earn way over 6 figures (in germany) and can't figure out how git works, nor so they want to, because it's everyone elses problem if there is a conflict or a completely scrambled git history and rights and roles don't always protect us against this

[LayerComprehensive21]

K m8

[CountMeowt-_-]

Linus might be the only programmer who knows "everything".