I disagree with the comment regarding the tech stack. It does matter - it only doesn’t if you’re willing to spend more money scaling worse preforming applications.
yeah, it is referenced later on.. it's a drunken post, so a bit disorganized :D
Drunk Post: Things I've Learned as a Sr Engineer
341–350 of 510 posts
Re: Drunk Post: Things I've Learned as a Sr Engineer
#342Earlier quoted context omitted.
They should try programming on an airplane or without internet connection. For some the productivity drops to zero without stack overflow.
"For some the productivity drops to zero without stack overflow." And it is bad to be a newb? And even for experienced devs to go to stackoverflow regulary ... isn't it productive, to not always reinvent the wheel? I can solve allmost everything on my own. But if I have a new problem, I assume someone else already had - I would be stupid, to figure it out on my own, when I could get a working solution in 5 min googli…
The issue does arise when you aren’t able to understand the problem space enough to realize that what you copied from stack overflow has a mistake or doesn’t fit the requirement you need (e.g. perhaps it doesn’t match your error handling architecture or so on).
That said, stack overflow can be a great source and I’ve written plenty of code with a comment pointing to a SO link to further explain a pattern or snippet for a future reader.
Re: Drunk Post: Things I've Learned as a Sr Engineer
#343Earlier quoted context omitted.
Pragmatic for me is knowing what’s wrong at compile time, and not being told much much later at runtime that I nested this array in a dictionary in an array wrong, or that my string is an integer. I got older, stopped using python for exactly the reasons above (I just really felt that it was wasting my time for trivial reasons), and found mypy which made it bearable again.
Yeah, I'd be on board with that if 99% of the people talking about typed languages at the moment weren't using Typescript for use cases where you literally get instant feedback from hot reloading as you code. Every time I see an example of a bug that TS would solve, it's something that I routinely find in 2 seconds by looking 10 degrees to the left at my second monitor and noticing the screen is white and there's som…
As your application gets larger it's not that easy. Even if your code hot reloads all the time, getting to the piece of code that breaks might take 10 clicks or you are working on some feature that has quite a few combinations for use and/or settings that influence it. Maybe some feature flags thrown in. With this setting off and that feature flag on, suddenly your integer is a string. Boom runtime error but only because your QA thought of it when testing it 3 days after you already moved on to another ticket.
Re: Drunk Post: Things I've Learned as a Sr Engineer
#344> 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.) I agree but think it is more than just _documentation_: effectively communicating ideas through text was one o…
I end up reading the source half the time, anyway; documentation is often incomplete, dated, and possibly incorrect. For code, I'd prefer the time go into designing a cleaner interface and making what calls do obvious. That said, I find high-level documentation for larger systems to be very valuable. I also find Python's docs to be lacking compared to Java's; I'm often left wondering about the definition of what type…
>end up reading the source half the time, anyway; documentation is often incomplete, dated, and possibly incorrect.
I'm a pretty firm believer that documentation has to live next to the code. Otherwise it's nearly guaranteed to be out of date and/or incomplete
Re: Drunk Post: Things I've Learned as a Sr Engineer
#345Earlier quoted context omitted.
Do it, if only to find Clojure.
Clojure goes against so many of lisp's timeless philosophies and principles that it can hardly be described as a lisp. When someone says "lisp is the greatest programming language" it's these principles that they refer to, most of which Clojure discards so it can play nice with Java and promote very specialized ways of solving problems in order to best fit a particular niche. The best way to discover the essence of l…
Does XLST count then?
Re: Drunk Post: Things I've Learned as a Sr Engineer
#346Earlier quoted context omitted.
They're stuck because they work with proprietary tools on obscure tech. Nobody else wants them because their experience doesn't translate. I recently made the transition but it was extremely difficult. I ended up with 1 offer after ~10 or so interviews and ~50 or so applications.
Yeah, this is my situation. I am AWS certified and started working on a team that uses it, sort of. So maybe I can transition off of there in a year or two because the subject matter sucks.
Get. Out.
Re: Drunk Post: Things I've Learned as a Sr Engineer
#347Earlier quoted context omitted.
It all depends on your use case. If your input is bound to a small N, I’ll take the simplest to understand implementation regardless of algorithmic complexity. Future you and other people will thank you later.
If small-bound is 50, yes. Otherwise, be careful; future people will not thank you for that timebomb.
It’s safer when it’s hard coded data and really bad versus dynamic data and sorta bad. I’d rather have O(n!) with a list of length six because it’s going to break hard before it gets to 20. O(n root(n)) on your customer list will slowly creep up and it would be easy to not notice.
Re: Drunk Post: Things I've Learned as a Sr Engineer
#348> Algorithms and data strictures are important--to a point For me, 90% of day-to-day algorithms use is not writing O(nm) or O(n^2) code, and knowing which data structures to use to avoid it (usually a hashtable, occasionally a heap or balanced tree).
It all depends on your use case. If your input is bound to a small N, I’ll take the simplest to understand implementation regardless of algorithmic complexity. Future you and other people will thank you later.
I'm fond of saying that one of the big differences between theory and practice in CS is that in practice, we don't immediately drop the coefficients. Instead we study the problem to learn what the coefficients are and use that knowledge to guide our approach. For instance, there are times a linear search will just flat out beat a binary search due to cache effects.
Re: Drunk Post: Things I've Learned as a Sr Engineer
#349> Hacker News and r/Programming is only good to get general ideas and keep up-to-date, the comments are almost worthless That's a weird one. I don't know anything about that subreddit, but HN comments are frequently great. I submit stuff because I want there to be HN comments on it for me to read. I typically read the comments first and only bother opening the link if they were interesting.
R/crypto has a great community fwiw
Re: Drunk Post: Things I've Learned as a Sr Engineer
#350>I don't know why full stack webdevs are paid so poorly. No really, they should be paid like half a mil a year just base salary. Fuck they have to understand both front end AND back end AND how different browsers work AND networking AND databases AND caching AND differences between web and mobile AND omg what the fuck there's another framework out there that companies want to use? Seriously, why are webdevs paid so l…
there is plenty of other software engineering work that is way more complicated than full stack web dev, and there are a lot of web devs.