I’ve noticed that the more high-level and complex the work you’re doing, the sillier your bugs get. Perhaps because you focus so much on the complex parts since they’re difficult to get right, so you gloss over the more basic parts.
I don’t think your pyramid is a good conceptual framework to understand programming expertise. Expertise comes mostly from seeing common/overarching patterns (which would be all over the place on your pyramid) and from understanding the entire stack—having at least some sense of how each level functions, from the high-level abstraction of RoR’s ORM to object lifetime and memory concerns to how database queries happen to how the db executes it (e.g. db indexes are also relevant to your example), down to at least having played around a little with assembly language.
I don’t even know Ruby or RoR, but if I had to use it for your example, my first thought would be “ok, how do I do a WHERE query in their ORM”, because every db abstraction in every language and framework has to solve this problem and I’ve seen a lot of those solutions. And I’ll know to consider eager vs lazy evaluation (what if a campaign has 1M records after filtering, maybe I want to iterate over results instead of getting a plain list), and whether campaign_id has an index, because all of those are very common concerns that crop up.
So the expertise isn’t knowing a factoid “don’t use x.all.filter() in RoR”, it’s knowing that anything that queries a database has to deal with the concerns above somehow.
I don’t think your pyramid is a good conceptual framework to understand programming expertise.
Perhaps. But does it meet the bar of “all models are wrong, but some are useful”?
So the expertise isn’t knowing a factoid “don’t use x.all.filter() in RoR”, it’s knowing that anything that queries a database has to deal with the concerns above somehow.
Agreed. The issue was that I am lacking a little in backend experience and didn’t think about those concerns.
I’ve noticed that the more high-level and complex the work you’re doing, the sillier your bugs get. Perhaps because you focus so much on the complex parts since they’re difficult to get right, so you gloss over the more basic parts.
I don’t think your pyramid is a good conceptual framework to understand programming expertise. Expertise comes mostly from seeing common/overarching patterns (which would be all over the place on your pyramid) and from understanding the entire stack—having at least some sense of how each level functions, from the high-level abstraction of RoR’s ORM to object lifetime and memory concerns to how database queries happen to how the db executes it (e.g. db indexes are also relevant to your example), down to at least having played around a little with assembly language.
I don’t even know Ruby or RoR, but if I had to use it for your example, my first thought would be “ok, how do I do a WHERE query in their ORM”, because every db abstraction in every language and framework has to solve this problem and I’ve seen a lot of those solutions. And I’ll know to consider eager vs lazy evaluation (what if a campaign has 1M records after filtering, maybe I want to iterate over results instead of getting a plain list), and whether campaign_id has an index, because all of those are very common concerns that crop up.
So the expertise isn’t knowing a factoid “don’t use x.all.filter() in RoR”, it’s knowing that anything that queries a database has to deal with the concerns above somehow.
Perhaps. But does it meet the bar of “all models are wrong, but some are useful”?
Agreed. The issue was that I am lacking a little in backend experience and didn’t think about those concerns.