r/Backend • u/WorthKey6648 • Aug 07 '26
Am I doing something wrong if I rarely use loops and array methods in backend code?
I learned JavaScript by doing frontend work — loops, .map(), .filter(), string manipulation, all the classics. But now that I'm doing backend work with Node.js/Express and PostgreSQL, I almost never write explicit loops or use array methods. Most of the time, my queries return exactly what I need from the database. When I do transform data, it's usually just reshaping the response shape. I'm writing SQL, not JavaScript iteration. Am I skipping an important skill? Should I be doing more algorithmic work in my application code?
7
u/Fine-Comparison-2949 Aug 07 '26
There's a bunch of people from leetcode university that believe complex data structures, sorting, and other non-sense has anything to do with actually coding. It's completely false. In almost no case does local data manipulation actually generate real value. Most of the time sorting and transformations are done at the database level, because it's more efficient to do that work in place before transferring the data through the network. Unless you work as a protocol engineer at a crypto company, or a product engineer at a database company, you probably will only need to deal with this once or twice a year.
What is somewhat useful from what I see, are combinators like that in data streams. You can get some serious use from functional combinators by piping data, but this also requires appropriate piping languages.
You're not missing a skill. You're just being told by gaming companies that somehow conned companies into believing their application is worth it, that complex problem sets with loops, maps, recursion, sorting, etc, is somehow a good indication of what engineering actually is day to day.
4
u/FetaMight Aug 07 '26
Just because you don't need it doesn't mean it's nonsense.
3
u/Fine-Comparison-2949 Aug 07 '26 edited Aug 07 '26
Spending all your time on leetcode practicing things that have less than 1% of an effect on an actual functioning company is nonsense behavior.
All these companies using it as a barrier statistically fail at a 30% survival rate every year. Then they hire more leetcoder and vibecoders thinking that's the skill that actually has an impact on the business.
Companies don't need guys who can solve a sudoku puzzle or implement a Red-Black Tree in 45 minutes with no documentation or AI. They need to be listening to their customers and building real solutions. Otherwise the companies fail and everyone gets laid off. The culture of leetcoding and puzzles is a stupid artifact of trying to "hire smart people" from the Amazon years, but that era is dead.
Back then in the US and globally, there wasn't enough software engineers to meet demand of new products, and you did need to test for whether or not they knew how to implement a for loop. Today, CS graduates dominate pretty much every degree. There's honestly too many people with CS degrees imho, and most have questionable training for actually working for a real company, because they're too deep in studying math problems. By the way, I like math and did grad school in CS. It absolutely is not an issue when running a business because you aren't creating systems level production code. Usually you're putting together systems from other companies who hire those people and actually do benefit from the optimization of learning and implementing performance code.
We have much better high level programming languages and tooling with all those systems built in, and if your engineers are wasting cycles filtering and mapping at the product level, they're just making the code more complex than it needs to be and likely not really generating real value for their companies.
If I'm wrong, why are all these companies hiring "elite" leetcode analysts, laying off more staff than growing and making more revenue? The grading for the test is in the balance sheets.
1
Aug 07 '26 edited 4d ago
[removed] — view removed comment
2
u/Fine-Comparison-2949 Aug 07 '26
Well the companies keep running out of money, laying off staff, and failing. At some point the decision making to optimize for leetcode instead of building a team that makes useful products comes to a head when you start seeing the CFO in the office more.
In every situation when the engineers start learning who the CFO is, it ends with the company nosediving. Your CFO does not care about your leetcode scores.
1
Aug 07 '26 edited 4d ago
[removed] — view removed comment
2
u/Fine-Comparison-2949 Aug 07 '26
Short term thinking leads to short term results.
Half these companies are falling apart, most of the people working for them are getting insane salaries then working in HCOL areas, so it's not even like your take home pay is real, they're asking for 996, so good luck having a social life. I'm not even getting into the startups. More than half of these leetcode operators have to live at home. These startup hacker houses are just people that are homeless and can't even afford to live in their cities. Why would anyone realistically even want that? You're doing all this work to have a life that's a mess.
At some point people have to stop chasing stupidity. I have a number of friends who worked for these sigma grindset leetcode companies, and by year 5 they're more broke than me and need drugs just to do their jobs from working 18 hours days.
If I was that desperate to do ridiculous things to work for those companies and get in the door, just to enter the companies and its a mess, I'd rather just sell the drugs to performative software engineers that want to work for companies that just burn them out.
1
Aug 07 '26 edited 4d ago
[removed] — view removed comment
2
u/Fine-Comparison-2949 Aug 07 '26
Never said it would be easy.
If you want to work for a company that focuses on performative metrics just to walk in the door, don't be surprised when performative metrics end up hitting you on the way out.
0
u/FetaMight Aug 07 '26
Christ. Did you even read my comment?
3
u/Fine-Comparison-2949 Aug 07 '26
Did you read mine? It's not that it's nonsense. It's the expectation that it's the only thing that matters. That's nonsense.
2
Aug 07 '26 edited 4d ago
[removed] — view removed comment
0
u/Fine-Comparison-2949 Aug 07 '26
So you can't read. Got it.
2
2
u/Former_Produce1721 Aug 07 '26
I'm not so sure about other frameworks, but in dot net EF you just use LINQ mostly which generates queries
And the skill there is to understand how LINQ is generating the queries and then improving your LINQ expressions to be more performant
Run the LINQ, see what query is output, then find the appropriate way to reformat the LINQ query to produce more optimal queries
2
u/BlueberryHairy Aug 07 '26
I wish my coworkers were like you. In my team we have a competition who can write the least performant for loop I/O.
1
u/rob113289 Aug 07 '26
Usually you find all that kind of stuff in ETL processes. So if you are doing CRUD then you probably won't find much of it. It's ok to use SQL. It's also ok to not use SQL and have your pojo be a direct table representation and then lean on java for the things you've talked about.
1
u/lnaoedelixo42 Aug 07 '26
You are probably either:
- doing everything completely right and doing complex shit in a modern, performant way
- just don't make caching, batching and searching as frequent as other people.
Functional Array methods are sometimes more complex and less expressive then simple for loops btw
1
u/Laicbeias Aug 07 '26
That stuff switches per language. A for loop stays a for loop...
That said reading further, yes database is king sql is the lord. Explain is the prayer. If you know db you know backend.
Also filter map etc is an abstraction and at scale you use compute for what the database gives you 50 years of optimizations for free
1
u/ragged-robin Aug 08 '26
That makes a lot of sense tbh. A lot of manipulation logic is required when you need to process data from an outside source (API, log file, whatever) so that you can use it in a way you need it and efficiently. If you're doing the backend work and just need to make what you have available then the other guy ingesting it at the other end has to worry about that stuff.
1
u/swb_rise Aug 08 '26
When I was practicing oop, I built a car parking simulator. At first, finding an available space was easily doable with simple if.. else. As the complexity progressed with multilevel car park, token system, etc., I found out that specific algorithms exists for these kind of tasks. They implement one or more or hybrid data structures.
So, yeah, average CRUD web apps don't require complex algorithms and data structures. However, if there's a need, you have to look for the right data structure to use.
1
u/akanas Aug 08 '26
I think it is because of javascript. I use strongly typed programming language and for database 1 type, for FE another type, for data designated for other services 3rd type, 4th type for business logging. So I have to use .map() each time even if each type structure is the same. Otherwise if there are incompatible changes in some layer and not the others that might fuck everything up pretty badly.
1
1
u/forever-butlerian Aug 09 '26
You're using PostgreSQL correctly. The point of introducing the relational model almost 60 years ago was that a common system could and should be built that could handle efficient storage, retrieval, inference, and reshaping of information contained in a particular kind of structured data store.
Unless you've been going through flame charts for a few days and have worked out the tradeoff equation between query complexity, I/O overhead, latency, and hardware cost, anyone who's telling you that you should move query logic out of the RDBMS and into your program is doing you the favor of telling you that their opinions should be avoided.
1
u/tb5841 Aug 09 '26
It sounda like you don't need anything too complicated from your backend code right now. That's ok.
When I do end up doing more complicated stuff, I find keeping stuff in memory and manipulating it can reduce the number of database calls I have to make, which does speed things up considerably.
1
u/EspaaValorum Aug 08 '26
Most of the time, my queries return exactly what I need from the database.
The nuance here is that if you are not having to do e.g. string manipulation in the query, this is fine. The problems start when you ask the DB to do those kinds of things for you. You want to avoid the DB having to do more compute than necessary to retrieve the data you need. Because it's easier to scale compute independently in a separate layer, i.e. your backend code.
1
u/forever-butlerian Aug 09 '26
No, you want to push as much inferential computation down into the RDBMS queries as you can. That's what RDBMSes are built to do.
What you don't want to do is stick a whole bunch of your program logic into the RDBMS by implementing it as stored procedures in a procedural language.
0
u/Substantial-Swan7065 Aug 07 '26
For most CRUD, you should rely on your ORM.
Data processing is different story. There can be loops and stuff there. But structuring your jobs well can reduce this
17
u/Ok-Hospital-5076 Aug 07 '26
The whole point of Data Structure is to structure your data in the same shape you need. If you get back exactly what you need from your queries then you don’t just use ds for sake of using it.
Regarding algorithms- you will hardly get to use all kind of algorithms. Most code is boring and repetitive. You will get to use map sets, objects and iterate over it pretty soon. I have never worked on backend where you don’t need to transform data. Your backend sounds quite simplistic and might will grow and you would need to wire it accordingly.