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…
The best programmers I know
311–320 of 320 posts
Re: The best programmers I know
#312The 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.…
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
#313Earlier 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…
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
#314Earlier 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.
Re: The best programmers I know
#315> 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?
Re: The best programmers I know
#316Earlier 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…
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
#317Earlier 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…
Re: The best programmers I know
#318Earlier 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…
Re: The best programmers I know
#319Earlier 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.
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
#320Earlier 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…
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..)