To summarize this whole thing in a word, that'll be YES. But the fact this essay exists goes to show I have to elucidate on this matter far more than I anticipated. The inspiration for this is a post on LinkedIn which seems recondite to me but makes sense to an undergrad student entering the world of software engineering.
I swear to God, I'll snap in an instant if someone brings it up thinking they are being erudite iconoclasts in this industry. I get it, you don't need to be a completive programmer to be a great software engineer. Heck, I'm an example of such programmers. I've built a bunch of toy compilers, a markdown parser and even an operating system despite being ranked as a newbie on CodeForces (yeah I know I'm not active on it but you get the gist). Not to mention I joined codeforces after my internship at Amazon only because I was bored and wanna try something new. However, if you think this vindicates you from learning about data structures and algorithms, here's my warning, you'll be in the world of pain and will hate the entirety of software engineering.
When I started coding I was very clear that DSA was not going to be my main focus since it does not translate into industry experience like development does.
This is the arrogance of a novice, when starting out every new programmer "thinks" the same since they're not into a challenging position where they need to fine tune. Only for them to realise that they absolutely need it to save time, resources and themselves from a potential brain damage. In my brief professional and personal programming experience, I have never found a situation where my DSA knowledge didn't translate into industry experience, in fact it's the opposite. Almost all of the instances, I found my solutions weren't regressing when I used my knowledge of data structures to get the task done.
But to get a chance of sitting for internships of big companies I started practising DSA questions a couple of weeks ago and my intuitions were right I am not made for DSA.
He already made up his mind, and now it seems to be confirmation bias to me. Giving this dude some pointers was a hard sell. Me and Abir tried and it seems to be bleak due him only fixating DSA to LeetCode which isn't true since data structures and algorithms are fundamental to software development. Like don't you think, for a message passing system it makes sense to use a hash map instead a code kludge made with multiple if-else statements?
Even going through the theory part feels like a burden since I know it won’t help me significantly in developing good software.
Hold on Mr. Turing, how are so sure DSA won't help you write good software? And why the theory part feels like a burden? Part of software development is creating a solution in your head and then translate that into code. Theoretical knowledge makes you navigate through practical solutions efficiently, I used to detest theoretical knowledge too in the past only to come back after a few years. Might as well run with it without fighting to begin with.
The good thing is that this post was made by a college student, which is why I can forgive his ignorance, I've hidden the name for privacy reasons. Had this was made by someone with 2+ years of professional experience, the pejorative "Soydev" was reserved to be used. For those who aren't familiar with this, "Soydev" is a pejorative coined by Luke Smith to deride software engineers for writing poorly implemented software that is hard to maintain and is criminally inefficient. This word seems to indicate the soy boy variant of software developers.
Personally and professionally, I consider soydevs to be a blight on this industry. While as a customer they provide poor quality software, they are also horrible professional role models lacking any form of professionalism that bears with the title of senior engineer or expected from someone in the block for 4+ years in this industry. When I was a teenager, I decided to become a software engineer not out of the pursuit of fancy FAANG jobs or changing the world, but out of sheer frustration with unstable, and bloated software.
If no one wants to build efficient and accurate software, I'll write it myself.
Apan Trikha (2015)
While this journey is pretty long, I'm thankful the seniors I work with have high levels of professionalism. Even though I outshine them in the ability to write C++ code, I get out-shined against their wisdom that leads them to accurate solutions of complex problems efficiently. But I consider it's a real thing since I often read poorly written open source code and spats from people who can't do otherwise very basic tasks in programming.
When it comes to data structures and algorithms, this is a thing that is unanimously agreed upon as the fundamental aspect of software engineering. Those who think otherwise fall into 3 categories:
Once I got into making parsers, I got the importance of recursion while making a recursive decent parsing and it's pain points reminded me the importance of an abstract syntax tree. While implementing ArukaOS, I implemented sys calls using function map. This was done using an array of function pointers along with enums in C, saved me tons of if-else statements.
If you think unironically that DSA is useless, let me give you something to reflect on your wrongness. Answer these two questions honestly and you'll see why DSA is important.
How can you create software that is accurate and efficient in terms of memory and speed if you don't know
- How to represent/organize your data?
- Or, how to implement a solution using the given data?
Once you get to the answer you'll realise these answer reflect the importance of data structures and their corresponding algorithms.
While it seems plausible to get into software development without knowing data structures or algorithms, it'll be equivalent to living in wilderness without utilizing your primal gift of intelligence. It'll work in short term, in the long run, you'll find yourself frustrated on a trivial solution. A solution that could've been solved within minutes had you knew that data structure or a technique to create an algorithm.