Live data from Hacker News

The best programmers I know

endler.dev

271–280 of 320 posts

Re: The best programmers I know

#271
post #263
post #199

Earlier quoted context omitted.

> The guy who wants to build his own ORM for his no-name company's CRUD app is wasting everyone's time. I once unfortunately joined a project where an off-the-shelf ORM had been selected, but when development was well into the deep edge cases started to reveal serious design flaws in the ORM library. A guy wanting (perhaps not a in a joyful sense, but more not seeing any other choice) to build his own ORM that was mo…

I've developed a deep distrust of ORMs at all. I've found that the majority of simple CRUD projects are better served by just having a DAL with explicitly written (or generated) methods instead.

> just having a DAL with explicitly written (or generated) methods instead.

That's a bit orthogonal. Even if you use an ORM library, you'd be remiss to not put it behind a DAL. But from your DAL if you emit/accept objects of your own transformation: Congratulations, you've just invented an ORM. You can emit/accept relations, which is quite justifiable, but even then you are bound to have to map it to objects at some point. e.g. interfacing with third-parties that require objects. There is really no escaping ORM in any reasonably complex real-world application.

Re: The best programmers I know

#272

> To know a tool well, you have to know: > its history: who created it? Why? To solve which problem? > its present: who maintains it? Where do they work? On what? I'm not clear on that. Why does the person matter? So you can check if their political views align with those of your tribe, or what? But then, I never read the user names on HN comments I reply to, and I guess the article author does. Maybe even keeps file…

The creator matters because they are the key to understand the reason was created in the first place and under which circumstances. You get to learn about their other work, which might also be relevant to you, the limitations of the tool based on the problem is was designed to solve, and the broader ecosystem at the time of creation. For example, if you're a frontend developer it helps to know who Brendan Eich is, where he worked when he invented JavaScript, and what Netscape wanted to achieve with it. You would even learn a bit about the name of the language.

Similarly, it helps to know who maintains the code you depend on. Is there even a maintainer? What is the project roadmap? Is the tool backed by a company or otherwise funded? What is the company's mission? Without those details, there is a supply chain risk, which could lead to potential vulnerabilies or future technical debt.

Re: The best programmers I know

#273

Earlier quoted context omitted.

Moment.js is one of those libraries to avoid; the bloat....

I still like Moment because it offers better control of time zones that aren’t the browsers time zone when compared to the builtin Date APIs. Do you have a recommendation to replace Moment for that use case? I’m hopeful for the future with JavaScript Temporal.

A maintainer of moment.js has moved on with an immutable rewrite called luxon.js. Highly recommended.

https://github.com/moment/luxon/blob/master/docs/why.md

Re: The best programmers I know

#275

> In job interviews, I pushed candidates hard to at least say “I don’t know” once. Yes yes! Although, in an interview, there is not always an easy way to separate out people that can’t say “I don’t know” during day to day work, from those that can. But what a difference. A strong need to hide a lack of omniscience is wildly irritating to me, in co-workers and people in general. It causes such problems!

Ha. “I Don’t Know” is probably my most common answer to questions at work, often followed up immediately with "What have you tried" or "What has changed"

Re: The best programmers I know

#277
post #199

Earlier quoted context omitted.

> The guy who wants to build his own ORM for his no-name company's CRUD app is wasting everyone's time. I once unfortunately joined a project where an off-the-shelf ORM had been selected, but when development was well into the deep edge cases started to reveal serious design flaws in the ORM library. A guy wanting (perhaps not a in a joyful sense, but more not seeing any other choice) to build his own ORM that was mo…

Not to get too off topic, but ORMs are bags of design flaws. They are definitional technical debt, the kind that gets you from proof of concept but needs to be reworked once you get to your target scale. There are a large number of fundamental impedance mismatches between relational data and object based data. Any ORM can fix some of them at the cost of ignoring others, but the fundamental character of ORMs is such t…

> There are a large number of fundamental impedance mismatches between relational data and object based data

My experience tells me that the largest among these impedance mismatches is the inability for OOP languages to express circular dependencies without resorting to messy hackarounds. Developers often fail to realize how far they are into the dragon's den until they need to start serializing their object graphs.

https://github.com/dotnet/runtime/issues/29900

Re: The best programmers I know

#278
post #87

Assuming you're working on regular software where you can run it in isolation, without cost, I disagree with "don't guess". A guess might be your best opportunity to test a theory about a bug you don't understand. That's particularly true where you're a newcomer to an area and the documentation is written for someone with different experience. A series of guesses and tests can narrow down the problem, and ultimately…

In my book that's not a guess, but a hypthesis, which is indeed a great way to narrow down the problem space. What I meant was to avoid blind guessing in the hope of striking luck, which comes back to haunt us most of the time.

Re: The best programmers I know

#279
post #217

Earlier quoted context omitted.

> It's not a reasonable place to start. Why not? If it works it works. Not everyone is concerned with receiving the award for best programmer. > they won't be able to answer because they don't know. I do understand that you are thinking of a specific person here, but broadly, you will know how it works more or less because you'll already know how you would implement yourself if you had to. But since someone's else co…

>> It's not a reasonable place to start. > Why not? If it works it works. Not everyone is concerned with receiving the award for best programmer. Ok, that clarifies things: programmers who avoid reading the docs to guess, or follow the "Google search, stack overflow, paste in the first answer" cycle are mediocre programmers. If they don't want to be good programmers (which what the article is talking about), they can…

> ...are mediocre programmers.

That depends on the beholder.

- A programmer who applies a laundry list of what they do to determine who makes for a "best" programmer, who doesn't guess themselves, is likely to exclude anyone who does.

- A business person is apt to consider someone who successfully delivers a product quickly by using someone else's code among the "best".

> You can't capture why in code.

Then you can't capture it in natural language either, making this whole thing moot. But I disagree with that idea.

> Your tests are a demonstration of the "what."

You have a point that some testing frameworks carve out a special declaration for "example" tests that are marked for inclusion in generated API docs. There might be a time and place for that kind of documentation, but that isn't the kind of testing I was thinking of. That isn't representative of the vast majority of the tests you will write. If it is, you're doing something wrong – or at very least aren't being fair to those who will consume your tests later.

In my laundry list, concern for the next guy is what separates the "best" programmers from the mediocre. But I understand why your laundry list differs.

Re: The best programmers I know

#280
post #260

Earlier quoted context omitted.

Logs, tests, debugging, ask questions, build a mental model, test that mental model. The more experience I get the less I guess.

Right, I misunderstood the meaning of "guess" here.

Yes. You weren't wrong. You need to first guess in order to not guess :)
Post reply on HN