Same - my new team doesn’t do any scrum or story points and it’s an amazing breath of fresh air - don’t miss those days just yelling random numbers at the zoom call for hours.

The truth is on most teams one or two people who are closest to the task have enough context to estimate, and probably only after they spent some time starting or prototyping the task.

Those people can give a reasonable estimate, in time not some strange point system.

Sometimes the estimate is wrong and that’s ok.

It’s fine to have a meeting catching everyone else up on the context but those pther people still likely don’t have enough to give an accurate estimate and shouldn’t be involved in estimation

Let me be clear -- nobody finds planning poker or story estimation fun. The same way nobody finds writing tests or documentation fun. So of course it'll be a breath of fresh air if it's not part of your job.

But the fact remains that in most environments, it's extremely useful for medium-term planning and especially in surfacing high-risk features that can send people down the wrong path for a long time. And it's meant to benefit stakeholders -- the people paying the developers' salaries -- not individual developers. It's about de-risking.

And if you really have the kind of team you seem to describe where everybody only works on their specific type of task and can't even estimate anybody else's work, then that's a danger situation when they leave or get sick or whatever and nobody else can step in and everyone's blocked because the only person who can do X is gone. Usually, you should be actively getting other developers to work on these features (usually the easier/smaller ones) and involving them in the estimation.

> The same way nobody finds writing tests or documentation fun

I'm not sure if it's the fun category, but at least they are useful and because of that, satisfying to do. In fact when I finish a solid suite of tests or good, clear documentation, I find it very satisfying. I can't say the same for poker/estimation. I've found to be them a complete waste of time in every job I've had and therefore soul sucking.

> you seem to describe where everybody only works on their specific type of task and can't even estimate anybody else's work, then that's a danger situation when they leave or get sick or whatever and nobody else can step in and everyone's blocked because the only person who can do X is gone

you're conflating the ability to estimate accurately with the ability to implement.

Just because I can't estimate a task accurately doesn't mean I can't do it.

> you're conflating the ability to estimate accurately with the ability to implement.

> Just because I can't estimate a task accurately doesn't mean I can't do it.

Most programmers could ultimately do anything... if given enough time.

But if they're going to do it professionally, you expect them to have some prior experience so they can do it somewhat efficiently. And if they have that experience, they should be able to estimate.

So yes, being able to estimate and being able to do (with reasonable professional efficiency), do tend to correlate, of course.

How does it help with medium-term planning when it's just pointing tasks in one sprint?

Because you often estimate something like three or four times as many tasks as actually get included in the sprint. You can't possibly know in advance which features will actually wind up in the sprint until you've considered all the possible candidates. You estimate, then the PM confers with stakeholders to prioritize what's actually most important and figure out the "puzzle" of which pieces add up to a coherent sprint, and then work starts.

To the developer, it seems like short-term sprint planning. But to the PM and stakeholders, it's very much medium-term planning because they're picking tasks for this sprint in light of what they also estimate the following couple sprints will look like (given current information, which is always going to change).

It's not as bad as it sounds, because when you're re-estimating something you already estimated in the past 2 planning pokers, it's usually pretty quick. You're just seeing if the previous estimate needs to be revised based on what the team has learned since. Most time is usually spent on newly proposed features, or features that have significantly changed or been split up.

Virtual credit card numbers are a great way to combat this.

For example, the Wall Street journal pricing is pretty wild (8 dollars a month for the first 3 months then jumps to much higher) so I use a virtual card which expires right before the planned price hike.

For other services I like to either use a virtual card with a single transaction limit, or just buy the service and cancel right away which typically is equivalent to just paying for a month

I tried to cancel a virtual card to cancel a service (that only allowed me to change anything by phone call, so this would have been far more convenient and less confrontational) and they tallied up a "delinquent balance" and threatened to sue if I didn't pay everything I owed in order to cancel.

Canceling the card does not work for predatory companies. Maybe for well-meaning ones that automatically cancel when a charge declines.

I switched home insurance away from liberty mutual after my term was up and did not renew. Three weeks after my coverage with them lapsed I received a notice from a collection agency for a late fee for coverage I never purchased. FUCK automatic billing and non-consensual subscriptions.

Take them to small claims court. You would win

It's too late for that now, but maybe if this happens again I will.

Agreed! I'm a long time privacy.com customer. It completely flips the script on subscriptions. I'll create a new card with only a budget for 1 month of the subscription. If I actually care about it I'll see the 2nd month's charge fail and quickly fix it. Also great for making sure free trials don't become forever subscriptions.

That's actually a great tip. Unfortunately I can't set them to expire at will, but using a 24 hours one (the usually available option here) is enough to get one month subscription without worries about the price hike.

Must be a shoe type thing - I’ve never had any smell with La Sportiva (solution, futura, Muira or katana)

My go-tos for outdoor climbing were La Sportiva Mythos, which never got too stinky because (I think) they were unlined leather so retained less moisture & funk. However, the laces made them less attractive for the shorter routes in the gym, so I branched out.

I just looked at the LS site, and it's been so long I recognize nothing aside from the current iteration of the Mythos. The biohazard shoes I had were from someone else, maybe 5.10? Maybe they were UFOs?

