zb

In 1812 he was the Earl of Wellington. https://en.wikipedia.org/wiki/List_of_titles_and_honours_of_...

CFC refrigerants are the canonical example.

Commit messages are immutable. Linking them to a bug ticket gives you a mutable place to record any new information about the bug that you discover in the future. (For example, that it affected more cases than you originally thought, or that the fix caused another bug.) This new information will be discoverable when starting from the original commit (found e.g. by doing a blame on a particular line of source).

To fail to do so is a gigantic missed opportunity in my opinion. You never know when you will need it.

It’s a lot better than the reverse.

Another way to look at it is that you’re getting to do all of the fulfilling parts of management roles (helping your team(s) to grow and develop) without the less fulfilling parts (endless meetings, budget spreadsheets, unpleasant conversations, having to give up writing code).

These are not rookies if they reached Principal IC, but the most experienced team members ever, yet the author still feels the need to say this.

At this level the job is qualitatively different from what went before - you do start as a rookie in this role, and if you only try to keep doing what you’ve done before only better then you’re not setting yourself up for success.

Do we need to move up or out?

Not to this extent, no. If you are still a Junior after 15 years, that’s a problem and questions will be asked. But if you want to stay in a role where you keep doing what you’ve done before only better, then that’s generally completely fine and the right choice for many people.

The ink ribbon contains a record of every word you type, and I believe hoovering them up was a common espionage tactic back in the day.

Debuggers allow you inspect stuff forward in time, while print statements allow you to debug backwards. (There was a lot of academic work on reversible debuggers at one point; to be honest I haven’t kept up on how that turned out.)

If you can detect a problematic condition and you want to know what will happen next, a debugger is a great tool.

If you can detect a problematic condition and you need to find out what caused it, it’s printf all the way.

My theory is that different types of programming encounter these two types of problems at different relative rates, and that this explains why many people strongly prefer one over the other but don’t agree on which.

A city is not a tree: https://www.patternlanguage.com/archive/cityisnotatree.html

Even trees are not trees: https://en.wikipedia.org/wiki/Anastomosis

Evolution is most definitely not a tree.

Nature also tends towards practicality, even more so than programming. Trees aren’t a fundamental truth, they’re a made-up oversimplified abstraction.

I’m reminded of an infamous occasion when this technique was used: https://en.m.wikipedia.org/wiki/Cable_243#Preparation

The one that sprang to mind for me was The Name of the Rose. Oddly it doesn’t show up as a title drop in the data.

This in turn is why air traffic still use AM where you can hear both overlapping transmissions at once (possibly garbled if carrier wave was off), and react accordingly rather than being unaware that it happened.

I’m not convinced this is the reason. The carrier wave is always off by a little. While you’re transmitting you hear nothing anyway. And when two parties are transmitting simultaneously, any third parties just hear very loud screeching. A 0.001% difference in carrier frequency would be more than enough to cause this effect in a VHF radio. Notably, this exact problem was a major contributing cause to the worst accident in aviation history. Using FM would have prevented it.

https://archive.ph/2013.02.01-162840/http://www.salon.com/20...

You must be American.

In Australia there are exactly zero heat pumps on the market that you can use an ecobee with. It just isn’t an option. There are no off-the-shelf options.

You don’t have to pay $1700 for this garbage $50 tablet, but it is the default that every installer will offer you without mentioning any other options (and the only options are the manufacturer’s proprietary controllers). In this case his builder procured it for him without even telling him the price. He may not even have been given a choice. You have to be extremely motivated to stay on top of every decision like this along with the thousands of other decisions involved in building.

The arrow has a white outline around it, so the hotspot is at the tip of the black arrow, at (1,1).

this can’t possibly be how you write tests in Golang?!

Only for very simple functions like in the example. Most of the time it’s much worse.

AIUI the Hybrid Synergy Drive combines aspects of a series and parallel hybrid, for efficiency at both high and low speeds. I think this is the main reason that pure series hybrids are not more popular.

This is called a series hybrid and there are lots of them on the market.

It’s a quote from Newton, so that’s obviously why we say it.

The reason he said ‘giants’ is supposedly that it was a dig at Robert Hooke, who was famously short. Impressively, if true then he both managed to get this dig in and to be remembered for his humility as a result of it.

I’m currently reading The Staff Engineer's Path by Tanya Reilly and it’s really good (so far). It’s a great thing to read at the point it sounds like you have reached, where programming a little better is no longer going to move the needle, even if you aren’t in a position to apply everything in it yet.

Exactly, but also that it's quite often experience you had this morning, not e.g. over the last 5 years, that makes the difference.

Lawyers make a distinction between "illegal" (crimes) and "unlawful" (torts) that is mostly lost on the general public.

Any thread about this is incomplete without mentioning the article about a note change in this performance by John Darnielle (of the band the Mountain Goats, who is also a novelist): https://harpers.org/archive/2016/01/there-are-other-forces-a...

No, because he’s clearly describing an engineering problem, not a physics problem.

Cloud infrastructure - so basically I have gone right from one end of the scale spectrum (tiny GPS receivers) to the very opposite extreme :D

