Is this normal? Or I need to work harder to learn them again?
The nice thing about forgotten knowledge is that it's much easier to jog the memory and get it back than to learn it from nothing. You likely still use a lot of the fundamental concepts without realizing it.
I am someone who came from a non-traditional, self-taught path ~25 years ago. I did get some formal schooling in electronics, which you'd think was useless, but I can think of a few times solid digital logic understanding has served me well in the past, for example. On the other side of that, I designed some shitty databases early in my career! Understanding normalization could have saved me a lot of headaches when I was new.
Each time I’ve forgotten how to construct them and use them from scratch, but a five minute skim of some grad student’s PowerPoint was all I needed to get right back into it.
For example, to build a web app the level of abstraction your job requires is probably on the level of web frameworks and API's. Now and then you'd need to understand the web protocols. Rarely would you need to write software involving the low level transport mechanisms. Rarely would you inspect packets yourself and perform verification and decoding through pen and paper. Even rarer still would you need to use maths to design the signaling procedures between hardware components. Point being that it's normal to now know off-hand all the lower level CS stuff, but you recognize the patterns, and in the rare occasion you need to actually access all that information you wouldn't be at a complete loss.
In larger corporations, the programming is often much higher level, and consists more of stringing together libraries and frameworks and entire systems so that they fulfill a business purpose. Even simple programs can take hundreds of megabytes of memory and have tens or hundreds of dependencies beyond anyone's control.
If you want to keep practicing your algorithm skills, you might try something like https://projecteuler.net/ , which is very mathy, or https://checkio.org/ , which is a bit more user-friendly, and get some practice there. As for OS theory, there are always open-source operating systems one can contribute to, though I suspect many of them would consume a lot of a person's time.
Software Engineering is a lot of the day to day work you do as software engineer. It’s more about people, process, execution. In reality, most problems you’ll encounter in day to day software engineering won’t be CS problems. Lots of CRUD-shaped apps of varying forms and sizes.
Occasionally, you’ll get a real CS shaped problem and those are fun.
As others say - refreshers worked well since you’ve already learned the material. Find some interesting books or ideas to explore and they’ll come back.
Software Engineering = Programming + people + time.
I remember most of the stuff from university 10 years ago including the brand and model of the microcontroller I programmed (ATMEL ATMEGA8-16PU) and the names of the I/O registers on that chip, the name of the program I used to program it with (AVR Studio). I also remember most stuff I learned in Discrete Mathematics, pretty much every ADT (Abstract Data Type) I learned about in my Algorithms and Data Structures class and I remember pretty much everything I learned in Machine Learning (decision trees with minimax algorithm, alpha-beta pruning, heuristic functions, Artificial Neural Networks, step functions, sigmoid functions, backpropagation algorithm)... Time and space complexity...
Except for time and space complexity and ADTs, I haven't really used the other stuff.
On the flip side, sometimes I don't even notice (much less remember) certain things. When I'm visiting a new city with someone else, I never seem to be able to remember how to get back to the starting point - I recognize almost none of the streets or landmarks on the way back (aside from a few particularly interesting ones). My mind just delegates the full responsibility of finding the way back to the other person. It's not a problem if I'm visiting a city alone though.
The thing though is most of the thing we (at least I) learned are outdated by at least 10 years. So if you want to learn how things work out in the field I suggest reading about actual implementation. For instance this book is terrific about Linux OS [1], and this is a classic on concurrent programming [2], this one about MySQL [3] and so on.
[1] https://www.amazon.com/Linux-Kernel-Development-Robert-Love/...
[2] https://www.amazon.com/Art-Multiprocessor-Programming-Mauric...
[3] https://www.amazon.in/Understanding-MySQL-Internals-Discover...
Put a little bit of your time into learning interesting new skills in even vaguely related fields. A Jack of all trades may be a master of none, but if chaos is the future, adaptability is the key to survival.
I try to integrate my CS education in my normal software engineering work. The work is high level, not a lot of opportunity to use theory of computer architecture or operating systems, but I'm still writing programs. This means lessons from algorithms and functional programming are relevant. Organizing code using this theory has not only retained the college lessons but reinforced them. My advice is to use the tools from your education when you can, and they will only become stronger when you do.
Is it worth relearning? Only when you need it. The big problem comes when you need to change jobs. If the industry has moved on from what you know then you'll have a hard time finding a job. What make sense is to stay aware of the industry trends and keep up to date.
College was just your first stepping stone of hopefully a very long and interesting journey. It might have been special to you, but there's no need to take it along.
Also I wasn’t a very diligent undergrad and my memory isn’t exceptional :) YMMV
So it's not YOU who is "wrong": it's the universities who have it backwards and are disconnected from the real world work that programmers do.
It was a semester long project where the professor was the "business" person and everyone had shared roles (someone was QA for a sprint)...and we get lectures on code quality, testing, best practices.
To my surprise it doesn't exist in every college. Even though I went to a state school, not all state schools in that state required it.
I disliked the professor but am eternity grateful for the class...I would interview kids nowadays who want $100k but have no idea what Agile is.
This was in mid 2000s.
I've worked for companies and managers who don't know what Agile is. Not knowing one specific thing, even if it's an important thing, isn't worth writing off a candidate. If you can't teach someone the basics of agile in an afternoon, you're doing agile wrong.
You’d be amazed at how many middle managers making 250+ think that agile equals scrum or that scrum is valuable in the context of software. I’ll take the person that has never heard of it, to be honest.
So yea, it depends where you did your CS degree from. Personally, I think it taught me a lot and got us ready for the real world at least as an entry level. Back then, there were no frameworks.
The programmers should take one level or so below that level of education (which has different names depending on where you live).
Academia has mostly devolved to intellectual dick measurement contenst by entrenched academics/professors who cannot be fired.
1. CS 101 - I mean, duh? Intro to programming, basic algorithms and data structures. By the end you can at least write a simple program, and if you weren't a nerd like me (started programming at 8 because the computer was there) this would be essential. Which was the case for the majority of my classmates in college, most hadn't done any programming beyond maybe "hello world" before college.
2. CS 102 - Data structures focus, don't recall its name, may have just been "Data Structures". Choosing the right data structure for the job (though many of the particulars aren't necessarily relevant, but how to choose what, that part is critical for embedded systems).
3. Compilers - Parsing, mostly, not the translation part. This was an introductory course, 200-level.
4. CS theory - Main takeaway was choosing between regular and context free languages and understanding the limits of both. Again, parsing but not translation has been more common in my work. The proofs side has been less useful in my professional work, but informal proofs are still very useful.
5. Systems 101 - Baby operating systems, especially working "close to the metal" in embedded, even on a host OS.
6. Computer graphics - Less the graphics part, more the structure of programs to operate at high throughput on large data.
7. Calculus through Linear algebra - (required by the CS degree, 4 courses) highly applicable to some of my work. Especially the recent stuff, touching on orbital mechanics.
8. AI - In the "good old fashioned" sense, not the deep learning/machine learning sense. Turns out it's highly applicable to making expert systems. Probably because that's what it excelled at, and those can be applied to some interesting situations. I'll place this as "indirect" though, like graphics.
9. Computer architecture - Direct and indirect. On the indirect side, it really taught me to work with boolean algebra which turns out to be very useful for studying real programs and their logic (and simplifying them). On the direct side, ever done VHDL/Verilog? Good luck being successful at that without studying computer architecture (self-study or in school)
10. Another computer systems course - Had a big assembly emphasis. Means that I don't "fear" it like many of my colleagues. I can read disassembled code without much trouble, and write it with reference material (because I don't do it often, it's like Fortran to me - I can read it, but writing is slow since I'm unpracticed).
11. Parallel programming - Actually very applicable to some embedded work if you have multiple processors involved or a multi-tasking OS available.
That's 14 courses right there that I've used in my career or am presently using. And that's not counting the math courses I took when I tacked on a math degree. At least I didn't waste 99% of my time. Maybe 10%? But, honestly, I cannot think of a technical course that has not, at some point, come up in my professional work. Even my abstract algebra class from the math degree saved us a lot of time and money a couple times when I proved a requirement was actually impossible.
I can imagine some of my colleagues feeling the way you do, the lack of utility of their degrees. But they all jumped into management roles early on, their technical degrees are useful only for the lingo.
EDIT: I finally thought of a time-waster class. It was our software engineering class. In theory, that should've been one of the more practical classes. Taking requirements, developing solutions, changing requirements, changing the system, etc. In practice, it was all theory. Useless. My AI class was actually a better software engineering class since it was team-project based.
The most helpful one was a "software engineering" course, but mostly it was c++ development in a Unix environment. The part that was directly helpful was the shell scripting, not the basics of it since I was already running Linux and knew my way around a command prompt, but the professor would demonstrate things live in class, and he was a serious pro. I was just blown away at some of the stuff he knew, he could basically operate in a shell environment at the speed of thought. I'm still not like that, but I learned some stuff.
CS 101, like you, I already knew. "Basic Computer Games" from when I was a 7 pretty much covered that.
Discrete math helped a little, I mean I already knew most of it, but it helped. Stats helped a little, the first stats class we had to take. The second was all proofs, never used any of it. Never used any of the other math, linear algebra, three semesters of calc, differential equations, and a graduate level combinatorics class that broke my brain. Never used a single bit of it.
Compilers, we wrote our own compiler, helped a tiny bit indirectly. It made PL/SQL error message make more sense, I don't remember why. Operating systems, we wrote our own operating system, don't know any way that that helped. Graphics, never used it. Two semesters of assembly, never used it.
Algorithms, the first day of class we had a substitute whose accent I couldn't understand and he spent the whole class writing proofs on the blackboard and I thought, "I am so fucked". The actual class turned out to be just things like "count how many times this for loop will execute", total waste of time. One extreme to the other.
Didn't take a database course, worked with databases most of my career. That would have helped.
You could fit the parts of the courses that I've used into a 3 month boot camp pretty easily. But that's not the point of a CS degree to employers, the point of a CS degree to employers is that if someone can figure out vector calc and differential equations, they can figure out what the bug is with your CRUD app. It's just an expensive workaround for an IQ test in an environment where employers aren't allowed to give IQ tests. And also, if they can stick around for 4 years to get a degree without flaking out, maybe they'll stick around for a few years on the job.
There is nothing wrong with CS curriculum. It's just not for everybody.
This is like going to college for Physics and then complaining that they didn't teach you how to fly an airplane.
Like yeah, go to college and get enriched and all of that, but honestly, if one can be self enriched by taking courses a la carte online, then is it really worth to pay out the nose for a degree that has not much (and even dwindling) monetary return? For some, yeah, because of a level of prestige you get from having a degree. For other fields, not so much.
No, people shouldn't take physics and then expect to become a pilot. On the other hand, computer science, which is not actually science but instead a fancy way of describing usage of computers, necessarily means applying algorithms and programming languages. If someone goes through an entire CS degree program but comes out with mostly knowledge that doesn't apply to real world usage of computers, well, what were they even taught in that case?
Ideally a lot more people would be doing apprenticeships or vocational courses instead, not getting Bachelor's and Master's degrees. This isn't really viable now though because of the expectation society has for everyone to get a university degree.
Most plumbers don't need to be theoretical experts in hydraulics and pneumatics; but there certainly is time when such expertise is called for.
But then the universities teach them CS bullshit where 90% of it is unapplicable to the real world.
Why would you go to such an university which is so disconnected from the real world?
Pretty much every class in my degree program used a different programming language. You had to develop the ability to learn a language and be productive with it in a semester (~4 months) or at most an academic year. Sometimes you'd be learning two new languages along with the course material.
The CS theory I use far less. I think if you are in a job that boils down to implementing CRUD functionality (even if dressed up a bit on the UX side) you don't really find yourself thinking about CS theory very often.
Yes, if it's doing something more complex, algorithmic complexity can be a factor. The vast majority of "enterprise" or business apps aren't.
That's your problem right there. Also, the term 'university' seems to be overloaded in so many different ways (multiplied by different countries and cultures).
To me, it seems that the American descriptions and their derivatives are pretty bad, same with the "poly"-prefixed educational institutions. There are so many factors that should be irrelevant (i.e. the "name" of the institute, the cost, the location) where only the subject matter and accreditation should be the actual factors.
If I were to categorise it, you'd have to split it in three directions:
- Academia, scientific research (University)
- High-level education, scientific principles and theory, but with application of said principes and theory in mind (College perhaps?)
- General or vocational education, aimed at learning how to do a job (Trade school?)
The world needs people in all sorts of varieties, but the real-world workload is overwhelmingly one of execution, not one of theory. Of course, when people are stuck in the (rat) race, one must go to university because that is the best, and only the best is good enough. So even if going that far risks people into diving headfirst into their own Peter Principle, it is what people do anyway. The end result are a bunch of people that barely made it through university and aren't all that useful in the real world right away (not advanced enough to propel the entire field or niche forward, not practical enough to perform less theoretical work).
Of course, FAANG only wants the best, and since they can't go screen the 100k+ applications in their inboxes in detail they just start filtering based on paper promises or previous experience, with the end result being a stack of people who either already did the job, or who came out of university with advanced enough results to be malleable into the positions that are available. And thus the path is biased towards "if you want to make a ton of money so you can rent a broom closet in the bay area, you have to work at a FAANG and you can only do that with a university background". Ironically, as large and advanced as those companies may be, most people in the world don't work there. And trading in 80k for half the amount of work and normal living arrangements really isn't a bad deal when working anywhere else that's not a FAANG.
The university that I went to (Riga Technical University) didn't quite have computer science and software engineering as two completely separate degrees. Instead, we had separate IT (basically sysadmin oriented stuff) and computer science degrees, the latter of which includes software engineering.
Currently the title of my Master's degree is: "Professional Master Degree in Computer Systems and Qualification of Programming Engineer"
Similarly, the title of my Bachelor's degree is: "Bachelor Degree Of Engineering Science in Computer Control and Computer Science"
I know that many believe that the theoretic aspects should be somewhat separate from the practical ones, but to me it felt like most people could probably benefit from a bit of both - so that the research you do isn't completely detached from ways it could be applied, and so that the day to day programming you do doesn't end up disregarding things like O(n) complexity or even the theory behind how software costs increase due to mistakes made in the earlier development stages.
Then again, we do have specialization in the form of "Academical" and "Professional" degrees, the latter of which involves more course work around practical development and working in a company, whereas I think the former involved more research (though of course anyone could submit articles for peer review in the "Applied Computer Systems" journal).
It is especially important to have balance in the undergraduate B.S. degree. At this point, the foundational knowledge is presented, and a broader perspective of the applications of computer science (e.g. software engineering, database design, compilers, operating systems, applied artificial intelligence, etc.) aids in decisions toward which concepts to focus on next whether it be for enterprises or as a researcher.
I think this is starting to change, for instance, front-end developers being hired from a boot camp or similar program (although this seems nearly the opposite extreme).
Can you point out a thing in standard CS curriculums that doesn't doesn't come up in software once in a while, assuming you are not doing react and express js entire life?
My personal experience has been that this knowledge is useful as a way of knowing “the lay of the land”. My brain knows that a cpu has a limited addressable space due to the length of bits used to represent memory addresses. It has a sense for how bits travel between networks. A rudimentary idea of how computers actually work.
Systems engineering makes you think about these things a lot more. e.g. I had to go back and relearn most of my networking knowledge to really grok DNS and firewalls in order to debug application connectivity issues. When you dig into them it feels like revisiting a garden you have been to earlier and you are excited to know how its changed over the years and whether there’s any new flowers in there.
When you see a problem that would benefit from application of CS theory you might end up applying it without realizing that is what you are doing.
The consolidation is that “use it or lose it” means you just gotta start using it again.
You’ll be okay and there’s no reason to panic! Panic will just make everything worse. Chill - you have got this and you will be okay.
The other thing is that it's normal. As systems get more complicated, the number of interactions between N elements grows as O(N*2). Thus, most "engineers" spend the bulk of their time organizing and arranging things, fitting things together, troubleshooting, dealing with vendors, etc. In some fields, manually operating tools such as CAD becomes more efficient than understanding the algorithms programmed into the tools. This is basically human powered information processing. The work needed to make the things that are fit together, such as algorithms, falls to a small fraction of the workforce, who are not necessarily the most highly rewarded, as their work is not so visible.
I suppose this would be an issue if I were working at a startup or doing some greenfield development, but I suspect the majority of software developers/engineers are working on a codebase that is already established. And, the need for those from-scratch fundamentals is low to non-existent and naturally that knowledge atrophies.
It does feel silly working on a big hulking code base but I have to appreciate the precision.
Memory locality, prefetching and branch prediction are all likely more important to actual performance than Big O complexity and those things can change from architecture to architecture.
When I was learning big o notation numa architectures where just becoming commercially viable. You’d get dramatically different performance results in one lab to the other based on which machines were in it.
But I do work for a very large company (not FAANG, but close) and so admittedly, the scale there is far larger than in most jobs, and knowing this stuff really does matter a lot more.
I have a bunch of those "questions" that I try to always remember.
My YouTube history is a bunch of those types of videos with some best moments clips from my favorite comedy shows in between them.
These are 3 very different professions that have 'coding' in common. And given the huge demand for "analyst programmers" nowadays, a lot of people who studied the other two, end up working as the latter.
Note that I based this analogy on being a CS graduate myself and also working for a while for a chap whose academic speciality was mathematical modelling of things like water hammer.
Discussions regarding PE-style certification for software development often get stuck in the mud, but I'd wager that we'll see something emerge in this generation for general development (as it already exists for safety-intensive applications). And crypto may actually increase the demand for formal proofs and other deep CS concepts.
Your CS prof may have made the remark with some degree of disdain, though there are quite a few programmers / developers out there making better money than a college prof (excluding those working in private consultation).
“Its hard to get a man to understand something when his salary depends on his not understanding it”
My alma matter focuses on undergraduate education emphasizing real-world applications.
Kind of nomal.
>> my mind is delivering the feature to meet business goals and Kubernetes stuffs.
Definitely not normal.
The CS fundamentals you are talking about are things that matter when you are doing specific kind of programming. For ex: OS theory matters when you are writing an OS.
In the same way network theory is helpful when writing programs that communicate on a network.
I find I've retained a lot of my CS theory, but in a "quiet" way. [1] It only really surfaces when I'm talking about things with colleagues, and I take some information for granted, but ultimately work out they don't have the same understanding.
I do a fair bit of database work, and all that normalisation, foreign keys, relationships knowledge is "just there". On the other hand I only very occasionally have cause to do graphics work, so I remember the very basics, but not much else.
I also remember we did things, which I haven't used for 30 years, but which "holds no fear". I recently had cause to consider writing some code in assembly, and it may or may not happen, but either way I have no "fear" of what it entails, its "just assembly code."
So to the OP I say, your CS degree isn't about facts. It's about an understanding of how things fit together, and in your career you'll use that knowledge in ways you won't even notice. So relax, it's not like you have to write a refresher exam to keep up :)
[1] today I'd get basically nothing in an exam, I don't remember all the memory-rote stuff, like naming the 7 OSI networking levels, or some specific algorithm, or the theory of P vs NP complete etc. But I actually tangentially use that knowledge every day.
That's a very generalized statement. A C program run on OS and so does a JavaScript on a webpage (at least indirectly). I am not sure how OS theory is useful in the JavaScript on a webpage case.
You gave an example the OS theory would only be good when writing an OS. But the (valid) counter point was that it also becomes relevant when interfacing with an OS.
JavaScript first and foremost runs on your browser, not on the OS itself. So understanding how browsers work (DOM, APIs, XHR...) becomes akin to understanding how the OS works.
(I also have the following rant, which I don't like too much [too polemic] after posting, but I'm keeping it for transparency sake)
No-one claimed you need to know quantum physics to understand what happens to the electrons in your CPU; but generally it's a good idea to know how the next few layers you're interfacing with work (in either direction). And that's often the OS, or the network, or the cache behaviour of your CPU or the superscalar nature of the GPGPU you use to accelerate something important. Or another something attached by some bus to your MCU in the embedded device you're building, or maybe the user navigating that website.
The prospects of passing leet code interviews without major time investment are not great .
Responses in this post is changing my perception. No wonder, recruiting is hard.
I have found a knowlge of OS, computer organizaton, digital logic, networking, compiler design are crucial. If you are into datascience or ML, math is absolutely essential. I don't know why so many people think forgetting fundamental is normal.
If anyone has idea on ways to design a revision schedule, please help me. Thank you in advance!
You're right though, we should hang on to the fundamentals to make adapting to new tech easier.
It’s pretty normal for people to forget knowledge they’re not using. Do you remember the physics, chemistry, etc fundamentals that you learned in high school/college if you haven’t been using them?
Because it is normal.
The notion that you recall everything from a random class you took some semester years ago, and that it won't ever leave your memory, is not realistic nor grounded on reality.
Furthermore, "fundamentals" don't mean the same for all people. Most developers will go through their entire career without implementing a single data structure or write a single pet OS or put together a single parser. They will however have to handle OO programming and software architecture and concurrent programming.
I guess that the definition of "fundamentals" is tied to what you need to do to perform on your every day life, and that's why absurd things like interviewing candidates based on data structures and ask stuff like what's placement new in C++ is a complete waste of time and effort to assess how a candidate will perform.
I am curious, do you enjoy your work? Considering that even if you do not have to 'use' any knowledge of how your 'system' is built, how do you resolve problems in your 'system'? Even then, what is is fun of not knowing what you are actually doing?
It amazes me.
The average software engineer does not need to remember compiler design, digital logic, esoteric datastructures etc to do their job well. If people are forgetting "fundementals" (of which I would not classify specialised subjects such as compiler design), then it's because they don't need it for the job they're doing.
Although I do agree that Computer Science theory is definitely important and knowing it is better than not. Sometimes a project your working on would benefit from knowledge of datastructures, cache locality, etc, and that makes the years of academia worth it.
Some people manage to use that knowledge to bootstrap an understanding of the software ecosystem they find themselves in, and others really struggle with it and flail around. Then some other people manage to bootstrap these things from a biology degree or art history degree (or no degree at all)... somehow. I'm not entirely sure what correlates with success on that front actually.
It is unpleasant for you to be on the other is of this argument? May be that is.
I am wondering why you had a prenatious tone.
CS topics are too interesting to forget. I always find fundamentals are useful to take good decisions in my work.
Guess what? I don't speak much my language for straight 15 yrs. But am still able to enjoy books written in that language, I can speak on phone fluently.
Everyone experiences this eventually, but not everybody realizes it at first.
Now that you know your capacity I recommend doing an annual round up of the things you still remember and can confidently put in your CV.
Also take note on how job interviews all but ignore this phenomenon.
1) Computer Architecture vs. Organization, CPU/Execution Units/Caches/Memory, Clock, Pipelining, ILP, Multiprocessor, SoC.
2) OS responsibilities - Resource management(everything), Kernel vs App, Process vs. Thread, System Calls, Timers/Interrupts/Device Drivers.
3) RDBMS Normalization - "The Key, The Whole Key and Nothing else but the Key".
4) Serial vs Parallel vs. Distributed programming.
Hit the books again if the above don't ring a bell.
I meant it to be "direct" since i felt the other responders were not being quite truthful and tiptoeing around in their answers. IME, That is never a good way to help somebody when it comes to STEM subjects.