Live data from Hacker News

The best programmers I know

endler.dev

281–290 of 320 posts

Re: The best programmers I know

#281
post #67

> "Don’t go to Stack Overflow, don’t ask the LLM, don’t guess, just go straight to the source. Oftentimes, it’s surprisingly accessible and well-written." It's a bit like math books. I dreaded reading formal math during my engineering -- always read accessible text. Got a little better in my master's and could read demse chapters which got to the point quickly. At least now I can appreciate why people write terse ref…

God, the boto3 python docs are _insanity_. The lack of type hints, having a single method for getting a client that could be for 100 different services…

For the uninitiated, boto3 is the official AWS python library. To get a client for, say, S3, you do `boto3.client(‘s3’)` - instead of the sane thing, like, you know, `boto3.s3.S3Client()`

Re: The best programmers I know

#282
post #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, wh…

> it helps to know who Brendan Eich is, where he worked when he invented JavaScript, and what Netscape wanted to achieve with it

That may have been relevant 15 years ago, whatever Eich wanted to do with JS, it's been out of his hands for a long time.

And you could also do the reverse and form an opinion about him based on JS :) Might not be very flattering.

Re: The best programmers I know

#283
post #271
post #263

Earlier quoted context omitted.

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…

"Objects" implies a few more properties than a simple data carrying container: while it might be expressed in a particular language using classes/objects, you really don't care about any of the "object"-like features other than the ability for it to contain attributes.

Generally, you can go a long way with simple, combined types which are closer to maps/hashes/dicts than to "objects" other than syntax (.attr vs ["attr"]).

And really, that would be my preference: combine a query builder (some ORMs have great ones too) with native types representing the data read from the database.

Re: The best programmers I know

#284
I'm a big fan of "reading the reference", but documentation often does not cater to that use case anymore. Instead of curling up with an authoritative book (like the Perl, Python, C, or C++ books, the dtrace book, or the O'Reilly X11 or BSD reference manuals), I get to, in the better case, click around a 1000 page web site, or, in the worse case, watch 50 videos covering 10% of the functionality.

Re: The best programmers I know

#285
post #271

Earlier quoted context omitted.

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

"Objects" implies a few more properties than a simple data carrying container: while it might be expressed in a particular language using classes/objects, you really don't care about any of the "object"-like features other than the ability for it to contain attributes. Generally, you can go a long way with simple, combined types which are closer to maps/hashes/dicts than to "objects" other than syntax (.attr vs ["att…

> "Objects" implies a few more properties than a simple data carrying container:

Agreed. Of course, strictly speaking, a relation is specifically a set of tuples. But if you are working with a SQL database, which has been implied, you are already long past that idea, so it is understood that we're speaking of the concept somewhat more loosely. An instance of a class with a set of basic properties nestled in an array would still reasonably be considered a relation as it pertains to this discussion, as far as I am concerned, and seemingly you too. Fair to say you haven't meaningfully changed the semantics of the data in that.

But that doesn't mean you won't need to map to objects. You almost certainly will at some point in a reasonably complex application, even if only to interface with third-parties.

Re: The best programmers I know

#286

Earlier quoted context omitted.

I think many engineers would highly benefit from doing a 1-2 year stint working on safety-critical embedded software, where there are correctness requirements, and lives are lost if you're wrong or careless. It may not be everyone's bowl of soup, but it would at least expose you to that side of the world and you might learn something from the experience. Perhaps if everyone did this kind of tour of duty, something wo…

Anecdotally, working on mission-critical always-on systems when I was a junior developer was influential on the development of good habits when writing code that have carried through in contexts where such code quality was not required. In my view I benefited greatly from this exposure early in my career. A lot of it is pretty basic: checking every single return code, testing every single branch, verifying that the e…

It seems like languages like Go promote this kind of development innately. I'm relatively new to it but found that much interesting about it.

Re: The best programmers I know

#287
post #255

Earlier quoted context omitted.

A DB query without ORM is effectively a service. This hides relations in the DB layer, rendering moot the need to model these relations in object oriented code. Thus, eschewing the ORM completely moots the question of whether to map objects and relations. I'd suggest if you are ever asking that question, you are already screwed.

Querying and ORM are very different concepts. Object-relation mapping is concerned with, as it literally asserts, mapping between relations (or, more likely in practice, tables – but they are similar enough for the sake of this discussion) and objects. Maybe you are confusing ORM with the active record pattern (popularized by ActiveRecord, the library) which combines query building and ORM into some kind of unified c…

Was confused by that too (ORM and Active Records), but I spend some time learning about DDD which leads me into enterprise architecture and that's when I all the design pattern for interacting with data. Most web frameworks only have Query Builder and Active Records.

Re: The best programmers I know

#288
post #68

Earlier quoted context omitted.

This is why I love LLMS. I drop 200, 100+ page 13F filing reports into Gemini, and after 10 minutes, it finds anomalies for me. This was impossible before, as these reports are not standardized at all.

Don’t they have some convoluted XML schema? Or are you sending the rendered text of the html versions of the reports?

No, these are documents with no super consistent standards. There are requirements regarding the content of the 13F filing, but not so much about formatting. And they are PDFs, which makes them difficult to parse using traditional scripts.

Re: The best programmers I know

#289
post #199
post #180

Earlier quoted context omitted.

This is smart if you work for a company that actually needs this level of robustness. The problem is that most don't, and a lot of people who work for these companies wish they were working someone "better"/"more important," so they pretend they actually do need this level of performance. The guy like you on a mission critical team at a cutting edge company is a godsend and will be a big part of why the project/compa…

> 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 think both makes sense, different times/contexts require different solutions. Maybe when the project started, the idea was loosely defined, so being able to change large parts quickly are favored over ideal performance.

But as the idea and project cements itself, you start to see exactly where the biggest flaws are, and you might draw the conclusion that a lot of problems could be fixed at the ORM layer, so you opt for working on that.

Maybe it would have been obvious from the beginning, but chances are the people working on the codebase initially had a very different idea of what exactly is the ideal design, compared to later on in the lifetime of the project.

Re: The best programmers I know

#290

> Read the Reference > Don’t Guess I find that, when working with a new "thing," I often like to guess for about an hour or so before I really do a deep dive into the reference. Or, I'll read a stackoverflow answer or two, play around with it, and then go to reference. Why? Often there's a lot of context in the reference that only makes sense once I've had some hands-on time with whatever the reference is describing.…

I also find it damn near impossible to focus on the reference. I know it sounds childish, but I just can't do it sometimes. Playing around with code is how I got here.
Post reply on HN