Drunk Post: Things I've Learned as a Sr Engineer • Hacker News Board

Re: Drunk Post: Things I've Learned as a Sr Engineer

#471

Post by lanstin » Mon, May 31, 2021, 4:58 PM UTC

repExpMon wrote: post #227

3pt14159 wrote: post #210

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…

> but it's way too complicated to quickly debug things like seg faults I know you've listed the common argument for static vs dynamic (dynamic -> so fast to code but slow to run, static -> way too complicated)but after a decade in SE I still have yet to see some good evidence of this. Yes some static languages (like Java) will make developing certain things slower vs JS but is Java a good statically typed language ?…

Also if you live near to high quality, it is easier to keep quality high. I worked in one place with a lot of C servers. Any time they segfaulted, the developer got an email with the back trace and a link to the core. Counts were kept and managers made sure people knew to fix them. For my code, it was always easy to fix each segfault. They were rare and usually the stack trace showed all that was needed.

I also worked in a place that was far from quality and they had totally given up on memory leaks and most segfaults. If the segfault happened deterministically enough, it might be fixed. infinite loops would be fixed. But sporadic segfaults were just ignored. It was too hard to get close enough to quality to make it worth fixing.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#472

Post by runeks » Mon, May 31, 2021, 5:02 PM UTC

seoaeu wrote: post #396

OJFord wrote: post #333

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

Obviously HN commenters like us are going to think that. Honestly, I bet even YouTube commenters would say the same about their own community.

That’s not obvious to me at all. I comment on both YouTube and HN, and I don’t feel I’m part of any “community”. I just think the quality of the average, highly upvoted HN comment is about 100 times greater than the equivalent YouTube comment.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#473

Post by joshuamorton » Mon, May 31, 2021, 5:09 PM UTC

kbenson wrote: post #406

lazyant wrote: post #367

Earlier quoted context omitted.

Quoting what a HN user said in another post a few months back "if a person can break a system, the system was broken to start with".

Eh, that's a nice thing to say, but it only makes sense at certain scales, and no matter what, there's always a person that can break it. If any random person can break it, it's already broken. If any employee can break it, it's probably broken (there are very small scales where even this doesn't apply. Ever worked for a company with less than ten people? There's probably something any employee can break). If any emp…

There are lots of places where we require that no single person can break the system at least in a certain way.

For example code review and LGTM ensures that a single individual can't just break the system by pushing bad code.

Often there are other control planes that don't have the same requirement, but I think the idea that there must always be one person who can break the system isn't clearly true.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#474

Post by joshuamorton » Mon, May 31, 2021, 5:12 PM UTC

lostcolony wrote: post #412

thethethethe wrote: post #403

Earlier quoted context omitted.

Why does someone need to take responsibility when you can have a culture of blameless postmortems where everyone focuses on making sure what ever happened never happens again instead? In blameless postmortem culture, everyone is responsible by default

"Everyone focuses" = nothing gets done. I've been at places like that, where a post-mortem happens, a course of action is decided on...and then no one owns actually carrying out that course of action. You could argue that "It should be assigned" - yeah, it should. But assigning it implies either "here is the team that is responsible for it", i.e., this is the team responsible and they need to be told to fix their shi…

But ownership of a fix is not blame for an incident. Those aren't the same.

You don't say "this incident was your teams fault". You say "your team is responsible for ensuring that this incident can't happen again".

Re: Drunk Post: Things I've Learned as a Sr Engineer

#475

Post by newbie2020 » Mon, May 31, 2021, 5:33 PM UTC

dmlittle wrote: post #212

dehrmann wrote: post #169

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

As the guy who has to deal with your code years later when the company is bigger...please think about the complexity, especially if it is a simple problem. Or not - that’s why I have a job

Re: Drunk Post: Things I've Learned as a Sr Engineer

#476

Post by wirrbel » Mon, May 31, 2021, 5:42 PM UTC

anyfoo wrote: post #237

wirrbel wrote: post #226

Earlier quoted context omitted.

I mean by now it should be clear to everyone that there are certain trade-offs in the choice dynamic vs static typing. I do like clarity of static type declarations, also the absence of weird polymorphism like functions returning a number or al ist of numbers depending on their parameters, etc. But then, many statically typed code bases are just tested abysmally. It is as if the type signatures would constitute prope…