Nothing in 5.10's lineup looks familiar to me, but apparently they were acquired by Adidas in 2011, which probably explains it.

My stanky shoes were all black with some grey accents, and closed with velcro, which made them ideal for the gym. I wore them outside exactly ONCE, to a place near Austin. They were fine until I got above the trees, and the sun started BAKING MY FEET. They got super super hot in the sun, which was very uncomfortable and relegated them to gym-only climbing thereafter.

All of the velcro katanas I've ever owned ultimately ended up pretty stank. I think its the textile lining. Meanwhile, my Muira VCS have stayed pretty clean. My Muira Lace, not so much.

In that setup, how do you write a test which acts against a mock version of your API client (a static function in your proposal?)

Run a fake version of the API server, and then connect the real client to it. It is usually a mistake to make the "unit" of your unit test too small.

In this case, API does not refer to client/server. The API of the aforementioned static class is the set of its methods and their signatures.

Generally, avoid mocks.

Run a copy of the server in a container, run client E2E tests against it.

In Go at least you simply define an interface and use it as the receiver then inject whatever mock object you want.

The mock itself may simply be a new type defined in your test case.

yeah, I wouldn't recommend trying to do this with pure Java but you could pass around method handles for that purpose.

You certainly would want to use an `interface` and that means you need an object. It could be an object that has no fields though and receives all data through its methods.

But it does go against the spirit of objects: You want to make use of `this` because you are in the land of nouns.

I got mine for health reasons (low back, must work lying down sometimes), and while for me it’s a really useful tool, I couldn’t see working in it full time. It’s just too bulky, leaves a dumb red mark on my face, has bugs where sometimes it doesn’t connect, and is pretty much always dead unless it’s actively plugged in (doesn’t idle well).

Some of those things can be improved but inherently strapping a computer to your face is just not a great experience.

I definetly get use out of mine - I’d say 5 hour a week is a sweet spot - and it’s cool working in novel places like a garden or by a river, but full time doesn’t seem feasible

As an opposite view point I work on a 10 year old legacy iOS app which has almost no abstractions and it’s a huge mess. Most classes are many thousands of lines long and mix every concern together.

We are fixing it up by refactoring - many through adding abstractions.

I’m sure code with bad abstractions can scale poorly, but I’m not clear how code without abstractions can scale at all.

> Most classes are many thousands of lines long and mix every concern together.

That's quite unrelated to abstractions. It's just poorly written code, for whatever reasons may have led there.

Abstraction is a an abstract word, but as an example, I would consider the process of refactoring a big piece of code which mixed together api requests and view presentation into a 2 classes (a presenter, and an api client) as adding abstraction, especially if those new components are defined by interfaces.

And I’d rather work in a codebase where the owners are constantly doing such refactors than not.

I'd call that separation of concerns. I call that design more than abstraction.

Difficult to read, loaded with surprises.

Climbing works great in jeans if they are a bit stretchy. Especially good for knee bars - almost as good as a knee pad and 1100% more stylish

Agreed, a lack of a bit of stretch is the only limiting factor for my jeans, otherwise I might prefer them

America is a land of inequality. There are many people (poor) which have bad healthcare, but for many others (the wealthy, stably employed), healthcare is excellent.

If you have a good job with a good PPO plan, this healthcare is just incredible. You are free to see any doctor you want, including specialists without any gatekeeping.

Want to see the best orthopedic surgeon in the world who just fixed Lebron James's knee? Make a call and get an appointment within a few weeks paying a 30 dollar fee. Want to see 10 more orthopedic surgeons to get 2nd, 3rd and 4th opinions? Same process.

Decide to have a surgery? Sure! Sign up to have that done in a few weeks, eventually paying $250 out of pocket for the whole experience, including overnight hospital stays and physical therapy.

Having spent some good time hanging out in facebook groups for my condition with international patients, its pretty much always evident that they dont have this kind of freedom in picking their doctor, getting a surgery quickly, and also often lack cutting edge and modern treatments that are offered in the states.

I totally understand that this system is very unfair, and there is whole subset of people that have no access to care, but it should be noted that if you are in the top 50% of society financially, and especially if you have a difficult health condition you manage there is no healthcare system better in the world to do that then the USA.

I'm pretty sure it can't be the top 50% of society that has this, because that would mean it was average or even median. I expect it can probably start to happen from the top 25% up

FAANG jobs absolutely hire engineers over zoom. It’s not just one interview, but the whole process is done remotely over video. It typically includes somewhere between 5 to 10 sessions covering coding, architecture and behavioral.

Source - work at a FANG which engineers exclusively via remote video call.

Is the option of in-person available to the candidate?, zoom interviews are exhausting

I haven't worked FAANG, but a Fortune 100 tech company who's been hiring a ton of ex-Amazon management. Interviews 100% remote, even though there's an office in Chicago. No option.

At least in the USA one major piece of the college application is a standardized test - a concept very similar to a Leetcode interview.

A standardized test is considerably more standardized than a leetcode interview though. Not to mention you take it once and then provide the scores to everyone. My process with taking the cpa exam a single time was a much better experience than random leetcode problems every time.