Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The best programmers I know

endler.dev

Post reply on HN
Print view View original

251–260 of 320 posts

Re: The best programmers I know

#251

Post by gorjusborg »

grayhatter wrote: post #216
gorjusborg wrote: post #170

Earlier quoted context omitted.

I think it is a fairly common trait of bad programmers to design a system based on completely unrealistic operating conditions (like multiple orders of magnitude of extra traffic). Now that they've gotten the hug of death they'll probably plan for it next time.

How many ways are their to build a site that doesn't have these defects and risks? Good engineers build things that eliminate failure modes, rather than just plan for "reasonable traffic". Short of DDoS, a simple blog shouldn't be able to die from reaching a rate limit. But given the site is dead, I can't tell, maybe it's not just a blog.

> Good engineers build things that eliminate failure modes,

Yes, but not all failure modes, only the ones in scope for the goals of the system. From the outside you can't tell what the goals are.

There is no such thing as eliminating all failure modes, which was exactly the point I was making in my post above. The best you can do is define your goal clearly and design a system to meet the constraints defined by that goal. If goals change, you must redesign.

This is the core of engineering.

Re: The best programmers I know

#252

Post by hombre_fatal »

ryandrake wrote: post #207
hombre_fatal wrote: post #151

Earlier quoted context omitted.

They are using Zola (Rust SSG) but I think they're serving from Worker + KV: https://github.com/mre/endler.dev/blob/32016d0f204911bc9a8a4... They have a history of using static hosting (GH Pages) but prob decided it wasn't necessary when they switched to CF. And whipping up your own lil scheme using compute is more fun and it let them mirror the request to their analytics service. I don't blame them: I'm so used to i…

The idea that you need "workers" and compute to serve 10KB of words...

HN mindset:

- When I do something, I did it understanding that's what I had the limited time/attention for and you should give me grace, especially when I'm dicking around with my personal blog on a Saturday afternoon.

- When other people do something, they engineered what they thought was the necessary + perfect solution, and they chose that exact impl after every option was evaluated to its end, and I will criticize them accordingly.

Re: The best programmers I know

#253

Post by flessner »

Taek wrote: post #133
bob1029 wrote: post #103

Not guessing is perhaps the most important thing to the business. I developed a lot of my problem solving skills in semiconductor manufacturing where the cost of a bad assumption tends to be astronomical. You need to be able to determine exactly what the root cause is 100% of the time or everything goes to hell really fast. If there isn't a way to figure out the root cause, you now have 2 tickets to resolve. I'll thr…

I always get a lot of pushback for avoiding frameworks and libraries, and rolling most things by hand. But, most frameworks and libraries aren't built to be audit-grade robust, don't have enterprise level compatibility promises, can't guarantee that there won't be suprise performance impacts for arbitrary use cases, etc. Sometimes, a third party library (like sql-lite) makes the cut. But frameworks and libraries that…

I think you're correct, but certain libraries are so widespread enough that it's sensible. Especially S3, SQLite (as mentioned), Postgres and Redis usually offer good abstractions.

Other than that, time and crypto are two things I also wouldn't code myself, both are just too easy to mess up.

Re: The best programmers I know

#254

Post by 9rx »

awkward wrote: post #249
9rx wrote: post #246

Earlier quoted context omitted.

In realistic practice there is no escaping it, though. Even if you maintain relations throughout the majority of your application, you are almost certainly still going to need to call some kind of third-party API or networked service that requires mapping between relations and objects. Especially if networked services are involved as they nearly always eschew relations in favour of objects to avoid the typical n+1 pr…

Oh for sure, they fill huge and consistent gap between most databases and most programming languages. The issue is that they are fundamentally a compromise. That means it's not damning to hear that issues crept in with scale and complexity. It's also rarely practical to take on the project of making a slightly different set of compromises from first principles.

> The issue is that they are fundamentally a compromise.

Which is no doubt why most newer applications I see these days have trended towards carrying relations as far as they can go, only mapping with objects at the points where it is absolutely necessary.

> It's also rarely practical to take on the project of making a slightly different set of compromise

I suppose that is the other benefit of delaying mapping until necessary. What needs to be mapped will be more limited in scope and can be identified as such. You don't have to build a huge framework that can handle all conceivable cases. You can reduce it to only what you need, which is usually not going to be much, and can determine what tradeoffs best suit in that. In this type of situation it is likely that using a ORM library is going to be a bigger waste of time, honestly.

