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

hug of death

After London City Airport comes "King George V"

thanks, i hate it

Great Visualization! My perception was that only 10% of the subs were going to go private. At the time of this comment, 87% of reddits are private

Sounds like: We want to invest on AI and this is our exclusive training dataset.

What other usages have you found for your foot pedal?

Code: https://gist.github.com/gareve/0a75f284650d8d74055aa8c7c31a5...

I wasn't expecting this to cost less than 3$

I trust more the BS here than the Phd from above

same, but instead of backup, I just delete the biggest unimportant files. I can last for years doing that, until I change Linux distro, new laptop, or just a fresh install

omg, they cherry on top was hijacking the back button

Is a good time to collect stories of this period in Software. I'm doing it too for my own private archives.

I want to compare in 10+ years, how me and my colleagues used to see & experience our industry.

True! Some books take a while to take off into the meaty part of the topic/story.

Until you reach that point, you may be disappointed due to mismatched expectations.

A good cover + summary + intro + PR can help to reduce it.

I haven't been able to apply to a real project yet, but I like the idea of building to refactor.

You execute for today, but make it easier to replace parts on the future

Hug of Death?

This seems very useful, but the subscription model irks me a bit.