Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New Grad vs. Senior Dev

ericlippert.com

Post reply on HN
Print view View original

141–150 of 392 posts

Re: New Grad vs. Senior Dev

#141

Post by why_only_15 »

lonelappde wrote: post #83
RookyNumbas wrote: post #68

Earlier quoted context omitted.

I like to start by thinking about cache locality and ensuring linear layout. Next focus on one-time, or minimal memory allocation. Then there are a bunch of small, systemic things you need to get right. After that you can start worrying about worst case big O scenarios. Of course this depends on your language. A c programmer will have a different mental model than a python one.

In Python performance is your last consideration, and that's OK. Most things computers do don't need to be fast. Only the innermost loops run the most do.

i used to think this was true, but theres a lot of stuff recently where there really aren't such hotspots everywhere. when i profile UI stuff for instance there isn't some big obvious hotspot to optimize, the runtime is spread all throughout the app doing random things. if all the regular code you write is just ludicrously slow, you're going to end up with something that's just laggy and without any way to fix it other than rewriting it

Re: New Grad vs. Senior Dev

#142

Post by arendtio »

I think it is good when new grads have the knowledge to see that those things don't look right and can articulate how and why it should look different.

After all, when you come across a problem, that does not contain just 100 chars, it is very helpful to know what you can use to create something that still works with reasonable resources.

Re: New Grad vs. Senior Dev

#143

Post by est31 »

ericlippert wrote: post #41
saagarjha wrote: post #33

By 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…

That's a great example; the most important part of your anecdote is the end which says what was the user impact? There is no prior reason to believe that a 50x speedup is actually a win; taking an algorithm from 100K nanoseconds to 2K nanoseconds when hitting the file system takes billions of nanoseconds is not a win for the user, and taking an algorithm that takes 5000 years down to 100 years is probably not either.…

Another anecdote: A few months ago, I was adding a bunch of features to an open source library. Before changing, I studied the library's code to find out where to put the change best. During that study, I found an instance where the code performed a slow operation, but I didn't attempt to change it because it was out of scope for my change, and I didn't want to introduce bugs [1].

A little bit after I have made the change, an user filed a bug [2] to the library about slow behavior when you passed a large amount of data to the library. They were using the public release instead of git master, so my code wasn't at fault thankfully. Due to the knowledge I attained from doing the change, I could quickly confirm that precisely this slow part was cause for the performance slowdown, and was able to file a PR to reduce the library's complexity from quadratic to linear [3].

It wasn't very complicated from the algorithmic point of view, I only had to create a lookup structure, but the lookup structure had to be created in a certain way so that the library still behaved the same way as tested by the test suite. It also had to support things like duplicates as the original implementation also supported them, as a very important feature in fact (toml arrays).

[1]: https://github.com/alexcrichton/toml-rs/pull/333

[2]: https://github.com/alexcrichton/toml-rs/issues/342

[3]: https://github.com/alexcrichton/toml-rs/pull/349

Re: New Grad vs. Senior Dev

#144

Post by ericlippert »

rkagerer wrote: post #119

Shockingly, InStr( , "docum") = 0 I'm a dev with some grey hair who feels it would have been useful for all that fantastic domain knowledge from Paterson to get documented in a code comment. I'd love to hear if either of them ever went back and did that?

In this case I think not. However I strongly agree with your position and have tried hard to ensure that my code is commented such that it explains why the code works as it does. See https://ericlippert.com/2014/09/08/comment-commentary/ for more thoughts on this subject.

Re: New Grad vs. Senior Dev

#145

Post by bogdanu »

maliker wrote: post #136

I'm the senior dev on my team, and whenever a new dev joined my team they would look at the codebase and go "ew, python2? Just use python3." That gave me a chance to explain the testing and refactoring cost that would come with changing python versions, and how the benefits to users would be almost zero. And then at some point one of the new juniors said, "hey, there's a lot of filesystem performance improvements and…

The reverse of this also happens: new team manager joins a team of 4-5 dev and goes "eww... a monolith, we'll write an MVP in 3 weeks with microservices, CQRS and all".

Long story short, one year and a half passes and the mvp is still not finished, the architect leaves the company and some poor guys (from an outsourcing company) are still going at it with the same architecture.

Re: New Grad vs. Senior Dev

#148

Post by yashap »

reader_1000 wrote: post #114

In real life, you will always start with simple working implementation and go with it. Then if things are slow, you profile your code with a good profiler while running for some kind of real life scenario and spot the slow parts (also keep in mind that profiling may affect the program's behaviour). After that you may want to consider alternatives with less asymptotic complexity iff that's the part causing slowness. O…

Although I mostly agree, there’s certain types of simple, fundamental performance considerations you want to take when writing code the first time, otherwise you’re just needlessly dealing with tones of performance issues in prod. Like make sure your DB queries are well covered by indexes, if you’re repeatedly looking up items from a list, turn it into a map or set first, in FE code try to keep re-renders to areas of the UI that need updating, etc.

Correctness and simplicity are almost always things you want to focus on over performance, but there’s still SOME level of simple performance best practices that you want to stick to up front. Similar to the tradeoff between YAGNI and software architecture - if you don’t start with some sort of coherent architecture, your project is gonna descend into a spaghetti mess. Ignore simple performance best practices and you’ll spend way too much time fighting performance issues.

Re: New Grad vs. Senior Dev

#149

Post by joshlemer »

corysama wrote: post #86
dilyevsky wrote: post #67

Earlier quoted context omitted.

Every good cs course has a section on cache aware algorithms. And i call bullshit that constant factor is not mentioned too

It wasn’t taught to me. And, in my previous job I interviewed many dozen fresh grads. One of my questions was “How much slower is it to sum integers in a trivial linked list vs. a trivial array?” 90% answered “Umm... I don’t know. 2x?” When asked why, they all said “1 op to sum the int +1 op to traverse the pointer.” It was amazingly consistent.

What would be the kind answer you're looking for?

Re: New Grad vs. Senior Dev

#150

Post by duck2 »

Jasper_ wrote: post #139
corysama wrote: post #65

Earlier 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…

Models are easy when you turn every cow into a sphere. But physicists never believe their models respect the real world. Computer Science should be about the Science of Computers, not hypothetical models acting on hypothetical architectures.

Computer Science existed long before there were computers. I think the Science of Computers you mention is known as Computer Architecture.
Post reply on HN