HN user
To the extent that is true, I agree, they should see the positive impact of what they do as well. Your blind faith in the regulatory regime, however, is deeply undeserved. Many approved drugs prove to be dangerous and we can reasonably expect that many effective drugs never make it to market because of bureaucracy.
I understand some people are checking boxes, with no space to consider their impact. Please generously reinterpret my point to extend to their management stack and the political establishment that is responsible for the system.
Those who establish, support and tolerate that system should be as directly exposed to its consequences as practicable. It is good for them to see these stories and feel the consequences of their decisions.
Regulators are, in general, too sheltered and disconnected from the impact of their actions.
Incentives matter. When you get to make decisions that impact others, but not feel any of the costs associated with that, you do not have the correct incentives. I hope the staff of FDA read this and can’t sleep tonight. We can hope they feel some emotional pain, even if it is only some small subset of the pain they have and continue to cause to others.
FDA delenda est.
Counting lines of code, commits, changesets or any other simple metric will destroy your culture.
The team _will_ find out, and then instead of contributing to the success of the business in earnest, they’ll be doing stupid things like maximizing their changesets or racing for “easy” large changes like deleting a module.
It doesn’t matter whether those values do or do not correlate with reality (IMO, if they do, it is for relatively junior engineers only). If you give off the smell of measuring people like that, you will ruin any collaborative team environment and you risk never being able to recover that.
There’s a good chance you’ll chase away excellent engineers with this sort of low-effort metrics management too.
Recruiters at my company aren't explicitly told to hit certain quotas, but they are given larger bonuses for diverse hires and they do have targets for certain percentages of diverse candidate.
I'm definitely not a lawyer and I live nowhere near the Bay Area, but by my reading of most of these laws, this is illegal. I realize we often interpret these issues differently depending on who they effect, but this sounds like an open-and-shut case of discrimination to me.
He almost surely means Compilers: Principles, Techniques, and Tools by Alfred V. Aho, Monica S. Lam, Ravi Sethi, and Jeffrey D. Ullman [1]... or one of the earlier versions of the book with different authors and titles ;-).
As was common for 80s software textbooks, this was nicknamed for the distinctive image on the cover.
But (and now your edit clarifies that this indeed was your point), perhaps your point is just how difficult it would be to automatically disambiguate nicknames in diverse communities like StackExchange.
[1] https://en.wikipedia.org/wiki/Compilers:_Principles,_Techniq...
This article doesn't seem to answer the question. It just asserts, without evidence, that "luxury is about no-nonsense boldness." Why wasn't this true in the past?
The OP did precisely this!
Which platforms don't ban consistent winners?
This is merely a series of opinions in academic article form.
I went ahead and flagged this. It is not HN quality. It is not even Globe and Mail quality.
The other comments have already expressed why that is the case - but in summary, there is no security flaw coherently expressed here, Excel is possibly the right tool for the job (it saves tens of thousands of dollars of custom software development through government acquisition programs) and the editorialism in the title was unnecessary and further hurt the credibility of the "point."
I am generally against often-called "excessive regulation," but the regulator -- perhaps FTC -- should aggressively prohibit the misleading marketing message here.
The entire problem manifests from calling this lane keeping mechanism "Autopilot." Tesla should be prohibited from using that language until they have achieved a provably safer self-driving level 3+.
The problem is exacerbated by Musk's aggressive marketing-driven language. Saying things like we're two years out from full self-driving (first said in 2015) and the driver was warned to put his hands on the steering wheel (15 minutes prior to the crash) makes Musk look like he is plainly the bad guy and attempting to be misleading.
"Provably safe" probably means some sort of acceptance testing -- a blend of NTSB-operated obstacle course (with regression tests and the like) and real world exposure.
If that is the case, why are there only 2000? The conditions must be more complex than that. Unless 2000 is nearly every phone they touched in that time period?
I'm having a hard time speculating about what phones are "encrypted cellphones" by this count. Are they counting iOS devices with a strong passcode or is there some other functionality they're specifically "having trouble" with? I find it hard to believe they're talking about Phantom and specific-application "cryptophones."
Giving him 1 star is part of the "economy" here, he won't be allowed to drive if people don't like this process.
Please write to CIPPIC [0] and the Members of Parliament [1] and Members of the Provincial Leglisation [2] for both your local jurisdiction if appropriate and Halifax, Nova Scotia to help protect this kid. The federal Minister of Justice [3] and Technology [4] may be good additions. Remember what happened last time we let a government go wild on a kid incrementing a number in a public URL.
The fact is, it is the organization who published "personally identifiable information" on the public internet who should be punished - and, in any case, criminal law is not the tool to do it. The kid who incremented a number in a URL to download that information is not the bad guy. What if the kid was not Canadian? Are you going to try to extradite a Russian national over accessing information on a public web server?
When a server announces to the world that it can answer HTTP requests, making a reasonable number of HTTP requests is, to me and most technologists I know, authorization (and thus, should be seen as with colour of right or non-fraudulent). The fact those HTTP requests released data he was apparently not entitled to is a security issue, a bug, a problem to be paid for by the actor who manages the HTTP server, not a problem of law. Unfortunately, this section of law has not been used often enough to clarify to me the interpretation of those words.
Here are some follow on questions:
- Why was there "personal information" in FOI releases? Surely a FOI release was intended for the public, as that is the intent of the act. Who's fault is it that there was undesired information in the releases?
- How do we get this law changed? As the law is written, it hangs on the words "fraudulently and without colour of right" - the rest of the clause is incoherent babble of a 1985 technophobe.
[1] https://www.ourcommons.ca/Parliamentarians/en/members/Andy-F...
[2] https://nslegislature.ca/members
Please keep us informed on the outcome. I have written a letter to my MP and MLA as well as the MP for Halifax.
It turns out administrators could change the email address anyway. :)
`whyever` said _end-to-end_ encrypted, presumably meaning "between the intended recipient and I," not "between a middleman and I."
Of course, you also need to trust your hardware.
So, where did the $50 million come from?
That is a significant amount of money for what has been a handful of people, not taking venture capital, now operating as a nonprofit to "secure communications."
I'm pretty sure CoinMarketCap just updated to include the previous minting issues: http://omnichest.info/lookupadd.aspx?address=3MbYQMMmSkC3AgW...
What is interesting, is it appears that CMC updating the total supply occurred simultaneously with the drop in value. Is CMC data impacting the market independent of the actual supply?
This is what I get out of his writing. He is a great pop-culture writer, expresses some important (and mostly, relatively old, repackaged) ideas about convexity and natural mathematical implications thereof.
He is one of my favorite authors, but I am unconvinced by nearly everything he has to say. He has this cult-leader style of "everyone else is wrong, but here, you can be part of the enlightened group" that I find somewhat grating, but more importantly, he simply does not provide "extraordinary evidence for extraordinary claims."
Almost nothing he asserts is empirically testable due to his reliance on fat tails and Knightian uncertainty, and when it is, it either has not been empirically tested or the entire "traditional" industry is built around the empirical results. His response to this is generally of the form "systemic failures can dominate normal effects." [1]
In the cases where he leans on statistical modelling, especially modelling with fat tails, his writing breaks down. I find his approach at that point to feel sort of "baffle them with bullshit" in the sense that he is indifferent to whether it is even possible for the reader to understand what he is saying, once he has convinced himself.
[1] e.g., https://www.facebook.com/nntaleb/posts/10155509264828375
The linked paper is empirical counterevidence to that theoretical model though.
Admittedly, we can always just say "we're not in the long run," I'm not sure how useful that is.
I'm not certain what model exactly you're talking about, but I think it also probably misses technological change as a real source of growth independent of any monetary musings.
I'm not sure I assumed developers are driven by the same things. A careful reading of my last sentence did not define what it meant for code to be good or by what process you would be proud of the output, I think that is a product for you, your team and leadership to decide. Perhaps my use of the word pride was too strong, the core of my philosophizing there is that software development on a team is a social endeavour and that code review can be a very effective alignment mechanism.
Someone further down the page suggested that the style nitpicks arise from a lack of understanding and familiarity with that piece of the codebase. I think that is often true and a factor to be considered both when allocating code review and when setting expectations regarding code ownership and cross-functional understanding.
I've also provided some suggestions for how to tune down the "95% style nitpicks" elsewhere on this page - it is a problem, but with appropriate tooling and expectation setting, it can be reduced to a small fraction of total code review output. It would be dysfunctional for a team to spend time on that stuff when we've all agreed it isn't high ROI. I agree that code review can be done very poorly, but your observed ratios are not a fixed property of the world of code review.
Let me be clear: I am absolutely not advocating for a process that motivates nerding for the sake of nerding - I push back on a whole wealth of that sort of behavior. I am a business person motivated by producing sustainable teams that produce real value in the form of solutions to problems. I just feel that is a high-dimensional problem and certain kinds of technical debt can come at extreme cost and can, at times, if done correctly, be mitigated with processes like code review.
My teams also assign code review "in addition" to the regular workload, but this is always in the context of an agile team effort: we get done what we get done [1]. A developer takes a story and works on it until it is solved (or splits it appropriately), then another developer (or a few) are expected to do review.
--
[1] I might be measuring productivity with story points in the background, but there is no "scheduled workload," this is merely an averaging/planning exercise.
The (correct, IMO) managerial effort to improve individual productivity is much softer and more understanding than that and comes with the understanding that your output takes many forms. Some of my best developers directly complete almost zero stories in a sprint because their time is spent on code review, pair programming, direct assistance and architecture discussion.
Another thing to add, is that for "obvious" style suggestions (i.e., changes that everyone is nearly certain to agree on, though they might not agree on the importance), I encourage the reviewer to simply make the change.
This is only for stuff like missing whitespace or a typo in a comment. It is not worth the roundtrip to call that stuff out and I've never seen it cause a meaningful conflict on my teams to simply fix it. I've only directly managed teams <10 local people or <5 remote people, I can imagine more structure is necessary on considerably larger or more disconnected teams.
While not a problem I've ever really handled, this approach may have the side-effect of reducing dysfunctional codebase ownership that I've heard about from other team leads.
With some reflection, I think you're correct on the understanding problem.
The problem has always been inconsistent - some code reviews are worth thousands of times more than others - and a determining factor may be how invested the particular reviewer is in that piece of code, how well they understand the surrounding ecosystem and things of that nature.
As a concrete example, it has always been rare that a backend API change PR doesn't get great feedback from the frontend team that is dependent on it. The visibility is a core benefit here and the clear process to collaborate (especially if done early, low cost with individual small changes) is essential to the return on time investment.
For the record, I agree, I think a strong culture of code review is the most valuable process I've added to any development team. In my grandparent post, I was merely drawing attention to a potential spot for improvement, I hope no one took it as against code review as a process.
Con 2 has historically been the biggest problem for me. If any experienced people have good methods to help me mitigate that problem on my teams, I want to hear it.
We've done a few strategies at places I've managed code review:
1. Insist on linting (in Javascript, eslint-config-airbnb) and opinionated style guides/automation (in JS, Prettier), and have the team buy in on "let's just not even debate this and just do what it says."
2. Have programmers highlight problem areas (structural/architectural/clarity) in their own code before submitting the PR. This is draws the discussion to the high ROI locations quickly, while not prohibiting the reviewers from catching more minor issues.
3. Clearly indicate that the goal of code review is to, yes, impart style and feel on the rest of the team, but largely to avoid duplication, resolve bugs and improve everyone's skill. It is a within-team visibility and knowledge sharing process that also happens to catch meaningful defects.
Have you ever actually been constrained in how much time you can spend on code review?
I generally try to get my developers to spend more time on it than they think is necessary -- if it comes at the short-term pains of their productivity, I am totally ok with that and will work to revise their individual contributor expectations.
I've read this and similar posts on this study a dozen times in the last few weeks. I think the data is poorly interpreted and what you're really seeing is that shorter pull requests elicit better feedback (in this case "more defects per line").
In my experience running code reviews, shorter pull requests, presumably due to their reduced effort necessary to understand, tend to get better review, review that is more than just superficial style/linting errors.
In light of that, I always encourage developers to aim for the shortest reasonable changeset - and make it very clear to them that 2 line PRs are totally acceptable - on my current team, we go as far as to encourage tricks like rewriting (local) Git history and cherrypicking to ensure that is the case. Continuous integration and good unit tests help to ensure that strange states generated from that process are still good and I find the costs are far outweighed by the better reviews.
Another little lesson I've learned managing that process is to encourage the submitting developer to highlight problem areas in his own code: when I submit my own code for review, I'll actually do the review first, line-level highlighting areas I wish the reviewer to pay attention to. This will only work if you can trust your developers to not try to "sneak something by," but if you can't do that, you've probably already lost. Developers generally know what they weren't sure about during the process, where things are going to be difficult to understand and where someone else on the team is going to have helpful contributions to the quality.
I think it is important for developer-managers to remember that programming is largely a craft and developers largely want to be proud of their output. People _like_ producing "good code" and it is easy to align the goals by having the process help improve their craft.