Yes, I was working for a company making standalone car navigation devices (remember those?), amongst other GPS-related things - I also worked on a lot of OEM GPS receivers. There was even a guy (not me!) who had written the firmware for a GPS receiver basically from scratch, so I got a look at everything from the very low level up to the navigation UI.

At this point the iPhone hadn’t come out yet, but building data was just starting to show up the maps we used for navigation.

Fun fact: when I was looking into patenting this concept in c. 2007, the prior art search revealed that it had already been patented by someone in Japan in c. 1997.

Amazing to think that ideas people had back when Selective Availability was on for the foreseeable future are just now becoming available to consumers. Congrats on getting it done!

I don't know anything about the .NET Foundation or much about this particular situation, but I know a little about open source governance.

It appears that Novotny believed she was acting in her capacity as a (long-dormant) maintainer of the project when she merged the PR in question. It was clearly wrong to do so without following the process set down by the other maintainers, and she was right to apologise.

However, as the Executive Director of the Foundation, she also had the power (perhaps indirectly) to force a merge of a patch in any project controlled by the Foundation. All Foundations must reserve this power to themselves (you can't take on legal liability for something you have no control over), but they also must never use it. To do so is the nuclear option, to be invoked only after all trust and goodwill has been irretrievably lost anyway, because it certainly will be once you use it.

When you wear multiple hats and one of those hats is very powerful, it is critically important to make clear when you are doing stuff but not wearing that hat. Sometimes even that doesn't help, and it's better to just refrain from doing that stuff until you have handed the hat on to someone else.

In this case she failed to make it clear that she was wearing her maintainer hat and not her ED hat. In fact, she accidentally invited speculation that she was wearing the ED hat by referring to the change as a requirement of the Foundation. I'd imagine this is why things blew up.

Note that this probably indicates a problem with the structure of the Foundation. It's more or less inevitable that at the board level these things are pay-for-play, and that the ED's continued employment is at the discretion of the board. But technical decisions should be delegated to a neutral body, preferably elected by the project maintainers. It doesn't sound like that exists, but had it done this situation might have been avoided.

The other issue seems to be a fundamental disconnect between the Foundation and the maintainers of various projects in it about the purpose of the Foundation. For example, I saw one where a maintainer politely declined to give the Foundation access privileges required to enforce the Code of Conduct, instead saying that the maintainers would enforce it themselves. Sorry, but I don't think any foundation could accept that. One of many reasons for joining a foundation is that it gives contributors confidence that there is a CoC backed up by an independent organisation, and that can be enforced even (especially) against powerful members of the community such as project maintainers - potentially even all of a project's maintainers. This is one of many ways that Foundations help build contributor confidence, which is one of the major benefits for a project of joining a foundation, and all of them rest on the credibility of the foundation to act as a circuit breaker and assert some kind of control should dire circumstances crop up. To allow individual projects - even historically well-behaved ones - to opt out of that control would be to effectively render those guarantees meaningless, and in fact reduce the foundation to what would be effectively just a giant fraud against contributors.

It appears that many projects signed up without being made aware of this, and that is an absolute disaster for which only the Foundation can be responsible, and again they are right to apologise for failing to communicate it. However, what many people wanted was an apology for having technical measures in place that would allow them to exert control over projects, which the Foundation cannot really apologise for because it would effectively be an apology for existing. Inevitably people who wanted that will see this response as a non-apology apology.

It looks like a long, hard road back from here to rebuild trust. I'd suggest that the board needs to work collaboratively with the community to clearly document the rights and responsibilities of both the Foundation and the individual projects, that they consider establishing an independent governance body for technical oversight, and that any project that feels this isn't what they signed up for be given the opportunity to leave on good terms.

He had no idea whether it was a risk worth taking or not, because they rejected any evidence short of certainty that the O-rings would fail on a given flight. The results of the Rogers Commission make this abundantly clear to anybody who cares to pay attention, yet he professes to have learned nothing.

The film “Challenger: The Final Flight” on Netflix includes interviews with the most important participants in the launch decision, including McDonald. (It also has interviews with many of the astronauts’ families and does a great job at putting their experience front and centre.)

The guy whose job it was to send the fax because he happened to be the one who knew how to operate the fax machine is to this day utterly devastated; weeping.

The MTI VP who signed off (although the decision was made above his head) admits that he agreed with it at the time, but acknowledges it was a mistake. He’s being interviewed in a large room full of very expensive furniture.

The NASA manager who bullied them into agreeing to launch because they couldn’t prove that it was unsafe basically says that if he had his time over he would kill all of the astronauts again. Truly terrifying.

Python's "threads" are actually fibers.

They’re actually not. They are native threads with high lock contention.

Async is arguably fibers, as are greenthreads in libraries like gevent or eventlet.

But if you want to use real threads, multiprocessing's "processes" are actually system threads.

They’re system threads running in separate memory spaces. Also known as… processes.

I recall encountering compilers that required this - there was no linker essentially. Sometimes that was all you had available.

Most of the manufacturers eventually just wrote gcc backends for their architectures, but the era of crappy proprietary compilers went on far too long in many cases.