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.

What does it mean for a field to be required in new API version but optional in the old version?

Man, I remember running this and ophcrack as a 15 year old to recover the windows login password for my mom's computer after she forgot it. She was convinced her password had just stopped working, until I recovered it and she realized that she just forgot what it was lol.

There is sooooo much more that Kotlin offers over Lombok it's not even close.

> Checked exceptions are optional. But they're one of the BEST features in Java.

No

> So much code fails unexpectedly. When you want to build a professional application you need to handle every error.

Yes

> Checked exceptions help you avoid that nonsense.

Wrong

> People hate checked exceptions because of laziness. Java guards you against yourself.

Wrong

Java checked exceptions are almost universally regarded as being a mistake because they don't actually solve the problem they were meant to solve, and they make the code extremely hard to work with.

See this post from Roman Elizarov: https://elizarov.medium.com/kotlin-and-exceptions-8062f589d0...

Yup, I work at Amazon and my team along with many surrounding teams are only coding in Kotlin from this point on. The JVM and its ecosystem brings insane value to the table, and Kotlin lets you take all the benefits while removing most of the downsides of Java.

I have some hope for Hytale, an open sandbox game created by the creators of the HyPixel minecraft server. https://hytale.com/

Commit messages don’t matter. In fact they matter so little that I'm going to write a blog post about how much they don't matter. Commit messages are probably one of the worst places for documentation and a common source of bikeshedding. So let me kickstart some more bikeshedding since there's not enough already.

+1 for Memrise

I agree with the author, but it's also possible to take the other extreme where engineers think they don't need any input from product.

Fasting is not unhealthy.

First question is already awful. "Haven't eaten in 4 hours? You need to eat!"

Give me a break, I skip breakfast and usually do intermittent fasting every day, not eating until 4 or 5 with a high-cal home cooked meal. I feel great all day.

Yup, this exactly.

It is often under-appreciated how much an active corporate engagement model is due to 1 or 2 highly motivated employees. Once they leave, engagement drops because it wasn't something being driven from management or PMs.

"first you learn the value of abstraction, then you learn the cost of abstraction, then you're ready to engineer"

- Kent Beck

To elaborate on this, the feature sets on these low level microcontrollers are no standardized. There is no common API for them to implement. Even chips coming from the same manufacturer will have different hardware capabilities, and although low-level drivers can abstract that way to a certain extent, there will always be differences.

The biggest challenge is when you need to update your firmware to use a microcontroller from a different manufacturer. Often times these chips are specifically chosen due to the set of hardware functionality they offer, and the firmware is written to take advantage of that from the start. The two are coupled.

Now you are forced to use a different chip, and the firmware that was written for a specific set of hardware now has to be modified for a new chip that may have a different feature set. Things fine print on how things like Analog to Digital converters becomes extremely important.

Seeing a lot of hate for DDD here so let me offer an alternative point of view from someone who advocated for DDD on my team.

When I joined, my team had been building the backend for the first version of our app for about 4 months. I would describe the state of the code base when I joined as an 'Anemic Domain Model' as defined by Martin Fowler

- There was a 'domain model' in the loosest possible sense - Each model type was just a POJO with raw getters/setters for each field - Almost all fields were primitives (mostly strings with a few int/doubles/dates) - All validation code for these types was done in application code and was fragmented throughout the code base - Internal DB identifiers were fully exposed into the code model - Internal service types were liberally mixed with external service types - No notion of aggregate roots - every entity was just accessed ad-hoc

It was a highly unsustainable approach, and one of the first thing I did was attempt to implement strategic DDD in the areas that were the most painful. This included

- Adopting rich value objects to represent domain concepts instead of raw strings - Enforcing business invariants inside the model classes - Enriching the domain entities with methods that matched business behavior and performed validation - Creation of repositories that shifted much of the persistence details out of the application code - Defining aggregates based on our required access patterns which simplified our data access - Bounded contexts for our internal domain - mapping external service types to our own internal representation

The result of all this was the creation of a core 'domain model' that captured business behavior expected of our service and most importantly, ended up significantly simplifying the rest of the application code. If DDD makes your app code more complex, you're doing something wrong.

This is cool and interesting, but for me it's in the same category as photography eccentrics who can develop amazing photos with a darkroom in 2021.

I'll stick with my web interface. When that doesn't suffice, I'll check out the remote branch locally and navigate around with the full power of my IDE.