Live data from Hacker News

The best programmers I know

endler.dev

311–320 of 320 posts

Re: The best programmers I know

#311
post #238
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…

it's not $1m TC but $1m cost to the company, all in, which is still high, but not the top 0.01%

Re: The best programmers I know

#312
post #134

The best programmer and the best Linux wizard I knew had absolutely no background in CS, he stumbled into programming in this 20ies because he had to develop a tool for his Master thesis in a completely unrelated field (agriculture). He then quickly taught himself Java, Python, C++, JavaScript, PHP, and PostgreSQL scripting. By his early 30ies he was the established senior developer at the company I worked back then.…

Sometimes all you need is passion.

I feel like the way universities teach data structures and algorithms isn't a great way to instill the joy of problem solving.

That being said, not everyone has that spark. And you can always lose it.

Re: The best programmers I know

#313
post #301

Earlier quoted context omitted.

Good engineering skills are transferable to being a good PM: you need to break down problems, scope them to fit a particular time allotment, estimate an effect on user experience (stats, tracking, what is a good signal and what isn't) and have the agility to react to changing requirements as things are getting built. Why it makes sense for them to be a single person? Often, "changing requirements" really comes from a…

Breaking down problems (vertical slicing) isnt inherently a dev skill. Insofar as it is a transferable skill to break down problems it is more of a life skill. Scoping tickets is more of a project management skill. Again, not a dev skill. Estimating effect on user experience - requires empathy, again not a dev skill. If you redefine the dev job as including PM skills then sure, PM skills are dev skills. But theyre no…

For any given ticket, unless you remove all creativity for an engineer, they will have to balance how deep and how wide they go, how much they refactor, and how much they skip, in order to be effective and not end up with a contraption that's extremely high risk to review and roll out to production: all of that is scoping.

If you are not doing that, you are being micromanaged and I feel for you in your engineering job.

And trust me, non-technical PMs are ill-equipped to figure out an incremental path to that North Star product or feature you want to ship — how you split branches and deliver value incrementally is something only a good engineer can do (well).

If you do not consider how an implementation will affect the user, you might just satisfy the requirement with an actually terrible experience (but the ticket never said it needs to load in under 30s and with no visible redraws and jumping elements): a good engineer will implicitly consider all of these, even if unspecified in a task (and many more, I only used an outrageous example to make a point).

Breaking down problems is certainly a life skill, but engineers are inherently good at it: it's the very definition of an engineer, and you can't be one without it. I have however seen PMs who mostly channel and aggregate customer experiences and stakeholder requests without an ability to consider (broken down, stepwise, incremental) paths to completion.

If you are good at all of these, you'd likely be a good engineer too: this does not mean that one can't be good at PM without being an engineer, just that a great engineer is very close to being a great PM too.

I am not against the division of labour and different motivations driving where each person invests their time, but if we are talking about a great either PM or engineer, they are pretty much of the same mindset with focus on different parts of the job that needs to be done — 90/10 split vs 10/90 split (and anything in between).

And finally, whether you are a great craftsman at engineering (or PMing), it is slightly different from a great engineer.

Re: The best programmers I know

#314
post #272

Earlier quoted context omitted.

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.

It's true that he no longer steers the project, but his first version shaped the internet as we use it today. At least one could how a modern version of a similar idea would look like. What has changed since then? Which issues should be fixed? You might end up with Deno or perhaps WebAssembly or something else entirely, but it definitely helps to know the people behind the tools we use every day.

Re: The best programmers I know

#315
post #166

> You built and shipped a critical service for a (larger) org. > You wrote a famous tool > You contribute to a popular open source tool > You wrote a book that is often mentioned all this will brand you as 'super nerd' and limit your career earning potential unless you are planning to become a principal engineer at google . don't be know for nerdy shit.

A principal engineer at Google lives comfortably. If you don't want to get into the business side of things, what better can you do?

most ppl have near zero chance of getting to principal engineer at google. but getting to mediocre paper pushing managment job is achievable for most .

Re: The best programmers I know

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

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…

The original designer for my most active product I work on choose EntityFramework. Used it for about 1.5 years before looking at the SQL statements it produced. It was a excessive UNION mess. Things that should be simple where 10x more complex.

Slowly replaced it with Dapper and handwritten SQL, a simple migration versioning system, and database seeding with validation. Once that was done, startup time was cut by more than 10 seconds on a standard SSD and about 30 on CFast. Even finally replacing the database connection with SQLite standard libraries shaved off 2 seconds.

EntityFramework maybe useful but it lacks performance when time to start using the software is important.

Re: The best programmers I know

#317
post #180
post #133

Earlier quoted context omitted.

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…

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…

[deleted]

Re: The best programmers I know

#318
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 see 'this guy' who wants or does build his own ORM, in every company I've worked with.

Re: The best programmers I know

#319
post #272

Earlier quoted context omitted.

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.

You may be crushed to learn that, while I did stop working on standard JS in Sept. 1997 when we finished ES1 (started in Nov. 1996), turning to found Mozilla and then Firefox to restart the browser market, which enabled restarting JS standards at Ecma in 2005, I then led the ES4 effort, forged the Harmony peace between ES3.1 and ES4 factions, and continued to work on the standardized language in committee through 2018 March.

BigInt was my last collaboration (with Daniel Ehrenberg). It's in ES2020 and all the engines now. Don't be bitter!

Re: The best programmers I know

#320
post #299

Earlier quoted context omitted.

First, for definitions, I'd suggest we use wikipedia for ORM [1] and also Active Record Pattern [2]. I believe Active Record is a more specific implementation of something that is ORM-like. We can stop speaking of Active Record since my point holds for the more generic ORM, and therefore holds for Active Record as well. To clarify my point, there is a fundamental impedance mismatch between object mapping of data vs r…

> To illustrate, let's pull some query code [3] from Java's Hibernate, a prototypical ORM. ORM and entity manager – which, in turn, is a query builder combined with a few other features. Your code is really focused on the latter. While the entity manager approach is not the same as active record, that is true, the bounds between query building and ORM, I think, are even clearer. In fact, your code makes that separati…

We might be talking past each other. I'm curious why you see such a strong distinction between ORM and active record. To that extent, do you have any references or links that explain Active Record as you understand it? I'm familiar with active record, but I don't think quite as much as you - I think I need to learn more. Do you have any good references I could look at?

My point is that (bluntly speaking), ORMs are intrinsically fucked because relational mapping and object mapping are just fundamentally different. Because of that difference, some things will always be difficult when doing so in any orm.

Here is an example of something that an ORM does well:

```

Person p = entityManger.findById(123);

p.setAge(23);

entityManager.persist(p);

```

I suppose an active record example is something like:

```

Person p = Person.findById(123);

p.setAge(23);

p.persist();

```

Regardless, of Active Record or ORM, the above is doing this query:

```

update person set age = 23 where id = 123;

```

The above is simple. When trying to update a linked entity is an example where ORMs are going to have complexity. Let's say a person owns books, and books are unique in the system. This type of query:

```

update book set person_id = (select id from person where name = 'Joe') where person_id = (select id from person where name = 'Jill')

```

In code, that looks like this:

```

Person joe = findByName("Joe");

Person jill = findByName("Jill");

jill.getBooks().stream().forEach(book -> { book.setPerson(joe); book.persist()) });

```

The ORM code is so convoluted... We do a full select for two Person entities, possibly eager fetching all their books with more queries (N+1) problem, but all other entities attached to a person as well, and then we do 'N' update statements. These types of problems are AFAIK unavoidable. They will happen for one scenario or another. One can choose the object representation to mitigate one case or another, but it's not long before something that is trivial in SQL becomes a huge burden in OO.

Thus, my thesis, Object-Relation Mapping will create unavoidable cases of convoluted code because RDBMS do not have a perfect mapping to Objects. The mapping is not perfect,the result of this is intrinsic complexity that is easily solved by sticking to SQL, but very difficult in ORMs (which manifest as various issues of inappropriate eager vs inappropriate late fetching, N+1 queries, caching issues, transaction issues, etc..)

Post reply on HN