Ironlikebike

Right, he still has access to his Google account, but he can't use YouTube from that account. In fact, he can't create a new account and login to YouTube from any of his devices. His only access to YouTube at this point seems to be through non-logged in access.

My son (a curious juvenile) found his own YouTube account banned in a similar manner for disclosing a security issue in Google wifi products. There was no first or second warning (despite what the Terms of Service say). Google would not give him a justification for the banning other than "terms of service violation". The appeals fell on deaf ears. Now their automated system keeps banning every YouTube account he creates within days of creation.

I worry that he'll never be able to appeal and a stupid 'mistaken reading of the ToS' on his part as a minor will affect his ability to ever host a YouTube channel or have a premium account subscription.

Good luck getting a real human in Google to sympathize with your plight and restore your account. They see disclosure of security issues related to their products or their customers' products as ToS violations and appear to be unyielding and swift in silencing such content permanently.

I'm not the OP but I'll describe a "behind the scenes" situation I dealt with.

I inherited a team of seven working on a project. They were led by a very strong personality who led the project based on his principles (he was interested in funneling as much corporate money into "free software" as possible while resisting delivery of business value). He'd been running the project for a long time by the time I inherited the team. One of the upper level folks gave me a call on Thursday and said, "In the operations call on Wednesday I'm going to propose killing that project because it's gone off the rails. We can use the money elsewhere. Just giving you a heads up".

I spent the weekend figuring out how to pivot the majority of the staff into other projects, use staffing as-needed to develop features for business need, and provide a minimal maintenance budget. I called the guy who wanted to kill it on Monday, presented the plan, and he said he'd sign off on it.

When I told the lead that the project will need to change he was outraged. He accused me of abandoning free software blah blah blah. I didn't get a chance to tell him about how I saved his job and the jobs of everyone else on the team by working 32 hours on my weekend and finding them other work to do.

The stack isn't in the C-standard, but it is often minimally defined in the psABIs (e.g., the ELF ABI on Linux) for the architecture. The psABI is generally trying to balance performance of addressability (on the architecture), with security (position-independence), while constraining the toolchain developers' implementation as little as possible. As a programmer you don't have to implement to the ABI, but if you want interoperability and you want to use a C language compiler, you should (good luck creating your own ABI otherwise).

I'm not aware of any way to programmatically query the rules laid out in the psABI. The implementation of the corner cases is often based on mutual agreement (convention) between the compiler and the link-editor.

You could probably write a tool that maintains a representation of these rules and returns the results in some sort of parse-friendly EBNF, but you'd need a convention linter to make sure that the implementation of your tool tracks the change in convention in the toolchain components.

On-the-other hand, you could write an extension to the compiler that warns you when certain C code results in behaviors around the stack that might be undesirable, i.e., if you're passing too many parameters to a function and it's going to spill those to the stack.

The standard way to avoid unknown behavior in this regard is to explicitly tell the compiler what you want to accomplish by not relying on auto-allocation or parameter passing rules (as stated in the top thread). This means explicit allocation on the heap, rather than than allowing the compiler to auto-allocate on the stack, and using pass-by-reference to avoid parameters spilling to the stack. All of this is slower since accessing values in the stack is often a single instruction operation (small number of cycles), vs multi-instruction loads from far-away addresses (large number of cycles).

"Being too open could so easily backfire."

I'm in the market for a new leadership role and I have a very well established leadership model that I've honed over the years to build high performing organizations. I was considering publishing my leadership writings (that I share with my employees when I coach them) on my LinkedIn so prospective employers could see whether I'm a good fit for transforming their organizations.

One of my former employees cautioned me that my since my leadership model doesn't virtue signal that I might find it hurts me more than it helps my prospects. I'm not sure what to make of this.

A promotion is not a reward. A promotion is an offer for a new job with higher expectations and more responsibility. If you struggle to meet the expectations of the current role, lack agreeableness, or are unlikely to be able to do the next role up there is no way that you'll get a promotion. Sometimes patience is key.

I'm currently mentoring a person who is transitioning into an engineering manager and this person has a noticeable stutter, but is an incredible candidate. If you don't like your southern drawl, change it. I'm from a place with a very strong accent but you'd never know it.

If you're getting a rejection to an application like "overqualified" or "not a good fit" it likely means your resume wasn't tailored to the position or there is something unbelievable about it.

When you get into the realm of enterprise sales you have to find a way to predict a fixed top-end price and it has to fit into their perceived value of your product even if they use less of the service than you or they predict. An enterprise customer will tolerate a higher per-unit cost for the assurance that they won't experience cost overruns. This is because they're budgeting large line items once a year and they can not overrun. This would mean that you'd price the product at 12000 euros per year and hopefully the value of the product is still high enough to justify this in their minds.

