A CS degree helps you understand why something is slow, and how to make it faster. Experience tells you when it matters.
New Grad vs. Senior Dev
271–280 of 392 posts
Re: New Grad vs. Senior Dev
#272I would use the standard ISO C strstr instead of writing the function they are calling find. Yes, we had strstr in 1994; it was in the 1989 ANSI C standard. On a very small system, strstr will probably just be naively coded, to save space. On a big system, it might use Knuth-Morrison-Pratt or Boyer-Moore. I don't have to care; by using strstr, that decision is taken care of.
As I noted in the text, the actual problem that we had to solve was complicated by a great many factors not the least of which was the fact that the library had to handle strings from different string encodings.
Re: New Grad vs. Senior Dev
#273I've noticed there's a similar form of this at the sr. dev/grizzled veteran divide.
The sr. dev will look at "old" code in horror and be sure the only way to make it perform is to port it to a newer language/framework/architecture.
The grizzled veteran will profile the code, think, and tweak a few lines. No fancy new things or big re-writes needed.
Re: New Grad vs. Senior Dev
#274Tell that to leetcoders
Re: New Grad vs. Senior Dev
#275With the world of developers becoming "senior" at faster and faster rates, we're asymptomatically approaching the demise of these questions, no?
Certainly at any startup "sr" is simply a self assigned title.
Re: New Grad vs. Senior Dev
#276As a new grad myself, I completely agree with the author’s freak out when seeing “inefficient” looking code. But I feel like this applies to basically all aspects of a company life as a new grad software engineer. For me at least, there seems to be a lot of inefficient things going on in every aspect of the company. Maybe the author is right in that there is a reason behind those seemingly “inefficient” things. Howev…
One thing you learn over time is many of those code horrors are there for a good reason, put there by someone solving a real problem, in the best possible way given time constraints. It is just the reason is lost to history. This is one reason the "big re-write" almost always fails. You are throwing away all those hard learned lessons just because they aren't apparent on reading of the code.
That is also true (perhaps less often) for byzantine process related procedures.
Re: New Grad vs. Senior Dev
#277Earlier quoted context omitted.
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.
CQRS and microservices has so much overhead, I'm amazed at how many companies adopt microservices without having anyone know a single thing about distributed systems. I think people underestimate the glue required to make microservices be useful. I had a similar situation at my last company where they spent a year and a half converting their monolith into half ass microservices and it still wasn't working properly. T…
They're perfect for a startup with lots of funding and little traction. So much busywork to keep the team churning!
Re: New Grad vs. Senior Dev
#278Earlier quoted context omitted.
What would be the kind answer you're looking for?
The question had 2 goals: 1) Do you think about cache at all or is it just something you heard mentioned as important that one time? 2) It's a good lead-in to discussing the effects of cache in algorithms. How that conversation goes helps me to understand how that person thinks and discusses complex problems. A good answer would be "I'm not sure, but probably way, way slower because linked list can point all over mem…
> But, in practice most will be 20-200x slower
My A+ answer is "My guess is [x] but instead of speculating we can create a test to discover the performance. [Describes test]."
Koala_man above says:
> I wrote a benchmark and found the difference in this case to be 3x-3.5x.
The actual number depends on a lot of things, of course (language, architecture, test methodology...), but it is possible that your 20-200x A+ answer is incorrect.
Re: New Grad vs. Senior Dev
#279Earlier quoted context omitted.
I just started working on a new project about half a year ago, completely greenfield. The backend developer (there is only one...) jumped into microservices directly, deploying on AWS Fargate, trying to split out as many things into containers as possible, because that's the "proper" way of doing it. We still have few users as the project is new, but hey, at least we could scale to 100000s users in a few minutes, ins…
A monolith can handle millions of daily unique users. The database is the hard part. In the web world, if you have less than 10s of millions of daily users, as long as you design an application that holds no state itself, the architecture is usually more important for scaling your team and the size of your codebase rather than the number of users you can handle.
With microservices, you lose the ability to use database transactions across services/tables. Later on, when people realize this, it's too late.
It's priceless to see their expressions when senior mgmt. and business owners finally find out.
Re: New Grad vs. Senior Dev
#280Earlier quoted context omitted.
What would be the kind answer you're looking for?
The question had 2 goals: 1) Do you think about cache at all or is it just something you heard mentioned as important that one time? 2) It's a good lead-in to discussing the effects of cache in algorithms. How that conversation goes helps me to understand how that person thinks and discusses complex problems. A good answer would be "I'm not sure, but probably way, way slower because linked list can point all over mem…
Question... What kind of software do you mainly work on?
I'm guessing it's not CRUD apps.