eckesicle

Okay, but you spend 2000 hours per year at work.

So 10 hours on a config is only .5%, which is the productivity gain you need to realise to get that time back in one year (assuming you also spend 0 hours on fighting vscode).

Unless you're retiring within the year, that calculus doesn't make sense.

The productivity boost you get with from Emacs/vim is huge once you learn it well.

I strongly believe that learning one of these two editors is probably the easiest and biggest skills leap you can take as an intermediate or senior developer.

No other skill you can learn will have as big of a payoff to your productivity given the relatively small effort to get proficient.

My wife died unexpectedly a year ago. A little before that I had set her up with a 1Password account and she had diligently moved all her details into it. She shared her master password with me.

It was an incredible lifesaver in the first few months. Everything was really easy to get in order, and anything that wasn't well documented, I could find in her laptop or inbox.

I'm so glad that she did it, and it saved us so much headache.

Banking and such things are the easy bit, they've got streamlined and established bereavement processes. It's all the other small stuff that's hard, like loyalty cards, airmiles, gym memberships etc that causes the headaches.

and exactly once delivery and exactly once delivery.

You're right of course!

My dad never taught me how to shave, and for the longest time I just used these disposable Gillette style blades, and got terrible results. Missed spots, cuts and skin infections.

At some point I decided to do some research and settled on double edge disposable blades.

I've never been happier, and feel much better about my skin too. These are the products I use:

* A wooden synthetic shaving brush (I felt bad about the beavers)

* Taylor of Old Bond St shaving cream. It lasts forever.

* A ceramic lathering bowl

* Floris after shave. Also lasts forever

