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

241–250 of 320 posts

Re: The best programmers I know

#241

Post by 9rx »

pc86 wrote: post #238
9rx wrote: post #225

Earlier quoted context omitted.

In that case it was more that the ORM was, under certain conditions, silently corrupting data and whatnot due to fundamental design problems. It needed a major overhaul to address the issues and at that point a rewrite that didn't deviate too far API-wise was seemingly the easiest/fastest way forward. Like the original comment asserts: Don't be afraid to use libraries, but choose them wisely. But in your example, eve…

TIL anyone making less than $1M/yr is budget. I was specifically calling out being able to do so (easily) from within the ORM itself, so I think implying that I don't know you can just call the database directly is a bit of a strawman. At the risk of going off on a tangent, the median dev salary is something like $100-150k/yr. So half of devs in the country make less than that. Gergely Orosz has a great discussion of…

> I was specifically calling out being able to do so (easily) from within the ORM itself

But, as I said, even if it isn't built-in, it doesn't make any difference, does it? Either way there is no reason to throw a perfectly good ORM out the window just because in some cases it isn't the right tool for the job. Surely you agree? That was my interpretation of the intent of your earlier comment.

While it may be true that ORMs today are of SQLite quality, the original commenter's point still stands: You need to make sure that is the case, else you are going to quickly wish that you did write it yourself.

> So half of devs in the country make less than that.

You may take things a bit too literally, but if you want to go down this road, do you truly believe that half of all devs have learned all the lessons there are to learn in software? Color me skeptical. 0.01% is likely even pushing it.

Re: The best programmers I know

#242

Post by tshaddox »

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…

What programming languages are you using? Compilers and interpreters are pretty darn complicated, not to mention operating systems and computer hardware.

Re: The best programmers I know

#243

Post by awkward »

9rx wrote: post #199
pc86 wrote: 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…

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 that taking an opinionated line on tough tradeoffs is as good as you can hope for.

This is why ORM guy is wasting everyone's time - his problem is almost definitely not going to have a unique or even valuable perspective on all of those tradeoffs.

Re: The best programmers I know

#244

Post by rcxdude »

skrebbel wrote: post #196
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…

> This is why I aggressively avoid use of non-vanilla technology stacks I was with you until this line. I've never seen a codebase where Not Invented Here Syndrome resulted in a stack that "antagonizes root cause analysis" in any way. I once worked at a C++ shop that had NIH'ed a supposedly thread safe string class, and it wasn't pretty. There's plenty mature robust tech out there, and the chance that your own invent…

I think you may have misread, they are saying they will try to stay on something as common and boring as possible, as opposed to NIH.

Re: The best programmers I know

#245

Post by rcxdude »

tacitusarc wrote: post #200
ryandrake wrote: post #195

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?

From my experience in the industry, if the average backend dev went to work in that industry, the average level of competence would go up (compare the average salary, for one thing). The processes are all about making it hard to fuck up really badly, they're very much not going to weed out 'careless' devs, just limit the damage they can do.

Re: The best programmers I know

#246

Post by 9rx »

awkward wrote: post #243
9rx wrote: 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…

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

Should your application map objects and relations at all isn't usually a question you get to ask unless it is doesn't do much or lives on its own private island. Should you do it yourself or lean on a toolkit to help is the question that you have to contend with.

Re: The best programmers I know

#247

Post by rhubarbtree »

irishloop wrote: post #132
epolanski wrote: post #52

I want to add another one, ability to handle emotions (mentioned but mostly in terms of patience) and ability to stay focused. Two programmers that start with similar levels at the thing that OP listed, but one able to stay focused and productive and the other jumping on YouTube, HN half the day (yes, that's me in many periods) etc are gonna have different impact and progression with time.

Do you think there's a way to train focus?

I did pomodoros for years to recover my productivity after time in academia.

Now I’m the most focused person in the office. But it took a very very long time.

Re: The best programmers I know

#248

Post by progforlyfe »

> Read The Error Message

100% !!! I get so annoyed when engineers get an error message and just copy/paste in Slack saying "I got this error: xyz" and nothing else... No inspection of the error, no reading docs or at least putting it in a search engine. No "This is what I tried so far...". Just a brand-dead copy/paste and shoving it someone else's plate to perform all those steps.

Re: The best programmers I know

#249

Post by awkward »

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

Earlier quoted context omitted.

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…

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.

Re: The best programmers I know

#250

Post by seadan83 »

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

Earlier quoted context omitted.

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…

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