In the example you brought up, I'd try to meter (and value-price) the output, not on the collection. You have to make sure that your margins on the output of the service covers the cost of passively collecting and storing the data.

Per-seat pricing can be value-based as well. "value based pricing" in the context of a per-seat license is about identifying the value of the 'seat' to the user, rather than calculating the pricing based on your own costs plus some projected profit margin.

Regarding seats and SSO, check out https://sso.tax. Many companies will have a seat based license that has a free tier and as soon as you need/want SSO (because you see the value) you're now cast into a very expensive pricing model. Personally I hate being on the receiving end of this, but they're using the free feature-set as a demand driver, and as soon as you want to rely on the service in an authenticated master, they've now got you locked in.

The 'value metric' can be a seat-based license. It simply means that you price the seat based on the value it brings to the customer, not based on a cost+ (your costs plus a margin) valuation or a competitor- (your competitors price minus some amount to make you stand out).

I think you're confusing "value-based" with "metered". There's another model which is a hybrid model, not strictly metered, but not strictly seat based. An "hourly package" like gitlab-runner minutes is an example. The trick is that you can incentivize usage by giving them leeway to exceed their per-seat cap without penalty (to a certain degree--which signals to you that they've outgrown their current plan), in fact you want them to, but not to the point where you take a loss. If they're seeing the value in the service enough to push the limits of their plan then they just need some time to internalize that value. You can then approach them about upgrading to a better fit package. You can also provide what are considered 'demand drivers' for 'free'. These are features that increases the value of the original service and actually drive increased demand as well.

The more 'health-food' oriented your peanut butter, the less salt it is likely to have as well. This is a big factor in the taste.

This reminds me of a sci-fi novel I read in the nineties. The premise had something to do with actors who took on roles in virtual reality where their bodies are fit with sense-points. They're cast in live-action role-plays with wealthy remote clients. They're basically deep-fakes in VR.

In his book "The workmanship of risk", the industrial design philosopher David Pye said that the best work of the century will be done by amateurs. The reason being that a professional's work will always be held back from perfection by the fact that one has to balance the quality of the paid work relative to what one can reasonably charge for the work.

This "up-and-down chain" should stop pretty quickly at the level where eng mgmt knows loaded costs. It's an eng manager and director's job to compute total-cost-to-execute, and opportunity cost (using loaded-costs for engineer time). They should be able to approve once you've convinced them that it's cheaper to buy than to build.

Engineers can head this off by prepping a total-cost-to-execute analysis for mgmt. This doesn't need to be complicated. It's just some estimates of what's needed and why, and what the alternatives cost. My eng VP used to ask me for these when I'd send up a request. He wanted to know that we thought about total-cost-to-execute. He'd usually only read the exec summary and approve. If these requests are really going that far up the mgmt chain either someone isn't doing their job, or higher level mgmt are micromanagers.

Developers are overly optimistic, undervalue their time (they don't know the loaded-cost of their time), and overvalue their solutions (they rarely account for maintenance costs or the long-tail of time to perfect the solution). So developers think they are cheap. For example, I had an engineer express disgust that we might have to pay $4/month-per-user for gitlab just to have mirroring enabled. He said "we can do our own mirroring." When asked how long it would take he said, "between 2 hours to two-weeks if we have to iron out bugs". So when accounting for his time, his price to deliver ranged between $200-ish in the best-case scenario, to $8000-ish in the worst-case scenario (which far exceeds the cost of paying for the licenses). Needless to say, we paid for the licenses. He also wasn't considering the opportunity-cost, i.e., what will he NOT do that's more valuable while he works on this proposed solution that we could just pay for?

Yes this is true. It's a beef flavoring. My father spent the majority of his career in food-processing engineering working in a factory that made McDonald's french fries and confirmed this was the case. They're also par-cooked (pre-fried) before being flash frozen, and they don't use a batter or seasoning. Interesting tidbit, all of their competitors had their fries made in the same facility. I believe most of them even used the same type of potatoes.

> The team rationale is computers fail all the time. We should have SRE scripts that recover things.

This is a potentially very risky approach. I was given the task of having my org stand up a large, complicated system. My engineering team built a system that was failing 2% here, 10% there, 5% somewhere, etc. They built recovery and retry mechanisms for every failure scenario. We ended up with a combined failure rate of 40% that was masking the failures but basically doubled our execution time for the service. I locked down all new development and directed all of our effort toward driving accumulated failures below 5%. They completely disagreed with me (because they'd gotten used to the life of being firefighters). Once we got to below 5% their opinion changed completely. They're very proud of how they were able to drive down the error rate.

Watch out for accumulated error (or even worse--compounded error)!

On the other hand, you can expect that any network based service will fail and need to retry. It's especially important to make software that relies on cloud-based services resilient in this regard.

I agree that you should correct a deficiency immediately, but I think it should be done with utmost clarity.'Casually' implies that you as a manager might not care about the outcome or might not express your true concern about the incident. I always make it very clear that an expectation has not been met.

Several years back I took a "Crucial Accountability" course on having accountability conversations. In their process there were four phases to every accountability conversation: 1) Reiterate the expectation 2) Describe the incident in question 3) Ask the employee to describe the gap between the expectations and their behavior in the incident 4) Have a conversation about what we're going to do about it.

