LennyWhiteJr

The logical outcome of an escalation like this is that there is no single threaded leader for this user experience, the org charts are wrong, and one or more sr. leaders are culpable. But no one wants to hear that.

This is unfortunately par for the course at many big companies. I have re-lived this exact same thread so many times I've lost count

1. Leader escalates issue to his team 2. The team scrambles to come up with a solution 3. No one wants to take ownership. #NotMyProblem 4. weeks or months are spent on 'developing a plan' 5. nothinghappens.jpg

I will implicitly trust anything Jessie Frazelle works on. Rare combination of taste, skill, and passion.

honestly just leave him. it's a more metal burial place than any other he'll get anywhere else.

Yeah, it's included as one of the gradle scripts which fails the build in CI if the rules don't pass.

No template, as it's specific to my team's project, but one example is that we enforce that classes within our core domain don't import types from outside the project. You could accomplish this with separate projects, but that comes with its own complexities. This rule basically says "any domain type shall not import a non-domain type".

I love Detekt! It's particularly good for enforcing project conventions that can't be covered with standard linters. With access to the full AST, you can basically enforce any kind of rule you want with custom analyzers. And LLMs take out 90% of the effort for creating new analyzers.

Almost my entire org uses it for backend server development at Amazon. There is very strong support for Kotlin support within the Amazon dev community.

Someone who actually knows what they're talking about.

Even with the Customer Obsession LP, it's not too hard of a stretch to arrive at a conclusion where more ads are shown. Better are worse are, in many aspects, quite subjective in these areas.

There is organic matter buried in and around the site that can be used to date the point at which it was filled in.

In my Amazon team, we use PostgreSQL as a queue using skip-locked to implement transactional outbox pattern for our database inserts. People commenting 'just use a queue' are totally missing the need for transactional consistency. I agree with the author, it's an amazing tool and scales quite well.

Nothing about the outbox pattern guarantees ordering.

Even if are "down to several nano-seconds", a slight clock drift can be the different between corrupt data or not, and when running at scale, it's only a matter of time before you start running into race conditions.

For a small web app, fine, but if you're running enterprise level software processing billions of DB transactions per day, clocks just don't cut it.

This is precisely why large tech companies generally offer parallel career progression paths for individual contributors who don't wish to go into management. A Senior or Principal engineer at Amazon carries nearly as much weight, sometimes more, in software related decision making as their SDM counterparts.

A couple ways. If the need is not real-time and analytical, you feed the data from multiple services into a separate BI database which can do slower and more complex joins across data from multiple data sources. Or if the need is real-time, you build a paginated API with a page limit that can always be processed within the API SLA. Then you build workflows on top of the paginated API to operate on that data.

Generally, unbounded operations have to be broken up at some point. It just depends on how big the data set is.