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

341–350 of 392 posts

Re: New Grad vs. Senior Dev

#341

Post by capableweb »

rumanator wrote: post #327
cc81 wrote: post #290

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

If you don't pile abstractions on top of abstractions on top of kubernetes on top of docker, you'd be surprised how much you can do with a single small-sized instance.

Re: New Grad vs. Senior Dev

#342

Post by dm3 »

spangry wrote: post #303
bambataa wrote: post #242

Earlier quoted context omitted.

It's probably based on some other meme I'm not familiar with but I really love how this borders on the absurd.

The original was about quantitative easing: https://i.kym-cdn.com/photos/images/original/001/781/373/b1e...

There's even an interactive version...

https://brrr.money/

Re: New Grad vs. Senior Dev

#343

Post by cousin_it »

ergocoder wrote: post #315
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…

Here's a tricky one that I encountered a year ago. A junior tried to advocate for browser test. Senior from the developer productivity team said browser test couldn't possibly be made non-flaky. I didn't know how to advice the junior because I agreed with them. Saying "something is infeasible/costly" is like a blanket statement. There was no way to quantify that. On a flip side, we couldn't justify the impact of brow…

There's another type of tests: visual diffing. I've used it a lot and I love it.

1) Keep a set of a few thousand URLs to diff, add new ones as needed.

2) Use a tool that can request these URLs from two versions of your app, make a side-by-side visual diff of the resulting pages, and present a report of any differences.

3) Before committing any change to your codebase, run that tool automatically on the whole URL set, comparing the new version of the app with the current version. Then the committer should review the diff report manually and it gets attached to the commit history.

This way, adding coverage for new functionality is easy (you just add some URLs to a text file) and the whole thing runs fast. And it catches all kinds of problems. Not just UI bugs where some bit of CSS messes up something unrelated, but also you can run the frontend diff after making any backend change and it will catch problems as well. It won't solve all your testing needs, but it covers a lot of ground cheaply, so you can concentrate the custom testing code where it's actually needed.

Re: New Grad vs. Senior Dev

#344

Post by michaelchisari »

tmpz22 wrote: post #127
dimtion wrote: post #7

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…

And they never factor in training or maintenance level complexity, i.e. your ball of mud runs fast but have fun teaching ~5 juniors how to use it two years from now.

This is key. If the number of objects processed will never be large, then it makes more sense to write a quick, easily understood O(n^2) loop in under a minute and move on.

Taking an extra 30 minutes to an hour or longer to optimize and test for large inputs that will realistically never exist is a waste of time and money.

If you feel that the value of N might, in some strange and rare combination of success and changed requirements, exceed the expected amount, add a check for the lowest value that may signify a problem and throw a warning.

  if N > 1000:
    debug.warn("N count of %d may be too large for existing algorithm. Consider optimizing.", N)
Leave it at that and get on to more important things.

Re: New Grad vs. Senior Dev

#345

Post by lima »

capableweb wrote: post #341
rumanator wrote: post #327

Earlier quoted context omitted.

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

If you don't pile abstractions on top of abstractions on top of kubernetes on top of docker, you'd be surprised how much you can do with a single small-sized instance.

k8s has no performance overhead and can be useful even for simple applications (like for reproducible dev environments and CI). Agreed, otherwise.

Re: New Grad vs. Senior Dev

#346

Post by Aeolun »

redis_mlc wrote: post #279
bcrosby95 wrote: post #266

Earlier quoted context omitted.

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.

It doesn’t matter if you have transactions or not. Just make sure you execute things in the right order! Same for referential integrity, if you just make sure nothing ever goes wrong, there’s no need for it! /s

Re: New Grad vs. Senior Dev

#347

Post by Aeolun »

jSully24 wrote: post #312
bogdanu wrote: post #145

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

Never hire anyone who’s top priority is not to first understand the whys of the current situation and understands how to move forward from there. If they have “the answer” but don’t understand the “why we are here today” their decisions should be, at the very least, suspect.

On the other hand, don’t hire who wants to understand everything first either. Sometimes a bad choice was just a bad choice, and it’s a waste of time to figure out if it was taken for a reason.

Re: New Grad vs. Senior Dev

#348

Post by sokoloff »

darkteflon wrote: post #340
JamesBarney wrote: post #252

Earlier quoted context omitted.

Basically it comes down to Distributed logging:hard Distributed debugging: hard Distributed versioning: hard Distributed transactions: very hard And on 95% of projects these problems aren't worth solving for the benefits of microservices.

Why is distributed logging hard? Genuinely curious.

It’s not the log writing that’s hard; it’s the log insight extraction that is. When you compare poring over logs from multiple invocations, even with request identifiers, the tooling is worse than tooling to look over stack traces/core dumps.

A calls B, C, and D. B puts an item on a queue that eventually causes a call to C. Both B and C call D. Which D call is slow/erroring? Is it the AD, the ABD, the ABqCD, or the ACD call?

Re: New Grad vs. Senior Dev

#349

Post by Aeolun »

nine_k wrote: post #319
joshwa wrote: post #292

Earlier quoted context omitted.

Knowing how so many devs are hungry to move to the new shiny thing, the question is often more like "why hasn't this been rewritten in Python3 already? ". Possible answers: • Legit technical or cost/benefit reasons • Probably a good idea but no budget/time for the effort • Somebody already tried and it was a disaster • No manager has been stupid enough to humor the devs

Most reasonable devs are not jackdaws and do not want a "new and shiny" thing for its shine. Mostly devs want to go away from the old and increasingly creaky thing. And when the cost / benefit ration is finally right (that is, it's creaking loud enough and slows things down much enough), the move hopefully happens.

> Most reasonable devs are not jackdaws

Most devs are not reasonable.

Re: New Grad vs. Senior Dev

#350

Post by pitay »

commandlinefan wrote: post #206
bogdanu wrote: post #145

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

On the other other hand, I’ve worked on system that stuck with “the old way” (like ColdFusion) for so long that it was impossible to even find documentation on the old programming environment if you could find somebody willing to maintain it. The longer you wait to upgrade, the more it’s going to hurt when you finally do.

The reason I have been left without product document is because Oracle bought the software the organisation was using. Cannot stress enough the value of keeping an offline copy of the documentation of a product rather than relying on a companies website or similar.

Edit: Also want to add software installation files are very important to keep offline as well.

Post reply on HN