664 karma · joined January 30, 2015
It’s the same as time boxing or pomodoro. You tell yourself it’ll take an hour. An hour later, you ask yourself what did you actually do and whether it makes sense how you spent your time.
I don’t think fake deadlines should be external. Hard deadlines is for external teams depending on you like marketing or sales or a customer.
Fake deadlines are for you to check in with yourself if things still make sense or if new decisions should be made because things didn’t turn out as expected.
> If you think that a prototype might take a month, why not challenge the team to see what they can deliver by the end of the week? You will be surprised, and so will they.
This is a great thought experiment but terrible for maintainability. It’s good to discuss what happens if we need it sooner, or what we could accomplish if we had more time. It’s bad to waste a week and commit to the bad decisions we make to meet a 1-week deadline when we all think 1 month is more reasonable.
Young people have a tough time pushing back. This technique is great for senior people, but juniors are just going to burn out. You have to be super careful with your language and be pretty clear that the pressure here is hypothetical.
Then they announced a $29 battery replacement program for phones that were affected by this battery issue. https://www.pcmag.com/news/report-apple-is-refusing-to-repla...
https://web.archive.org/web/20230415000000*/https://theaviat...
I’ve caught multiple production bugs in code review by just carefully reasoning about the code and changing some variable names to match my mental model. I didn’t quite understand how bad it was, but I could tell it wasn’t right so I left a comment saying “this seems wrong”. What happened after? It was merged without addressing and it triggered a P1 regression in production two weeks later. Like the author said, it takes time and energy to truly understand a program and think through all the modes of execution. BUT I think it’s a worthwhile exercise. It just doesn’t really get rewarded. In my experience, this happened at least twice a year over my last 10 years of working in software.
The other example is blindly accepting AI generated code, which I think is an extension of copying template / boilerplate code. You take a working example and massage it to do what you want. It includes so many things that either aren’t needed or don’t make sense, but it works at first glance so it’s submitted and merged. For example, build configs, JSON or YAML configs, docker container build files, helm charts, terraforms, gradle builds. It takes a lot to learn these things so we often just accept it when it works. It’s exhausting to learn it all but if you do, you’ll be much better at catching weird issues with them.
I think the problem is we trick ourselves into thinking we should spend more time coding than anything else, but it’s everything else that causes us more problems and we should build the muscles to handle everything else so that we waste less time on those mistakes. We’re often already really good at shipping features but terrible at finding and handling bugs or configs or builds or infrastructure or optimizing for performance.
Perhaps I'm saying crash and you're interpreting that as a bug but really it's just an OOM issue cause of too many in-flight requests. IDK, I don't care enough to handle serving my website at Facebook's scale.
It seems a bit naive for some reason and doesn't do performance back-off the way I would expect from Google Bot. It just kept repeatedly requesting more and more until my server crashed, then it would back off for a minute and then request more again.
My solution was to add a Cloudflare rule to block requests from their User-Agent. I also added more nofollow rules to links and a robots.txt but those are just suggestions and some bots seem to ignore them.
Cloudflare also has a feature to block known AI bots and even suspected AI bots: https://blog.cloudflare.com/declaring-your-aindependence-blo... As much as I dislike Cloudflare centralization, this was a super convenient feature.
At my previous company, there was a strong drive to make OKR’s complex because it looks better on a performance review package, but it just caused us to spend so much time creating and finding complex problems rather than solving the ones in front of us.
That’s the meat of it. It’s Heroku for statically generated websites or websites that can run as lambdas. Pretty limited but very fast for those purposes cause everything is handled by edge servers rather than primary data center servers.
They do just the right amount of "help" without really getting in your way.
Highlights:
* searching for shrimp will suggest prawns, seafood, fish…
* searching for “tomatoes and eggs” will suggest “tomato and egg” to be more inclusive
* searching for “ratatouie” will suggest “ratatouille” cause my spelling is mid and I cook a lot of languages that are romanized inconsistently (chow mein, chao main)
* it’ll show related recipes – “Red Braised Pork” suggests “Orange and Milk Braised Pork Carnitas”, “Sukiyaki Ginger Pork”, “Brown Sugar Bourbon Apple Pork Chops”
* supports searching through linked content (youtube subtitles, descriptions, comments section). Just drop a link and it’ll be searchable!
This links to my blog discussing how it works and features I dropped, but you can [play with it here in read-only mode: (https://recipes.href.cat/recipes.
I will say they come out with some dank video games like Lineage, Guild Wars, MapleStory, Black Desert Online, PUBG
It talks about the point of feedback and how there are different categories of feedback: appreciation, coaching, and evaluation. The frame bad feedback or poorly received feedback as “crossing the wires” where the receiver wants affirmation but gets coaching or evaluation. This throws them into a spiral. Recognizing this can make you better at receiving feedback and giving as well.
There’s a bunch of little things like “publicly praise, privately criticize” and that it’s way better to make time for feedback rather than waiting for the right time. Feedback is best fresh, where you can talk about concrete examples or incidents.
I deleted a tweet and saw this request:
HTTP POST https://x.com/i/api/graphql/VstuveVgh5q5jk7lmnVopqr/DeleteTweet
{
"variables": {
"tweet_id":"12344567899123",
"dark_request":false
},
"queryId":"VstuveVgh5q5jk7lmnVopqr"
}
You can execute these from javascript in the browser if the auth part is too complicated.### Update, this is the pure javascript console way, if you don't want to write your own client doing HTTP posts
I played with the console more and got these parts:
// Find all tweets on screen (this gives you the tweet IDs too)
document.querySelectorAll('a > time')
// Click the "more" button on the first tweet document.querySelectorAll('a > time')[0].parentElement.parentElement.parentElement.parentElement.parentElement.parentElement.parentElement.parentElement.parentElement.parentElement.parentElement.querySelector('button').click()
// Click delete on the tweet document.querySelectorAll('[data-testid="Dropdown"]')[0].children[0].click()
// Confirm delete document.querySelectorAll('[data-testid="confirmationSheetConfirm"]')[0].click()> Any headline that ends in a question mark can be answered by the word no. It is based on the assumption that if the publishers were confident that the answer was yes, they would have presented it as an assertion; by presenting it as a question, they are not accountable for whether it is correct or not.
I like to swap out any of these maybe-headlines with the exact opposite. It may help us, or it may not.
https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...
From the article:
> Just five minutes of activity a day was estimated to potentially reduce blood pressure, while replacing sedentary behaviours with 20-27 minutes of exercise per day, including uphill walking, stair-climbing, running and cycling, was also estimated to lead to a clinically meaningful reduction in blood pressure.
Sounds like 5 minutes of exercise is where it has a statistically significant measurable impact in blood pressure, but 20-27 minutes is where it's a meaningful impact.
Location: San Francisco, California, USA
Remote: Open to anything, but I prefer hybrid
Willing to relocate: Must be within commutable distance within San Francisco or along BART.
Technologies: TypeScript (Node, Next.js, React), Python (Django), Postgres, Cassandra, OpenSearch, Kafka. I'm backend-leaning but happy doing fullstack work. I also dabble in AI/ML on the side (see side projects on resume).
Résumé/CV: https://href.cat/resume [pdf] or https://www.linkedin.com/in/markersss/ for a short summary
Email: m.hireme [at] href.cat or see my resume
Hi! I'm a generalist software engineer with 10 YOE working on many things: android, operating systems, internal tools, microservices, distributed systems, frontend/backend web dev, high scale storage and search. As you can see by my experience, I love learning. I'm looking for a product role that is backend-leaning in the SF area. I have experience at 20 person startups (Procore/Airtable) up to 15k+ engineers at Apple. I prefer a smaller company where I can wear more hats and have a larger impact on the product.For you, if you’re expecting guests, just tell them to ring your doorbell. Get rid of the ambiguity and give them comfort in knowing the “right” thing to do. You clearly gave it some thought and have strong opinions about it. I’m sure other people are just trying to be considerate in a generation where they mostly grew up living with lots of other people.