anthlax

The current optimal strategy for new grad SWE applications is to shotgun as many out as possible as fast as possible. I know many people who’ve applied to 50+ new grad jobs (even in this market) and due to its many to many nature, many new grad job applications get 20k+ applicants (from an inside source at a medium sized company). It makes new grad applications slightly better than a random lottery. There is nearly no difference between an applicant that gets screened in and an applicant that gets screened out at the margin. Really unfortunate situation, and I don’t know if there’s a solution. Colleges solved it by adding a barrier to entry to apply (you have to pay) but jobs can’t do the same thing. Perhaps a arduous application process is a kind of mechanism to throttle applicants and weed out those who are just applying for applyings sake?

To be honest, this is more of a question about how best to handle errors in asynchronous event handlers (not handlers marked as async, I mean like send an email at xyz time). Imo best way to solve this is to get notified of an error in sentry, be it an NPE or validation error.

In a case where the client expects an immediate response (http GET) getting “400 validation error: foo is not allowed to be null” is a lot more meaningful than “500 Null pointer”.

In general I try not to model invalid states - less mental overhead (no one has to tell you xyz can’t be null it just cannot be null).

Ofc this is a matter of opinion and the lines get blurred as soon ad you move stuff to runtime.

Most frameworks give 400 bad inputs. If the client gives a null but null is not allowed in the type, it will auto respond with 400 before it ever invoked the handler.

Java spring does the same thing: if you use an unboxed type (int instead of Integer) and the client passes in null, the handler will never be invoked.

Sure, but the one thing Kotlin has that makes me never look back is null-safety. Java has optional and non-null annotations and whatnot, but you have to be vigilant and put the right annotations everywhere. Kotlin you get this for free.

The extra sugar on top is super nice too - listOf, mapOf, x to y, apply… I think it just makes code that much cleaner. None of these are make or breaks but together they work amazing. A lot of what I work on professionally is still on Java 8 or 11 so I don’t get any of the cool features like record types.

Most of the OSS I do is Kotlin bedsheets I just enjoy writing Kotlin. I don’t feel that way with the older versions of Java (I’m starting to with the newer ones).

Quite the broad generalization! What say you about American cities? The Americans living there are viewed as failures by other 5, as well as themselves?

This is very cool! I didn’t know this was a thing. Thank you.

Yeah, they’ll review when they get the chance :). I was talking more general advice. Thanks for taking a look, appreciate it!

Levels mixes location which kind of sucks - for example, Google’s non-negotiated pay bands for entry level are 220k - 157k depending on location. That’s an incredibly wide gap - > the standard US citizens salary. Levels takes the average of those numbers so the usefulness dwindles.

Malthus anyone?

Ah! It seems your crystal ball is working better than mine. Could you tell me how you know a bigger crash is coming?

Could you give an example of a modern idea that young people echo that is “propaganda driven and ready made sentences?”

Mixed feelings about go. - I dislike the verbosity of the error checking; rust’s ? Operator did it 100x better. With go, if some function deep in the call stack might return err, every single point in the call stack above it has to check “if err != nil”. I understand the point of this; unchecked exceptions are very bad, but some syntactic sugar could go a long way here.

- I dislike in general code generation. This isn’t a Go thing, this is a “any language but rust” thing: macros are just _so good_. I don’t have to keep a code generator daemon running in the background, and I don’t have to worry about running a code generation step in CI.

- I dislike implicit interface adherence: this makes it so hard for me to navigate code bases. For instance, If I take a Foo interface, I just have to guess at where all the Foo implementers are?

Those are just a couple of my qualms. In general, though, I do reach towards Go for projects that I know aren’t going to hit massive scale (scale as in “need 10 developers supporting it”), and it hits the sweet spot for me that’s between prototyping in python and enterprise in Java / Rust.