321–330 of 510 posts
This is good he is not drunk enough to tell the main dark truth - there are no senior engineers, only some people who finally managed how to cope with their imposter syndrome. Oh whait...
>> Third party recruiters are leeches Can confirm this and it was surprise for me when I discovered it. I assumed they would try to maximize $$ in my offer in order to maximize their profit. Yet most of them were trying to get offer accepted as quick as possible. Seems like more offers with less money in each is preferred over less offers with more money in each.
The same dynamic occurs with real estate agents. A successful agent optimises for quick sales, while giving the appearance of trying to get the best price. Very important to know when dealing with agents if either selling or buying a home.
Earlier quoted context omitted.
You have a great point, but let's balance this out with a few of the author's other comments. - OP uses the phrasing senior engineer. - Never worked for FAANG. This is relevant because $120k + bonus/benefits is basically a FAANG new grad. Fairly normal for SV tech companies. - Those numbers likely provide a solid standard of living, but as a senior engineer you are likely underpaid. - Esoteric and proprietary knowled…
I'm an intermediate dev, masters degree, 9 years experience, non-FAANG, higher cost of living area (not SV, NYC or NVA), and work with obscure tech and proprietary tools. It sucks that I suck. Oh well.
Are you on LinkedIn? Do you ever speak with recruiters about other opportunities? That's a great way to get a feel for the 'market rate' for your skillset in your area. When's the last time you changed jobs?
> The older I get, the more I appreciate dynamic languages. Fuck, I said it. Fight me. I see this in myself also. Static typing is such a fever at work especially amongst juniors and mids. Sometimes it’s almost as if they believe object types will spontaneously change at runtime, unpredictability.
But that’s exactly the point. It is too easy to introduce a code change that effectively will unpredictably (because it was unintended) change a type to something unexpected. And then blow up much later in spectacular ways. Try writing something asynchronous in python with futures and complex nested data types. See how long you enjoy being told that you’re trying to look up a key in something that doesn’t seem to be…
> The most underrated skill to learn as an engineer is how to document. Fuck, someone please teach me how to write good documentation. Seriously, if there's any recommendations, I'd seriously pay for a course (like probably a lot of money, maybe 1k for a course if it guaranteed that I could write good docs.) Highly recommend a journalism class at local community college.
Earlier quoted context omitted.
But that’s exactly the point. It is too easy to introduce a code change that effectively will unpredictably (because it was unintended) change a type to something unexpected. And then blow up much later in spectacular ways. Try writing something asynchronous in python with futures and complex nested data types. See how long you enjoy being told that you’re trying to look up a key in something that doesn’t seem to be…
I get all that, however I am saying that they’re being superstitious about it. I’ve been programming at least 20 years and thoroughly love programming in a dynamic language. My preferred being Common Lisp.
That said, the reason I like static languages for teams is where the "burden of proof" lies. With dynamic languages, the default being rather loosey goosey means my colleague writes a function that "asks" whether the thing handed to it is a list or an object and I have to somehow convince them that it should just take a single type, for consistency's sake... but with a static language even though people try probably exactly the same amount of weird, shit, it sticks out like a sore thumb and needs justification to include in the first place.
Earlier quoted context omitted.
I've been programming for over 20 years too, and I like dynamic languages. I like them a lot more when they're properly tested and well architected, but even the tire fire codebases are at least debuggable. The compiled stuff helps with types catching the trivial bugs, yes, but it's way too complicated to quickly debug things like seg faults. Dynamic languages let you introspect and modify things way more easily, and…
What's a seg fault? I jest, but static languages have come incredibly far since C++ (where they are already less common than in C) and I truly haven't dealt with a segmentation fault in the past many years working with static languages.
Why does he hate pandas?
Earlier quoted context omitted.
Also, most companies like to brand themselves as ‘tech’ to signal that they are growth based. Why is Peloton a tech company? They’re not. A lot of us have jobs because companies need to fulfill the image. It’s half the reason why so many people are allowed to do full-stack when in reality they would have no business dealing with those parts of the stack in a real operation. So no, you don’t actually deserve more mone…
Isn't their core product some kind of a streaming service that you pay for monthly?
> Good code is code that can be understood by a junior engineer. Great code can be understood by a first year CS freshman. The best code is no code at all. This a thousand times. Having empathy for future devs, maintenance, and bug fixes is so important.