Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
asgs1156362dMaps and Sets are the most obvious ones we use all the time for their constant time lookups and comparisons
-
Root8260061dHeh. The legendary golden boys at $work would see this and chastise you for “premature optimization.”
According to them: “you should only ever think about optimizing anything after you run into a performance wall.” … which explains the horrible performance and memory issues we keep running into everywhere.
Fucking hell I hate my job. -
bosslogic19661dMassive data processing may require knowledge of algorithmic complexity, sure. That's a bit niche, however. Maybe less so going forward.
-
hjk101573160dI know about performance but really can't be bothered by big O notation.
So far I'm the one fixing all the issues. Most of the issues are race condition or database representation related.
All my coworkers seem to know about big O, but none of them can seem to grasp the rules of synchronization. Understanding the implication of things is far more important than anything any school has to offer. -
CaptainRant361159d@hjk101 A good school helps you train and understand the implication of things through projects.
Perhaps as a tip for the junior devs out there, here's what I learned about programming skills on the job:
You know those heavy classes back in college that taught you all about Data Structures? Some devs may argue that you just need to know how to code and you don't need to know fancy Data Structures or Big o notation theory, but in the real world we use them all the time, especially for important projects.
All those principles about Sets, (Linked) lists, map, filter, reduce, union, intersection, symmetric difference, Big O Notation... They matter and are used to solve problems. I used to think I could just coast by without being versed in them.. Soon, mathematics and Big o notation came back to bite me.
Three example projects I worked in where this mattered:
- Massive data collection and processing in legacy Java (clients want their data fast, so better think about the performance implications of CRUD into Collections)
- ReactJS (oh yes, maps and filters are used a lot...)
- Massive data collection in C# where data manipulation results are crucial (union, intersection, symmetric difference,...)
Overall: speed and quality mattered (better know your Big o notation or use a cheat sheet, though I prefer the first)
Yes, the approach can be optimized here, but often we're tied to client constraints, with some room if we're lucky.
I'm glad I learned this lesson. I would rather have skills in my head and in memory than having to look up things and try to understand them all the time.
rant
job-skills
data-structures