What tends to happen as you refactor bad code is that you gain some intuition about the way the code needs to flow. The longer you spend grinding away at the existing code, the more likely it is that rewriting it will work, because you'll have pent-up "architectural energy" waiting to be used, and good, already-debugged code from the previous version that can be copied in.
The most likely causation for crossing a threshold from refactor to rewrite, while steering clear of the "big bang rewrite", is that you have to ship a feature that triggers an end-run around some of the existing architecture. So you ship both new architecture and the new feature, and then it works so well that you can deprecate the old one almost immediately, eliminating entire modules that proved redundant.
Edit: And if you don't really know where to start when refactoring, start by inlining more of the code so that it runs straightline and has copy-pasted elements(you can use a comment to note this: "inlined from foo()"). This will surface the biggest redundancies at a minimum of effort.
What your emotions are getting conflicted on is the idea of learning your real limitations. Because, despite appearances of competence and opportunity, you've surely got flaws that would prevent you from doing something someone else would find easy. One of them is manifest right now, in that you're bailing before the commitments get too intense. This happens within youth fairly often, even when no graceful exit is possible and it's the rationally correct decision to stick with a commitment. Other people, already people younger than you, even, have gone and made hugely consequential decisions without thinking twice. Some of them are dead, so maybe you're doing all right.
What an older person tends to figure out is that they are only getting more limited and closer to an end as time goes on, which makes them more motivated to focus on relative strengths and weaknesses. They will exit the situation when it plays to their weaknesses and saps their energy, and stay in and struggle when it fits their strengths and motivations.
It's hard to see, though, what you are doing when you're living it every day. Somehow you ended up on HN. But why HN, and not anywhere else? Do you know how you got here, or why you stay here?
These are things you can pick apart by journaling, collecting data, and trying to challenge your internal narratives. The "why" of what you do never really gets answered(because it's philosophical, hence it never reaches an end), but if you're occupying your time with struggles that you feel are worthwhile to you personally, and not just escaping forever, that's probably a good life.
That statement means we will all be using Web Assembly to manipulate the DOM...and then to do any scripting we will just be writing WASM? What am I missing here?
Real-time video composites were achieved on analog hardware such as Scanimate [0] starting around the 1970's; traditional film matte techniques [1] had also been used for well over a generation by that point and a travelling matte would suffice for compositing that image.
Check the bitcointalk forums. There are lots of altcoin announcement threads. Most are absolute drek and not worth your time, and most of the comments are people deceiving others or themselves by engaging in pumping/bashing. I scanned those a little more when I started, but they're awfully crowded now.
Is there a mining aggregator? I've got a few decent GPUs around, enough to mine a couple hundred bucks worth of, eg Monero a month. I'd love to run a script to automatically jump in on new coins where GPU mining is feasible. Not the most profitable at the moment, but more like speculation. Am I stuck with dredging through news and manually mining each one?
It's not purely the sampling that's doing it to Hollywood: In some fashion, it's the heavily-derisked blockbuster formula to blame, and technology comes along for the ride.
Tony Zhou's Every Frame A Painting [0] offered a take on how the tendency is to work very closely to a temp track and then ask for something identical, which of course can only get you increasingly similar sounds. Dan Golding responded to this by adding some nuance, noting that temp tracks have always been in use, so the answer has to be a little more complicated, and he points back to the technology. [1] I would say that the technology is just a piece of the puzzle; you can order in a different type of sound and get it, whether or not you're using a computer-heavy approach. That's aptly demonstrated by the variety seen in indie games, for example. This is a problem that movies have made for themselves by being focused on fitting everything to a formula. The occasional film does slip through that has a great score that draws on something bigger than other films(for one example: Scott Pilgrim vs the World).
I gave up on Amazon the other day. What did it? The "accidental" signup for Prime. They have a multi-year track record of doing this to people, some of whom can't afford it. I rarely need to get anything from them. So I cancelled both Prime and my account. They are clearly uninterested in keeping up service quality these days.
You may want to try out RapidComposer, Sundog Song Studio, or Odesi to get a sense of what that workflow entails right now. I bought each of those (two of them on sales), hoping I would come to terms with them, but they just don't work for me. It's mix of "the UX could be better", in some cases, but also some underlying consequences for complexity that show up when you're given a blank piano roll and every possible axis of music theory exposed as an affordance in the UI.
What's working for me right now? ChordPulse [0] which contains arranger keyboard style presets, plus a few options for sequencing and detailing the arrangement. Export to MIDI, add melodies and tweaks on top, and the song is ready. There are much more complicated versions of this formula around like Band in a Box, but they both have things I don't need, and aren't quite as good at this basic workflow.
It's only helpful if it adds something to the feedback loop. That's what an organization and its projects need at every stage: healthy feedback. If it's too far into fantasy, it gets forgotten and replaced with something more expedient; if it goes completely unaddressed, the absence manifests as some other failure.
So, early org chart is only useful if it doesn't jump too far ahead of what the business is: If you discover you need a different organization to execute on the plan, there's no point in planning for scaling the existing one out. But if what's being followed is a "hire a great team and great things will happen" kind of plan, then there's no conflict since it just means you've considered both near and long-term aspects of building a great team.
In some respects I think the apparent lack of automation in GUI comes down to the methods by which it's accomplished feeling too crude to take seriously. Even ordinary "power user" apps like Excel are so in-depth already and support so many workflows that it's hard to figure out the efficient path for what you want to do.
The most likely causation for crossing a threshold from refactor to rewrite, while steering clear of the "big bang rewrite", is that you have to ship a feature that triggers an end-run around some of the existing architecture. So you ship both new architecture and the new feature, and then it works so well that you can deprecate the old one almost immediately, eliminating entire modules that proved redundant.
Edit: And if you don't really know where to start when refactoring, start by inlining more of the code so that it runs straightline and has copy-pasted elements(you can use a comment to note this: "inlined from foo()"). This will surface the biggest redundancies at a minimum of effort.