Can you elaborate? To my knowledge, 401k target date funds sometimes have small allocations to REITs (like 3-5%) or REIT indices that might be comprised of a mix of commercial and residential. Maybe there is some exposure to CRE mortgage backed securities through the bond indices?
"Sitting down with an RFC and coding up what it says is nowhere near as simple as it seems like it should be"
I learned this for myself when I tried coding an IRC server for fun. Quickly found that I made more progress, faster by just using Wireshark to see what an established server was doing and copying that.
1) "Web application development" doesn't happen in a vacuum. Often it happens in contexts where the "backend" is also consumed by various non-web applications. In those contexts, collapsing the frontend and backend back into 1 component is less of the slam dunk than it's made out to be in this post.
2) The missing piece is how you can achieve this "collapsing" back of functionality into single SSR deployable(s) while still preserving the ability to scale out a large web application across many teams. Microfrontends + microservices could be collapsed into SSR "microapplications" that are embedded into their hosting app using iframes?
At the team level, keeping M to 1-2 works really well in my experience. Of course M is never really 1 or 2 because you're always wrapping up small details from $previous, looking ahead at $next or just doing $maintenance. A reasonably sized team will be kept busy enough with "just" an M of 1 or 2.
The constraint helps to ruthlessly focus on the most impactful work. The maximalists want to get cute and try to bin pack but it just doesn't work, unfortunately.
Anecdotally, I've observed across my ~12 year career so far that an emphasis on estimates and estimating is negatively correlated to productivity, lead time, velocity, impact, positive outcomes etc...
I suspect the reason is because management is trying to use numbers to justify bin packing more work to an already oversubscribed team. What never shows up in those project management spreadsheets is the very real and predictable cost of context switching and the increase in mistakes from dealing with a larger amount of in-flight work.
Am I correct in thinking that PG's MVCC implementation results in a worse story around offloading some mild OLAP workloads to a replica without affecting the primary? Anecdotally, it seems that MySQL handles this better but I don't understand the internals of both enough to explain why that is.
In theory it is good practice, but in practice enforcing referential integrity is not free and it makes satisfying other non-functional requirements harder. Engineering is about tradeoffs. Foreign keys are overkill in modern architectures where DBs/tables are typically only written to by a single application. They solve a problem that lots of people don't really have anymore.
MySQL stored procedures work fine when invoked from application code IME. The lack of native collection types is not ideal when you need to inject N values to a bit of data logic. As such, and for other reasons, I personally prefer raw parameterized SQL passed through a lightweight ORM that handles mapping for me as well as securely marshal a collection value into a parameterized query. But beyond that Id say that they are "usable".
Can you elaborate on the challenges you've faced with them?
Ive had a fair amount of low effort "big wins" in my career, simply by reversing the technical decision/implementation of people who took this idea too far. IMO the OP sits at a reasonable level on this particular "spectrum". The title is more controversial sounding than the post which itself is quite reasonable.
The implications of being tightly coupled to the (transactional) database are less onerous in a microservices environment where databases are "private" to a single application/service.
Ownership disputes often stem from non-technical issues. Two orgs with different agendas might feel they require ownership of a given piece of tech to drive their own agenda forward. This can be expected to happen in firms that have multiple product lines but perhaps some shared functionality across them, as just one example.
I sense that we have different experiences and so can't relate to each other's points without getting more specific so I will make this my last reply.
I will just say that a common trope I've seen in online discourse on this subject is basically that you aren't a real <verySeniorIC> unless you are effectively doing the job of (or heavily carrying) your peers in the org chart who explicitly hold management roles. I broke my own back, metaphorically, trying to live up to that ideal with nothing to show for it and at the expense of the output that was expected of me and so I reject that notion. The <verySeniorIC>s Ive seen who hold those titles with longevity aggressively delegate politics to management and focus on the tech.
I am talking about non-technical roadblocks. Cross-team product engineering projects can sometimes involve ownership changes which affects the company in non-technical ways. Some influential product/design lead might lose some control of their UX, some engineering team will become "redundant" and need to be reorged or refocused to other types of work etc ...
You might be able to help with those politics but it's probably also not your job to do that. That's partly why actual engineering and product managers are on-staff to focus on things like that.
If I understand you correctly, I have felt similar angst before in this kind of role. Basically, you see "org-wide" work that needs to be done but it requires some level of "org-wide" alignment that doesn't yet exist. So you feel like you are twiddling your thumbs doing code reviews and making the tests faster while you wait to get the green light to "do your actual job".
At least for me, in hindsight, a lot of that was just in my head. It's fine once you earn the level to not always operate at it. Just as long as when that's needed again you are able to step up.
Agreed. There is also a natural disincentive here to optimize the architecture for "team-based flow". As a product engineer, you often get promoted for doing projects that essentially cope with a sub-optimal architecture. If you improve the architecture, there is less promotion fodder for the next person to get to these levels. In fact, I have myself literally been promoted for the former and NOT promoted for the latter.
Note that I am referring to product engineers. Platform/infra engineers necessarily have to work cross-team. And of course some "product" projects should be cross-team ... but if most or all of your product engineering projects are cross-team that is a huge red flag.
At a certain amount of scale its net “simpler” if the analytics people are free to do their jobs without worrying they will bring down “the app” and vice versa.
OLAP has certainly become overcomplicated but collapsing everything into big monolith dbs again is an over correction IMO.