Live data from Hacker News

Suppose I wanted to kill a lot of pilots

historyofyesterday.com

131–140 of 178 posts

Re: Suppose I wanted to kill a lot of pilots

#131
post #102
post #92

Earlier quoted context omitted.

I just deployed something worldwide that took about six weeks to develop and our initial guess was about two weeks, so this is fresh in my mind. I was able to lay out a list of work items at the beginning that stayed like 80% the same from the beginning to the end, but didn't account for the possibility that each one of these could be push-button, or could lead to a blocking problem that needed a day or two of resear…

The best framing I've heard for this problem is: minimum time for each component is bounded, maximum time is unbounded. I.e. there is effectively no answer to the question "If this component becomes a problem, what is the maximum amount of time it could take to solve it with the resources available?" Ergo, in the worst case, any given single component's ballooning time can dominate the overall project schedule. Which…

One interesting thing to also account for is the correlation between activities regarding cost or schedule impacts. Meaning the uncertainty analysis should also account for systemic effects where a ballooning of one item’s will also cause another item’s schedule to increase by some correlated amount

Re: Suppose I wanted to kill a lot of pilots

#132
post #90

Earlier quoted context omitted.

> React uses a virtual DOM to avoid DOM unnecessary manipulation, which is slow and error prone. While it may be the case that DOM is far from perfect, React is hardly the only way to avoid it. Even if for your use case avoiding DOM manipulation is necessary (which I strongly suspect is not true for like 95% of people who use React as the framework du jour), there seem to be significantly better thought out approache…

