jbmsf

This was always the case.

I have worked with so so many ineffective product managers. The good ones are indeed unicorns.

Even when you have good ones, they can't scale up to all of the things that I'd want them to own, meaning that engineering fills a lot of gaps.

This ends up being uncomfortable and necessary. I'm still learning how to make it work.

Recently, I've been wondering about the point of code review as a whole.

When I started my career, no one did code review. I'm old.

At some point, my first company grew; we hired new people and started to offshore. Suddenly, you couldn't rely on developers having good judgement... or at least being responsible for fixing their own mess.

Code review was a tool I discovered and made mandatory.

A few years later, everyone converged on GitHub, PRs, and code review. What we were already doing now became the default.

Many, many years layer, I work with a 100% remote team that is mostly experienced and 75% or more of our work is writing code that looks like code we've already written. Most code review is low value. Yes, we do catch issues in review, especially with newer hires, but it's not obviously worth the delay of a review cycle.

Our current policy is to trust the author to opt-in for review. So far, this approach works, but I doubt it will scale.

My point? We have a lot of posts about code review and related tools and not enough about whether to review and how to make reviews useful.

Early in my career, most of the people I interviewed were not very good.

Eventually, enough time passed that the talent pool grew considerably and most people are baseline competent.

Consequently, I now find that respect and time efficiency matter a lot more.

That's mostly true.

- You may need something to connect the dots between code changes and containers. It's not always possible to build everything on every change, especially in a multi/mono-repo setup.

- You probably need some way to connect container outcomes back to branch protection rules. Again, if you are building everything, every time, it's pretty simple, but less so otherwise.

- You likely want to have some control over the compute capacity on which the actions run, both for speed and cost control. And since caching matters, some compute solutions are better than others.

I don't think GitHub Actions solves any of these problems well, but neither do containers on their own.

We have one junior dev in a team about a dozen. They have had other roles with us, both at the current job and previous ones. We know they are smart, reliable, and motivated. It's a no brainer to spend time on training because, combined with the skills from other roles, they are likely to have a lot of leverage.

But it's hard to imagine committing to the training without the history.

And also, engineers who are sick of the stupidity that comes from having too much VC money and not enough wisdom to use it.

Ditto.

If I have to make a rule, it's to prevent the worst people from doing the worst things. If I have an opportunity to use my judgement and you are neither doing the worst thing or someone I consider the worst person, there's bound to be wiggle room.

In our case it absolutely is. There are user facing flows that require data from partner systems to complete. Waiting for the next sync cycle isn't a good UX.

Absolutely. My current product relies heavily on a handful of partner systems and, adds an opinionated layer on top of these systems, and propagates data to CRM, DW, and other analytical systems.

One early insight was that we needed a representation of partner data in our database (and the downstream systems need a representation of our opinionated view as well). This is clearly an (eventually consistent) synchronization problem.

We also realized that we often either fail to sync (due to bugs, timing, or whatever) and need a regular process to resync data.

We've ended up with a homegrown framework that does both things, such that the same business logic gets used in both cases. This also makes it easy to backfill data if a chosen representation changes)

We're now on the third or fourth iteration of this system and I'm pretty happy with it.

Mostly tax forms, state-specific formations documents (Articles of X), and state-specific payroll registration documents.

Interesting. We're using a SAAS solution for document extraction right now. I don't know if it's in our interest to build out more but I do like the idea of keeping extraction local.

Honestly, this is the first LLM concept that makes me want to change my workflow. I don't use vscode but I'm excited by the idea.

And you believe that?

There's a reason this happen though. Whether you like it or not and regardless what the standards say, people want a technology that matches with the identifiers they want to use (eg email) and not whatever opaque value happens to be in the sub claim.

I don't like blaming users for wanting something sensible.

Can confirm. I've used ECS with Fargate successfully at multiple companies. Some eventually outgrew it. Some failed first. Some continue to use ECS happily.

Regardless of the outcome, it always felt more important to keep things simple and focus on product and business needs.

Happy to see someone else who watches Michael Penn videos.

I like the idea. The main thing I'd want to adopt this design is a comparable ability to inject environment variable secrets into lambda that ECS offers.

It'd also be nice to have a better log aggregation strategy for lambda than scraping cloudwatch, but that feels less important.

We deploy lambda using container images. We configure lambdas using terraform and deploy using GitHub actions.

We never considered using serverless or anything else because we also have ECS services, RDS databases, React frontends, and a lot more. It requires some knowhow to get a good setup, but it's hard to imagine anyone more opinionated framework doing what we want.

I'm sure these managers exist, but there's plenty of places where they don't. My recent experience has been that the managers I work with, when asked, almost always say yes to extending technical work to do a better job and that it's inexperienced developers who either assume they can't have more time or don't know how to ask in an effective way; these are professional skills after all.

This doesn't mean that there's never a need to hurry, external deadlines exist, but these are the minority in a healthy organization.

Our profession doesn't always work the way you describe. Some companies want cogs, some want professionals.

I can't give you advice beyond that, there are too many different circumstances. But in most of the places I've worked, it's been developers, not managers, cutting corners. Sometimes these are good choices, informed by product context and trade-offs. Sometimes it's a perceived urgency that doesn't actually exist. But it's almost never a micromanaging boss asking for something specific.

The most sane thing I've found is:

- Pin all application versions - Don't pin or set upper bounds in libraries. Lower bounds may work. - Use automation to continuously upgrade and test new versions of everything

If you just pin, you fall behind and eventually it becomes expensive to catch up. If you don't pin, you lose repeatability. If you don't automate, the upgrade work doesn't happen reliably.

I love it when someone shares an idea that I wouldn't have considered (which is on me) and so clearly solves a real problem.

I don't write go, but I like these patterns. Feels fairly universal for testable code.

I never want to see another (esp. Python) Quick Start guide that treats dependencies as implicit/static/untestable.

I appreciate the clarity of this article. I know it was written by the author for themselves, but it feels like it could have been written for me!

I think you missed the point. No application developer wants to use "sub" as the identifier; they want to use "email" or "phone" because these a) are actual ways to message a human and b) do not require a deep understanding of any technical spec to do the intuitively obvious thing.

I am not saying that my solution works today. I am saying that is a completely natural thing to want and the fact that it doesn't work or that we're even having this discussion is failure of the people who designed and implemented these specs.

I get it, but you're throwing technical specifications at a product/human/application problem.

No one wants to build an application that has to invent its own id scheme or manage this complexity. That fact that the specs don't provide a solution here -- something like informing you when an email address is no longer valid (again, I get it, this is hard/impossible) -- means that the spec will always be in conflict with actual usage.

Right? That seems to be the thing this article is advocating and I have no idea what they are.

I can't agree. This guidance just pushes responsibility down onto application developers and I would expect most of them to either do nothing or implement guidance inconsistently.

The right thing here is to offer APIs that fit the needs of the applications that will use them with as little extra responsibility as possible.

In this case, I'd have hoped that Google would set email_verified to false so that applications (or downstream IDPs) would know that they had to do extra verification.