roosterdawn

The Tim Bray blog post, while well written and respectable, was still in my mind contentious and arguable. I unfortunately can't make that same call here. It's taken me a while to realize this, but I have begun to filter out reading thoughts that aren't fully formed, and I think this is one of them.

The author brings up the Nuremberg defense[1] as an example of complicity which is indefensible, but this is rhetorically quite hollow. If you go a little bit further into political theory and consider Arendt's conception of the banality of evil[2], and furthermore the idea of a panopticon[3], you very quickly come to the philosophical impasse between individual culpability and agency and systematic mechanisms and the political.

What is this impasse? Plainly, I think it is that the individual has nearly zero agency alone, and only has power when effectively organizing into groups. That makes arguments like these functionally useless (or even "usefully idiotic"[5]), because they fundamentally misattribute the locus of value production, capture of capital and political clout onto the individual, in what Marx would call the petite bourgeoisie[4].

This misattribution misses the asymmetric distribution of power towards the top of organizational hierarchies, especially within the size of large mega-corporations. If this author were correct and engineers were truly accountable for the work of their employers, what is the unique labor that managers and executives contribute to the corporation that ICs do not provide? And who has the power to make and override decisions at a corporate policy level? It's transparently obvious that corporations are intentionally set up divide labor such that decision making agency is allocated towards executive leadership and management, and that line level ICs serve to execute on those decisions but do not have the agency to veto decisions they disagree with.

This is obvious to anyone who has ever worked at a mega-corporation, enough so that I wonder if the author has. If they have not, then the post amounts merely to speculation about something the author doesn't have enough firsthand experience with to credibly analyze. That doesn't mean it should have never been written, but I certainly got no value from it.

[1] https://en.wikipedia.org/wiki/Superior_orders

[2] https://en.wikipedia.org/wiki/Eichmann_in_Jerusalem#The_bana...

[3] https://en.wikipedia.org/wiki/Panopticon#Criticism_and_use_a...

[4]https://en.wikipedia.org/wiki/Petite_bourgeoisie

[5]https://en.wikipedia.org/wiki/Useful_idiot

