97 karma · joined October 4, 2017
So people trying to solve these problems better focus on root causes rather than exciting technical problems which do not change the rules of the game anyway, unfortunately.
And yes, mainly it has to do with the problem that tech people aiming for decentralization are yet to accept that this isn't a tech problem, but economic/incentive problem.
I seriously disagree on this (our company is facing similar challenges, and I've asked these question myself numerous times). It's not better, it's much worse.
"Some crypto" creates illusion of security, where you don't really know has it failed or not - frequently, there is no functional failure in cryptographic failure. It doesn't stop working, it stops providing the very guarantees you're using it for.
> However, we think that not playing is taking the easy way out, so even though the game is 'rigged' against us, we have a great team of engineers who have decided to play anyways.
Truly so, but you need to play better then ;) Godspeed!
If you think of it for a second, web crypto (protection against intermediaries and dishonest server) actually requires trusting the server, so no encryption-derived claims are sound if the server is dishonest. Any third party exploiting (or forcing legally) the server can make it dishonest and collect required keys in few simple steps. And, FWIW, if encryption is controlled by browser, adversary compromising the client itself can simply disable it.
So, while the effort is very important (and I bet they'd be around the first people who will suggest techniques for safe in-browser crypto execution), it isn't that they can be compared security-wise other than: - ethics - security policy - competence of security teams.
Isn't a level playing field for ProtonMail.
And, my final problem is, 99% of people are still outside Protonmail anyway, hence the intolerant winner argument, which ruined PGP and will ruin many optional security systems on top of convenience protocols in the foreseeable future.
It's literally the biggest leadership failure when non-managers get elected to management positions - failure to coach them by senior managers, and ends to torture for everyone. People don't get to deadlift 500lbs after lifting 20lbs for previous 10 years just because someone decided they can do it.
Point 1. Good engineer should know how to code, and how to cooperate with fellow engineers well. This means healthy balance of "hard" (engineering) and "soft" (communication) skills. When engineer becomes tech lead or engineering manager, being able to communicate, understand other people's behavior, lead them, communicate situation up and down the chain,- soft skills start to matter way more. If there are serious skill gaps in soft skills (and all ex-engineers have ones when they start to grow in this area), addressing them is more important for engineering manager's career than addressing lack of up-to-date-ness in latest technology.
Point 1, Example: when I first got to manage a small team, me not understanding power distribution between younger and more experienced engineers (I came from latter category) led to mass extinction of juniors: the way important decisions were made (with more contribution from senior engineers) was good for the company, but the way it was presented (We The Elders Made Crucial Decision) pissed youngsters off, made them feel incapable of making valuable contributions and they quickly left. After understanding the reason (which took hours of mentoring from CTO, a very experienced manager), I had to really work hard on creating the atmosphere where, even when the decisions were made by seniors, the ownership and responsibility for actual implementation of these decisions was distributed among the teams and everybody could contribute to mutual success.
Point 2, with examples already: It kinda continues point 1, but bridges from personal scale to team scale. Process is as good as it's bottleneck. Team is as fast/writes as quality code, as it's weakest members. If you tolerate them, they constrain the process. Your goal is to spot weaker people / weaker engineering decisions and put reasonable amount of effort to either make them better or make them live. As an engineering manager (e.g. manager that comes from engineering, not from fancy MBA factory), you actually can tell the slacker from person who wasn't properly integrated into the process. As an engineering manager, you can tell that the decision to make blocking tests stop CI on the first failure is a poor decision and having a proper failure log of all tests is crucial for speed of bug fixes, not fixing them faster or with better method. Basically you are responsible for the failure (even if you're formally not), because you're the focal point of knowledge and power that can prevent them, put slower people to speed, put processes to full power.
Think for a second: why can't you produce a better working text editor that people actually use, if all current ones are produced on inefficient technologies by subpar engineers with impaired judgment that led them to current choice of techniques? What are the real barriers to do that?
As an executive who elected senior engineers into engineering managers three time in different companies, there are three challenging areas for even the most fit for the job engineers:
- understanding that soft skills and understanding company politics now matter not as much, but more than detailed technical skills. focusing on eliminating weaknesses in this area is that pareto-ean 20% of effort that makes the rest 10x easier. - it's now about eliminating weaknesses, not growing strengths: what you tolerate slows down and makes everything toxic, while what you preach is a second-order problem for a while. it evens out, and later on you can focus on growing strengths, but only after a while. - you own consistency of engineering culture, not your piece of code and responsibility, now. which makes figuring out internal feeling of "I'm doing it right" twice as hard.
When feeling like the rest of the world is running in a direction of utter madness, it makes sense to re-read "Worse is better" [1] once in a while. However, I agree, DT and GIL aren't helping anything but writing poor code faster and blinder.