* Jagen David B40 (make sure to get a butterfly version, they're much more convenient)

* Derby blades (I bought a bulk of 500 blades for like £30 quid, and I'm only halfway through using them after many years).

Now I probably spend less than £40 per year replacing shaving cream and after shave, having had to spend that amount monthly on disposable blades, and that terrible canned cream, and I hardly ever get any cuts anymore. And my shave is much closer.

Besides these products look great in the bathroom.

I do quite a few interview each week, and one of our problems highlight the differences in these two approaches quite clearly.

Inevitably, those candidates that layout their types, and think about the structure before they start coding come up with convoluted interfaces, leave unused class/struct/type member variables, duplicate data, or are simply unable to complete the problem because they've coded themselves into a rabbit hole.

The best candidates decide what the public interface will look like, create the method signatures that they need and then start coding the logic. They add parameters/member variables only when they discover they're needed.

In the end they arrive at a minimal and feature complete solution, rarely getting stuck on the way there. I've changed my own style of thinking about a problem as a result of this. Now I code outside-in, instead of inside-out.

Sanctions and boycotts are unfortunately blunt. Yet, every citizen in Russia pays russian taxes. Tax rubles funds the war. Taxes are paid equally by those who support the war, and by those who oppose it. The end result is the same - bombs on Ukrainian maternity wards.

It is a shame that the innocent have to suffer, but I'd rather impose sanctions and boycotts and see a smaller number of bombs rain down over Ukraine.

For this reason, I support every move to cut off anyone in Russia from any and all foreign products and services (perhaps with the exception of medical supplies and children's toys, but the principle stands).

In aggregate all these small actions are having a very real impact on Russia's ability to conduct the war.

Would you mind naming the company you work for? It sounds like a really nice place to work.

For fun, I started keeping a log book of the number of times a driver has been involved in a dangerous situation with me (like cutting me off), grouped by make.

BMWs show up about 30% of the time in my notepad (in absolute numbers, not adjusted for how many BMWs are on the road here in the UK (5%)).

I would be shocked if BMWs (and Vauxhalls/Opel) aren't massively overrepresented in accident statistics here in the UK.

That's certainly NOT generalisable to Sweden as a whole. Rural Sweden is definitely not accessible by public transport as a whole.

Thanks for clarifying the difference.

Well I, and my family took several tests with this firm - and I am very upset about this.

I will be speaking to a barrister today or on Monday to explore what, if any, remedies we can seek over this in court.

Please if anyone could recommend a London-based barrister who specialises in this sort of matter by DM or in reply that would be much appreciated.

Microsoft locked me out of my Skype account by enabling an old phone number as two factor out of the blue. I hadn't used that number for 10 years.

So disappointing since it was my only point of contact with lots of old friends.

My strategy was: minimise casualties to kids, people and then pets. If the choice is between equal damage to pedestrians or passengers then pedestrians take precedence. All else being equal don't intervene.

The roles that I get approached for that pay 200k+ are mostly in Finance (quelle surprise) or DeFi. I regularly see golang and c++ roles paying 175k+ outside of Finance too though. Some tech roles typically fall between 120-150k with the odd outlier. And yet other roles come in at 60-80k.

I'm pretty sure the distribution of salaries are multimodal, even when you discount finance.

Salary aside, IMO the higher paying jobs are also the more attractive ones when it comes to remote work, holiday allowance, and (I suspect) technical maturity.

I managed to land a well paying job with good work life balance by changing my approach to job seeking. Here's what I did.

1. I tracked all incoming offers in a spreadsheet with a column for salary and equity 2. I responded to every incoming lead on LinkedIn with 'what is the salary band for this role?' and 'how did you find my profile? What did you like about it?'

This allowed me to build a distribution of jobs available to me, and then I only ever took calls with the top 1% of those offers.

I must've spoken to 150 recruiters on chat, but I only interviewed for 6 companies and secured 4 offers.

I kept iterating on my LinkedIn based on the feedback from the initial chat interaction and very quickly I was getting really good leads.

I put in about 100h work over a year to get to that point. I still, 3 years later, regularly get offers with >200k GBP base compensation now.

EDIT: I forgot to add a key factor. When the recruiter responds with a salary that is below the top 1% you reply: 'Thank you, but I am currently only able to consider salaries with a base comp of at least X, please get back in touch with me if you find something in that range." - X being your current estimate of the top 1-5% of the distribution.

My sister got a 9 month gig with the local municipality to copy-paste cells from a folder of 1000s of source excel sheets (with some transformations) into a master Excel sheet.

They paid her per entry and she was supposed to do 200 entries per day. By the end of the first week she'd automated the entire thing with a script that did just that.

So she ran that script every morning for nine months and spent most of the days biking, hiking, and swimming.

It looks like the all time death toll of nuclear power so far is <20,000 total. Meanwhile coal plants kill 30,000 per year in Europe.

https://en.m.wikipedia.org/wiki/List_of_nuclear_and_radiatio...

https://www.independent.co.uk/climate-change/news/air-pollut...

My understanding of nuclear power economics is that the bulk of the cost is incurred at construction, and that you can maintain minimal capability at a comparatively affordable rate. Closing operational reactors makes no economic sense either, and the argument in Germany has mostly been environmental and safety related (since the accident in Fukushima).

https://en.m.wikipedia.org/wiki/Economics_of_nuclear_power_p...

In my opinion Europe's decommissioning of nuclear plants, particularly in Germany, is the greatest geopolitical blunder in recent history.

The EU is now completely dependent on Russian goodwill to power their infrastructure for the next few decades, and have given up all leverage they had to push back on Russian power plays.

At the very least they should've kept the plants operational and operating at minimum capacity for redundancy to mitigate this factor. We have no idea what the political landscape will look like thirty years from now, and Russia hasn't exactly been a stable or kind neighbour in modern history.

https://www.euronews.com/2021/11/01/europe-must-reduce-its-d...

Unsolicited advice: Get something new lined up before you hand in your notice.

US has 40% of world GDP and EU ~32%. If you include non-EU countries they're neck and neck.

I've never used or tried any ergonomic keyboards.

Last time I looked into it ~10 years ago I dismissed them since there didn't seem to be sufficient evidence to support the bold claims they made.

What does it look like these days? Do these keyboard work? Is it worth switching from a traditional qwerty mechanical keyboard?

There's not really a seniority level where this happens.

The outrage around the technical interviews shows a lack of understanding for the situation companies face when hiring.

The reality is that something closer to 99% of the pool are applying for jobs they're not qualified for (not the same as saying 99% of developers aren't qualified - there's extreme survivorship bias in the pool).

At company X we would hire ~1/400 applicants who applied, and about ~1/20 referrals. At a smaller company I worked for we hired perhaps 1/200.

The thing is, many of these applicants have five to ten years experience (some at FAANG), but can't code at all. It's simply not possible to trust anything on a CV without verifying it. How do you verify this at scale? A pair programming exercise.

Now the training of most interviewers is often poor, but it's far better to go down this route than the HN alternative: hiring without technical screening.

Yeah, I'm seeing the same clipping issues since upgrading to Android 12. Lots of other bugs too.

For example, since upgrading when I use my "<Car Company Name> Remote App" to lock my car the phone will crash to the lock screen and get stuck there. The only way to get out of it is a hard reboot. Shocking.

Yes of course, but code reviews do not always tend to transfer a lot of context.

With strict deadlines and OKRs to hit it wasn't really feasible for people to double up on projects.

> Instead of 2 devs working for 2 months each on their own project, put them together on the first project for a month, then on the other project for the second month (simplified example, of course).

We did try this and it sounds good in theory but as the old saying goes 'two women can't have a baby in 4.5 months'.

In my experience (in this particular team and org) it would've simply been better to invest some time into documentation and suffer a short drop in productivity on a project when owners left.

Two years ago my team (then) was maintaining 15 or so projects in production, and landing 3-4 more every quarter. Each project was de facto owned by one person who did the bulk of the work on 2-3 projects.

After a team member left and a new maintainer had to step in to maintain an unfamiliar code base, our new EM decided that the bus factor must be raised across all projects. So every quarter we shifted responsibilities to new projects and had someone else take over ownership - the idea being that the previous person would still support and we'd not be in trouble in case someone left. That's not what happened though.

It didn't really matter if the old owner was around to support. Productivity plummeted with every project. It was as if every owner of every project had left the team every quarter.

Now I'm more convinced than ever that it's better to pay the price of an owner leaving if and when it happens, rather than try to prevent or mitigate that risk up front. The productivity costs are far too high for most software products.

I was thinking a bit about this during the game too.

Perhaps alongside centipawn loss (a measure of how many hundredths of a pawn a player loses by making the non-optimal move as determined by a chess AI engine) we could also measure the difficulty of any position.

Stockfish (a popular chess engine) roughly works by constructing a tree of possible moves and evaluating the score according to some heuristic at its maximum depth. The best result at depth n (25 I believe) is considered the best move and incurs 0 centipawn loss.

Perhaps we can define the difficulty of a position by the relative centipawn loss at each preceeding depth in the tree? The difficulty of a position is then determined by the depth at which the best move no longer changes.

The study says nothing about the underlying reasons for that discrimination though. The point of discounting those two roles in my post was to test my personal hypothesis of the underlying cause based on the data at hand - not to trivialise the findings of the authors.