Admittedly clueless question: what does 'brrr' mean? (I'm not a software dev and idioms that may be obvious to others are unfamiliar to me.)
It's a meme not a software thing. It's the metaphor for sound of a machine working at high speed.
New Grad vs. Senior Dev
91–100 of 392 posts
Re: New Grad vs. Senior Dev
#92By the way, here’s an anecdote for the flip side: at one of my internships I was working on a tool to process large log files, and by careful application of Aho-Corasick I was able to make it about 50 times faster on the dataset we were dealing with, which made using the tool change from “let’s go grab lunch while this finishes” to “let’s stream the logs through this live”. Sometimes you do know how to make things fa…
The open source intrusion detection system Suricata [1] used aho-corasick until intel released hyperscan [2] in open source. Hyperscan is apparently more performant than aho-corasick. If your language can handle the C libraries, have you considered trying hyperscan to see how it compares? [1] https://suricata-ids.org/ [2] https://www.hyperscan.io/
Based on their use of past tense, I’d assume they aren’t interning there anymore.
Re: New Grad vs. Senior Dev
#93Heh... reminds me of my first proper MS internship, when I too was responsible for speeding up some code, this time in the VS Code Go extension. This code was responsible for tokenization, so it affected pretty much every operation and ran on every edit. Important shit. Day 1: do some basic hoisting. O(n^3) => O(n^2). Tokenization times for a 10k line file go from ~15s to 500ms. Sweet. Days 2-30 [1]: ideate, develop,…
One of the most important things you can do in perf analysis is to know when to stop looking for incremental improvement. If this subject in particular interests you, we did a lot of work in the C# lexer/parser so that once the file is lexed, it only re-lexes the tokens which changed on every edit. It also does fun stuff like the syntax colourizer only runs on code that's actually on the screen. Getting every operati…
Does the C# parser implement incremental parsing by just using a recursive descent parser with caching, or does it do parsing with nonterminals as lookahead?
Re: New Grad vs. Senior Dev
#94I dislike the mentality that one must "struggle" to be patient with new devs and that it's "more than they deserve." Is it really so hard to help other people learn, and to accept that the only advantage you have on them is starting earlier?
I take your point, but let's be fair. My attitude was "this code is bad and I'm going to demonstrate my skill by improving it" when it should have been "please teach me what design and implementation concerns went into the choice of algorithm here". I was lucky to get a gentle and thoughtful correction for my presumptions.
It's great that you saw that you had a bad attitude and reflected on it. But ignorant arrogance is a personality trait some people have sometimes, not a new grad trait.
Re: New Grad vs. Senior Dev
#95I dislike the mentality that one must "struggle" to be patient with new devs and that it's "more than they deserve." Is it really so hard to help other people learn, and to accept that the only advantage you have on them is starting earlier?
Except it is a struggle. It's often a struggle to get newer devs to stop wasting time, it's often a struggle to get them to focus on the problem you're trying to solve instead of the new library all the cool kids are using, etc. I agree with the "more than they deserve" mentality, but let's be honest here: it's a struggle. We've all been through it as new devs, and we'll all help new devs struggle through it as well.
I've seen in with senior devs too. "architecture astronauts" and "principal engineers" interfering with solving problems. Why drag an unnecessary distracting stereotype into the conversation?
Re: New Grad vs. Senior Dev
#96Admittedly clueless question: what does 'brrr' mean? (I'm not a software dev and idioms that may be obvious to others are unfamiliar to me.)
It's the whirring sound of a motor. The for loop is metaphorically spinning to loop over everything instead of doing something smarter to find what it needs. The programmer thinks the whirring sound means it's doing a lot of work for him.
It's an interesting dichotomy because the most practical solution could go either way. Maybe it's looping over a table of 20 customers and the wasted time is microseconds that wouldn't even justify ten minutes of developer thought, or maybe it's looping over a million customers and causing all sorts of capacity problems. Maybe the memetic "senior dev" here knows the former is true, or maybe his "senior" experience was all misplaced and he's clueless.
Re: New Grad vs. Senior Dev
#97Earlier quoted context omitted.
Except it is a struggle. It's often a struggle to get newer devs to stop wasting time, it's often a struggle to get them to focus on the problem you're trying to solve instead of the new library all the cool kids are using, etc. I agree with the "more than they deserve" mentality, but let's be honest here: it's a struggle. We've all been through it as new devs, and we'll all help new devs struggle through it as well.
I've worked with juniors who always scope creep their very simple introductory tasks. Something as simple as "add these two fields to the existing API response" suddenly turns into "change the method signature of 90% of existing methods because DTOs make code lines shorter".
New team members also notice the mess veterans made by feature creeping "add two more fields" to a 100 field monstrosity that is a usability and security nightmare, but no one can improve it because the lead engineer got promoted for building v1 and refuses constructive criticism.
Re: New Grad vs. Senior Dev
#98Earlier quoted context omitted.
It’s because Big O is Computer Science. Cache effects are Software Engineering. Professors of CS do a fine job of teaching CS. They even briefly mention that there is a implicit constant factor k in O(k n log(n)) and then they never mention it again. They certainly don’t mention that k can easily vary by 128x between algos. AKA: 7 levels of a binary tree. Or that most of the data they will be dealing with in practice…
Every good cs course has a section on cache aware algorithms. And i call bullshit that constant factor is not mentioned too
When I took data structures and algorithms, I believe almost every single lesson was concluded with the caveat that constants are important.
Re: New Grad vs. Senior Dev
#99> NO! YOU CAN’T JUST USE BRUTE FORCE HERE! WE NEED TO USE SEGMENT TREES TO GET UPDATE TIME COMPLEXITY DOWN TO O(LOG N)! BREAK THE DATA INTO CHUNKS AT LEAST! OH THE INEFFICIENCY!!! I'm the opposite of this stereotype, and I think there are more like me. Two reasons as to why: (1) Psychological: I never had this. As a junior dev, I don't like to optimize because I feel a bit of pain when I need to moderately focus. I c…
The "malice" aspect is a great one and I did not go into that in this post because of course back in the 1990s we were not at all concerned that someone would maliciously craft inputs that would slow down this algorithm. In modern code we'd want to do a threat model that considered the consequences of untrusted inputs.
In the 1990s Microsoft certainly didn't think about malicious inputs to its software, and the world suffered.
Re: New Grad vs. Senior Dev
#100Earlier quoted context omitted.
It’s because Big O is Computer Science. Cache effects are Software Engineering. Professors of CS do a fine job of teaching CS. They even briefly mention that there is a implicit constant factor k in O(k n log(n)) and then they never mention it again. They certainly don’t mention that k can easily vary by 128x between algos. AKA: 7 levels of a binary tree. Or that most of the data they will be dealing with in practice…
That's an arbitrarily restrictive view of computer science. It's like saying teaching physics ignoring friction perfectly fine.
Yes you should ignore the details of friction for the first few semesters.