This is a classic engineering take on the problem. It changes when you become a CTO. Because now technical debt is your problem and the choice whether to fix it or not is yours to make. The flip side here is that wrong choices (either way) can be expensive and even kill your company.
I've been on both sides. Having to beg a manager to get permission to fix a thing that I thought needed fixing. And now I'm on both sides where as a CTO it's my responsibility to make sure the company delivers working products to customers that are competitive enough that we actually stand a chance to make money. And I build our product too.
Two realities:
1) Broken stuff can actually slow down a lot of critical feature development. My attitude as a CTO is that making hard things easier is when things can move forward the fastest. Unblocking progress by addressing the hardest things is valuable. Not all technical debt is created equally. There's a difference between messing with whatever subjective esthetics I might have and shit getting delayed because technical problems are complicating our lives.
2) We're a small company. And the idiot that caused the technical debt is usually me. That's not because I'm bad at what I do but I simply don't get it right 100% of the time. Any product that survives long enough will have issues. And my company is nearly six years old now. The challenge is not that there are issues but prioritizing and dealing with them in a sane way.
How I deal with this is very simple. I want to work on new stuff that adds value whenever I can. I'm happy when I can do that and it has a high impact. Whenever some technical debt issue is derailing my plans, I get frustrated and annoyed. And then I sit down and analyze what the worst/hardest thing is that is causing that. And then I fix that. It's ultimately my call. But I can't be doing this all the time.
One important CTO level job is to keep the company ready for strategic goals and make sure we are ready for likely future changes. So I look at blocking issues from the point of view of the type of change that they block that I know I will need to do soon. This is hard, nobody will tell me what this is. It's my job to find out and know. But getting this right is the difference between failing or succeeding as a technology company.
Another perspective here is that barring any technical moat, a well funded VC-funded team could probably re-create whatever you do in no time at all. If your tech is blocking you from moving ahead, it can be sobering to consider how long it would take a team unburdened by technical debt to catch up with you and do it better. Because, if the answer is "it wouldn't be that hard" you should probably start thinking about abandoning whatever you are trying to fix and maybe rebuilding it better. Because eventually somebody else might do that and beat you. Sometimes deleting code is better than fixing it.
Technical debt is intentional compromises. It sounds like you are thinking of not intentional compromises, but instead accidents where someone didn't understand the requirements and so did it slightly wrong for the expected future. Cases where the system wasn't designed to handle requirements changing in the way they did so you had to "make an ugly hack" to ship are technical debt.
I understand the distinction, but at some point it's not super helpful, and I would argue even counter productive.
If you have a system that is big enough and has had enough change over time that it's structure is no longer well suited to the current or near future job-to-be-done, then it doesn't really matter how you got there, you need to explain to non-technical stakeholders that current business requests will take longer than it would intuitively take to build if you just look at the delta of the UX that exists today compared to what they want (ie. the "why can't you just..." conversation). This is a situation where the phrase "technical debt" is a useful metaphor that has crossed the chasm to non-technical business leaders, and can be useful (when used judiciously of course).
It actually undermines the usefulness of the metaphor if you try to pedantically uphold the distinction that tech debt is always intentional, because non-technical stakeholders will wonder why engineering would intentionally put us in this situation. I understand we all get to have our techie pet peeves (hacker != black hat), but this is really not a semantic battle I would fight if I'm dealing with anyone non-technical.
The value of the back catalog is still substantial for years to come. But you are right about the landscape changing dramatically for new productions.
Hollywood was premised on economies of scale. Concentrate a lot of talent in one place and then put infrastructure in place for block buster productions to happen (studios, tech, money).
That's being disrupted by several things:
- LA and the US are no longer cheap places to be. A lot of blockbuster content is filmed outside the US at this point. Canada, Europe, and elsewhere. LA and Hollywood are still important but mainly because that's where the money is. It's not necessarily where the money is being spent.
- Independent content producers self publishing content on platforms like Youtube and growing audiences rivaling those of popular TV shows.
- AI is starting to drive down the cost of special effects, digital processing, etc. And it's probably also going to erode the value of needing actors at all for especially a lot of the less glamorous roles (think all the extras in big movie productions). This is a sensitive topic in particularly Hollywood. But not enough to delay the inevitable by very long.
All this is driving down the cost of creating decent quality things that people still want to pay for. That's a critical distinction. There's a lot of ad sponsored stuff that people don't really pay for as well. To make money, you need quality. AI is working its way up the chain here, with increasingly better stuff. But most of it is still pretty low value.
But things like soap operas, third rate series that Netflix bulk purchases from places like South Korea, etc. are all fair game for AI.
Netflix adding the WB back catalog is a great move for them. Their own back catalog isn't strong enough to keep people and expanding with newly created production it is a very slow and expensive process. And they've had some flops and cost control issues. There just isn't enough there to keep me permanently. I tend to sign up for just a few months and then cancel. I'm probably going to cancel soon again. HBO did not actually offer their streaming services in Germany until recently. And I was considering trying that for a while. Now I might not have to.
Pollution is as much their problem as it is ours. More so in the case of Bangladesh because rising sea levels have some very real consequences for them as they are already dealing with floods a lot.
China is doing a lot about climate and is actually leading on what you might regard as contributing to solutions rather than making the problem worse.
The obvious ones are their technical contributions (electrifying transport, clean energy generations, batteries, etc.). But they are also very active with massive projects to tackle large scale engineering projects to undo the effects of desertification, soil erosion, etc.
You are right to point out that we are a bit naive in the west to consider problems solved simply by moving them outside of our borders.
We don't have to buy sneakers that were artisanally glued together in some sweat shop in Vietnam. And when the brand name on those sneakers says Nike, or Adidas, we can sort of hold those companies accountable to what they are doing and how they are sourcing their product. And it's not the government that should do that but us.
I'm more pragmatic here and I think we should balance sustainability with our willingness to pay for it. Also there are minor problems and really big problems. We tend to zoom in on the negative and forget about the positive when it comes to issues like this. Just look at China. Very poor country five decades ago. Now, it has a huge middle class. Us buying their cheap labor has pulled that country out of poverty. And now they are a climate tech leader and taking their responsibility on a lot of fronts. In some ways, we should be following their lead. Not the other way around.
There are other countries, like Vietnam, Pakistan, Nigeria, etc. that are currently seeing a lot of economic growth and rapid improvement in work, social, economic, and environmental conditions. Some of those countries are electrifying much more rapidly than we do in the west. Not all of it is perfect of course. But we do hold power over them via our buying power. Especially when it comes to companies active inside our borders maybe cutting a few corners when it comes to their suppliers and choosing cheap over sustainable. Ultimately that's on us. If we consumers don't care, our governments won't act, and companies won't address this, and so on.
A lot of this stuff starts with people caring enough. And it seems a lot of us like buying cheap stuff. I'm not any better here of course. I don't actually know who made my socks, underwear, and t-shirts, for example. I ordered that from Amazon, so I'm expecting there might be an issue or two with sustainability and environmental impact.
I agree with some of your points, but there isn't much individuals can do in some cases. Many people can't afford expensive goods made in the domestic market (much like many people cannot afford healthy organic food). In some cases you find that all the products available are made in sweatshops.
The onus must be on the manufacturers.
When you shift factories out of your country, the pollution there decreases, but it increases somewhere else.
Besides, while I hope China is addressing its environmental issues, it is still a dictatorship which disallows open discussion of many such things. It not only has sweatshops but concentration camp labour, and disallows proper trade unions.
Even BMW has a few electrical cars that aren't half bad. The main problem is that they are compromise cars that can be sold as ICE, PHEV, or full EV.
That means more complexity, sub optimal design, less efficiency, etc. However, competition is indeed brutal right now. Tesla did something that only some other manufacturers have managed to copy so far: make cars that are EV only from the ground up. Love them or hate them, they don't make any design compromises to allow space for a combustion engine, a generator, or whatever. There's no room for a transmission, a fuel tank, or even an engine compartment. That's where the Frunk goes. The result is a car that's simpler, more efficient, and more optimal for what it does.
BYD did the same. Kia and Hyundai are having a lot of success with their electric only line of cars. And in the EU Renault and the Stellantis group have some decent and competitive low cost models on the market. Tesla's advantage is rapidly evaporating here.
Japanese car makers have been more conflicted on this. But Nissan's collaboration with Renault is giving them access to the right tech to adjust course. And even Toyota is now using a lot of Chinese made drive trains and components to finally offer EVs that are actually not that bad. The danger is of course that "made in Japan" has very limited value in this world if all your core tech is effectively Chinese and European. That's something that might change in the next years of course.
Cost wise, buying a compromise car means having to deal with more that can break, more components that may need replacing, and a lot of increasingly obsolete parts and components that are no longer being modernized. Combustion engine R&D ground to a halt about fifteen years ago. All those fuel injection systems, and other computer intensive hardware that keeps them going is aging fast and not really being invested in a lot at this point. Sourcing replacement parts might get harder and more expensive over time.
Low latency is desirable for stock traders. Most of the data center growth isn't driven by that but by non latency critical workloads such as AI.
The reason, data centers choose to be near London is because there is no pricing advantage to go up north. Even though energy is plentiful, readily accessible, and often curtailed when there's too much of it there. If there was a pricing difference, you'd see a lot more economic activity up north.
Basically the physical advantage is there but the lack of economics cover it up and wipe out the advantage.
Zig is distributed under the MIT License. MS is completely with in their rights to clone the git repository from Codeberg and do whatever with the source code. Including feeding it to their AI algorithms. Moving it to Codeberg doesn't really fix that. I get that some people want to restrict what people can do with source code (including using it for capitalist purposes or indeed ai/machine learning). But the whole point of many open source licenses (and especially the MIT license) is actually the opposite: allowing people to do whatever they want with the source code.
The Zig attitude towards AI usage is a bit odd in my view. I don't think it's that widely shared. But good for them if they feel strongly about that.
I'm kind of intrigued by Codeberg. I had never heard of it until a few days ago and it seems like that's happening in Berlin where I live. I don't think I would want to use it for commercial projects but it looks fine for open source things. Though I do have questions about the funding model. Running all this on donations seems like it could have some issues long term for more serious projects. Moving OSS communities around can be kind of disruptive. And it probably rules out commercial usage.
This whole Github is evil anti-capitalist stance is IMHO a bit out of place. I'm fine with diversity and having more players in the market though; that's a good thing. But many of the replacements are also for profit companies; which is probably why many people are a bit disillusioned with e.g. Gitlab. Codeberg seems structured to be more resilient against that.
Otherwise, Github remains good value and I'm getting a lot of value out of for profit AI companies providing me with stuff that was clearly trained on the body of work stored inside of it. I'm even paying for that. I think it's cool that this is now possible.
> Zig is distributed under the MIT License. MS is completely with in their rights to clone the git repository from Codeberg and do whatever with the source code. Including feeding it to their AI algorithms.
MIT license requires attribution, which AI algorithms don’t provide AFAIK. So either (a) it’s fair use and MS can do that regardless of the license or (b) MS can’t do that. In any case, yeah, that’s not the issue Zig folks have with GitHub.
> Zig is distributed under the MIT License. MS is completely with in their rights to clone the git repository from Codeberg and do whatever with the source code. Including feeding it to their AI algorithms. Moving it to Codeberg doesn't really fix that. I get that some people want to restrict what people can do with source code (including using it for capitalist purposes or indeed ai/machine learning). But the whole point of many open source licenses (and especially the MIT license) is actually the opposite: allowing people to do whatever they want with the source code.
MS training AIs on Zig isn't their complaint here. They're saying that Github has become a worse service because MS aren't working on the fundamentals any more and just chasing the AI dream, and trying to get AI to write code for it is having bad results.
Trade wars work both ways. So far the US export market is not doing so great. All those tariffs are raising the cost of exported goods as well. And those were already too expensive before the tariffs. If the US wants more US cars on EU roads, it needs to start making better cars. It's that simple. But in the EU, cars have to compete with domestic cheap cars and imported Korean and Chinese cars. It's a level playing field. Hence not a lot of US cars on the roads. A few Teslas (made in the EU mostly), a few Fords (some made on the VW platform), and a sprinkling of niche imports for things like muscle cars and pickup trucks. They are quite rare but you see one or two once in a while.
Communication overhead is a big thing in teams. If you have a struggling team, halve the size. It's crazy how well that works. It's not the people but the number of them. Once your people are consumed by the day to day frustrations of having to communicate with everyone else and with all the infighting, posturing, etc. that comes with that, they'll get nothing done. Splitting teams is an easy to implement fix. Minimize the communication paths between the two (or more) teams and carve up what they work on and suddenly shit gets done.
In this case, they probably were trying to not just rewrite but improve the engine at the same time. That's a much more complicated thing to achieve. Especially when the original is a heavily optimized and probably somewhat hard to reason about blob of assembly. I'm guessing that even wrapping your head around that would be a significant job.
Amazingly enjoyable game btw. Killed quite a few hours with that one around 2000.
>Communication overhead is a big thing in teams. If you have a struggling team, halve the size. It's crazy how well that works.
I wish my managers would get this. Currently our product shit the fan due to us being understaffed and badly managed due to clueless managers, and what they did was add two more managers to the team to create more meetings and micromanage everrying.
I'm not confused about the acquisition but about the investment. What were the investors thinking? This is an open source development tool with (to date), 0$ of revenue and not even the beginnings of a plan for getting such a thing.
The acquisition makes more sense. A few observations:
- no acquisition amount was announced. That indicates some kind of share swap where the investors change shares for one company into another. Presumably the founder now has some shares in Anthropic and a nice salary and vesting structure that will keep him on board for a while.
- The main investor was Kleiner Perkins. They are also an investor in Anthropic. 100M in the last round, apparently.
Everything else is a loosely buzzword compatible thingy for Anthropic's AI coding thingy and some fresh talent for their team. All good. But it's beside the point. This was an investor bailout. They put in quite a bit of money in Bun with exactly 0 remaining chance of that turning into the next unicorn. Whatever flaky plan there once might have been for revenue that caused them to invest, clearly wasn't happening. So, they liquidated their investment through an acquihire via one of their other investments.
Kind of shocking how easy it was to raise that kind of money with essentially no plan whatsoever for revenue. Where I live (Berlin), you get laughed away by investors (in a quite smug way typically) unless you have a solid plan for making them money. This wouldn't survive initial contact with due diligence. Apparently money still grows on trees in Silicon Valley.
I like Bun and have used it but from where I'm sitting there was no unicorn lurking there, ever.
They don't need Bun to make revenue, but they need Bun to continue existing and growing for their products to make revenue. Now they can ensure its survival, push for growth, and provide resources so that Bun can build the best product rather than focus on making money.
It will be interesting to see how this evolves. It used to be that game developers could safely ignore Linux. But with a growing number of Steam OS, Steam Deck, and Linux + Steam users gaming, it's going to get increasingly more painful in terms of revenue to be telling those users "our game only works on Windows" and just miss out on the revenue and deal with the angry users, forums full of users complaining the game doesn't work, etc.
It might only be a few percent of overall users. But a few percent of a billion $ is a couple of tens of millions. That's a steep price to pay for anti-cheat code.
Most game devs can continue to ignore linux and trust that proton will work it out.
It's only the highly competitive online games that have this issue. While they make up a lot of playtime, they're worked on by a tiny minority of developers.
They are still ignoring Linux, hence why Valve is using Proton, the validation they failed to convince studios to care, studios that happen to target systems like Android NDK, or use platform agnostic engines.
> They are still ignoring Linux, hence why Valve is using Proton...
Eh, maybe?
I'd put forth the notion that game devs might be caring how their game works on both Windows and Proton. That is, that they're still using the Microsoft-provided APIs to build their game, but care about how it runs on Linux just as much as how it runs on Windows.
Not really, otherwise you would be getting SteamOS native builds.
It is up to Valve to sort it up, they are the ones that care, otherwise they will need to pay Windows licenses, which is really what this is all about, while pretending to be some kind of white knights.
I've been on both sides. Having to beg a manager to get permission to fix a thing that I thought needed fixing. And now I'm on both sides where as a CTO it's my responsibility to make sure the company delivers working products to customers that are competitive enough that we actually stand a chance to make money. And I build our product too.
Two realities:
1) Broken stuff can actually slow down a lot of critical feature development. My attitude as a CTO is that making hard things easier is when things can move forward the fastest. Unblocking progress by addressing the hardest things is valuable. Not all technical debt is created equally. There's a difference between messing with whatever subjective esthetics I might have and shit getting delayed because technical problems are complicating our lives.
2) We're a small company. And the idiot that caused the technical debt is usually me. That's not because I'm bad at what I do but I simply don't get it right 100% of the time. Any product that survives long enough will have issues. And my company is nearly six years old now. The challenge is not that there are issues but prioritizing and dealing with them in a sane way.
How I deal with this is very simple. I want to work on new stuff that adds value whenever I can. I'm happy when I can do that and it has a high impact. Whenever some technical debt issue is derailing my plans, I get frustrated and annoyed. And then I sit down and analyze what the worst/hardest thing is that is causing that. And then I fix that. It's ultimately my call. But I can't be doing this all the time.
One important CTO level job is to keep the company ready for strategic goals and make sure we are ready for likely future changes. So I look at blocking issues from the point of view of the type of change that they block that I know I will need to do soon. This is hard, nobody will tell me what this is. It's my job to find out and know. But getting this right is the difference between failing or succeeding as a technology company.
Another perspective here is that barring any technical moat, a well funded VC-funded team could probably re-create whatever you do in no time at all. If your tech is blocking you from moving ahead, it can be sobering to consider how long it would take a team unburdened by technical debt to catch up with you and do it better. Because, if the answer is "it wouldn't be that hard" you should probably start thinking about abandoning whatever you are trying to fix and maybe rebuilding it better. Because eventually somebody else might do that and beat you. Sometimes deleting code is better than fixing it.
reply