To backproject the causation of popularity of a given ecosystem and language towards cultural relativism and sociological in-groups rather than pragmatics just seems like a post-hoc rationalization. But, to take your comment in good faith (I don't want to dismiss it) I wonder if there really are generational dynamics at play here.

Earlier on, software engineering wasn't as glamorous as it is today, from either a material or cultural standpoint. I even recall a staggering difference now versus twenty years ago, when I first got into it, which even then was right before the bust of the first dot com bubble. While ostensibly by that point, the field of software engineering as a creative pursuit and an intellectual space had already thoroughly lost its pioneer spirit to the metaphorical urban and suburban "gentrifiers", there's no denying that the field itself continued to grow, and even at that point is a small fraction of what it is today. If software has truly eaten the world, isn't it possible that the languages and ecosystem that survived and reached dominance outcompeted the other ones?

That is to say, what makes you believe that another language is more fit to be in the position where Python is? While I will use whatever language is necessitated by the job (and have never had issues doing that) and even prefer the aesthetics and "handling" of Ruby and modern JS, Python is still the tool I reach for most often when I need to get some general purpose scripting or systems design task done. The ease with which I can go from zero to prototype and prototype to production and production to pain-free maintenance is unparalleled. The only two ecosystems that are remotely close are JavaScript and Java, and ostensibly Rails for web dev. Nothing else is competitive.

What would make you dispute this?

Right, that's the other side of the equation that needs to be fielded beyond a certain size in organizational scale. Organizational processes need to be in place that protect the organization from bad actors, in a manner which is most resistant to being corrupted. As you say, even a few parts per million is essentially enough to get a large scale PR headache.

With that said, the question of whether the system could improved (and significantly, in a step-wise manner) how it handled this situation remains an open question to me. I don't know well enough what happened in the cases that caused Tim Bray to resign to comment, but it's possible that actions taken by the corporate management, HR and legal have taken backfired in a way that will be looked at as unforced errors. At a company (ostensibly THE company) that prides itself on operational excellence, I'd be surprised if this doesn't end up being the case. High profile resignations like this are sometimes the spark that sets the whole process in motion and the few externally visible signs that you can see later on as evidence. If this was attrition was truly regretted by corporate, and was something that could be prevented ahead of time, it will have been a very expensive black eye, waste of resources and loss of true executive leadership talent. For folks like Tim Bray, the difficulty of filling the organizational void they leave is very high, and potentially not guaranteed.

I guess time will tell.

This is one of the few voices of sanity I've seen on this thread. Your father seems wise.

With that said, I do understand why companies try and install panoptical surveillance practices in places where it's basically overkill. Competent managers, as you said, don't need to keep people on a tight leash. They do, as you said, learn to analyze the noise and intervene when something is clearly going wrong. The panopticon is put in place beyond a certain size because manager quality cannot be guaranteed. Now, whether that's a sound reason for its existence or not can be debated (I'd tend to agree it's not), but it does seem to function efficiently.

It is vindictive. When non-vindictive measures failure, the measure of last resort sadly tends to be the vindictive one. I don't know if this was part of your point (I imagine it was), but the vengeful carcerality of vindictive justice is independent from meaningful structural change that would prevent bad actors from repeating similar actions in the future. Everyone performs their role feigning outrage, repentance, regret and reconciliation, until the same thing happens all over again.

I would be surprised if that did not happen here. The collusion between credit bureaus, banks and lenders is well known for its issues to consumers, but without consequences for adverse consequences to them, business will continue as usual. Will it be savvy fraudsters who place backpressure on the crumbling ability of credit bureaus to prescreen for credit-worthiness? Will upstart incumbents see high margin, low fitness targets ripe for disruption? Will corporate raiders see ossifying remains just ripe enough to be scavenged? Even if all answers to these questions were in the affirmative, I don't know if any of that would lead to immediate change. But, I'd be surprised if business continued as usual forever. The bar for a step function level improvement is quite low, if you could somehow retrofit a better way to pull credit into legacy underwriting processes.

Source: Early stage engineer and prior executive at $PREVIOUS_FIRMS that included two growth stage consumer lending startups.

Yes, it probably would be a valuable to Amazon. So valuable, in fact, that it already[1] exists.

[1]https://flex.amazon.com/

But is max-pos - cur-pos better to read than maxPos - minPos or max_pos - cur_pos? I would say no to both cases.

The last time I checked, Zoom was a publicly traded company. Of course, this doesn't invalidate your second point due to the existence of large institutional public investors.

`kebab-case` isn't perfect. It works just fine in a prefix notated language such as LISP, but less so in an infix language. I suppose you could require significant whitespace to differentiate `a-b` from `a - b`, but even that is a little counterintuitive to read. `snake_case` is popular in both Python and Ruby, and canonical in the former. Moreover, it's canonical in SQL. Frankly, even though I like the idea of kebab casing, without the ecosystem around it changing, I have historically just apathetically accepted camelCase and snake_case, and despite being a Python lover at my core, I've gravitated more and more to camelCase as time has gone on because I definitely do find capitalization easier to parse than hyphens or underscores. I like it for the same reason I like significant whitespace. Yes, it's more painful to parse and design a language around, but it's that much closer to pseudocode.

For what it's worth, I think this is why kebab-case originally became popular in lisp-land. We used it significantly in our JS style guide at $PREVIOUS_FIRM.

After using `ember` and the wonderful `ember_data` at $PREVIOUS_FIRM, I wholeheartedly agree. React is good for what it's good for, but the community sadly did not stop there.

This is a great question. To me, the only answer is (as I believe you're alluding to) "who" is at fault is not relevant when compared to "what" is at fault. In this case, the problem is the lack of proper systems level integration testing, and neither Alice's nor Bob's code in isolation, and the "who" that ends up being at fault should be the management chain of command that allowed the state of things to allow such a scenario to occur. As management decides to want to prevent such embarrassing and costly blunders, they should resolve to invest more in the process and tooling that prevents such situations from being possible.

Of course, it is also possible for management to shirk such responsibility and push that responsibility (without corresponding process ownership) onto the ICs. It's quite common in low performing organizations.

Why doesn't your team have a process (integration tests, etc) that makes it impossible to check in something like `input_array[0]` without breaking a build? Why is it allowed to directly push to master?

How does the old saying go? The road to where is paved with good intentions? You could engage in moralizing against "carelessness" and "neglect" and presuming that a teammate somehow cares more about watching Netflix than doing their job (which they presumably outperformed other candidates to even get), and maybe that will make you feel better. You are the good, careful, model employee, and that other one -- they're careless, slovenly, apathetic and lazy. But if that's the case, how did they get past the door in the interview process? If the whole company is like that, why do you work there as opposed to a company where the bar is higher? Something does not add up. In all likelihood, your explanation is a rationalization and not the most obvious answer, which is that your process could be improved but it hasn't been because such investments are not viewed by your companies executives as improving the long term bottom line to be worth the short term investment cost.

Take a look at history and figure out how companies in the industry have solved this problem before by building more bulletproof runbooks, processes and tools. These companies, as they approach enormous scale, necessarily have to determine how to deal with employee reversion to mean. It turns out, surprisingly, that process eats good intentions and care for breakfast. You'd be surprised at how quickly those good intentions become useless if your company is successful and you hit hypergrowth and scale. It's ironic that for a profession where it is so tractable to automate away mundane or repetitive tasks, where we study spacetime complexity in data structures and algorithms, that we have so many practitioners that default to witch hunting and moralizing and seem unable to apply spacetime complexity or procedural analysis to their own software development lifecycle. I expect to see this trend change as our still young industry continues to mature.

I'm not sure this was your intention, but you have just described how folks are supposed to do postmortem and retrospectives at most agile shops, as well as how Toyota created the kanban process and implemented the andon cord. It's strange and probably not useful if it's based around assigning guilt. But if it's based around trying to uncover a root cause in process or system deficiency and solving that, then no, it doesn't seem strange to me.

You can modify your code to use the API correctly, but if your team doesn't get the documentation fixed or the test environment to sync back up with the production API, your team is not solving the issue.

Your code can cause headache for everyone after runs in production for a month, but unless your team begins to do code review, you're not solving the issue.

In a very literal sense, the idea of the team finding an issue and resolving it (apology or not) is extremely important and one of the few ways for an organization to improve rather than decay over time. The apology is almost a formality.

For what it's worth, this intuition is sound and I think it works just as well if you formalize[1] it to be used to illustrate the lambda calculus.

[1] http://dkeenan.com/Lambda/

What you're saying is that it's worth it to lie because it's too expensive to give a truthful answer. That is something that your customers likely would not agree with.

This issue comes up a lot. As a sibling comment says, if it is so common an occurrence for the character limit to lead to misleading headlines because they were overly condensed, you may want to consider slightly expanding the headline length limit (perhaps to 120-140). But I appreciate that it's a balancing act, because making it too long dilutes the punchiness of the HN front page itself. No easy answer here.

Wow, very cool idea. While obviously this wouldn't be a substitute for lab grade testing, what makes me excited is that it could make sense as something folks produce for themselves as a precursor to getting a proper test done.

I don't know whether a smaller change means necessarily a lower probability of small blast radius, but the larger a code change is the higher the probability is of a high blast radius. Blast radius isn't necessarily going to be smaller because of change size, but the chance of it being smaller certainly does decrease in relative terms as it becomes smaller even if it never reaches zero and is still in absolute terms quite high. It's still a noticeable improvement and because of that still a worthy goal to pursue, nevermind the ancillary improvements to product/design/engineering/business coordination and delivery volume as a result of lower iteration cycle time. That's the larger win for me.

Even if it doesn't work over the whole visible spectrum, is there any way that this could be used in some way that is sort of like an inverse ink jet printer where half-toning is used with a couple basis wavelengths to simulate the whole color spectrum? Am I basically just describing something similar to an LED screen but in lens form?

This is fascinating and something I've wondered about. It'd make for an interesting study, and actually, I wonder if you know about any research that has been done on this subject. I'd be curious to know if the data backs up the intuition!

YMMV with amphetamines -- they seem very specific-body-metabolism specific, but you'll always be fighting your body's attempt to move to homeostasis which means it will be very probable that you'll run into tolerance, diminishing returns, side effects, and so on.

As far as sleep deprivation goes: it's fascinating what happens to our brains at night. Studies show that REM sleep prunes and maintains new synapses associated with development and learning[0], but other studies show that this effect might be amplified with sleep deprivation[1]. If intermittent fasting can cause one's body to behave differently in a fasted state, perhaps intermittent sleep deprivation could cause effects that in moderation are not wholly negative? I really don't know, but anecdotally, I've noticed myself able to sometimes get some huge breakthroughs in the late night hours. This has been happening less frequently as I age and become more proficient at a lot of things I do, though.

At first blush, this looks like new lipstick on the old pig of the venture studio. The issue with venture studios is the same as with corporate "intrapreneurship" -- lower rewards and lower risks. Savvier founders will be more capable of either hiring the right talent and upselling equity, or having access to enough cash to hire the right talent outright. Consultants won't mind additional free leads, but good ones will do just fine without. So, the unit economics just don't work out as well for savvy founders or consultants, so you end up creating a market for lemons.

The problem with this model is that consultants will want to be paid in liquid cash, companies will want to pay in illiquid equity, and someone would have to step into the middle and establish valuations and liquidity. This is the bigger problem with the increasing illiquidity associated with VC funded startups. Savvier would-be employees or consultants risk adjusting shares even further towards the direction of worthlessness and insisting on cash.

With that said, perhaps the main silver lining I see here is of VCs playing a role in creating some kind of liquidity for shares. By establishing a three party transaction like this pegging exchange rates between hours of labor, shares and dollars, they're setting at least a stated valuation that allows companies to pay with either shares or cash to prospective employees and service providers, with the risk underwritten by the VC.