vp8989

That's not what the parent post was referring to. If SQS (or your ability to talk to it) is down and your database isn't, what do you do?

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?

Focus on high value work that can't be automated is terrible advice?

Totally common IME. Bluey is for the parents. Kids like it but don't love it.

"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.

https://mysqlconnector.net/ is very good.

Dapper and ^ that works very well IME.

Agreed about replication.

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.

It's absolutely cargo cult nonsense and judging by the surrounding comments I'm SO glad we've all finally decided to stop pretending like it isn't.

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.

https://aws.amazon.com/blogs/database/manage-long-running-re...

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.

Fair enough. To reiterate, Im personally not a fan but I would say they are generally usable.

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.

I dont agree with the premise that running transactional and analytical workloads on the same database is architecturally “simpler”. In my experience this is only true at very low scale and those contexts are already sufficiently well served by existing database tech.

Kubernetes

DDIA is a good book and I've read it at least 3 times, but there is no substitute for real world experience.

I also think a lot of system design material is oddly positioned in that it caters towards synthetic interview scenarios where you are designing mega scale systems but somehow are also the single person responsible for all of load balancing, CDNs, message queuing, databases etc ...

In the real world it doesn't really work for that way for product engineers.

It's good to know about that stuff but there's lots of other topics that would have higher ROI like learning how to plan and sequence work properly, how to reduce different kinds of risk during build and deploy, how to migrate complex, existing systems towards better architectures without disrupting the business, how to actually become someone who gets to design systems ...

Year to date -> The market is down almost 20%, long treasuries are down almost 18%, IAU (gold ETF) is up 2.75%

Seems like it's doing it's job quite nicely.

It's quite common in larger companies for "senior" to actually mean "mid-level" or "not junior".

This title inflation provides some flexibility to create a level below the new grad level, to hire people from non-traditional backgrounds who would otherwise fail a typical entry level screening but are willing to (temporarily) work for low $ to get themselves on the "engineering ladder".

It also makes new grad offers cosmetically/psychologically more competitive. All else being equal, if company A offers you "junior software engineer" and company B offers you "software engineer" you might favor the latter.

Wouldn't a DevOps role have more context switching?

Effectiveness at work from what I have observed is mostly about pragmatism and willpower to do what needs to be done in that context. You need some baseline amount of mental horsepower but in most pursuits it's not that high.

Really smart people can be some combination of idealistic, lazy or simply in a context that diminishes their willpower. Therefore their smarts don't really "manifest" in that particular context. I've worked with lots of people who I thought were bozos because they sucked at their programming job but they were clearly smart about other things.

"2) Or: Managers have too narrow of a view of what their job is. Speaking generally (not accusing the parent comment) - This often happens when developers who haven't experienced good management or managerial mentoring get promoted into their own management positions and assume their job is literally just to delegate to the engineers and then check on them until it's done. In non-stagnant tech companies, there is always more for managers to be doing: Reviewing/updating documentation, helping with hands-on testing of the product, observing or interacting with customers to get a deeper understanding of the problem, coordinating with the sales team to get a better understanding of their domain, and the list goes on. Many of these tasks aren't immediately obvious without proper managerial mentorship, and they might be downright foreign if your only experience with managers has been of the delegate-and-wait variety."

Big companies tend to hire "specialists" to do all those tasks you mentioned, which I think is a mistake. If the purpose of those tasks is to improve the function of product development, which can be rephrased as "make the coders more effective" then each of those people require a high bandwidth communication channel to the coders. You can only have so many people that you communicate a lot with, and so the effectiveness of those people in improving the effectiveness of product development is limited. Their job is to make sure the devs arent working in silos but they all just end up forming their own silos because its simply not practical to have high bandwidth communication with all these different groups of specialists.

Im talking about designers, product managers, project managers, user researchers, data analysts etc ...

My broader point is that I agree with your vision of what a manager should do but IME it's not how larger companies tend to be structured.

The WebAssembly component gets pulled on app startup. That means you make a bug fix, deploy a new build to an S3 bucket and every single user is running the fix inside of ~24 hours.

I joined that Slack about 6 months ago and deleted it after 3-4 days. Found the people on those channels completely repulsive.