Live data from Hacker News

The best programmers I know

endler.dev

211–220 of 320 posts

Re: The best programmers I know

#211
post #188

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. I think we're talking about different kinds of guessin…

> Like "I don't know anything, so I'm just going to try "stuff" I find online without really understanding. A reasonable place to start. But fair that you can't stop there if it isn't working. Next step, in my opinion, is to look at the interface more closely to see if it provides any hints. It will most of the time if it is well designed. > But even with the best designed interfaces, not everything is discoverable S…

>> Like "I don't know anything, so I'm just going to try "stuff" I find online without really understanding.

> A reasonable place to start. But fair that you can't stop there if it isn't working.

It's not a reasonable place to start. You're basically talking about copy-paste coding. Google search, stack overflow, paste in the first answer. Afterwards, ask the dev if they know what they did and why it works, and they won't be able to answer because they don't know.

> Next step, in my opinion, is to look at the interface more closely to see if it provides any hints. It will most of the time if it is well designed.

The people I'm taking about can't and won't do that.

> Sure. That's what the test suite is for, though: To document for users full intent and usage. You're still not going to go to a reference for that. As an added bonus, it is self-validating, so none of the "is it me or is the reference incorrect?" rigamarole.

I'm getting an "I don't need comments because code is self-documenting" vibe here. I disagree with that. Prose is a better way to express many, many things related to code than the code itself or even its test.

Sure, the code is the most authoritative place to find what was implemented, but it's not the best way to find the why or the concepts and thought behind it.

Re: The best programmers I know

#212
post #80

Earlier quoted context omitted.

Generally we aren't paid for our business expertise. In fact, most businesses actively resist giving developers deep domain responsibility. This is manifest in management methodologies: developers are largely interchangeable cells in a spreadsheet. I'm not saying this is a good thing. The reasons for this are complex, but generally, business people want us to solve the technical problems they can't handle themselves,…

Yep. A developer with "business impact" might be seen as a liability. One aspect might be that a developer who engages in "business" effectively stops being "subordinate". Management decisions need to be justified on a different level to maintain legitimacy.

This thread is kind of wild and something I've never heard anywhere in tech. Every place I've worked would consider a developer at least 5X more valuable if they actually had business or product sense, and could operate without the need for constant symbiosis with a "product guy". At one BigTech company we've all heard of, our division didn't even have product people. The engineering lead was expected to handle all of the product duties, and they wouldn't hire you if they didn't think you could at least grow into that role.

It's one of the reasons I went back for a business degree and then re-entered tech. No, of course nobody in Silicon Valley cares about the "MBA" title (HN sees it as a negative), but everywhere I've interviewed/worked they've appreciated that we could talk about the economic and business impact of the software, and not just the algorithms and data structures.

Re: The best programmers I know

#213

Earlier quoted context omitted.

Most developers are terrible at system administration which is quite disappointing and is one of the reason that the author uses Clownflare. Being able to maintain systems is as important as writing code

This is kind of a ridiculous take. Not going to speak for the author, but some of us just want to be able to write a blog post and publish it in our free time. We're not trying to "maintain systems" for fun. Some of those posts get zero views, and some of them end up on the front page of Hacker News.

There is literally a "Submit to HN" button at the bottom of the blog post.

Moreover, the author appears to be a lot more serious than just a free time blogger:

https://web.archive.org/web/20250405193600/https://endler.de...

> My interests are scalability, performance, and distributed systems

> Here is a list of my public speaking engagements.

> Some links on this blog are affiliate links and I earn a small comission if you end up buying something on the partner site

> Maintaining this blog and my projects is a lot of work and I'd love to spend a bigger part of my life writing and maintaining open source projects. If you like to support me in this goal, the best way would be to become a sponsor

Re: The best programmers I know

#214

> 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 as Theory Building". It's 40 years old now but still nails the essence of programming. The value produced by programming is a shared working theory of the system, not the source code itself. I can't see how you would develop a sufficient theory without first forming hypotheses.

Re: The best programmers I know

#215
post #161

For those unable to open the link due to owner site being hit by Cloudflare limit, here's a link to web archive - https://web.archive.org/web/20250409082704/https://endler.de...

There's some irony, is there not, in presuming to be able to identify "the best programmers" when you've created a programming blog that completely falls down when it gets significant web traffic?

The best programmers know that using the free resource of the Internet Archive is the optimal approach for their own effort and cost, versus making their own website scale for a temporary load? (Kidding…I think)

Re: The best programmers I know

#216
post #161

Earlier quoted context omitted.

There's some irony, is there not, in presuming to be able to identify "the best programmers" when you've created a programming blog that completely falls down when it gets significant web traffic?

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.

Re: The best programmers I know

#217
post #188

Earlier quoted context omitted.

> Like "I don't know anything, so I'm just going to try "stuff" I find online without really understanding. A reasonable place to start. But fair that you can't stop there if it isn't working. Next step, in my opinion, is to look at the interface more closely to see if it provides any hints. It will most of the time if it is well designed. > But even with the best designed interfaces, not everything is discoverable S…

>> Like "I don't know anything, so I'm just going to try "stuff" I find online without really understanding. > A reasonable place to start. But fair that you can't stop there if it isn't working. It's not a reasonable place to start. You're basically talking about copy-paste coding. Google search, stack overflow, paste in the first answer. Afterwards, ask the dev if they know what they did and why it works, and they…

> 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 code already did, no need to think about it further. This remains a reasonable place to start.

> but not the why

If you are not capturing "why" in your tests, what are you testing, exactly? The "what" is already captured in the implementation. You don't need that written down twice. Worse, if you do end up testing "what" you are bound to have to deal with broken tests every time you have to make a change. That is a horrid situation to find yourself in.

I do agree that writing useful tests is really hard, at least as hard as writing good reference material, and thus beyond the skill of most. But if you have to work with something built by the unskilled, all bets are off no matter which way you look.

Re: The best programmers I know

#218

Earlier quoted context omitted.

Most developers are terrible at system administration which is quite disappointing and is one of the reason that the author uses Clownflare. Being able to maintain systems is as important as writing code

This is kind of a ridiculous take. Not going to speak for the author, but some of us just want to be able to write a blog post and publish it in our free time. We're not trying to "maintain systems" for fun. Some of those posts get zero views, and some of them end up on the front page of Hacker News.

I was talking about more than just a blog. It puts things into different perspective when you are writing a big program. For instance, you are tasked on creating a custom auth. Would you feel more comfortable after having used something like authentik or kanidm in the past or having no experience with it at all?

Re: The best programmers I know

#219

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…

On the other hand, do I want careless devs working in those industries?

I don't think "careless" is a permanent, intrinsic attribute of a developer. It's something they learn to be, and it can be unlearned.

We respond to incentives. If a developer's only incentive is "we reward shipping as fast as possible" then they will carelessly ship slop as fast as they can type it. If that incentive is removed, they can learn a better way...

Re: The best programmers I know

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

The problem is that for every example like yours where you run into very specific ORM edge cases, and seems completely reasonable, there are about 95 where a story like this is used as justification to spend months building something when a library would have actually worked out just fine and been implemented in weeks or days. And that running into these edge cases is used as justification for "throw the ORM out" not "don't use the ORM for this particular class of query."

One of my favorite features of Entity Framework from my .NET days is that it's very easy to just break out of the ORM functionality, even from within an EF-specific function, or to have multiple instances with slightly different configuration (I never had to do that last bit but I know it was possible a decade ago).

Post reply on HN