You do need to write less tests with a static language. The types in your program are proof that your program is correct within the confines of the type system (literally, even in the mathematical sense). The stronger the type system, the more properties can be proven through it (at the extreme end there are, unfortunately not Turing complete, languages where you can prove every single property--those are more used a…

I am bringing up this point that there are tons of miserably tested Java/C++/etc applications because its a problem correlated with their usage, just like runtime type-errors correlate with dynamic languages. A fair comparison mentions both.

Of course a strong type system can drastically reduce the unit test coverage you need. But last time I checked, the strong type systems that allowed for this were all not used in our corporate code bases.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#477

Post by denton-scratch » Mon, May 31, 2021, 6:28 PM UTC

"I don't know why full stack webdevs are paid so poorly."

- The barrier to entry into webdev is low. You just need a laptop.

- An awful lot of websites seem to have been thrown together by morons; shipped; and never improved.

- For most sites, performance isn't an issue - strong tuning skills for PHP, SQL and Javascript are not an issue.

- A "full-stack webdev" generally doesn't do the full stack - few of my webdev colleagues have been interested in networks, for example.

TBH I don't know. In my last position I was paid £45K; I was the most versatile and experienced developer in the company (12 people). The bosses constantly complained that there was a dire shortage of talent to recruit. They recruited quite a few overseas visitors.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#478

Post by denton-scratch » Mon, May 31, 2021, 6:40 PM UTC

hutzlibu wrote: post #295

edoceo wrote: post #257

Earlier quoted context omitted.

Not for code tho. I've never seen booze help make good code

Alcohol really does not help me with code either (except maybe a relaxing beer), but Marijuhana works(occasionally). But you really, really need to do the sober clean up part. Otherwise it becomes a mess.

I cannot work while stoned - velocity drops to a crawl, and any complexity becomes overwhelming. And dealing with colleagues becomes much more difficult.

I can code with a few drinks in me; in fact the activity of coding seems to reduce the amount I drink (I'm a functioning alcoholic).

It's decades since I drank during working hours. In my early career in the City, it was the custom to drink at lunchtime. Those days are passed.

Re: Drunk Post: Things I've Learned as a Sr Engineer

#479

Post by runeks » Mon, May 31, 2021, 7:10 PM UTC

734129837261 wrote: post #296

odiroot wrote: post #178

> The older I get, the more I appreciate dynamic languages. Fuck, I said it. Fight me. The other ones are quite obvious but this is the one that really resonated with me. People, with experience, tend to get more pragmatic and less "academic".

I keep getting downvoted on Reddit for stating that I personally hate TypeScript to the max. It ruined the beauty of JavaScript (once you know it, anyway, I understand there are difficulties for JS-novices) and I honest to goodness 100% do not EVER find myself thinking: "Gosh, thanks TypeScript!" - on the contrary, it's always: "For fuck's sake you stupid POS TypeScript, you're wasting my time for no benefit at all."…

TypeScript isn’t strongly typed when doing “.map” on a non-array crashes at runtime: https://stackoverflow.com/questions/55229131/typescript-arra...

Re: Drunk Post: Things I've Learned as a Sr Engineer

#480

Post by yakshaving_jgt » Mon, May 31, 2021, 7:29 PM UTC

realusername wrote: post #446

yakshaving_jgt wrote: post #445

Earlier quoted context omitted.

I'm not sure what to make of that. Maybe you just haven't bothered to look? You personally not knowing about something is a reflection of your own knowledge, and not of the state of the world.

No, I've look enough I think. Maybe those better frameworks do exist though indeed, but I have no proof of that. Usually they just have the bare minimum of assert checks and call it a day. A testing framework should be able to mock and patch any class (or applicable) of the running instance of the program without modifying your code for example, tell me if a method was executed or not, intercepting all HTTP requests…

> mock and patch any class (or applicable) of the running instance of the program without modifying your code

Why is it important for the sake of testing to be able to alter the runtime behaviour externally without changing the code? This is contrary to all TDD literature I've read which advises to make production code easy to test, e.g., by coding against interfaces. After all, something being hard to test is exactly the feedback you're looking for when doing Test Driven Design. If it's hard to test, it's probably too tightly-coupled.

> tell me if a method was executed or not

Spies are possible with e.g. the ReaderT pattern.

> intercepting all HTTP requests without changes

My earlier two points are applicable here too, although I'll add type classes as another viable solution.

> have complex assertion partially matching objects

Pretty easy with lenses or just making assertions against record field lookups.

> factories

I don't know what this means. I looked at several articles describing some kind of factory pattern in TDD — all of which were horrifically verbose — and all I can glean from that is we are talking about mocking some function which generates objects.

> change the current time

This is no different from mocking other system boundaries, which I have already addressed.

> I could add a lot more here

You're welcome to, and I imagine my suggested solutions will continue to follow a theme. I'm not sure you're here to have your mind changed though. It seems you've reached your conclusion already.