Re: The best programmers I know

#255

Post by 9rx »

seadan83 wrote: post #250
9rx wrote: post #246

Earlier quoted context omitted.

In realistic practice there is no escaping it, though. Even if you maintain relations throughout the majority of your application, you are almost certainly still going to need to call some kind of third-party API or networked service that requires mapping between relations and objects. Especially if networked services are involved as they nearly always eschew relations in favour of objects to avoid the typical n+1 pr…

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 concept? ActiveRecord, the library, confusingly called itself ORM when it was released which may be the source of that.

Re: The best programmers I know

#256

Post by d0mine »

gwbas1c wrote: post #154

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

Actually, your approach “test yourself first, then learn” is better for learning compared with just learning first according to research.

Re: The best programmers I know

#257

Post by d0mine »

ryandrake wrote: post #201
9rx wrote: post #176

Earlier quoted context omitted.

The trouble is that there is a strong correlation between being able to design good interfaces and being able to prepare good documentation. Meaning, where guessing fails, the reference is bound to also fail due to inaccuracies or failing to communicate what you need to know. Which stands to reason as both require concern for how the user perceives the product. That is a skill in its own right. In practice, so many t…

Say what you will about Windows development, but back in the 90's the MSDN reference documentation that Microsoft shipped for Win32 and MFC was quite good. Almost gold standard good. That, plus Petzold and Prosise, and you pretty much could answer any API question you had without even going online. Yet, we had engineers who would still just hunt and peck and stumble guess until they either accidentally got it working…

It was good but it was not perfect. I remember leaving comments such as “MSDN says X, but the actual behavior is Y, therefore there is Z in the code”

The fact that I remember this is the evidence that it was not everyday occurrence that the docs were good overall.

Re: The best programmers I know

#258

Post by grayhatter »

gorjusborg wrote: post #251
grayhatter wrote: post #216

Earlier quoted context omitted.

How many ways are their to build a site that doesn't have these defects and risks? Good engineers build things that eliminate failure modes, rather than just plan for "reasonable traffic". Short of DDoS, a simple blog shouldn't be able to die from reaching a rate limit. But given the site is dead, I can't tell, maybe it's not just a blog.

> Good engineers build things that eliminate failure modes, Yes, but not all failure modes, only the ones in scope for the goals of the system. From the outside you can't tell what the goals are. There is no such thing as eliminating all failure modes, which was exactly the point I was making in my post above. The best you can do is define your goal clearly and design a system to meet the constraints defined by that…

> Yes, but not all failure modes, only the ones in scope for the goals of the system. From the outside you can't tell what the goals are.

Is basic availability not a goal of a blog?

Phrased differently: given two systems, one that fails if a theoretically possible, but otherwise "unpredictable" number requests arrive. And one without that failure mode. Which is better?

> From the outside you can't tell what the goals are.

I either don't agree, not even a tiny bit, or I don't understand. Can you explain this differently?

> This is the core of engineering.

I'd say the core of engineering is making something that works. If you didn't anticipate something that most engineers would say is predictable, and that predictable thing instead of degrading service, completely takes the whole thing down, such that it doesn't work... that's a problem, no?

Re: The best programmers I know

#259

Post by d0mine »

perrygeo wrote: post #214
gwbas1c wrote: post #154

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

Agreed. Make a guess, then verify that guess with running code, repeat. I'm surprised this is controversial; engineering ostensibly follows the scientific method. Without forming hypotheses and testing them, there is no scientific method. Unless we want to nitpick the difference between guessing and hypothesizing, making guesses is a critical part of programming. I always come back to Peter Naur’s essay "Programming…

Formulating your assumptions before you run code and check saves you from rationalizing after the fact whatever behavior you happen to observe. Invalid predictions help improve understanding, learn.

Re: The best programmers I know

#260

Post by hk__2 »

foobahify wrote: post #95
hk__2 wrote: post #89

I don’t get this one: > Don’t Guess If you work with anything but a very simple program, you often must guess what could be the cause(s) of your issue in order to know where to look. The more experienced you are, the more accurate your guesses will be.

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.
Post reply on HN