1,803 karma · joined August 27, 2007
To fail to do so is a gigantic missed opportunity in my opinion. You never know when you will need it.
> 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.
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.
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 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...
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.
Only for very simple functions like in the example. Most of the time it’s much worse.
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.
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.
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!
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.
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.
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.