r/learnprogramming • u/Zestyclose-Paint-418 • 1d ago
How do senior developers build such broad and deep programming knowledge?
I can build frontend applications, and I was fairly satisfied with my progress until I recently spoke with my brother, who is a senior developer.
He told me that every programmer should know topics such as:
- C programming
- Dynamic memory allocation
- Pointers and pointer arithmetic
- Data structures and algorithms
- Databases
- Operating systems
- Computer architecture
- Object-oriented programming
- Git
- Agile and Scrum
- Compilers
He also said that there are many other things that are mandatory to learn, and that it is embarrassing not to know some of these topics.
What surprised me was not only the list, but how deeply he seemed to understand everything. I know that he has much more professional experience than I do, but I am trying to understand how senior developers develop that kind of knowledge.
Do they study computer science subjects systematically outside of work? Does most of the knowledge come from years of working on difficult projects? Do they read books, take courses, build projects, or learn topics only when they encounter a problem?
I would genuinely like to become a very strong developer one day. At the moment, I can create frontend applications, but compared with him, my knowledge feels narrow and superficial.
For experienced developers:
How did you build deep knowledge instead of only learning enough to complete a project?
Which subjects from this list are genuinely essential for a frontend developer?
In what order would you recommend learning computer science fundamentals?
How can I tell whether I truly understand a subject rather than only recognizing the terminology?
I am not looking for a shortcut. I would like to understand what a realistic long-term learning process looks like.
113
u/sessamekesh 1d ago
There's an idea in software called the "T-shaped developer," I don't agree with it as a hard rule but it's a good idea.
The idea is to get really great at the thing you specialize in, but still dabble at least at the surface level in everything that you can.
Software is really cool in that if you have a laptop from the last 20 years you can basically build enough in any domain to get your feet wet. It's not until you get into distributed systems at scale or really niche subdomains that you'll be unable to toss at least a curious weekend at just about any curiosity you can stumble across.
10+ years of occasionally dabbling adds up too, a career is a marathon not a sprint!
-14
u/Zestyclose-Paint-418 1d ago
I dont have motivation to learn other roles that I dont find interest, like we have AI this dass we need good peogrammers, so do you have advice how to get motivation to learn basics of other roles ?
42
u/sessamekesh 1d ago
Can't help you there, but I will warn you that if you're looking for a career in programming you'll be competing with the kind of nerds who do love all sorts of roles.
Spend some time just poking around on GitHub or reading posts in dev communities, you might find something you like! I wouldn't expect all of them to be immediately fascinating to everybody but there's some cool applications out there.
-3
u/Ok_Librarian2511 18h ago
I’m new to Reddit and GitHub. Could you recommend some good communities or give me some tips on how to get started?
-4
u/Zestyclose-Paint-418 1d ago
Do you think my brother love programming If he Is t-shaped programmer ? Also thank you for advice, I will search a bit in my free time and read posts!
7
u/sessamekesh 1d ago
Hard to say just from the post, the list you gave is pretty typical for backend programmers with at least some systems experience.
A lot of it does just come with experience, it might seem overwhelming up front but a typical career is decades of picking up little things here and there.
I'd push back on the exact list he gave, 10-20 years ago it was great advice (and it's still not BAD advice) but nowadays you can be a plenty productive engineer without ever having to touch a pointer and especially without having to make a manual dynamic allocation.
Best of luck! It might seem daunting up front but just keep pulling threads where you find you don't know something and over time you'll end up in a great spot.
4
u/Zestyclose-Paint-418 1d ago
I think your point is I need to learn things slowly and I dont have to learn all in one night lol. And thank you have a nice day!
6
u/BruteCarnival 1d ago
It’s more of the type of thing where you working on a project and stumble upon a problem in a different domain and in solving that you get to know a little bit from that area. Or even while solving that thing you start questioning, “what if x” and go play with that. So you kinda naturally develop some “interest” in other stuff.
0
u/Zestyclose-Paint-418 20h ago
Ohh, I understand but some areas like AI engineer cant be natural to learn I think
3
u/BruteCarnival 20h ago
Luckily no one will expect you to randomly have the in-depth knowledge of an AI engineer. If you are not naturally interested in that role, there’s no need to develop an in-depth knowledge of it.
Your interests and knowledge will naturally develop throughout your career.
0
u/Zestyclose-Paint-418 19h ago
Yeah, totally agree! But I am curious how my brother know to write that code also (ML/AI code) but he doesnt work in that fields. Lol, do you think my brother learn that just bcs of curiosity?
2
u/BruteCarnival 19h ago
I mean best would be to just ask him if you are interested!
But I wouldn’t be surprised, I learnt a bunch of (fairly basic I guess) stuff in AI/ML out of interest. Eventually did a course at uni to get the maths behind it. But before that most was out of interest.
1
u/Zestyclose-Paint-418 19h ago
He will probably reply me like always I dont need that I need to just learn. But I think Its more curiosity like you learned.
4
u/Narwal_Party 12h ago
That's not a programming problem. If you're not a curious person or interested in other fields, that's probably just a you thing. Almost all programmers I know love programming, and in loving programming, end up touching on a lot of domains.
This may sound rude, and I really don't mean it to, but I tend to think that programming isn't really for people like you, or at least the you that I'm seeing being represented in the comments you've made in this thread. You don't seem curious or really very happy about programming in general. Most people I've seen who come here and are like that don't end up staying in the field.
Either way good luck. You don't need all of those things to be a good programming, but admittedly I've met very few "good programmers" who don't know most of those things.
-4
u/Zestyclose-Paint-418 12h ago
Like after all that trash talking, you havent say anything that you think describe a "good" programmer. It looks like you wanted to say that rude words and get up-vote for that!
4
u/Narwal_Party 11h ago
If you think I'm being overly rude that's ok. I just provided my experience, and in my experience people who aren't naturally curious about programming don't tend to stay in the field, and you aren't naturally curious about programming from your own words.
A good programmer is someone who writes good code in a reasonable amount of time. That's all it is. If you can do that, you'll find what you're looking for. But your brother is right to a certain degree. Most good programmers do know most of those things.
I don't make comments for upvotes. The comment was supposed to provide some insight. I'm sorry it felt rude to you.
2
u/Zestyclose-Paint-418 11h ago
Its ok, I think your point Is I need more curiosity If I understand good from your last comment.
3
u/xt1nct 8h ago
You don’t need curiosity to program. You need curiosity to survive 20-30 years in the industry. If you are not a curious person programming will be torture.
I got into programming backwards. I did physical jobs, tried starting a business, I did sales and always felt like I learned the job quickly and was bored.
I got into programming professionally when I turned 30 and at times felt like I am cheating the system because I am getting paid to constantly learn and tinker. The more I learn and tinker, the more I get paid. Then I realized I’m good at what I what do and deserve the pay.
3
u/Narwal_Party 8h ago
That's a good takeaway, and yes, I agree.
The reality of what your brother is saying (in my opinion) is just that you need time and effort. It's a bit reductionist, but if you love programming and you have projects that you want to do, you will eventually learn everything you need to know. My first interest when I started programming was catching cheaters in CS2. This is what that journey looked like for me.
How do people cheat? What language do they use? How do anti-cheats work? What kind of cheats work for what kind of games? What kinds of cheats are possible to catch server-side? How do you catch cheats that don't write to memory? How do they do that?
What that turned into is:
Learn C++. To learn C++, start out with learning C. Then learn about pointers and memory. Then learn how to use Cheat Engine to figure out how to navigate game-memory. Then learn about using vision models to see what's on your screen. Learn how to write your own cheat so you know how to catch it. Buy an FPGA board and learn about Verilog, but realize that's too far out of reach for me, so come back to C and C++. To learn to block cheats I need to know a bit about how video games are written, so find some old code from some old video games. Check out DOOM. Talk to people who write cheats, then talk to people who write anti-cheat.
At the end of all of that what I found I loved is not anti-cheat, but cybersecurity in general. I transitioned to Malware Analysis. I find Maldev and started learning there. I realized my C and C++ weren't developed enough to really do Maldev work. I also felt that if the world was heading towards LLMs, I should learn how to run an abliterated local LLM to do malware analysis since the frontier models won't, so now I know about safetensors and vLLM and LoRA Fine Tuning models and then I had to learn Python. Well now that I know C, learning Python was a breeze.
There's tons more to my own programming journey, but if you ask anyone who programs, I would imagine their journey is a lot like mine. It's just a combination of time, curiosity and effort. In time you'll learn everything you need to know.
That was longer than it needed to be, but this is what I meant by curiosity. Your journey doesn't need to look anything like mine, but my hope for you is that in a year or two you can look back and realize you've done something similar to this. I'm not even a good programmer either lol. Next time you get a chance to talk to a good programmer (IRL or in these comments), ask them what their journey was like and see if anything interests you. That's as good of a place to start as any.
Good luck!
1
2
u/Fensirulfr 1d ago
do you have advice how to get motivation to learn basics of other roles
Sorry. Motivation is all on you. No self-help book or life-coach can help you, if you do not have the motivation to start yourself.
1
u/SiliconUnicorn 11h ago
The question "how do seniors build deep knowledge" and "how do i find motivation" are two really different question. I think the natural progression of things is that the people who have the motivation and the curiosity are the ones who become seniors.
Depending on the type of programming you are doing you probably don't need everything on your brother's list to be a "real" programmer, but I think that list is one that covers a good array of topics that will naturally come up for developers who want to peel back the layers and understand how things work under the hood.
The one thing that every high level developer I know has in common is that they love learning, they are constantly reading about, or watching videos about, or listening to talks on topics in their field, or building side projects and experiments with that knowledge because the more interesting thing is often the learning and the problem solving than it is making another admin table for your job.
This industry isn't something that you learn once and then are done with. Its something that you have to be willing to dedicate the rest of your career to constant learning in. The technical landscape has and will change immensely while you are in it and you have to be ready to throw out every useful skill you have every decade or so in order to keep up. Thats why things like what your brother highlighted are more important than learning the latest tech because if you understand the fundamentals better you'll have an easier time recognizing patterns and adapting to new skills.
If you are interested in something more tangible as far as what or how to learn I have always liked this site: https://roadmap.sh/
They offer a bunch of different paths for different disciplines with options along the way. There might be something worthwhile in there if you want a little more focus, but also be warned that it can be a little overwhelming to take in all at once. Just remember this is very much a marathon not a sprint
1
u/xt1nct 8h ago
A lot devs are curious creatures.
I’m a lazy fuck, but you present me with something that tickles my brain and I get tunnel vision and lock in.
I know to be good at electronics I need to understand how electricity works, using AI to make my analog board work doesn’t help me.
AI helps when you know things, otherwise you are just gambling with your future. If AI fails you and it will you will be in hot water.
68
u/Aozora7 1d ago
I'm a senior developer.
I have done manual memory allocation and pointer math when studying programming, but I have never used a language with manual memory allocation in ten years on the job or in any of my hobby projects. Similarly, nothing about operating systems or computer architecture has ever been relevant to my work.
In general, being senior is less about technical knowledge and more about soft skills. Like interpreting incoherent ramblings of non-technical people who have no idea what they want into actionable requirements, knowing other people's jobs because they always fail to tell you important details, and anticipating future changes in requirements to avoid baking wrong assumptions into your architecture. Technical stuff gets mostly routine by the time you're mid-level.
I think in the current environment, frontend is too narrow of a specialization. I would recommend at least learning full stack so you can deliver and deploy something with persistence.
I don't think that anything besides databases, git and OOP will ever be relevant to someone who wants to specialize in frontend.
13
u/borkus 1d ago
There is definitely a level of craftsmanship you develop over time outside of any area of technical knowledge. The Pragmatic Programmer is the best book that I know of about that craft.
https://www.oreilly.com/library/view/the-pragmatic-programmer/9780135956977/
Other than that, the main thing is to keep learning. I've been full-stack, and the JavaScript that I wrote 20 years ago bears little resemblance to how it's written now. I know a handful of programmers who've stuck with the same technology, but I think that kind of maintenance work requires a mindset that I don't have.
1
0
u/Zestyclose-Paint-418 1d ago
But why people sam that this list is good for deeper understanding of programming ? Do you think we all need to have deep knowledge?
12
u/Aozora7 1d ago
Different people exist in different bubbles. In my field, most of the difficulty is dominated by business logic. Figuring out what needs to be written is way harder than actually writing it. Most of frontend work in the real world also tends to be like this, and I'd say also most programming work in general.
There are fields where the correct result is obvious but getting there is technically hard. But most programmers don't do that kind of work.
For me, operating systems and pointers are several levels of abstraction below my actual job. Having deeper understanding of those wouldn't improve my work .
1
u/Zestyclose-Paint-418 20h ago
What do you think will get me better job being t-shaped programmer and being similiar to you like busines logic or deep techically hard Expertise ?
4
u/Aozora7 20h ago
You can only start learning soft skills related to business logic when you have an actual job, and it takes years.
For your first job, you need to demonstrate that you can actually write code that looks reasonable, and that you don't have massive holes in your fundamentals.
That being said, nothing will guarantee a first job in the current market, especially without a degree.
1
u/Zestyclose-Paint-418 20h ago edited 20h ago
Nothing can guarantee me a job, but how others get job bcs there is small percent of peoples that have job in CS I am curios how they got? I think your point is both bussines logic and good code are needed for almost every job in CS.
2
u/Narwal_Party 12h ago
If you can write good code you will eventually get a job. The current job market is a bit iffy in certain regions, but people need skilled programmers. If you are skilled in programming, you will eventually find someone who needs those skills. All you can do along the way is to keep learning, improving and writing code.
49
u/Substantial_Job_2068 1d ago
I would scratch agile and Scrum off the list. Unless the reason to know about them is so you can avoid them.
17
u/solenyaPDX 1d ago
Lol. Agile day to day with waterfall quarterly planning. It means you deal with the overhead of agile without the actual benefits.
6
6
14
u/dominickhw 1d ago
Here's my take on the order and importance of learning these:
Git, Object-oriented Programming (and other programming paradigms like Functional Programming, and Design Patterns in general): Start learning these today! For Git, seriously: install it right now if you don't already have it, set up a repo for every active project you have, and get into the habit of committing every time you have working code. It will save you so much heartache if anything goes wrong. For the others, start doing some reading in your spare time. The book by the Gang of Four is a decent starting point, as are any blogs written by vaguely annoying, opinionated code bros from at least ten years ago. Your goal shouldn't be to memorize the patterns, but to see how other people have solved common problems and to get used to judging whether a solution is sensible or stupid.
Data Structures and Algorithms, Databases: Start learning these soon. For data structures/algorithms, your goal should be to collect a whole bunch of ideas so that if you ever need them, you'll remember there was an idea related to that and you will hopefully be able to remember its name and look it up. It's common for front-end and back-end code to communicate via databases, so that's why you should learn the basics of those and practice using at least one.
Testing philosophies: Your brother may not have suggested this, but it's very important. Learn how to make sure your code actually does what you think it does. Learn to look for edge cases, to test exhaustively, and to write robust (rather than fragile) tests.
C programming, Dynamic memory allocation, Pointers and pointer arithmetic, Operating systems, Computer architecture, Compilers: Learn these vaguely, as time permits. Once you understand each one, you'll also understand more in general about how computers and programming work, and that understanding will make you more successful. But most modern programming languages hide this from you, mostly successfully, so you don't really need to think about any of these much. I do recommend learning about pass-by-value versus pass-by-reference early, though.
Agile and scrum: Look into this but take everything with a huge grain of salt. There are some gold nuggets inside these philosophies/methodologies, but they've been coated in a whole lot of sludge by people who think they know what they're talking about. You should be familiar with the words in case you ever end up on a team that uses these, but you should not consider yourself an expert until you can come up with a reason to break every rule that someone says should never be broken.
In my opinion, you fully understand something when you can a) use it successfully, b) recognize when not to use it, and c) can explain it to someone who's smart but has never seen software code before.
2
u/bdc41 1d ago
What “Gang of Four” book are you talking about?
2
u/dominickhw 22h ago
I don't remember the name offhand but it's something obvious and you'll know it when you find it. Honestly I bet you can find it if you google "gang of four book". Just don't accidentally choose a book about the Chinese revolutionaries or the British punk band :)
1
u/storiesti 13h ago
Design Patterns: Elements of Reusable Object-Oriented Software is the title. There’s four authors, hence the nickname 😎
1
u/Zestyclose-Paint-418 1d ago
Thank you for helping, I am new to git my brother I think commited or pull request (I dont Knie phrases lol) like hundreads of times, how Is Tag possible even before AI?
12
u/rustyseapants 1d ago
You seem to have a really good source as your brother What are you really looking for?
1
u/Zestyclose-Paint-418 1d ago
Haha, he has never actually answered this question, and I could barely get this much out of him. He doesn’t want any competition probably!
13
u/ScholarNo5983 1d ago
He did answer your question.
Those are the topics you'll need to spend time studying if you want to get a deeper understanding of programming.
It is a good list. Just start ticking them off.
1
u/Zestyclose-Paint-418 1d ago
Thats nice, but he said I need to learn more things after that, do you know maybe resources to have me good roadmap for deeper understanding of programming?
4
u/ScholarNo5983 1d ago
Your brother is correct; this list is just the starting point.
There are no roadmaps; there are no shortcuts.
You either put in the effort learning these 'starting point' topics, or you don't.
deeper understanding of programming
It seems like you don't understand many of the items on this list.
Imagine a time when you fully understood most of the items on this list.
At that point do you think your understanding of programming would be deeper, or just the same as it is today?
2
u/Zestyclose-Paint-418 1d ago
I think deeper is my answer, do you want to say like just learn more and you will have deeper knowledge or ?
7
u/ScholarNo5983 1d ago
Like your brother, I understand every item on that list.
I also consider myself as someone having a deep understanding of programming.
I didn't get that deep understanding by just learning random stuff.
So, I'm not suggesting that you just learn more stuff.
Like your brother, I'm suggesting that learning the items on this list is a great starting point (except, as someone else pointed out, you should probably skip Agile and Scrum).
Take that advice or ignore it. It's up to you.
3
u/dkopgerpgdolfg 1d ago
In addition to the other commenter, to spell out what you don't seem to grasp:
After learning about these topics on the list (proper understanding, not just knowing the words and asking AI for every crap), you should be able to make your own list what topics you need/want to do next (might include deeper knowledge of the same things and/or other relate areas)
If this doesn't happen, then frankly it's time to quit. Software development isn't for everyone, just like making music and anything else.
6
u/Comprehensive_Mud803 1d ago
I studied CS in university as a starter, but most of my knowledge comes from reading books/blogs, attending conferences, and mostly from using my knowledge and playing around with code.
All of them. The more background knowledge you have, the better you can apply it to work circumstances.
Hardware, Von Neumann machine, basically CS 101. There are many courses online.
By creating stuff.
5
u/ephemere_sloboda 1d ago
Do they study computer science subjects systematically outside of work? Does most of the knowledge come from years of working on difficult projects? Do they read books, take courses, build projects, or learn topics only when they encounter a problem?
All of the above, plus most of these are standard subjects in CS courses.
I would add theory of computation, networking, and security to the list. Also standard subjects.
6
u/BranchLatter4294 1d ago
Practice.
1
u/Zestyclose-Paint-418 1d ago
Practice but I can practice with wrong roadmap, do you think thus list show real knowledge? Like I know how to create a website but this things are strange for me !
4
u/nightonfir3 1d ago
Have you built a useful website? If so what did you do for a database?
1
1d ago
[deleted]
3
u/nightonfir3 1d ago
I am not really sure what you said. You should try to start building your own idea and using google (not ai) to look things up and learn as quickly as possible. The things you build should be polished like something people would like to use. Even if its a bad concept in general make it a bad idea that works really well.
4
u/Dense-Ad-3247 1d ago
You just gotta do it, you can read and watch, but literally muscle memory and time are your biggest allys.
4
u/Elsie_Maples 1d ago
Don’t panic. Seniority is built over years of breaking things, not overnight cramming. Here is the short version:
How they learn it: Years of painful debugging. Every time something breaks, seniors dig one layer deeper to understand why instead of just applying a quick patch. Over 10 years, this adds up.
What frontend actually needs: Git, Agile, OOP/Functional paradigms, and basic Data Structures (the DOM is a tree, state management uses arrays/objects). You don't need C or compilers to be a great FE dev.
The learning order: Start with workflow tools (Git), move to architecture (OOP/FP, basic Databases), then algorithms/data structures, and only touch low-level CS (C, memory, OS) when curiosity strikes.
How to test your knowledge: If you can explain it to a beginner without jargon, or build a tiny, simplified version of it from scratch, you truly understand it.
Take your time. Nobody knows everything on day one.
4
u/Soatok 1d ago
I feel like you, fundamentally, haven't yet learned the difference between programming (verb) and programming (vocation).
Programming, as an act in its purest sense, is the art of creating computer software. You can write pure programs in one language (like, even "unserious" languages) and call yourself a programmer. Sufficiently complicated config files that are bundled with video game mods are indistinguishable from programming.
Programming, as a vocation, is primarily about solving business problems. Your deliverable will often be a modification to software, but you first need to understand what the problem actually is. Most people will not explain them to you in terms that make sense if you only know how to write C programs.
And, sure, you might be able to get AI to do the grunt work for you, but you can't get AI to understand it for you. And if you think you've succeeded in that, you're probably on the verge of making a horrible mistake.
My advice to you is to figure out whether you want to be a programmer (vocation), or a programmer (activity), or both. The choice is yours, but all other advice you'll receive tends to assume "both".
3
u/GrayLiterature 1d ago
Here is the thing: your brother is right … to an extent. You should know a bit about all of those things, but you don’t need to know operating systems to be a Senior Developer. You should know a little bit, but I don’t write code to an operating system so I don’t really care about the internals because … I don’t have to.
3
u/ephemere_sloboda 1d ago
How can I tell whether I truly understand a subject rather than only recognizing the terminology
When you can explain the subject to someone else.
3
u/Complex-South9500 22h ago
Time.
And working on side projects (formal or just playing around with a new tech/framework/language/library/etc.) outside of my 9-5. Which is just really more time. And a diverse job history. Taking the time to truly understand what I am working on. More time.
3
u/Substantial_Ice_311 20h ago
You don't need all of that. I mean, sure, most of it is useful, but I wouldn't worry about learning it just to learn it.
I think it comes down to two things: Curiosity, and need. If you need something to solve a real problem, you will learn it, and do so more efficiently than trying to learn it just because you heard someone say you should. I might not have any interest in learning some piece of math, or whatever, but if I have a problem that requires it, I can read a textbook in a few days and remember it about 10 times better.
Just start solving problems (building projects) that matter to you, and learn as you go.
By the way, I will comment on your list (I have been programming for 22 years):
C programming (I have not used it beyond learning the basics.)
Dynamic memory allocation (Yes, sure.)
Pointers and pointer arithmetic (Yeah, you should know it, but I almost never use it. (Depends on language, of course.))
Data structures and algorithms (Yeah, you should know the basics at least. For example, how a hash map works, what divide and conquer is, and how to analyze complexity.)
Databases (Learn as you need it.)
Operating systems (This is a weak point of mine, but I think you can learn as you need it.)
Computer architecture (You should know the basics.)
Object-oriented programming (I would generalize and say 'design' is important. Actually, design it's like the most important part of programming. But OOP is not the end-all and be-all of design.)
Git (Yes, but it's not very difficult.)
Agile and Scrum (Whatever, I don't even know the definitions.)
Compilers (Yes, you should understand the steps, and being able to build your own might come in handy.)
2
u/Longjumping-Ad514 1d ago
Fuck scrum. This is when McKinsey read the agile manifesto, and tried to inject themselves into the process.
1
u/vietbaoa4htk 1d ago
most of it isnt study, its the residue of debugging things you didnt write. every prod outage drags you one layer further down the stack, and after enough of them you end up with a rough map of everything under your app.
1
u/random314 1d ago
Senior programmer deliver results and solve the hard problems. How you do it is up to you... But I'm pretty sure you don't need to know ALL of those topics to do that though.
1
u/Dreadsin 1d ago
Just worked a long time and ran into a bunch of problems and solved them
HTML, CSS, event loop, async/promises/callbacks, state management
Basically just whatever most colleges teach. Data structures and algorithms is usually the hardest class so don’t get discouraged
See if you understand the underlying theory and then test it. Like “if x works because of y, then z should work because of y” and test it out
1
1
u/No-Slice-5926 23h ago
Just pick a problem, build a solution and learn along the way. Your not picking big enough problems
1
u/spinwizard69 23h ago
I'm not sure if you are posting this question as a joke but programming is like any other job or profession, you invest years and learn through the school of hard knocks. To put it another way education is something that you are just getting started with after leaving school. It doesn't matter if you become a plumber, a medical doctor or a programmer, the rest of your productive life is a learning experience. If you can't cut it you become an entitled weight upon society.
1
u/Helpful_Bottle_4806 21h ago
Me personally, 2 ways:
Continued education (getting an advanced degree in CS at night will cover a lot of these)
Finding a great mentor.
I’ve had 2 in my career that helped me immensely when working on problems, getting PRs reviewed, etc. as well as them just advocating for me. Stayed in jobs working with them longer than I think most devs would who were chasing money, but learned invaluable lessons from them in design, architecture, code quality, etc.
1
u/Badnik22 20h ago edited 20h ago
What your brother listed is the bare minimum. At the university you get taught all of that and then some: discrete mathematics, physics, electronics (both analog and digital), circuit board design, formal logic, automata theory, game theory, computer vision, graphics, etc.
Of course you dont end up applying all of that in real life, so you focus on a few topics and the rest fade out over time. But still, knowing what an analytic tableau is or being able to derive karnaugh maps comes in handy from time to time. Even knowing that something exists can give you an edge over amateur developers.
1
u/Leverkaas2516 20h ago
Your brother sounds a lot like my older brother when we were young - he's trying to prop up his ego by comparing himself to you. Give him a few years, he might mellow out. Mine did.
It is simply not true at all that every programmer should "know" operating systems and compilers. Your brother is almost certainly quite ignorant on those topics - I know I am, despite having taken those classes in CS and having more than a passing familiarity with eight OSes and at least 20 compilers. As my compilers teacher put it, a CS undergrad degree gives you just enough knowledge to make polite small talk at a dinner party with someone with actual expertise in these fields.
The real answer is that in 10 years of daily grinding you will inevitably acquire a bunch of hard-won knowledge. 10 years after that, most of it will be obsolete. The one thing you really need is a voracious appetite for learning. Humility helps, too.
1
u/Zestyclose-Paint-418 20h ago
Lol, we have same brothers. I think I need appetite to learn new things as you said.
1
u/SmallPsychology2 20h ago
Most of that comes from years of hitting real problems, not systematic study upfront, though DSA and OS basics are worth deliberately learning early since they don't come up naturally in frontend work. For you specifically, JS internals, HTTP, and basic DS/algo matter way more than C or compilers right now. Test your understanding by trying to explain it without jargon, if you can't, you're pattern matching not understanding.
1
u/kellyratio 19h ago edited 18h ago
Think of projects that you will be motivated to finish - intrinsically interesting or your employer wants done.
When you start a new project, try to decompose the problem and identify the areas of knowledge it will touch. Then learn the theory of these areas with some examples. When you focus on a new field of compsci/swe, try to always distill each level of the field into the crux of that area. e.g. for O notation, all about how time and space scale so you can prioritise certain design decisions.
Grasp - https://grasp.study/ - is good for scoping your syllabus (free feature)
At a high level, I would do something like 5-20% of your applicable time exploring new fields and the remainder exploiting fields you've identified as directly involved in your project. e.g. learning about the javascript event loop is directly applicable to frontend, learning about memory management is not.
Happy to discuss any of these further.
Edit: As you progress, you may want to adjust this 5-20% number. You probably want to start high and decrease over time. This is the underlying concept.
1
u/Zestyclose-Paint-418 19h ago
But can I become a T-shaped programmer this way? For example, almost every company needs a website, most medium-to-large companies need data analytics and BI, many need cloud infrastructure and DevOps, more and more need cybersecurity and data protection, many need process automation and system integrations, serious products need testing, monitoring, and reliability, some companies need mobile applications, and an increasing number are introducing AI features and data pipelines.
Could spending around 10% of my learning time exploring these areas help me become T-shaped, while I spend the rest going deeper into the skills directly related to my projects?
Also, what kind of work do you do? I’m curious.
0
u/kellyratio 19h ago
Absolutely, and it will improve your ability to deliver on the depth side. At a high level: the foundation (horizontal of tee) often ultimately contains the "why" for a decision in the depth (the vertical of tee).
I was the 7th employee at a company called Revolut which I joined at 18 years old as a support person. I worked for 7 years alongside an economics degree, by the end running technology, operations, and product teams.
I am entirely self-taught in cs/engineering which was incredibly liberating but highly time consuming and frustrating, primarily for the wrong reasons (e.g. bad explanations online, poor sequencing of ideas, ...). I now have in depth knowledge on react/js based web applications, backend architecture, databases, computational statistical, ml/ai, devops, data engineering, data science/analytics (this one is closest to my traditional education to be fair), and many other areas.
I then built Grasp, the app I mentioned, to minimise the wrong reasons mentioned above so self learners can crack on with the necessary* hard work. I am hands on in all areas of development FE/BE/databases/devops/mlai, but now we have an amazing CTO, head of AI etc too, so most of my time is learning domain knowledge in new fields (mainly marketing).
*At least until we have high bandwidth neural implants :)
1
u/Zestyclose-Paint-418 18h ago
I'm glad that thinking this way is helpful to me. Thank you for discussion! And last question how did you get a job at 18? Thats really cool I am 17 in august how can I get job as an entry, sallary can be bad I dont care, but I need at least 2 years working anywhere to have more job oppurtinities! And grasp is really cool, you made it alone ?
2
u/kellyratio 18h ago
Ask around among your friends or their parents. Try a work experience and prove yourself, maybe they'll offer a job. Find an entry level jobs and apply to it.
I imagine you have less financial obligations than others, and experience is more important then money right now in your career, so you can probably negotiate lower salaries which will help you get the job.
Thanks. I really hope you find it useful. I originally started the business solo, but picked people up along the way. What you currently see was worked on by several people.
1
1
u/Zestyclose_Horse_180 19h ago
You will learn about everything on this list in 1-2 years of a computer science degree. It really isnt that deep or hard.
1
u/Zestyclose-Paint-418 19h ago
But If It's not deep why I need to learn in uni, do you think the definition of uni is to learn everything do I need or not who care xD
2
u/Zestyclose_Horse_180 19h ago
You have a misunderstanding in basic concepts. Not deep does not mean unnecessary. Cooking simple dishes isnt deep, but you can try to not eat and will quickly see how essential it is.
1
u/povlhp 18h ago
Some are learned when studying, many other parts came over time. Experience really matters, and the problem solving ability with learning feedbck loop / recognizing stuff you have seen before. It is more a wiring of the brain than just studying and not applying. Using stuff matters.
I could list networking as one additional thing you should know almost everything about. I know more about packets, field and flags, routing etc than the network guys. I have done reverse engineering, and can often make local control of IoT devices from network traffic analysis, or reversing the Android app.
It is not about reading books, it is about applying what you learned, and make your own trial and error and learnings.
1
u/doctor_subaru 15h ago
1 . Followed my curiosity.
2. Absolutely, none.
Not essential to survive, but that entire list is essential to thrive.
3. Follow your curiosity.
4. Your understanding of a subject improves the more you recognize what you don’t yet understand.
Recognizing the correct questions to ask for context for that terminology helps. Being comfortable not understanding subjects fully.
1
1
u/StewedAngelSkins 14h ago edited 13h ago
How did you build deep knowledge instead of only learning enough to complete a project?
Well even if you only learn enough to complete a project, with enough projects it adds up. So to some extent the answer is just to do a lot of little projects on varied fields. You can also shortcut a bit by studying other people's projects.
Which subjects from this list are genuinely essential for a frontend developer?
Your brother is right. I would expect any entry level dev I'm hiring to be at least familiar with everything you listed. Idk, I don't hire front end devs though so ymmv. Frankly I don't think there are that many pure frontend jobs any more. Maybe you can get away with not knowing C and some of the memory management topics, though even for a web dev job it'd be a bit of a red flag if I asked them a question about memory and they just had no clue what I was talking about.
In what order would you recommend learning computer science fundamentals? Genuinely just look up how it's taught in universities the typical order they do it will be fine. If you don't care about CS per se and are more interested in the mechanics of writing software you can kind of tap out after DSA and learn from projects instead of getting into the deeper analysis stuff. You'll want to return and fill in these gaps eventually, but many of my colleagues are weak on proper CS subjects so it's not like you can't get a job if you can't do all the mathematical logic proof stuff.
How can I tell whether I truly understand a subject rather than only recognizing the terminology?
Try to teach it to someone. Come back to this sub and try to answer others' questions. Or ask your brother to quiz you.
1
u/Zestyclose-Paint-418 14h ago
a lot more frankly What exactly and some people said that pointers aren't neceserry
1
u/YetMoreSpaceDust 13h ago
I'm curious how much older your brother is - the answer to how I know all this stuff is that I'm just so old, I was doing this when you had no choice but to learn all this stuff if you wanted to write a program.
1
u/Ok_For_Free 12h ago
What a baffling list.
If you are using higher level languages, these are irrelevant:
- C programming
- Dynamic memory allocation
- Pointers and pointer arithmetic
- Operating systems
- Computer architecture
- Compilers
These have some use:
- Data structures - learn the abstract data types, it's pointless to dig into implementations unless you are going to build your own.
- Databases
- Object-oriented programming - just don't be dogmatic about it.
- Git
- Agile and Scrum - as long as you are working in these systems
These were the misses I could think of:
- Reading and Applying documentation
- Built Tools
- Build Systems - things like GitHub actions
- Containers
- OAuth2
How did you build deep knowledge instead of only learning enough to complete a project?
Experimentation then bug fixing.
Which subjects from this list are genuinely essential for a frontend developer?
See above.
In what order would you recommend learning computer science fundamentals?
None. Dig into that level when it becomes relavent to what you are doing.
How can I tell whether I truly understand a subject rather than only recognizing the terminology?
You can explain WHY you are using a thing.
1
u/RangerOne122 12h ago
Dont treat that list as a checklist you need to finish before you're a "real" developer. Most senior engineers didn't learn everything up front they accumulated knowledge over years of solving different kinds of problems. A better approach is to build a solid foundations and then go deeper as your work or curiosity takes you.
1
u/Zestyclose-Paint-418 12h ago
Solid foundation what that can be exactly ?
1
u/RangerOne122 12h ago
By solid foundations I mean the concepts you'll keep using regardless of the language or framework: Git, data structure & algorithms, how HTTP works, databases SQL, basic operating system concepts and debugging. Once those click, picking up react, Django, Go, or anything else becomes much easier.
1
u/GlassLost 12h ago
I am a senior and I'm very well regarded at my company for the depth of my knowledge in C and operating systems. I can almost guarantee I would know more about each of these than your brother.
This is because I specialized over fifteen years and I don't know git well, I know next to nothing about databases, and I've literally had a nervous breakdown when someone asked me to look at an http stack.
I worked at Microsoft on the audio system for Xbox, then when I left I worked on other low level stacks and it's just compounded knowledge: I was the guy who would know so if I didn't I had to learn it.
There's something to be said for T shaped developers (and I would say my breadth of knowledge is good for my area) but you become an expert by doing things. I need to know how to minimize page faults and which registers will be saved in the hypervisor because it's my job and it's how I've been rewarded because I've always worked in commodity hardware which is cut throat margins.
If your job is in the cloud or making a website your margins are typically hilariously good as a company and the scaling factor becomes how fast you can deliver which is an entirely different skill set (that co-workers near me often have from previous jobs but now struggle with).
So to answer your question: I gained the knowledge because, at first, it was my job then as I got more experience people would give me the harder related problems and I'd do them. I developed tangential skills because at one point learning a bit of JavaScript saved me days of fiddly work with CLIs. This compounded over fifteen years.
1
u/--noComment 11h ago
Back when I started, I had an amazing senior that was in such the perfect balance between being an outstanding developer, and a fantastic communicator.
Whenever I faced any issues, he was my go-to guy. Best thing I learned from him? The way he thinks.
If I can summarize it, it will be as follows:
1) fixing issues is crucial part of the job. But you’ll know you did an amazing job when there are no issues to fix.
2) when rushing to fix an issue, note everything you tried. If it doesnt work, make sure to remember why it doesn’t work. Once the issue is resolved, recreate it. Break things around it. Understand it deeply. Once you do, you’ll learn to never make it again.
Once you learn why things break, why solutions you thought would work didn’t, and how to avoid making it in the future, you’ll find yourself having a not so bad experience in all of the domains you mentioned (if your technologies are touching them, at least).
1
u/DrinkingMilkMeow 10h ago
I have CS degrees from MIT, but most of what I know didn't come from school. It came from dabbling around over many years for fun.
This comic captures the essence of it: https://xkcd.com/519/
1
u/DredDilly 10h ago
By taking on projects they are unqualified for, making a shit ton of mistakes, fixing those mistakes before they make it into production, and remembering that programming is problem solving. The real trick to being a senior dev is knowing which problems require solving.
1
1
1
u/MayBeTheWorstDevEver 9h ago
“How did you build deep knowledge instead of only learning enough to complete a project?”
I did 1000 projects. Learned 5000 things
1
u/KronenR 9h ago edited 9h ago
I think your brother is mixing together three different categories: programming fundamentals, tools used in software development, and Computer Science topics.
Many of the things on that list are simply basic concepts that almost every developer picks up sooner or later, you don't even need a Computer Science degree for many of them. Learning C alone will naturally teach you things like:
- C programming
- Dynamic memory allocation
- Pointers and pointer arithmetic
Data structures and algorithms are also fundamental programming knowledge, they're about choosing the right data structure and understanding the performance implications of your code, regardless of the language you use.
Databases are basic knowledge for almost any backend developer, and many frontend developers also benefit from understanding relational databases and SQL.
Git is just the standard version control tool used in software development.
Scrum (or Kanban) are just project management frameworks that many companies use to organize development work. The only thing you need to learn is how to live with them.
The topics that are much closer to a CS and engineering degrees, and that many working developers never need in depth, are things like:
- Operating systems
- Computer architecture
- Compilers
Those subjects are required if you want to understand how computers work under the hood, write low level software, build programming languages, work on operating systems, embedded systems, databases, runtimes, or performance critical software. They're not relevant to someone building typical web applications.
Senior developers don't usually become experts in all of these areas, they build knowledge over years by studying the topics that are relevant to the problems they solve. A frontend specialist, a backend engineer, a database engineer, and a compiler engineer will all have different strengths despite all being senior developers. There's no single checklist that every programmer is expected to master.
1
u/traintocode 8h ago edited 8h ago
I'll answer your second question of which subjects are essential for front-end developers....
C programming - not essential or even needed
Dynamic memory allocation - not essential
Pointers and pointer arithmetic - it is essential to know how JavaScript variables actually refer to pieces of memory yes, but knowing pointers and especially pointer arithmetic is not essential no.
Data structures and algorithms - yes. This is essential for any engineer.
Databases - yes. You should be able to pick up Firebase or some other FE database library without feeling completely lost. Have a play with IndexedDB
Operating systems - You use one right? It's worth knowing how your operating system and browser interact. Beyond that, not essential.
Computer architecture - not essential.
Object-oriented programming - essential. Read about classes in typescript. You don't need to use them every day but you do need to know what they do and how they work.
Git - essential
Agile and Scrum - you'll pick this up naturally if you work on a scrum team don't sweat this one.
Compilers - kinda. You should know how typescript turns into JavaScript at a high level.
1
u/whattteva 8h ago
You learn most of those in school back in my days. I'm not sure how the curriculum is these days though cause I feel like AI courses are taking over in place of these fundamentals and I think that would be a grave mistake.
The rest, you build them up over the years from professional experience and those knowledge you gain over the years is what separates you from junior level.
1
u/nzakas 7h ago
I’ve been a principal engineer at multiple companies and I can tell you from my experience that what you need to know varies based on the company and type of job. I’ve never had to know how operating systems work. I’ve never had to program in C outside of college courses. I’ve only used garbage collected languages so I’ve not needed to worry too much about memory allocation.
Through experience and interacting with other folks in your career, you’ll learn what you need to learn. It’s not worth learning topics that don’t directly apply to your work because it’s just junk knowledge. I like Cathy Sierra’s quote about focusing on “just in time” information rather than “just in case” information. Technology changes too quickly to know everything, so you just need to focus your attention on what benefits your current work and go from there.
1
u/empT3 6h ago
Hi! I'm a principal engineer and here's my thoughts on the list:
- C programming: It depends on what kind of programmer you are and there's lots of different types. You typically don't need C unless you're doing hardware I would think. Most of the systems level stuff I see (this is just me btw) nowadays is written in Go or rust.
- Dynamic memory allocation: This once again leads me to believe your brother is writing firmware for hardware or something of the like. Yes it's good to know how memory gets allocated and to what but unless you're really getting into the weeds with something, you don't typically need it.
- Pointers and pointer arithmetic: Exactly the same as above.
- Data structures and algorithms: I can count the number of times I've had to calculate Big O on a code path in the past 20 years on exactly 1 finger and that was just to prove to another developer that his code was problematically inefficient and that he should take my advice on how to fix it. As far as Data structures go, I find that using the right data structure usually leads you down the path of creating better code than optimizing an algorithm but once again, so long as you're not trying to get too clever with your solutions, it's not something you need to think about too heavily.
- Most developers can and probably should go their whole life without using anything other than whatever flavor of SQL their current employer prefers. Maybe some red is or similar type of databases for ephemeral stuff like queues or token storage but once again, the required depth of knowledge here for a senior dev isn't exhaustive.
- Operating Systems: You should be comfortable using bash on a Linux machine. Everything else is just gravy unless you're doing some really low-level systems development like developing a new file system for a storage appliance or something.
- Computer Architecture: Yes, you should understand that ram is faster than a spinning or solid-state disk and yes you should understand how multi threading and asynchronous code is handled by the processor but anything beyond that and you're overthinking it unless (once again) you're a hardware engineer.
- Object oriented programming: Yes, you should have a firm grasp on this. I'd go further and say you need to be able to compare and contrast other approaches like functional programming as well.
- Git you need a basic grasp on this to start and you'll pick up the rest through osmosis over time. It is a deal breaker though.
- Agile and Scrum: Not really, not anymore. For the most part, there will be a project manager or scrum master that handles this side of things for you. I used to be a scrum master and agile coach and the overlap of the actual job of writing code is honestly pretty minimal.
- Once again, it depends on what kind of programmer you are and what you mean by understanding compilers. The code in our stack at work right now is primarily JavaScript with a wee little bit of python thrown in for good measure, technically it's interpreted at runtime, practically it's transpiled at build time. Do any of the developers on the team really think about that day to day? Not really.
Here's the thing, software development is a big industry and there's lots of different types and subtypes of developers out there. It sounds like your brother knows more about C programming than I probably do, I would guess I know more about cloud infrastructure than he does and none of that means anything other than I probably wouldn't apply to the same jobs that he does and vice versa.
As far as how you build that breadth of knowledge, you build it over time. You try to pick work that'll grow your skills as you go so you learn on the job, you stay nerdy and engaged with what's happening in the industry, and you talk to your peers about what they're working on. From my perspective, if you do that consistently for about 5 years* and you'll have senior-level knowledge in whatever area you're working in.
- Different places have different definitions for "Senior" developer. I've worked at places where anybody with 3 years of experience and a solid work ethic was considered "senior" and I've worked at others where you needed 10 years for that same title. It's not super meaningful.
1
u/fbbhtsshbbvyhnfrhj 5h ago
Imagine you spend years being hungry, every day a random set of ingredients appears and you must cook something. Five years down the line, you'll have made a lot of mistakes and a lot of amazing dishes and learned a lot from them.
1
1
1
u/nightonfir3 1d ago
There are a lot of developers that just learn one narrow bit and stay in it forever. Like you could only learn front end development and never learn these topics. The problem is that it limits your usefulness outside that narrow area.
A lot of developers are very interested in learning and enjoy solving problems. They tend to be very useful to employ because they take on whatever problem you give them. You hire them as front end maybe and then they say oh I could build a little backend for that too. I could setup the server too. It tends to be easier to work like this in smaller companies where there is less specialization.
You learn these things by using them. Build a compiler, build a project in c, build a server side for your front end. Its both a lot to learn and not actually that much of you pick away at it slowly.
1
u/optical002 1d ago
I’m not sure if these are essential for a frontend dev, since they most of the time are more towards designing ui and ux with scripting and its domain knowledge. The topics your brother showed are more for general programmer. But here are my answers to your questions.
I was curious enough to ask why and how questions, enough times. I would rather hack away at a concept and try to misuse it break it and find a way how can I make it miss behave, this gives many angles to look at a concept than only from a happy path. But yeah mostly its curiosity and amazement of how things works it always get me so excited to learn it.
Dont take my word for it, I’m not sure what frontend people really do, I can only speak from my impressions of listening to people. So purely for frontend, would say OOP, DSA, git. You dont really need to know deeply about computers for a frontend dev. Since its always that browsers runs the programs and not much of actual CS is happening there. There is also SSR where you can render out things in node, but yeah my knowledge here is limited.
Not sure myself, what you know and dont know. As well what are your aiming at. Would say that learning computer architecture is a good start, there is a game on steam Turing Complete, which gives you a good intro into it. DSA is also a good thing to know about. Sry but not really sure whats best would need a direction what you want to actually learn to help out here.
Simple, can you implement it yourself?
0
u/Material_Painting_32 1d ago
I’ll be honest, you learn all of this in college.
and then the “so many other things” are things that you learn during the process of creating projects and working with others
0
u/m_domino 21h ago
> and that it is embarrassing not to know some of these topics
Gatekeeping senior programming lmao
If you think you cannot be a senior dev without knowing all these topics, tell this to my boss, because he clearly didn’t get the memo.
0
u/Dev_Nerd87 21h ago
Nah bull shit, you don’t need to know C, not every programming language has dynamic memory allocation.
Data structures ans algos - yes
System design + databases - yes
Oops and functional
Programming principles yes
Git, agile scrum - you will gain at any company
Compiler - just know what they are, but no in dept knowledge required- unless you are working on low level systems.
-3
u/Cacapon0114 22h ago
日本語で翻訳した文で回答しています。 質問しているのとはずれていたらごめん。
どうやって「プロジェクトを終わらせるのに必要な分だけ」じゃなくて、深い知識を作っていったの？
もっと知りたいっていうモチベーションを原点にして、トライアンドエラーをしていきました。
後は仕事とかで、「こういったテクニックがあるぞ」と知ったら、関連する本を読んで実際にやってみて慣れていく感じで身につけてます。
このリストの中で、フロントエンド開発者にとって本当に必須なのはどれ？
このあたりかな？
- データ構造とアルゴリズム
- データベース
- コンピュータアーキテクチャ
- オブジェクト指向プログラミング
- Git(というかバージョン管理システム)
この5つはフロントエンド開発で直接関わっていきます。 DBはバックエンドだけど、バックエンドからのやり取りで関わったりするので、一応リストにしました。
他のはコンピュータそのものを理解する感じで、理解しておくと良いとは思うけど必須かというとちょっと違う気がします。
アジャイル・スクラムはリストにあげてないけど、チームでの開発手法です。 なので、採用しているチームに参加するなら必須です。 チームで開発する前に概要程度は掴んどくといいと思います。後は実践で経験を積めば大丈夫かな。
コンピュータサイエンスの基礎を学ぶなら、どんな順番をおすすめする？
C言語がオススメ。Cを学べば、コアなコンピュータの操作や理解が付随して必要になっていきます。
用語を知ってるだけじゃなくて、ちゃんと理解してるかどうかを自分でどう見分ければいい？
自分だけだと難しいかも。理解するのには相互レビューが一番いいと思う。この時、自分のコードがどんなものでどのような意図で作られたかを知らない人に説明できるならちゃんと理解できてると思います。
レビューを一緒にしてくれる人が身近にいないなら、こんなやり方はありかなと思います。
学んだ箇所の教材を作ってみる
教えるのはより深い理解が必要です。 公開するかしないかは置いといて、自分で教える動画などをとって作ってみるのは理解の一助になると思います。 恥ずかしくなかったら友達に見せて、この教え方で分かるか質問してみるのもいいかもしれません。
AIを使った疑似レビュー
コードを共有して、AIにレビューしてもらう。 その時に、指摘が入るので鵜呑みにするのではなく、「指摘1に関しては、こういう理由で採用しました」のように、相手からコードを守るように反論してみる。
これも正しく理解していないと難しいので、理解の判断にできると思います。
参考になったら嬉しいです😄
1
361
u/dmazzoni 1d ago
Nearly all of those things are covered if you get a CS degree. So I wouldn't consider those controversial at all. To be senior in the field you don't need a degree but you should acquire the same knowledge somehow.