jbmsf

9 ms·

31.
by jbmsf 1y ago
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
32.
by jbmsf 1y ago
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 c
33.
by jbmsf 1y ago
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
34.
by jbmsf 1y ago
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 so
35.
by jbmsf 1y ago
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, combine
36.
by jbmsf 1y ago
And also, engineers who are sick of the stupidity that comes from having too much VC money and not enough wisdom to use it.
37.
by jbmsf 1y ago
Ditto.
38.
by jbmsf 2y ago
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 t
39.
by jbmsf 2y ago
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.
40.
by jbmsf 2y ago
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 repre
41.
by jbmsf 2y ago
Mostly tax forms, state-specific formations documents (Articles of X), and state-specific payroll registration documents.
42.
by jbmsf 2y ago
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.
43.
by jbmsf 2y ago
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.
44.
by jbmsf 2y ago
And you believe that?
45.
by jbmsf 2y ago
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 i
46.
by jbmsf 2y ago
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
47.
by jbmsf 2y ago
Happy to see someone else who watches Michael Penn videos.
48.
by jbmsf 2y ago
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
49.
by jbmsf 2y ago
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 lo
50.
by jbmsf 2y ago
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 t
51.
by jbmsf 2y ago
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 worke
52.
by jbmsf 2y ago
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,
53.
by jbmsf 3y ago
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.
54.
by jbmsf 3y ago
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.
55.
by jbmsf 3y ago
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!
56.
by jbmsf 3y ago
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
57.
by jbmsf 3y ago
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&
58.
by jbmsf 3y ago
Right? That seems to be the thing this article is advocating and I have no idea what they are.
59.
by jbmsf 3y ago
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 need
60.
by jbmsf 3y ago
I get it, but this is also, frankly, terrible. I should not be required to store your identifiers in my system in case order to login users. I've always felt that email+email_verified would make much more sense. I don't actually c

More ›