How to grow from intermediate developer to expert developer?

[peerreynders]

@sztosz

And the most valuable lesson I learned is that often all the ORM’s are abstracting too much, and they makes simple tasks easy, but they tend to get in a way when the queries gets complicated.

And this is important to experience first hand - before that point

Programmers know the benefit of everything and the tradeoffs of nothing.

So while in general it still makes sense to reuse something that already exists, especially something that has been battle tested, one needs to be aware what tradeoffs are being made like:

• Is this library/framework pulling it’s weight to justify another dependency (and all it’s dependencies)?
• Is this imposing abstractions that aren’t appropriate to the problem being solved?

FYI: Framework Bound[2]

ORM/DataMapper won’t give you the flexibility raw SQL gives.

Data Mapper technology tends to be easier to grasp once you understand SQL (which draws on set theory) - core technology before library/frameworks.

DRY IMHO is often wrong goal in itself, because as I heard it first from Sandi Metz “Duplication is better than Wrong Abstraction”, and I wholeheartedly agree with this.

See also

• Development by Slogan with DRY: Part 1, Really DRY (2015-Jan-01)
• Development by Slogan with DRY: Part 2, The Tower of Coupling (2015-Jan-08)
• Development by Slogan with DRY: Part 3, DRY vs WET (2015-Jan-09)

I think the best way is not to over-engineer things

It tends to be over-engineering when we are trying to predict the future - which most of us are notoriously bad at. However then you have this:

used the word over-engineered in a positive light

I have to assume that it was successful because the architecture embraced change without trying to predict the shape of change. But they didn’t get there in a straight line. By 2014 WunderList was on its third rewrite. And right now Microsoft seems to have difficulty assimilating it (possibly due to cultural reasons).