I've used this model many times and it is very effective. Usually the employee leaves the conversation understanding what I expect and assures me that they will try to do better. Sometimes it requires follow-up correction, or further conversations, and sometimes it requires an action-plan that we work on together. Rarely does it lead to an untenable disagreement in how things should be done (and you can guess where that leads). Also rarely, the expectations will be amended or more clearly expressed to everyone.

I do think getting their perspective is necessary to understand if the expectations were incorrect, or if my understanding of the incident was incorrect. But it is essential that the conversation always start with reiterating the expectations.

Per this document it appears that (frequent) Delta second stage explosions were one of the most significant contributors. By 1981 27% of all tracked debris (of orbital period under 225 minutes) were from Delta second stage explosions. (I'm guessing these are considered high velocity debris). It's quite interesting that NASA was surprised by this (asking McDonnell-Douglas to find out why in May of 1981) considering how long they had been launching the Delta rockets and tracking debris. From the document, NASA officials continually approved work to track orbital debris, but often didn't give the reports administrative attention.

My understanding is that the AGPL is an answer to an older problem and didn't see the cloud coming. It addressed those running web-hosted GPL licensed applications who were side-stepping the viral aspect of the GPL by claiming that they were not "technically" distributing a binary by making the application available on the internet as an executing web app.

The AGPL requires those who create web applications derived from the AGPL (whether they're distributed as binaries or not) to make the code for their web applications available.

The AGPL does not address the cloud-hosting conundrum at all. This conundrum is where a cloud hosting company (e.g. Amazon AWS) can replicate the original author's service offering using the unmodified open source tool (wrapping it and interacting via API at most), and undercut the original author's business model. I.e., you can imagine a power user of some AGPL software competitively putting the software author's company out of business.

This is the reason for the recent licensing restrictions around ElasticSearch and MongoDB. The originating companies have had their hosted service revenue models undercut by Amazon AWS offerings that simply repackaged the software as part of their cloud offering.

Making the AGPL even stronger by adding in a viral API clause would pigeon hole AGPL software to only the most fringe ideological use-cases as everyone would be afraid to run AGPL software in a business context.

I recommend Monaco. It's a great story-based co-op game.

Joined just to respond as I have some experience in this area.

I went from engineer, to engineering manager, to engineering director and had a similar conversation with my boss who is an Exec VP.

It's not clear whether he's responding to how you talk to your team or how you talk to him, or both.

If the latter there a few things to consider. You need to come to your boss with several possible solutions to your problems when you bring your problems to him. Let him advise you and give you ideas you haven't thought of, but he's not going to want to just solve all your problems. He has plenty problems of his own. He hired you to make decisions at a lower level.

You should bounce your instincts off of him and let him course correct you. Tell him how you're approaching solving the underlying causes of problems, not just addressing symptoms.

Be careful what your bring to him and how you talk about your problems. When you say 'fire' to an exec, they think you mean a forest fire, not a camp fire and they'll act with a heavy hand and get upset with you if they end up over reacting. The exec's wagons include artillery and nukes, not small arms. My mentor used to say 'Executive exposure can be good... But you can die from exposure'.

Talk about engineering risk, milestones, long term plans, etc. He wants to know you've considered the risks and have mitigation strategies. He wants to know that you know what things will cost. He wants to know what your effort estimates are. He wants to know that you've done due diligence in procurements and hiring to prove you need what you say you need.

He doesn't want to know who is doing what or what isn't working well, unless you need him to solve the problem with a nuke. If something isn't working, come up with new ideas.

If he's referring to how you address your team, you need to not help people solve their immediate problem by only talking with them about how to address the problem at hand.

You need to talk to them about expectations, habits, and behaviors. You need to have accountability conversations.

I had a training course from the folks that wrote 'Crucial Accountability' in how to have these conversations. It is incredibly effective. I highly recommend this approach.

You need to assess operational execution and develop procedures to improve it rather than just fighting fires. You need to help them be better, correct, rebuild, stay out of trouble in the future.

For operational leadership the book 'The Phoenix Project' really helped me develop a strategy.

A great book for personnel leadership that I used is 'First break all the rules'. It will help you cultivate talent in employees.

Develop a leadership philosophy of your own that you believe in and use it in your conversations with your teams. A great resource is the book 'One Piece of Paper'.

I hope these help.