Is the opposite also maybe true? Allowing someone who has contributed so little to the team to have an equal share in the company may make people feel like their comparative effort isn’t recognized.
I think you maybe getting ahead of yourself. It’s one thing for AI to produce art that roughly aligns with a prompt, which is as you well know right now what it is capable of. It’s another to fulfill the exact vision of what a person wants. That requires a much higher level and more detailed and more intuitive understanding of what the expectations are and what the vision of the director is. AI is not capable of that level of understanding yet, as far as I know. I suspect it might turn out like the issues we are encountering with self-driving. Autonomous vehicles may be able to deal with 99% of all driving situations right now but that last 1% is the killer. That last 1% is the reason self-driving isn’t good enough. Furthermore, while the first 99% may have taken only 20% of the total time to adoption to solve, I suspect that last 1% may take the remaining 80% before self-driving gains widespread adoption. Just as it could be many years before we can fully rely on self-driving technology to cart us around, it could be many years before AI really starts to supplant human artists, before prompt engineering becomes enough of a precise art to no longer need people who can exactly translate a vision into a visual work.
Of course, feel free to print out this comment, hang it on the wall and throw darts at it in a much fewer number of years when my prediction turns out to be totally wrong. It's really just based on an intuition.
If we're going to go for 128- why not just go for 256-? that way we won't have to do this again for a while.
or better yet, design a new abstraction for not having to hard-code the limit of the pointer size but instead allow it to be extensible as more addressable space becomes a reality, instead of having to transition over and over. is this even possible? if it is, shouldn't we head in that direction?
'In other words, chess engines have redefined creativity in chess, leading to a situation where the game’s top players can no longer get away with simply playing the strongest chess they can, but must also engage in subterfuge, misdirection, and other psychological techniques.' - this sentence doesn't follow from the premise and discredits the whole article. Author thinks training with a chess engine means that players must engage in deceptive playing tactics. This is not even true in the slightest. Players use chess engines to learn how to act in more situations. They must still recognize the position, and compute the move themselves. The computer just adds to the library of experiences they can draw upon for deciding the move.
I think the takeaway is "a year." Businesses typically don't have a year to fix something like this, so saying something will take a year usually means, "It's impossible."
Indeed, this is precisely what makes getting it right up front so important. As mentioned above, the data model tends to proliferate across anything that interacts with it. The principles of normalization mean that there is usually one natural way to interact with a given conceptual entity, given current and potential future requirements, but thousands of ways to box yourself in. Getting it wrong can mean the wrong assumptions about the data shape propagate across thousands of lines of code, preventing the possibility of ever implementing certain features in a clean, maintainable way.
Right, but in the constraints of a business, "more iterations" may (and probably does mean) "impossible." Second, the iterations to fix the problem block all your iterations to add new functionality - because the data model is foundational for everything else.
When designing a complex system with multiple business modules and multiple services, correctness becomes a little more binary than that. Your data model tends to proliferate across anything that interacts with it - fixing it may require a complete refactor of all of those modules and all of those services. Throw in a process that is constrained by pesky things like needing to preserve WLB, limited surge capacity, and competing priorities, as well as varying levels of experience on your team, this rewrite can potentially take multiple years and require the maintenance of two parallel systems, and yet it must occur because the data model is foundational for everything else. Continuing to build on the wrong data model will keep boxing you in further until it's too late to ever fix it, with every new feature forcing you to fight with a fundamental flaw of your system. The resulting workarounds and hacks will slowly strangle your business logic until it's too complex to change with any confidence. It's kind of like building a house on top of quicksand.
When faced with such constraints, it's really, really important to get this right from the beginning.
Perfectionism is a pitfall, but agile development has led a lot of developers to prize velocity over correctness. Many seem to believe that any upfront mistake can be fixed through iteration. The truth is that there are things that you can't fix through iteration. Things like having an incorrect data model. Some things need to be perfect up front or you will quickly find yourself boxed in down the road as you try to extend the system.
Once you've gotten the right design at the center of your system, understanding not only the current requirements but also likely future requirements as well, scrum away. It's just not OK to blow the "big picture" decisions that you need to do in order to build a piece of software the right way because you want to move fast.
I've thought about this issue so very many times, and I feel that until someone creates a system capable of understanding the underlying purpose of the code, we will not be able to automate this stuff away. I think the issue is that all of the things the author wants a breakthrough for is exactly what makes programming hard. We don't have systems intelligent enough to reason about a contract between two systems so as to create a general-purpose solution for things like glue code. The subtle differences that are there and that require us to do this work over and over again with small variations are precisely why programming requires intelligence.
Interesting that they claim HBO Max tech stack to be buggy. I’ve never had a problem with streaming anything and indeed have encountered more problems with platforms you’d think would have a better handle on the complexity of it - particularly Netflix.
And the tradeoffs did not make sense. This was a simple case of bad normalization - a missed many to one relationship. It just so happens that it happened to be a relationship at the center of a very large platform, and is baked through many services. And without fixing it early-ish, we'd be fighting the schema for the next 10 - 20 years and creating unmanageable complexity in the process, all the while making it harder for ourselves to eventually fix it.
So I'm just pointing out something factual. Sometimes making sure something doesn't happen again means calling a spade a spade. If that means pointing out a mistake, then we absolutely should.
Data structures being badly designed is a perfectly valid and common blocker. That is why we try to design things correctly, after all - to avoid blocking future engineers when they try to change the system. Badly designed data structures can make a system impossible to extend. Regardless of who is to blame, we need to call such things out so that people actually pay attention to data design in the future, and avoid things that are extremely costly but necessary to fix. So I'd say it is productive to point it out.
When I've gotten stuck it's usually because the previous engineer completely screwed up the data structure design and in doing so made it impossible to change. This boxes me in because I can't implement the feature in an architecturally sound way without a significant refactor.
This is part of why I think a ban on humanoid and even animal-like robots should be considered. Our intuitions are leading us astray here and we are going to start extending rights to things that don’t have subjective experience, but may insist to us that they do. It’s going to create intense confusion and an extremely inefficient bureaucracy that will stifle innovation.
Yes, and that middle ground is the public blockchain. The transactions are visible but the identities of the endpoints are not. That leaves discovery of those identities up to the investigatory bodies following due process, whether through forensic blockchain or other methods. The blockchain is public but anonymous.
CNN+ is the ill-fated streaming subscription news service of CNN. According to CNN, CNN+ failed because of the merger between WarnerMedia, CNN's parent company, and Discovery, and not because of low viewership. The purported reason for the shut down was that CNN+ does not align with Discovery's streaming strategy, because Discovery wants to have bundled streaming services with multiple offerings for its brands, versus a dedicated niche streaming service for each brand. [1]
Is this the real explanation or was it low viewership / subscriptions? I have no idea. It seems odd that they would shut down the service instead of simply folding it in to whatever successor services took its place, which wouldn't have such a terrible narrative around it.
On my first day at my current company several years ago I was told to refactor something that was very poorly designed and written by the tech lead who had written it. The code was impossible to work with and it took months to add the features they wanted, both because the PR process demanded small deployable PRs and because I had to avoid breaking the thing while working on it. Because I was new and because the tech lead I was working under had written the terrible code I was working on, I didn’t immediately say ‘This code is awful and the entire thing needs to be rewritten, both backend and front end.’ Instead I attempted to introduce right patterns to the data shape, etc. Suffice it to say the code was even worse and less maintainable at the end, only now I was taking the blame for it being that way because now my name was all over the git history.
It was eventually rewritten anyway by another team. Suffice it to say, DO NOT touch code if it is designed in such a way as to be impossible to change. Throw it back up the chain and say , This needs to be rewritten, now. The consequences will be worse for you if you try to work around other people’s bad architecture as you will eventually be blamed for both the original mess and whatever you did to work around it given whatever condtraints on process you have.
Years later. I am fixing another massive architecture mistake by the same engineer, who has since been promoted to higher levels. Over a year in, another data design mistake at a fundamental level that makes the system impossible to change without a huge refactor.
Sigh.
Throw people under the bus if necessary. Don’t accept ownership of code that sucks.
While I agree that many of these items are way easier than before, it still comes at a cost. Making a lot of these things easy has actually caused new problems that are once again, hard, mostly because of emergent complexity. For instance - configuring cloud infrastructure declaratively has made it very easy to stand up vast numbers of computational instances and distributed systems that now have to be reasoned about, monitored and managed effectively. CI/CD pipelines means we are able to deploy code way more quickly and efficiently and with less manual testing, likewise causing an explosion in complex business logic that's been deployed. If you're not careful, the complexity enabled by these developments can quickly overwhelm you and your team.
For the love of God, critically think about your database schema and object model at a very detailed level, taking into account likely future requirements. I can’t emphasize enough how important having the correct data shape is from the beginning. This is something you cannot ‘iterate on.’ You have to nail it from the get go, especially the parts central to your application. It’s either right or it isn’t and as soon as it is baked throughout your entire codebase it is too late to change.
I am currently refactoring a giant system that had a badly normalized object model that couldn’t be extended and have been doing so for over a year.
but on the opposite side of the spectrum, worrying way too little about accommodating likely future requirements down the road in such a way that the giant hairy mess they create is basically impossible to change