I find that the biggest misunderstanding happens because "new grads" (and I happen to be one) confuse _asymptotic complexity_ with actual complexity. I'm not sure sure why, but CS courses and interview questions mostly focus on _asymptotic complexity_ and usually forget to take into consideration the complexity for "little values of n". And funnily enough, in real life n never goes to infinity! In a strict sense big…
After a few years working on real-world code, I understood that faster asymptotic complexity was often slower on average. After a few more years working on real-world code, I understood that it's usually better to choose the algorithm with better asymptotic complexity, anyway. Like, sure, my O(n) algorithm will be 10x slower than your O(n^2) algorithm for small n. But users aren't going to notice a few microseconds.…
New Grad vs. Senior Dev
381–390 of 392 posts
Re: New Grad vs. Senior Dev
#382Earlier quoted context omitted.
If your application is stateless following your definition then it's trivial to break the monolith down to microservices that focus on a bounded contexts while sharing a common db. This is a very well known microservices pattern. https://microservices.io/patterns/data/shared-database.html
Martin Fowler lists the benefits of microservices as Strong module boundaries Independent deployment Technology diversity And with a single database you severely limit the benefits from strong module boundaries and independent deployments. Suddenly you have to synchronize deployments, and anyone can pull or change any data in the database which now must be enforced with discipline which gets you into the same boat as…
Only worse because you don't have tools (IDEs, linters, etc) telling you what parts of the code have to be changed.
Re: New Grad vs. Senior Dev
#383Earlier quoted context omitted.
> To mirror what some others are saying here, students should also be taught the realities of cache behaviour, SIMD-friendliness, branch prediction, multi-threaded programming, real-time constraints, hardware acceleration, etc. They are in many places I'm aware of. At least, as an EE (at Stanford, but I've heard MIT and several others do the same), I had to take a digital system design class, but the majority of the…
> They are in many places I'm aware of. Yes, sure. I hadn't meant to imply otherwise. The pure-algorithms lecturer needn't cover these other topics in detail in their course, but should be careful to emphasise the uses and limitations of complexity theory. > this class is not a requirement for CS since it's potentially too hardware oriented I don't see the sense in this. Computer scientists publish work on applying G…
I agree, I'm not sure why this is the case either, just my idea as to why it may not be a requirement. (Some part of the class does involve writing a good chunk of a 5-stage RISC processor based on MIPS, but this was still relatively straightforward with just a basic understanding of digital logic.)
Re: New Grad vs. Senior Dev
#384I'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…
Not everyone is accepting suggestions like you. I am a senior dev and I always try to push new ideas to my team lead (senior dev and older than me), but all I get is blatant criticism because he says "I've tested it and didn't like it). A clear example: refusing to move to Spring Boot and still staying on the dead horse JavaEE, which got more complicated and fragmented than ever since Java 9
Re: New Grad vs. Senior Dev
#385The way I read this, TIM FREAKIN' PATERSON, the man who wrote the most hated "operating system" in history, put an algorithm with a nasty performance bug into the standard library of VB, and conveniently forgot to document that this function is no good for large and/or repetitive inputs. Confronted with his blunder, he not only doesn't correct his blunder, but instead condescendingly proclaims that those inferior VB…
Re: New Grad vs. Senior Dev
#386Earlier quoted context omitted.
Not everyone is accepting suggestions like you. I am a senior dev and I always try to push new ideas to my team lead (senior dev and older than me), but all I get is blatant criticism because he says "I've tested it and didn't like it). A clear example: refusing to move to Spring Boot and still staying on the dead horse JavaEE, which got more complicated and fragmented than ever since Java 9
Just like I asked my Team Lead to drop IE support. Even the product owner is OK with it. He is quite obsessed with IE.
Re: New Grad vs. Senior Dev
#387Earlier quoted context omitted.
I've been in discussions about internal applications with few hundreds users and very moderate amounts of data being shuffled and stored and some people, of various backgrounds, are just so convinced that we need to go all in on Kubernetes, Microservices, Istio etc. And all I can think about is "Hey, you could build this with a small team as a simple monolith and with proper caching you could probably run this on one…
> And all I can think about is "Hey, you could build this with a small team as a simple monolith and with proper caching you could probably run this on one or two raspberry pi, that is the amount of power you actually need here". If your product has a global audience who needs to CRUD stuff, caching and a single raspberry pi won't get you very far in the game. If it's just an intranet stuff with a few hundred users a…
In 2016, Stack Overflow ran on 11 IIS web servers, but they really only needed 1.
[0] https://news.ycombinator.com/item?id=18496344
[1] https://nickcraver.com/blog/2016/02/17/stack-overflow-the-ar...
Re: New Grad vs. Senior Dev
#388Re: New Grad vs. Senior Dev
#389Earlier quoted context omitted.
You can have a monolith and still suffer form these problems and need these technologies, as soon as you introduce a load balancer.
If the application is stateless (all state lives in the DB) you can run as many copies of the monolith as required behind a load balancer.
Re: New Grad vs. Senior Dev
#390I'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…
As a manager I always hated these situations, firstly, because the problem the juinor dev is trying to fix is almost never as productive as "Hey let's upgrade to python3", it's more like "Hey let's migrate to this specific version of this specific tool that I happened to use on one of my pet projects" or "I've got this incredibly ambitious plan to change everything about this peice of code you gave me to work on" (You're only looking at that code at all because it's simple, relatively unimportant and we're trying to ease you into the team).
The problem is if it is the junior dev whose wrong you're now going to start seeing all these new issues because you've taken someone whose intuition isn't quite there yet and given them something incredibly complex to do. That's when you get into work 2 weeks later and find their mega-commit changing 2,395 files changing tabs to spaces and auto-modifying everything to camel case. Taking a chance on that intern's pet project means a lot of support from others in the team.