Live data from Hacker News

Ask HN: Concepts that clicked only years after you first encountered them?

news.ycombinator.com

261–270 of 946 posts

Re: Ask HN: Concepts that clicked only years after you first encountered them?

#261

Haskel monads.

There is a common saying that if you can't explain something to someone else then you don't really understand it yourself. Monads made me realize that some things need to be experienced in order to be understood.

Re: Ask HN: Concepts that clicked only years after you first encountered them?

#262

Earlier quoted context omitted.

Amen. I have been frustrated at many jobs where developers were so proud of endlessly writing mocks and spending more time on their tests than on core functionality. Over time I have favored very basic unit tests and leaning in more on automated integration and regression tests. I know the theory of unit tests catching things earlier, I just don’t think it matters in practice.

I once saw type checking presented as kind of an alternative to unit tests which doesn't rely on the assumption that developers write good tests, and I really like that viewpoint. A powerful type system can prevent many bugs, doesn't need additional test code and doesn't make any assumptions. Of course it's not necessarily a full replacement, but it's definitely better and more time efficient than bad tests.

Yes, static analysis of types can eliminate a big class of unit tests (basically just checking pre- and post- conditions on types), which is a big part of why it's great. But most unit tests should be for logic. But that's why they aren't very useful for "glue" methods which just thread things through different dependencies - they shouldn't have much interesting logic.

Re: Ask HN: Concepts that clicked only years after you first encountered them?

#263
post #2

Unit testing and using dependency injection to write test-able code. I'm not sure if it was years, but it wasn't immediate. I just didn't understand why dependency injection was good at first, and not just someone's weird personal code style choice. I thought it was just people being "Enterprisey" which I'd encountered many times over the years. Once I committed to unit testing, I realized how necessary it is. Unfort…

Another solution is to eliminate classes and only use structs or similar plain objects. Makes mocking and testing functions much easier. At this point I see no reason for OOP whatsoever and consider it a big mistake.

OOP tends to encourage thinking in more abstract ways than is often necessary imho. I feel like learning a language with only structs had a positive effect on my coding ability (as someone who more or less started with Java).

The few times I had to use Java afterwards I felt the same - all OOP features were unnecessary or at least didn't feel like the most straightforward approach. Nowadays I never use classes in Python, JS etc., it's just not needed - and in the case of Python it makes JSON insanely cumbersome.

Re: Ask HN: Concepts that clicked only years after you first encountered them?

#264

1. Everyone is the main character in their own story. This manifest in all sorts of ways - from people not being there when you need them the most, from friends dying off as soon as proximity changes, to how and why get people get promoted in jobs. This isn't necessarily bad, but if you don't know how to navigate this it can be quite painful and confusing. 2. Representation matters. I knew this for a long time, but i…

2. Hits home for me as I’ve begun to realize the same thing. Not seeing any person of color in an activity makes it’s so I don’t want to be the first.

Similarly this gives me pause about Ivy League MBA programs.

Although a small sample size, despite their ambitions the BIPOC people I know haven’t been able to reap any professional benefits from it. Whether from access to executive roles, getting taken seriously by venture capital firms, or in their attempts to join venture capital firms. There is a level of discretion in these team forming situations that is not extended to them whether it has anything to do with their race or not, its pretty clear the upwards mobility is not coming from this credential.

For people with their own capital and leverage, it amplifies their ambition if they want. BIPOC don't really have this.

The “average salary” of MBA alumnis is not what is interesting about getting one, for me or them.

Some, or more, examples to the contrary would make it seem less like a total waste of time.

Re: Ask HN: Concepts that clicked only years after you first encountered them?

#265
post #224

Earlier quoted context omitted.

Seven years into my career I'm increasingly convinced that the emperor has no clothes with respect to unit tests that are just transcripts of the code under test with "mock.EXPECT()" prepended to everything - 95% by volume of the unit test code I've ever read, written, or maintained.

I think my favorite of these was a function that called 4 other functions and didn't do anything else, its unit test mocked out all 4 other functions and asserted that each was called.

Every damn day. It’s the thing that puts me most at risk of falling out of love with software engineering.

Re: Ask HN: Concepts that clicked only years after you first encountered them?

#266

Matrix multiplication. First encountered it in high school, where the textbooks presented matrices without any real motivation, and matrix multiplication just seemed like a weirdly-defined operation. Once I got to linear algebra in college and matrix multiplication was presented as the way to compose linear transformations, it made a lot more sense.

Matrices are funny. You can encounter them as a teenager reading 3D graphics tutorials on the internet, learn that they can compactly represent scalings, rotations, and translations, and that several transformations can be conveniently “stacked” using this thing called matrix multiplication which looks like this… and that’s it, now you can use them for a cool practical purpose, but the tutorials never derive or attem…

It reminds me of a funny story back when I was a student.

We had a week-long group project in the first year whose theme was "a 360° pong". Our group decided that it meant the paddles had to travel in a circle around the playfield and I've decided that matrices and stacked 2D transformations were the way to go. The other students gave me blank stares, I basically said "trust me, you don't need to understand them to use them" and off we went coding.

We ended up with the most impressive pong clone out of all the groups, as nearly all of them had axis-aligned rectangular paddles going around a rectangular path, whereas ours had a stretched half-circle paddle going around a circle path always facing the center of the playfield, alongside extra features like walls and a level editor.

First class the Monday morning after, the math teacher announced that the next topic was matrices. We stared at each other in the group and grinned manically.

If anyone wants to stare at an old C codebase from 10 years ago by a bunch of first year students: https://code.google.com/archive/p/pong-norris/

Re: Ask HN: Concepts that clicked only years after you first encountered them?

#269
>longer wires mean more resistance while thicker wires mean less resistance.

Intuitively (perhaps incorrectly) I would assume that it's like trying to force a fluid through a skinny long pipe vs a wide pipe - the skinny long pipe will have higher pressure inside.

Or, the long thin wire has more distance for the current to travel (= more resistance), while the thicker wire has more "options" for the current to choose a path of least resistance (literally), tending towards a lower overall resistance compared to a thinner wire of the same length

Re: Ask HN: Concepts that clicked only years after you first encountered them?

#270
post #224

Earlier quoted context omitted.

Seven years into my career I'm increasingly convinced that the emperor has no clothes with respect to unit tests that are just transcripts of the code under test with "mock.EXPECT()" prepended to everything - 95% by volume of the unit test code I've ever read, written, or maintained.

I think my favorite of these was a function that called 4 other functions and didn't do anything else, its unit test mocked out all 4 other functions and asserted that each was called.

I had a take home test a year or two ago and I got grilled during the interview for not writing crap like that.
Post reply on HN