gareve

I think it all depends on the size of the team.

Very small team and too many design docs, not good.

Huge team, multiple timezones, multiple squads, and few design docs, not good either.

And then you balance with all the values in between depending on your team size & culture.

Even within the same company, your approach will/should change as it grows. There's a critical point where move fast and break things approach will eventually end up with too many outages, production bugs, unpolished/confusing product, and last but not least, FTC eye watering fines.

These days we don't know if that's true or if is just a marketing ploy to publish some unfinished book.

my guess is: scam sites acquired by meta to stop the scam

roflcopter attack

Seems it will be hard for her to attend the event on San Francisco, given that US decided to label her as Russian spy.

baby steps baby!

this is great strategy for debugging & so code reviewers have an easier time reviewing your incremental changes.

On newer teammates, I usually reject code reviews if they don't follow these practices (if the company's engineerimg culture is compatible with it)

I was there when lifehack blogs will continuously talk about a newly released note taking app(Wunderlist, Evernote, OneNote, etc.)

After trying several apps, including evernote, it felt they had too many features that made them too complex for my simple use case.

After trying several methods, my stable workflow is: - Dropbox markdown file for year long notes. - Google Keep for (shared) checkbox lists & multimedia notes. - Unread emails + snoozing for TODO tasks.

In the US, lead was found in Tumeric

for the db schema definition for this tool, where does the source of truth lives?

I'm trying to think what happens when a column gets deleted or added in the prod, ci, or dev db tier. Ideally those db schema changes should happen at the same time but real life doesn't work like that.

with some basic extrapolation, at how many users they'll hit the extra expensive Hertzner servers? or in other words, at which point they'll need to improve their architecture?

> Games made by passionate small dev teams that really love what they are doing will still produce indie success hits.

If there's 5 indie games that fit that description, people can easily enjoy, & more importantly, remember them.

What happens when 20, 30, 50 games fit that description? There's no way no good games fall through the cracks. The amount of games developed in a year increases while people's retention remains constant.

that's solved with Relay's graphstore

create a music or YouTube bot together

if you would have to do it again, would you change something on your methodology? I assume there were some unnecessary time sinks here & there

the low depends on the volatile price of apples. That hand doesn't move for free