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…
Suppose I wanted to kill a lot of pilots
131–140 of 178 posts
Re: Suppose I wanted to kill a lot of pilots
#132Earlier 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...
Re: Suppose I wanted to kill a lot of pilots
#133Quotes[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
#134Earlier 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.
Re: Suppose I wanted to kill a lot of pilots
#135Earlier 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."
Re: Suppose I wanted to kill a lot of pilots
#136Suppose 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 -…
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
#137That 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
#138Earlier 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.
Re: Suppose I wanted to kill a lot of pilots
#139Earlier 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.
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
#140Earlier 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.
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.