Avoiding direct DOM manipulation is a benefit in almost any case. Virtual DOM is now at the root of most popular UI frameworks libraries, including Vuejs and Angular, also less popular WASM ones like Blazor(C#) or Percy (Rust). I do remember writing complex JQuery components. React felt like a liberation for me...

But because JQuery was bad doesn't mean that React was the answer. That would be a false dichotomy to make.

Re: Suppose I wanted to kill a lot of pilots

#133
Lots of parallels to "know your enemy", if you're willing to broaden "enemy" to include the impersonal.

Quotes[1]:

> It is said that if you know your enemies and know yourself, you will not be imperiled in a hundred battles; if you do not know your enemies but do know yourself, you will win one and lose one; if you do not know your enemies nor yourself, you will be imperiled in every single battle.

and

> Thus, what is of supreme importance in war is to attack the enemy's strategy.

The part about both knowing yourself and knowing your enemy is similar to the idea of iterating back and forth between thinking about how to fail and how to succeed. The universe is not actually out to get you, but you can ask what its "strategy" would be if it were.

---

[1] see https://en.wikiquote.org/wiki/Sun_Tzu#Chapter_III_%C2%B7_Str...

Re: Suppose I wanted to kill a lot of pilots

#134
post #120

Earlier quoted context omitted.

Spot on. They used to call me 'Dr. No' because that is exactly what I would do, but it saved us tons of money so it was tolerated. We also actually delivered on time and within the budget but I'm sure it cost us contracts to more optimistic competitors.

My inner nihilist thinks the more "optimistic" competitors might be making more money.

It can depend on accountability mechanisms. I would like to see more contracts that give bonuses to companies that come in under budget and under schedule and penalize the overly optimistic ones that never seem to hit their target. This is becoming more common in some domains.

Re: Suppose I wanted to kill a lot of pilots

#135

Earlier quoted context omitted.

Spot on. They used to call me 'Dr. No' because that is exactly what I would do, but it saved us tons of money so it was tolerated. We also actually delivered on time and within the budget but I'm sure it cost us contracts to more optimistic competitors.

This. Most engineers delude themselves and plan for the happy path. I was famous too for "being negative." In the planning of a complex project once a rather dull engineer, after I had just pointed out a major potential problem asked, "Why are you so negative?" "I'm not negative, I'm planning for success."

My approach was to allocate 2 weeks for even the most basic things because unknowns always creep in and a tighter schedule tends to make those things creep in even more. Also, many of the requests had no particular urgency to begin with.

Re: Suppose I wanted to kill a lot of pilots

#136
post #25

Suppose I wanted to make a program inscrutable, hard to modify, hard to test, heavily coupled, and hard to reason about: - hide information so that it's not queryable - force information to flow through multiple hops - make it hard/impossible to set the true state of the system in its entirety - allow state to be mutated silently - give interfaces roles and force certain state to have to flow through specific paths -…

> The latter kind of feels like a criticism of FP

It may feel like that for somebody with little experience with FP, but half of those points are design decisions that aren't changed by the language paradigm, and most of the rest is a non-sequitur where the stated problems aren't caused by the characteristic that precedes them.

Immutability makes chaching easier, not harder, the same for propagating by reference. Besides, there's nothing on FP that asks for more IO operations or distributing your software. The item about larger data structures is on point, although the indirection is very often optimized away on practice, while imperative programmers often have to create their own indirection by hand, that the compilers have a harder time to put away.

Anyway, most of both lists apply perfectly to the modern "mandated microservices" architecture some place use, that I think was your point.

Re: Suppose I wanted to kill a lot of pilots

#137
First, a tangent. I've noticed recently that a number of websites aren't letting me do old-school copy-to-clipboard. They're hooking highlight events and only allowing copy according to their own method (e.g., Twitter or whatever). ScriptSafe causes them to hide the article completely. I've found that the "Absolute Enable Right Click & Copy" Firefox extension works with the article for this post, but there may be other extensions that unbreak copy-to-clipboard.

That said, from the article:

> Prioritize near-term income over long-term value.

In terms of one's career, I'm not sure what the author has in mind. I've found that, in the long run, work experience is work experience, and your skill in interviewing plays an outsized role in your future career prospects. If you're getting paid a lot of money to do something, that generally means there's going to be competition for your job, and it's noteworthy that you're the one who got it!

I'm sure there are some exceptions (and in my experience people on social media Internet forums like this one love to point them out), but I'd argue those exceptions are mostly outliers.

In addition, high income early in your career means you can start accruing compound interest earlier. Disproportionate quantities of money in an index ETF in your early 20's is a very, very powerful force function for your entire life. Play your cards right, and you can FIRE by your early-to-mid-30's, at which point you can pursue any work you want without the stress of needing to care about performance reviews, layoffs, toxic work environments, etc., etc., since you can always walk away. Even if you don't end up walking away, simply knowing you can easily walk away can have a significant impact on your overall quality of life.

Of course this can be easier said than done. I spent most of my 20's hardly paying any attention at all to what I was paid, focusing my efforts on the type of work I was doing and my education, and the company I worked for (a faceless Big Tech entity) was more than happy to take advantage of me. I had to spend my 30's catching up on savings. If I could rewind the clock and do it again, I'd aggressively hone my interview skills and spend a lot more time negotiating comp with a lot more companies once I had a year of two of professional experience on my resume.

I guess what I'm trying to say is that if you are fiscally responsible and invest wisely, short-term income can be a form of long-term value.

Re: Suppose I wanted to kill a lot of pilots

#138
post #134
post #120

Earlier quoted context omitted.

My inner nihilist thinks the more "optimistic" competitors might be making more money.

It can depend on accountability mechanisms. I would like to see more contracts that give bonuses to companies that come in under budget and under schedule and penalize the overly optimistic ones that never seem to hit their target. This is becoming more common in some domains.

What domains is it becoming more common in, in your experience?

Re: Suppose I wanted to kill a lot of pilots

#139
post #130

Earlier quoted context omitted.

Interpreters are considered elegant, too. For example, Lua is a great little language and it runs everywhere precisely because it's interpreted.

Sure, there are many elegant interpreters. I'm not sure that patching DOM from the changes in a redundant data structure is one of them. Even Blink's idea to instead pull browser's own DOM into Javascript definitely looks saner to me.

It's not a redundant data structure if you need it to figure out the necessary changes.

You are free to choose other approaches for your frontend projects. Just don't expect to get hired into larger teams easily.

Re: Suppose I wanted to kill a lot of pilots

#140
post #130

Earlier quoted context omitted.

Sure, there are many elegant interpreters. I'm not sure that patching DOM from the changes in a redundant data structure is one of them. Even Blink's idea to instead pull browser's own DOM into Javascript definitely looks saner to me.

It's not a redundant data structure if you need it to figure out the necessary changes. You are free to choose other approaches for your frontend projects. Just don't expect to get hired into larger teams easily.

> It's not a redundant data structure if you need it to figure out the necessary changes.

And why exactly can't you "figure out the necessary changes" without it?

> Just don't expect to get hired into larger teams easily.

Honestly, I see that as a win-win.

Post reply on HN