I spent a ridiculous amount of time on this video. If you liked it, please consider sharing it with a colleague! My interactive git cheatsheet is coming soon™, go grab it here once it's released: philomatics.com/git-cheatsheet
The transfer of theory seems quite important in a world where programmers change positions ever 2-3 years. That alone might be responsible for a lot of bad code and bad architecture. A meta language to facilitate transfer seems quite interesting. It's mainly the abstractions and interactions that are hard to transfer, right!? I think, languages could do a better job of representing/expressing these. Concepts introduced to C++ come to mind, but that's rather niche.
Great video! Where I work, we've inherited a messy codebase, and most of the persons with the core domain knowledge has left the project. These questions keep me awake at night, and your video gave me a lot of inspiration and ideas! Oh, and yes, please do share your ideas on your new language! I would love such a video!
If you only write code only for yourself there's no problem with source code that only has value to you. I think the video is geared more towards the value of source code to other developers, to a software project, or to a company developing the software.
if I don't feel that I am learning anything new that has value when writing code at a job, then it's time for me to move on.. And do note, that learning new stuff is not only code, there is also domain knowledge...
@@lbGkifoo1bj12e9plhjfWA Absolutely, moving on to another project when years of domain knowledge has built up can feel like bereavement (in the extreme) but the collection of domain knowledge across disciplines and projects is what ultimately forms our ability to tackle new projects. It's important to keep moving and keep challenging ourselves. To step outside our comfort zone is how we excel ourselves.
I forget where I heard it, but best advice is to think of code not as a financial asset, but a financial liability: The more you have, the more expensive it is to maintain. And if you can accomplish the same outcome with less (or none), you’re better off.
So, If I don't have inhouse code and everything is outsourced or acquired via SaaS is better ? more layers of expenses so my profit goes to others so they have to maintain the very code my company relies on?; no thank you; they need to go this road too at the end of the day...
You could make the point then that the value of code is actually negative - better make sure to offset that cost by fostering an environment where the actual value (i.e. the programmer's mental model as brilliantly argumented in this video) is retained.
I keep a diary for each project, writing down what approaches I am considering and why I chose "the one" to go forward. This helps a ton when I come back to a project after a few months. Skim through the last days, maybe look up the decision which is giving me a headache now. Sometimes an underlying assumption changed and another approach is better. But most of the time I did forget about some detail which made the chosen approach the only feasable one.
@@philomatics I do something similar in Obsidian, but not in dairy log style. It's mostly me explaining it to myself and what I want to do, instead of what I did. I'd love a video on this.
@Tieno I was trying to use obsidian inside my project so people could just download it, but I ended up just using MD files directly. I am still interested in using a shared vault though.
I'm not sure if I fully agree here, but it proves the point that documentation should explain the idea or theory behind the code instead of merely repeating its functionality
Right, I think a distinction of documentation types needs to be made here. Surely there is mapping the DSL (Domain Specific Language) between code and the real world, but like every other form of good prose, there is the invitation into the author's thought process in observing a particular field. This is not only an area where hackers would struggle to recreate, but also AI; as it is the quintessential human artifact.
Great video! Years ago we had managers who got a bit obsessed with security of our source code. When I argued that our source being stolen wouldn’t hurt us, the scenario they brought up was “what if a hacker takes a USB stick with our code to our biggest competitor”. To demonstrate how ridiculous this idea was, I asked them to imagine the opposite: what would you do if a hacker tried to sell your competitor’s source code to you? You’d throw them out without a second thought. It didn’t do any good though, they couldn’t let go of the idea that their source code was a precious jewel.
@@Jendrus12 Seriously, you're going to diss tense in a sentence containing "a thick, soft, moist substance typically produced by mixing dry ingredients with a liquid."
Guys, my apologies. Had a tough day and IQ lowered significantly then. You’re right, the comment is quite readable and clear. But also could have some lifting 😅 Paste tense!! 😂
I was tasked once with fixing a broken script that had to comb through petabytes of git repos. The script would take 8 days to run. I poked around in it for a few days. Then I chose to throw it out and rewrite it. By the time I had a working build that ran, it took 5 hours to run. In total, that whole process including getting a valid result from the new script took me less time than the original script took to run.
Careful though! Often times, the code you don't understand has the most important design decisions in it. Some teams take years to recover from decisions to scrap things they don't understand. Make sure you fully understand it first, then it might be the right call to replace. But usually by the time it makes sense, you know how to fix it anyway.
@@username7763 Definitely. I was careful to reverse engineer what the code was doing and double check with the team that set the original requirements to determine if particular behavior needed to be preserved. You should never wantonly rewrite something thinking you’re going to magically fix everything, but if you exercise good judgement and caution to preserve desired behavior, as you say, by the time you determine you should rewrite it, you’ll know what you’re doing and will probably improve on the original.
Tractability is the single most compelling reason to document your code meticulously. If your future self doesn't care what decisions went into your code then tractability is irrelevant, think automatically generated code. However, if your code is going to be read, re-read, re-interpreted, and used as a reference or jumping off point then it's really important for people to understand the ideas that went into that process. The assumption that the process you followed to developing a module was intuitive and therefore intuitive to all experienced developers is exclusionary at it's core. The notion of intuition is a completely subjective mark.
@@Turalcar I recently thought about this and I'm starting to flip back to using comments. Why? Because the assumption that code is going to be unmaintained is a dangerous self fulfilling prophecy. Of course, I write my code in a legible, clear cut way, but what if I want to include a chart to illustrate the way an adapter connects two or more application layers? I feel like "just adding it to confluence" is a bit -ded. Having deep documentation but then separating it from the code, doesn't seem like eliminating unmaintainable comments. Given the AIs capability of maintaining code and such, I think a deeper code ownership might become more viable and "orphaned" throwaway code might become more distinct. Yet, of course I also use AI slop when it's beneficial.
@@FenrirRobu That's almost the opposite of what I said: comments aren't as bad in code that won't be maintained because they are less likely to diverge. In total, they bring negative value: you either need to maintain them (which is harder per-line than code because no static checks) or they'll mislead you at some point. Almost all of my work is maintenance so the code is already better than what existing LLMs can produce.
@@Turalcar And while I understand that argument, I am starting to disagree with the position. Yes, code that changes a lot and has comments will require more comment edits than code which is basically a textbook and never changes. However, I am leaning towards the position that such code - dynamic but not "maintained with documentation" should be scrutinized more. To be clear - I see documentation (clear, precise and concise one) as a part of the "maintenance" spectrum and maintaing as being part of quality. With the opposite being code that is garbled by excessive edits with meaningless or confusing variable names, unreachable conditions, misleading comments and archaic commented out code as the unmaintained part. In my last corporate job we had a lot of "temporary" code that actually was not very temporary at all, but there was the assumption that it would be. In reality the developers left and there was a code ownership crisis due to turnover. In that case the code was both valuable and a cost sink, because it kept the system running but also it needed to be rediscovered. So I think that the "low maintenance code" (not accusing you of doing that, to be clear) or "build fast and break things" mentality is overused nowadays. It seems like the default assumption is that we can only write bad code at first so let's just commit it in with the MVP as long as it runs. While of course, other projects exist with high requirements for each code change.
I don't believe it matters, whether the process you followed while developing a module was intuitive or not. And it's really not obvious to me that knowledge of that process would matter at all for future readers/users of your code. I can't think of a time I cared. If something is complicated, then it's faster and more reliable to directly read the code, rather than reading a developer's rant about how they _think_ the code works. Especially since that documentation is never going to be complete enough, and might even be misleading or plain wrong, at times. A documentation is fine too: but it's a comfort thing, mostly useful to provide examples on how to use a tool. Unless you're developing a framework, you don't really need it. What you need is clear code. Code that rarely, if ever, needs comments or explanations.
Haven't watched yet, but sweet to hear code is cheap or free! Finally I don't have to code things myself and can hire people to do it for literal pennies! Makes my life so much easier
Holy shit. Are you the author of "How to hire senior developers: Give them more autonomy"? I read it years ago and it pointed me to Naur's article which I also read and both have shaped how I really think about programming since.
Don't listent to this guy. I've license my own source code for hundreds of thousands of dollars If nobody uses your binaries, then, of course, your source is worthless, BUT if ALOT of people use your binaries, your source code is 1,000% GOLD.
What about an old code that consistently passes security audits each year? You can assign value to anything, but that doesn’t necessarily make it profitable. From my experience with various CRMs, on-premise solutions, SaaS, ML, pipelines, algorithms, and other software types, it’s not the latest framework that defines the code’s value...it’s the profit it generates.
Basically you are saying that programming is the neverending everlasting project support. Which implies that there's nothing to brag about how many projects you've done, but rather how many projects you're involved in and support at a time is telling how good you are. In other words understanding the business logic quickly is a must
This still sounds like oversimplification of more complex problem :) The code clearly has value. You basically say, that it may not be economical to increase its value in certain circumstances, which is applicable to everything.
Interesting point of view. But to clarify, I think my main point is more that there are diminishing returns, and that further adding documentation/code does not further increase its value.
@@philomatics There are diminishing returns with almost everything, just consider what we do to "satisfy" Moores law. In the beginning we just scaled masks down with few simple tricks, now we are pouring millions of dollars just to shave off bunch of atoms. Same goes for building thermal insulation - there is point at which building is considered passive, but there is still loss of heat. You can mitigate half of that loss by doubling insulation thickness, but there is point at which it stops being worth it. So in this regard, I would say "such is life". As value is subjective, I would say, that these things are defined by market demand. But company environment does not have such mechanism, so it is easy for some manager to pursue a pointless goal. I would say, that pointless goals are made of blanket statements, so here also applies, that the value of goal making is in the process. See, I could have said, that management has no value :) Anyway, sorry for rant, I don't even know what this channel is about, just clicked on random video.
@@philomatics I was considering my latest interest a very different proposition: games for old microcomputers/consoles and emulators. In that case documentation could be a lot of non-commercial value to the community, and even heightening and extended the creator's reputation (and perhaps even some economic benefit). And for the employing game company (like Nintendo) keeping that code secret for it's viable commercial life, or second life, would be valuable. These are two extremes that don't follow your thinking at all, as niche as the cases may be. I do think you have generalized much too much, it is an oversimplification that applies mainly to a certain kind of code, although it may be a large segment of what average code monkeys work on.
Super interesting point comparing not reading other devs code to being a writer that doesn’t read. We take a lot of snippets from stack overflow but we don’t often dig into a package to try to understand it. You’ve inspired me to start doing that more!
Thought experiment: You have a compiler that has an "approve build" button. You may build and run test builds that only function on your dev system as many times as you like until you "Approve Build for Distribution". As soon as the build is approved, all of the source code used to build it is deleted. That approved build is locked in and cannot be changed. Was any value lost? Let's modify that a little. You can now add extension modules to any approved build you found online. But once you approve that extension for distribution, the extension's source is also permanently discarded. Was any value lost? Now for both scenarios, let's assume an end user has purchased one of these builds and has found a bug in a feature that is critical for them to use the software for what they intended. Was any value lost? We can write a new module to extend the old one. Or an entire new build from scratch specifically designed for this client's needs. Was the value proposition shifted at all? I feel like the message the video is trying to get across has some genuine merit, but the optics in how it's being presented is probably going to give people the wrong idea and do more damage than good for it. *Especially* with that thumbnail. Though for anyone taking the thumbnail itself on surface value, I urge them to consider "If you were to delete all of your source-code for the project you're working on right now, are you still going to be able to make meaningful progress tomorrow?" That's gonna be a yes and a no for some and others, but I just don't want anyone to get pulled in by the short catchy one-liner and then do something regrettable for it. (That and it's kind of a hard swerve from the previous trend of Git-specific topics, and I'm assuming the largely git-focused video description is probably the remnants of a slightly edited template than it is meant to be relevant to this specific video.)
This is shown surprisingly well when you use AI to code. Once you pass the context window, it's basically like having a new programmer each time, as it can't remember what it was doing at the start to get the program going. Your code has to have enough details for the new coder to understand and continue it, which is incredibly hard/impossible to accomplish. So the best the next guy can do is try to catch up to things that are documented, it'll still completely miss all the undocumented steps you took to get there. The coder's understanding of the project is far more important than the code.
Yeah this video really should have had a disclaimer that it is incredibly specific and that a lot of source code is EXTREMELY valuable. Also, I've absolutely been able to go into code bases with hundreds of thousands of lines of code or more, and been able to modify things or add features on day one. And think of the value of so much source code when it comes to trading & finances, or proprietary curation algorithms, or some of the closed source AI models, or the value of source code when it comes to TRAINING models. There are an infinite amount of ways that just the source code itself can be valuable and useful.
@@cooltrashgamer It's not the code that is valuable in most of those cases (well except business code directly, or formulas when you already possess all the theoretical knowledge except this formula), it is the way the code does it that is interesting. It is like a map of how to complete this task specifically that is important in that code.
@@rvvon1214 That is such a bike shedding statement, it's not the instructions that make the computer do things that are valuable! It's the computer doing things! Getting a computer to do things can be massively valuable, and pretending like source code -> machine code mapping somehow means that only the machine code is valuable and not the source code is an asinine sentiment.
@@cooltrashgamer What's very specific is code that exposes "secret sauce". Most code hides no secret sauce, just vaguely explained structures that do nothing special in the end.
@@randomuser66438 Yeah, but even in no secret sauce examples, if it was trivial to RE any program, everything would be inherently crackable immediately. Cracking to even get a program to run on another computer without actually altering behavior can take months of hard work and research. Having the actual source code would be valuable, which is why some leaks of source code that aren't even hidden behind a server are still valuable to buy.
Very nice video and information, just two observations: 1. Getting the source code of a project is useful mainly for copying specific techniques (how is he grabbing the screen content?, how is he communicating without NAT? etc) It is the understanding of the field the code is written for and the interactions of its modules (objects, etc) that requires effort and understanding from the programmer and it takes time to achieve. This is why training a programmer in a specific field (scientific field, engineering field, a framework ...) is a serious investment of the company and also why sometimes it can take days of studying and/or planning just to write a few lines of code. 2. Being able to get into a code easily, just to fix a small thing, requires the code to be so tightly separated that it consists of small black boxes so that changes to each black box can be easily estimated without the need to understand the whole architecture or interactions with other parts of the code. In practice, this is very difficult to achieve and very costly, plus the need for high skilled software architects. Also, it will lead to paranoid levels of abstraction of the whole construct.
If it's some companies I've seen, then it could be worth millions, as there's still people stupid enough to store their admin passwords in source code on the cloud.
True. Plus if you could how a code base's internals are operating, you could seek out attack vectors for exploitation. I've even seen code that in-lines server and port settings depending on IF DEBUG\DEVELOPMENT statements. Code Theft = Data Theft = Reputational damage + Fines + Class Action lawsuit.
A side note, but when thinking of the product being the “solution” to problems. I suddenly remembered that many “solutions” turned out to be good ideas that even the creator didn’t know. For example, in Math, the guy who first came up with calculus wrote in the documentation that “this is just a cleaver hack please don’t ship it into prod”. But it turns out, the solution is actually super useful and is basically what the entire modern math is based on.
I was sleepy before watching this, but now you've got my gears spinning. I definitely want that follow-up language video. Btw, this is one of the reasons why the language Zig insists on no hidden control flow.
I feel that the best theory transfer languages we have today are DML and DDL in SQL. The "metadata" of relational database structures and transactional processes defines so many inherent characteristics of theoretical models that you can literally use it all to auto-generate code that does 80% of whatever you need done in the vast majority of applications without any use of ML in any way. I have seen this in practice many times, and did it myself decades ago. Tables, views, and stored procedures get you nearly all the way there in the majority of CRUD applications with zero code needing to be written. And SQL is already practically natural language, so there isn't even a need to go nuts with trying to use "AI" to bridge the gap between NL grammars and context-free grammars.
The concert pianist metaphor does not work because there is not one single correct way to play a piece. Also, I can very easily write down interpretation notes about a piece that accurately convey the changes in dynamic and tempo necessary for a specific interpretation. We literally use written notes all the time.
i mean having the original developer is the best way. but you caaaaaan get by just reading the code. with enough experience, that gets easier. programming is an art. you were spot on with the pianist teaching you to play a song as she does.
This has to be the best coding channel i've ever stumbled upon. I was making a consultancy platform for my college department and with this video I understood why is it too hard to explain to teachers ( as a part of evaluation ) what we actually build. The entire problem was mapping different roles to different silos and make controllers that interconnect. And I truly agree, the source code actually is not worth a lot.
A reasonably done codebase may have general-purpose routines or particular algorithms that might save a competitor time. And not surprisingly, those are the things usually sought.
The value is not the code, but the knowledge about how to solve particular problems. So of security is too good to steal the code, try alcohol and an attractive person of the opposite sex on the developer.
my impressions: value correlates to intended change. -complete code is desirable with non-existent management (valuable code) -incomplete code is tenuous with dynamic development driven by momentum (valuable leading programmers) -neverending code is tenuous with constant management (valuable programmer economy) -complete code - from open source with minimal module-granular functionality - is valuable (value in code) -uncompletable code - of software developers with minimal foresight - is cheap (value towards programmers) -decrepit code - from software companies employing minimal simplicity - is worthless (value towards company) hence, valuable code is free and timeless, everything else is a business venture.
I’m choking. I’m not currently a systems engineering and I have never been a programmer. To me, all that matters is validated and verifiable requirements. Every line of code should be written with the purpose of satisfying a requirement. A line of code that doesn’t meet a requirement should not be written.
I've been saying this at work for years. It's not the solution that is our edge, it's the fact that we can come up with these solutions. If someone takes them, they will just be stuck in our old past. Great vid! 👍 It was your comment at the end that made want to comment. I wonder how common it is to start a channel for one reason then fall down into a different hole. For me tutorial hell exists on both sides of a tutorial and I really don't want to be on any side 🤭 I don't know which hole you fell into, but I'm glad to hear that are are crawling out with this video. 👊
I love the fact that the company called panic, didn't panic when most companies would in that situation.
Месяц назад+6
Interesting, video! I did find the statements quite black and white. I do think there are ways to make it easier to transfer this domain knowledge, one way is to do more Domain driven development. Even reading code as you stated at the end is a way to transfer this knowledge, were at the beginning of the video you state that knowledge can only be transferred by working closely with other developers. Open source libraries are a great of of developers using other peoples code and also contributing to it.
The domains will have to mimick/represent real world concepts (or at least they usually are), the trick is we usually don't try to mirror that concept 1:1 in our code, because that would be really hard and time consuming, let alone that we don't mostly need many of the properties of the real-world concept in our code, and that makes the ddd basically useless or highly inefficient to say the least in communicating this theory.
Wow, this is a fundamental insight into some of the deeper questions that are in the back of my mind during work. Great explanation on e.g. why onboarding new developers has always proven impossible simply by documentation on processes. It always seems to depend on close 1on1 interaction and co-developing ...
I think "source code" as portrayed here doesn't really address all of the types of source code. Code that is developed for a very specific context often is difficult to generalize, and so the theory of the code is bound to its situation for which the solution was engineered. However, source code and documentation can be quite useful when they are more widely applicable and can be generalized. This requires a theory of code that abstracts the process of writing code into solving separate smaller problems, these problems individually being of interest apart from the whole solution the project is intended to address. I would argue that code and documentation so constructed is quite valuable, but rarely does the perspective on a problem transcend its immediate needs and therefore this is quite rare.
This is a very good point and probably a good middle ground for my admittedly pretty one-sided portrayal in the video. I think one example for such code might be research code, where the core idea represented by it has value itself.
Modders understand better than most professionals how to absorb the intents and theories of the programmers from the code base itself. It's not impossible, and gets easier with practice. My very first programming job was to assume responsibility for abandoned yet wildly popular code. My own love for the work made me more dedicated to take what was there and make it better than to abolish it all and replace it.
I was always haunted by the idea of source code leak or theft. Your video gave me a new perspective to think about. One of my struggle lies on a proprietary financial trading software I wrote for myself which gave me 40+% return last year, but I am stuck to sell it out for fear that my code could be hacked. Now your point is really worth considering because what really worth is the theory behind and not just the code alone. That's so real and to the point. Thank you for your video explaining that
Code rots so fast. Even if code had value *at the moment it was written*, because it was solving a problem that needed a solution asap, after a while the value depreciates and the problem goes away for many possible reasons.
That's circular reasoning. If code is written for a problem ASAP, it could rot fast. But what if it's code for ASCII lowercase to uppercase conversion? Sure, we can obtain this code in seconds with Google, but it's a simple example of evergreen code. But if it's not valuable, then what about code for crystal growth? Or a grammar book? While I extend this to trade secrets and patents, I do believe that code, architecture and decisions can absolutely be part of a competitive advantage. Like C has not really been fully replaced even in 50 years, and C# is being replaced by languages that just implement the same features. If you had a superb C compiler, it could be valuable for a long time. Especially the source code, since it would be a pain to edit it without the original source, whether you know the original theory behind each decision or not. Other examples are MP3s, JPEGs, PDFs.
@@FenrirRobu right, good luck finding a meaningful use case for your ASCII lowercase to uppercase conversion in the world of UTF. C compilers rot faster than anything else (as a former full time Clang contributor I know what I am talking about). Yes, there are some very foundational things that are eternal, like BLAS and LAPACK, TeX and Metafont, bc, and so on. But hardly any private company ever written proprietary code of this scale of importance.
@@vitalyl1327 it's true that many companies have not made important code, and many problems become less important, like with UTF-compatible uppercase conversion, the old ASCII code becomes only one conditional branch. I'm interested if C compilers' changing code is the result of fast innovations or other factors, because there was a long period where the actual C spec did not change much. Other similar products are SQL databases, file systems, system utilities, emulators, mathematical libraries, simulators, maybe some parts of graphics libraries. It's still the wild west, but it's possible that Transformers and Diffusers might be long standing specs. Whether the implementation changes constantly or not, there are many bugs or not, market shifts or not is circumstantial. As a whole, I will say that there's a sea of rotten code out there, but not all code is doomed to be rotting.
There are plenty of programs that have been in use unaltered for 30+ years and to change one line of source code might require a year or more of testing costing millions of dollars.
What you call "optimizing for transfer of theory", I might call "information design" (though I only discovered this term recently). Over the last 20 years I often find myself coming back to the question of the ideal way to bring this kind of practice to programming. For example, the ways to allow much richer, more clearly specified, and more legible programs without increasing the cost of maintainability or explainability. I'm sure you have very different ideas to what I've been pondering but definitely something I'd love to see more of.
I agree with a lot of your thesis. I think it is weaker for tools than it is for targeted applications. Imaging trying to "rewrite from scratch" a monster like Mysql or Eclipse, rather than starting with the existing source code.
I am an Indi developer, I put code for my commercial projects on display if an interviewer asks me for projects, duing that time when my code is open I do push any new code changes until I lock the repo again.
When RUclips recommended this video, I did not click it because it looked like one of a million others like it: "X is trash! Here's what I think!" RUclips would not stop recommending it, so I relented. The theories and your rhetoric sound really convincing and I am encouraged to do my own research because of your video.
Theory making view of programming is especially important now with large language models being able to read our codes instantly. I felt this video pretty thought provoking when I think about how I could archive/transfer/modify technical knowledge with new tools.
Abstractions are helpful for prototyping but an antipattern for understanding. Especially object oriented programming. Now i can’t just ask “When is this called?” or “What functions own this data structure?” I have to ask “When is this constructed?” “When is it destroyed?” “What is its lifetime?” “Where is it stored?” “What does it store?”
a lack of abstraction is also just as harmful "which platform-specific quirk is this leveraging?" "why do it this way?" "what problem is this even solving?" "where is the business logic?"
You just blew my mind. And you were able to articulate something that I've been feeling for a long time. Please do a video on your theoretical programing language! Maybe we can open source it and it will be a living experiment for the theory building programming language. Incidentally, I think that dev notes are the most useful part of code, and I personally try to include as much dev notes written in non-technical language as possible. I now realize that I was using dev notes as a way to pass my theory building knowledge. I would write the "why" behind my code.
I think there is a difference between continious access to source code and one time access. Also some things have a robust internal implementations, that can't be easily copied just by looking at the product. For example chat gpt will lose a lot if theit model's source code was leaked
Logistically, this doesn't hold for any of the extremely large LLMs like Gemini or ChatGPT because the number of people with the resources to run or train anything similar is extremely low and because in the case of most machine learning neural network based models the "source code" doesn't matter as much as knowing the training dataset, the training parameters, and the output weights. And even if one has all of those available openly, because of how the training tends to be randomized, one is unlikely to get an identical outcome even if they used the same dataset and nearly identical dataset if the seed is different. Fundamentally, the process of making a machine learning model is really not that hard and most comp sci students would be fully capable of doing so by the time they get their bachelors of science degree. But unless they have wealth in the billions, they're not going to be making multi-trillion parameter models in the near term with consumer grade hardware.
Au contraire, my friend. The models are already super simple. The pre training that givesOpenAI value is what would be super expensive. They somehow managed to be valuable by guerrilla tactics of taking all the data it needs without concern for "copyright" before they went ahead and whined about how dangerous companies like it were for profitable creative works and "public safety", which is so laughable that they can act like aYakuza yet pretend to be angels 😂
@@SimGunther They have lots and lots of optimisations that would help their competitors. They won't be able to use the code as is, but it has lots and lots of hidden info, that can be extracted and is very valuable
@@SimGunther "The pre training that givesOpenAI value is what would be super expensive." And the loads and loads of post-training/fine-tuning to correct myriad undesirable behaviors, and frankly to make their products seem smarter (far closer to AGI) than they actually are. Them releasing their actual model specs and training and fine-tuning processes would almost certainly be more valuable than the actual source code (especially to the research community), and would be entirely in line with their founding principles (which included _opposing_ opaque gatekeepers; they quickly became the thing they were supposed to be guarding against). My personal hope, though, is that they and all the other companies who straight up stole for their training copyrighted data or other assets that at least require attribution (e.g. code licenses, Creative Commons licenses; as far as I know, they don't provide any attributions for such, which is clearly abusive and illegal) are sued into oblivion for obvious rampant and willful violation of copyright laws and various license terms. There is blatant malicious intent in this activity. They don't deserve to be allowed to stay in business behaving like that. As far as I'm concerned, any executives complicit in such choices should be facing criminal charges. An individual doing the same would be imprisoned for a long, long time, and probably bankrupted by fines and court losses.
This makes a lot of sense, at work we have a lot of systems that are constantly changing to fit the needs of our users better. I haven't been programming for long, but the amount of times I've seen super experienced devs make mistakes just because they were unfamiliar with the project is surprisingly high. Code is much more valuable when you have devs that are specifically familiar with that code.
Yes, the bulk of this video is intriguing, but that intro example is way off. If a competitor released a free copy from stolen code, they would be sued into oblivion. Panic wouldn’t be like “oh well, it doesn’t have our bugfixes”. Therefore the only way to ship stolen code is to conceal that fact, which isn’t itself commercially viable, to the actual more interesting point of the video, in that the real work is understanding the code, which that writing from scratch can be faster. Not to mention the ability to deconstruct the code and verify that parts of it are stolen etc. If companies didn’t care, they would just open source everything
@@omnipi > wHy Wont MiCroSoFt jUsT SteAl the coDe. Bro literally never heard of the concept of copyright or DMCA. TBH the examples shown feel more like damage control to me. I do believe the core argument holds true though. It's hard for people to get on board. But the argument of somehow people can understand the entirety of a system is ridiculous. I wonder if this guy ever worked on a large project. Literally no one understands Linux as a whole. Overall, this video robbed me the wrong way. It's rare to see such a true statement being completely undermined by the examples.
Will they? If they just publish the code once, and never update it ever? I highly doubt it. Who would dig into all that code and continue to work on it? Side note, I shudder to think what the Adobe code base must look like after all these years 😅
I believe that 'code' is essentially worthless without the people who built it, but this primarily applies to non-mature products. If a group had access to the source code of mature products like Office, MATLAB, or Tableau, they could disrupt the market by creating clone products and attracting investors to build from that point onward. With the advent of large language models (LLMs) and their improving capabilities in understanding and reasoning, it is only a matter of time before an AI assistant can guide me through source code I've never worked on. This would help me get up to speed in a work-from-home environment where interaction with other developers on the project is difficult and formal. So, in the end, code may not be worth close to zero.
Office has competitors like LibreOffice and OpenOffice which are just about as good and it still has tons of value. I don't think someone with the source code would do better. Particularly since MS would quickly add incompatibilities here and there jsut to keep their edge.
I feel writing code is like tending to a palace garden. It's a never ending work of getting to know all the plants, maintaining them through different seasons, experimenting with new ones, adapting the look of the garden based on fashion and practical needs. The value here is the constant care, the knowledge and the efficiency in achieving the result. The garden will deteriorate within a few weeks if the Gardner is paid a lump sum for his work and let go.
I enjoyed this presentation but I disagree with it entirely. In fact I go so far to say that it is a harmful perspective. Here's why: 1. Failure to express the logic in documentation is still failure in documentation. Scientists still manage to communicate the most sophisticated ideas known to man in publications that their peers can grok. Software engineers do not do this because documentation is not seen as part of their craft, whereas in science writing is part of the craft (publish or perish) yet in software engineering not so much. This is one of the reasons why some people insist that software engineering is not engineering. Can you imagine a structural engineer not documenting anything about the 6 lane overpass that he's just designed in his head? 2. The talk of the relationship between a component and the real world is avoidable by writing pure functions. The less a function knows about the rest of the world the better. This is also makes testing possible. 3. Justifying your decision is what comments are supposed to do. When you return to some old code and you no longer understand why you did that shift and swap its not because you've forgotten the syntax for sift or swap but because back then you thought it was super obvious why these operations were necessary. Future you however realized that it was not super obvious after all. If you don't have the patience to explain why you are doing something don't be surprised when future you or no one else knows why. 4. Human interaction is great and perhaps the fastest way to get knowledge across, but it does not scale and requires patience (which not many people have) and willingness to sacrifice productivity (which many orgs think they cannot afford) while this training is going on, time and other geographic constraints. It can and should supplement documentation but should not replace it. Many ideas have passed down from the ancients to us because someone in 123 BC decided to write it down. Document your code, extensively and write top down wikis that start from the topmost modules and explain the relationship between them and work your way down. It is difficult but so is writing code; yet devs are willing to pay the price for writing code but unwilling to pay the price when it comes to documentation. 5. The value is not in the source? Tell that to Microsoft and ask them to rewrite Windows from scratch, or SAP or Bloomberg to rewrite their terminals. This is a ridiculous assertion. The knowledge in the head of the dev delivers no value to a customer. Only the source does that.
I had this thought recently when making a new startup, where we had to build a new workflow automation from scratch. People ask us -- why don't you just fork n8n? I think of it as having a high degree of programmability over the system you design. You can impose and translate your will on the development of your software platform, and you know the most efficient way to mobilize your team's human capital to adapt to new opportunities. This level of control and understanding is hard to replicate if you're simply forking someone else's open source project.
Great ideas presented here. One main problem. You say you would hate as a programmer to have to document theory, but that is actually the precious resource that needs to be preserved. I challenge the notion that this is impossible. In actuality, the problem characteristic of the theory held in mind is that it is analog, and thus is in the very domain that humans are suited to manipulate. Consider how rich and compelling stories can be transferred through sequences of text: machines and lazy people (hacks) suck at this. A valuable "programmer" will be somewhat of an artist; able to succinctly convey discrete meaning from an infinite field of constructs using the codification of language.
Finally, a reasonable explanation for all the phenomena I've been describing for the past 25 years! Thank you for that, and greetings from Vienna! ^^ endlich eine vernünftige erklärung für die ganzen phänomene die ich eh schon seit 25 jahren umschreibe! danke dafür & lg aus wien ^^
Great video. I recently decided to code a CMS, and thought that I could just take bits from WordPress to make the process faster. I immediately realized that just reading the code was useless, without talking to the devs that wrote it. Though the WordPress code is well documented, I was still having trouble understand why the devs opted to use one method vs another. I'm now just coding the CMS completely from scratch as it's just faster to implement my own theories.
I will tell you the value of source code: try sell Microsoft to a buyer and tell him he can’t get the source code with the sale. And see how much you get for Microsoft. 😂😂😂
Man one of the real golden nuggets of this whole video was at the very end: We need to read other peoples source code and review it to get better at programming. This has been a HUGE leap for me in programming skills over the last 3-5 years now. I've been able to position myself as an engine developer due to my interaction with open source engines (UE and Godot) and digging in and solving problems. You should do a whole video on this. And so should I. Thanks!
Captivating video! Some parts I figured out myself, but couldn't have expressed. This video and the article compiled and expanded it. Make more videos like this 👍👍👍
Not that I dont say that it's not true, but as someone who have seen lots of coding projects I also think this is a wrong view. The 'new code is cheaper then refactoring/maintaining old code'. The not maintaining old code is what makes code old code. And a mix of old and new code is what a project makes spaghetti, chaos and worthless.
@@krishnabharadwaj4715 Not always, but more often then not I think not really new code is made old by not maintaining.. I know everything has a shelf life. But I feel like, in the code world the shelf life is the moment it is put on the shelf.. And that is the result ~I think~ of these kind of views.. ..And therefore I think this is a bad view of things.
I found this video insightful. I hope the CEO of my previous company watches it to understand the true value of employees. It's difficult to foresee the severe impact layoffs can have on development velocity until it's too late. Clean code can devolve into a Frankenstein's monster, leading to more bugs and downtimes that erode the trust of users and investors.
Dude! The idea of a language that prioritizes communicating the theory? Go! It’s so explicit and upfront and consistent that it forces you to surface your “presuppositions”, not giving you macros or other compile-time code-gen facility. It can be painful to write, but I think this describes why it works so well for team projects!
Great video, however I think you are missing or confusing some things here. The theft for example of the actual physical source code is a massive deal. Just because right away the company says "oh that code is already old and we are 1000 commits ahead of the old master" means nothing. That is called PR and damage control. In the industries "Corporate Espionage" is a very real thing and companies spend billions on protecting their assets which includes source code. If I were to walk into a corporations HQ with a USB drive and go up to a computer, sign into their code repos and click download all or something and walk out. What will happen to me ? Will I get arrested ? Will I have to give back the code ? OF COURSE. Maybe that codebase has some algorithms that the competition wants to shorten their development process. Maybe the code has concepts that the competitions developers have never even dreamed of. Maybe their is a whole new programming language that when used can shorten development time by 90%. The point is that source code itself can be both worthless and highly valuable at the same time. I don't see Apple, Microsoft for example publishing on a daily basis their source code to their respective operating systems. Why ? Because they know if either company gets a hold of the code it will reveal things that neither want the other to know about. How to implement X, or how to implement Y, etc....
I mean to some extent yes, but in my opinion the bigger and more complicated a codebase is the less valuable it is to leak it. It would be catastrophic PR-wise that security was so low that something like that was allowed to happen, but in reality you can't just sell someone else's product on the open market that you built by simply stealing their code. The law would slam down on top of you so fast you'd have the wind knocked out of you. As for gaining valuable insight into how it works, if the codebase is huge and complicated you wouldn't know where to look, and if you did you'd probably be able to figure out the details by yourself more easily than stealing it. Most of the small efficiency hacks will be pretty opaque to you, and if you're building a different product for a different set of users they might not even apply to your use case. You can't just drop-in solutions from someone else's software unless you know why it's going to be efficient/do what you want/work at all, and once again that requires you to figure (a lot of) things out on your own... again. Unless you own a company with such a novel, valuable and well-kept secret technique that no one else in the entire world is using it in any open source project (I mean something like a solution to a major open problem like a fast algorithm for cracking factorization-based encryption e.g. RSA, which would give you a massive competitive advantage), your source code getting leaked probably will not mean much for your competitors. Unless you're doing something very stupid like storing API keys in there. In that case you may be fucked.
> In the industries "Corporate Espionage" is a very real thing and companies spend billions on protecting their assets which includes source code. Oh, you are not completely wrong here. But 99% of the source code is about as harmful a secret as, say, the lobby and outer layout of a company HQ. Would you consider, say, boilerplate code to handle command line switches efficiently a trade secret? Or a C++ module that implements a standard that is widely used in the industry, like a TCP/IP stack, standardized switches or perhaps even something that enables Active Directory RBACs in a straightforward manner? Any code written by IT (as opposed to R&D) is basically throwaway boilerplate code that is of no use to anyone else. The implementation has no direct value; but it does have indirect value insofar as automating specific tasks within the company. The code is generating value each and every day; but the person who wrote it did so once and the cost is already paid for. That said, this implementation could reveal intimate details about manufacturing processes and how to best hack this specific site, so the code is not completely worthless either.
I know of a company whose source code was stolen and the code was offered to a competitor. That competitor just reported the thief. On the other hand, I have decompiled some programs to understand how they worked and shared that knowlege with other people, meaning the code source wasn't even required. Reverse engineering doesn't require having the source code, and it's probably way easier to just study the program from the outside most of the time. I'm pretty sure the only thing valuable to an outsider in source code would be bugs and holes that pirates can take advantage of.
Loved this vid, highest value vid I've seen in a while on YT, not going to lie. Subscribed, and def would love to see your proposed ideas of incorporating the Theory Building View into IDEs more. This is such a meta topic, it's never even crossed my mind! I just told myself in the beginning "Of course writing it from scratch is faster most of the time" but then you started diving right into exactly why. Perfect for my typically low attention span xD, cause I would've stopped at that point.
1:36 …. Always love when a small start-up in a funding round is concerned that „some big company“ would steal something. Seriously, going through that pain and keeping it a secret at a company of more than 5 people is already hard. No, if they would want to do that, it would be much much much cheaper to just buy you instead of taking all this risk outside of a process. Phew
Also, the complication is not in the code for the most part, is in the business mechanics, clients, market, revenue, etc. The code alone means very little.
as a principal I often quote "nobody cares about your code" to dev teams, most useful code is lightweight and easy to replace and the behemoths that a lot of devs write are ultimately useless, most services I fix I do so by replacing the code entirely and my instruction to the teams I hand it off to is "heres how it works, if you dont like it go ahead and replace it"
Would really love a deeper look into programming paradigms that utilize this theory as a sort of framework for approaching problems in general before even touching an dev environment.
Don't listent to this guy. *I've license my own source code for hundreds of thousands of dollars* If nobody uses your binaries, then, of course, your source is worthless, BUT if ALOT of people use your binaries, your source code is effing GOLD.
@@philomatics I don't understand the question. A company will want to license the source code for a version of the binary. We provide future source code releases to t hem too for addition money. The company cannot distribute any derivitives of the source or binaries.
Would they still pay for your binaries if your company would just vanish afterwards? In other words, is the promise of your continued support part of what gives your code its value?
Not to be that guy, but if you're selling binaries, then it is the binaries that have value. The source is only worth anything if you will need to provide different binaries in the future made from derived source.
@@philomatics They have the source code and can build it at will and/or add additional features/options/etc. Once they have the source, they really don't need us. That's the other point of getting the source.
It also depends on the quality of the documentation which can vary massively from mere function signatures with a (hopefully) a short sentence explaining its effect vs thorough tutorials that are well presented and easy to follow.
All the developers of apps that suddenly have some Chinese competitor that built exactly the same looking product but with much more aggressive marketing might see this differently. Otherwise I mostly agree.
@@batatanna have you ever lifted some custom VM? that's also packed/obfuscated/fuzzed dynamically and streams in modules from the internet and decrypts itself in the vm and each time the module is polymorphically different and has some sort of polymorphic executor in the vm that changes it's execution each time a function is used, that has also advanced timing checks inlined everywhere that are also polymorphically built? It's not that hard for someone to reverse something of value inside a binary, that is unprotected and has large set of boilerplate code, but try that in a protected binary lol which also has strong integrity checks and anti debugging.
@@depralexcrimson I stand by my point. You may not redo the exact same code, but by studying the functionality you are very capable of creating new code that does exactly that.
Theory transfer is largely the purpose behind "Clean Code" and by extension "Design Patterns". There are other flavors, like "self documenting code" etc. Both are still vulnerable to lazy practices though. I think the closest we've come to mandatory theory transfer is strongly typed, strictly typed languages. Few languages do both, but the ones that do are used in critical systems. Basically, we need to "slow down to go fast". (Taken from either "Clean Code" or "The Pragmatic Programmer", I forget which.)
Isn’t theory transfer the purpose of a requirements document? The purpose of the code/program is to meet the requirements and ultimately satisfy the Statement of Work and the contract.
@@brianernzen2509 Yes, but humans are ultimately the ones maintaining that code. Maybe with AI we'll be working at much higher levels of abstraction, but natural language can be just as difficult to decipher. It really comes down to communication skills.
What's the benefit of publishing it for Microsoft? They probably have some secrets they don't want to reveal (vulnerabilities, backdoors). That sh*t code is surely worthless, as we have Linux... :)
I've been thinking about this problem as well and have also pondered ways to capture the design decisions that go into writing code. Basically, the code answers the question "what does the program do", but the most important questions are "why does the program do X" and "why does it do X in the way that it does". Behind every program lies a conceptual map of the problem space that only gets partially expressed by the code. Trying to understand this conceptual map by reading the source code is like reverse engineering software from assembly into idiomatic high level code: certainly possible with enough time and experience, but very inefficient. On the other hand, approaching the code with the conceptual map already figured out makes it trivially easy to understand the code.
I love this idea. I come from physics to coding. You can turn equations into code and vice versa. Every code is a representation of the underlaying phenomenon that it describes. A scheduler for sales is it self a model of sales. I even think that science is getting to a point where this kind of software representations will be more important than the symbolic ones just for practicing. Because even when you have the mathematical symbols you need to turn them into code to make predictions to then test the theory. You can skip all of that with just representing the theory as code.
Wrt sharing the code in my opinion one of the best approaches to that kinda of "theory" exposing coding would be the blueprint system from unreal. I think it allows people not used to big blocks of text to grasp the ideas behind certain things and have the represented visually. Amazing video!
![The moment we stopped understanding AI [AlexNet]](http://i.ytimg.com/vi/UZDiGooFs54/mqdefault.jpg)
I spent a ridiculous amount of time on this video. If you liked it, please consider sharing it with a colleague! My interactive git cheatsheet is coming soon™, go grab it here once it's released: philomatics.com/git-cheatsheet
Great video! One suggestion, please try and not do that weird Euro upspeak with your voice next time.
Good job! ❤
The transfer of theory seems quite important in a world where programmers change positions ever 2-3 years.
That alone might be responsible for a lot of bad code and bad architecture.
A meta language to facilitate transfer seems quite interesting. It's mainly the abstractions and interactions that are hard to transfer, right!?
I think, languages could do a better job of representing/expressing these. Concepts introduced to C++ come to mind, but that's rather niche.
Thank you for pointing my attention to this essay. I’m reading the original now. ;-)
Great video! Where I work, we've inherited a messy codebase, and most of the persons with the core domain knowledge has left the project. These questions keep me awake at night, and your video gave me a lot of inspiration and ideas!
Oh, and yes, please do share your ideas on your new language! I would love such a video!
The value of my source code is how much I've learned from writing it.
If you only write code only for yourself there's no problem with source code that only has value to you. I think the video is geared more towards the value of source code to other developers, to a software project, or to a company developing the software.
if I don't feel that I am learning anything new that has value when writing code at a job, then it's time for me to move on.. And do note, that learning new stuff is not only code, there is also domain knowledge...
Maybe the real treasure is the friends we made along the way :D
@@lbGkifoo1bj12e9plhjfWA Absolutely, moving on to another project when years of domain knowledge has built up can feel like bereavement (in the extreme) but the collection of domain knowledge across
disciplines and projects is what ultimately forms our ability to tackle new projects. It's important to keep moving and keep challenging ourselves. To step outside our comfort zone is how we excel ourselves.
But then it is only valuable to you.
I would value it at about $15 trillion because I don't want anyone seeing how bad of a programmer I am
lmao
😂 monetary value: $0.5. Value to my sense of pride: priceless
I'd settle for $100 mil. That's enough that I don't care what anyone thinks about my code
Just don't make it open source, works for windows
omg X pfp
I forget where I heard it, but best advice is to think of code not as a financial asset, but a financial liability: The more you have, the more expensive it is to maintain. And if you can accomplish the same outcome with less (or none), you’re better off.
Fully agreed! Code is a liability, not an asset would almost have been the video title
I heard this sentiment in a video about the single core developer of lichess :-)
So, If I don't have inhouse code and everything is outsourced or acquired via SaaS is better ? more layers of expenses so my profit goes to others so they have to maintain the very code my company relies on?; no thank you; they need to go this road too at the end of the day...
@@jorgechristophergarzasepul3209 I think the point was to rely on less code, not to outsource the code.
You could make the point then that the value of code is actually negative - better make sure to offset that cost by fostering an environment where the actual value (i.e. the programmer's mental model as brilliantly argumented in this video) is retained.
I keep a diary for each project, writing down what approaches I am considering and why I chose "the one" to go forward.
This helps a ton when I come back to a project after a few months. Skim through the last days, maybe look up the decision which is giving me a headache now. Sometimes an underlying assumption changed and another approach is better. But most of the time I did forget about some detail which made the chosen approach the only feasable one.
I do the same thing! Mainly for myself, helps me put projects down and pick them back up at a later time.
I hope orgmode is made for this.. though i have note/ folder with notes in markdown for every project
Do you keep the diary in a timeline format, or as a collection of notes on topics, without the time aspect?
@@philomatics I do something similar in Obsidian, but not in dairy log style. It's mostly me explaining it to myself and what I want to do, instead of what I did. I'd love a video on this.
@Tieno I was trying to use obsidian inside my project so people could just download it, but I ended up just using MD files directly. I am still interested in using a shared vault though.
The real value of our source code is the friends we made along the way.
I'm not sure if I fully agree here, but it proves the point that documentation should explain the idea or theory behind the code instead of merely repeating its functionality
Right, I think a distinction of documentation types needs to be made here. Surely there is mapping the DSL (Domain Specific Language) between code and the real world, but like every other form of good prose, there is the invitation into the author's thought process in observing a particular field. This is not only an area where hackers would struggle to recreate, but also AI; as it is the quintessential human artifact.
Great video! Years ago we had managers who got a bit obsessed with security of our source code. When I argued that our source being stolen wouldn’t hurt us, the scenario they brought up was “what if a hacker takes a USB stick with our code to our biggest competitor”. To demonstrate how ridiculous this idea was, I asked them to imagine the opposite: what would you do if a hacker tried to sell your competitor’s source code to you? You’d throw them out without a second thought. It didn’t do any good though, they couldn’t let go of the idea that their source code was a precious jewel.
Sorry, you’ll be not a writer for sure. The conditional paste tense stuff is so ubiquitous in your comment, that is makes the whole just unreadable
@@Jendrus12 eventho English’s not my native language, I understood the entire post.
Could you explain what part you missed?
@@Jendrus12 Seriously, you're going to diss tense in a sentence containing "a thick, soft, moist substance typically produced by mixing dry ingredients with a liquid."
i like paranoid people. we can sell more stuff to them to make them feel secure ^.^
Guys, my apologies. Had a tough day and IQ lowered significantly then. You’re right, the comment is quite readable and clear. But also could have some lifting 😅
Paste tense!! 😂
+1 vote for the video diving into the project you've been tinkering with that helps programmers capture and share the philosophy of the code.
Thanks for letting me know! Might be a while before I got something worth showing but good to know people are interested :)
I was tasked once with fixing a broken script that had to comb through petabytes of git repos. The script would take 8 days to run. I poked around in it for a few days. Then I chose to throw it out and rewrite it. By the time I had a working build that ran, it took 5 hours to run. In total, that whole process including getting a valid result from the new script took me less time than the original script took to run.
noiceee
Petabytes of git repos is all of public github and friends. What were you looking for?
Thats cool! A classic example of shit code, or "uninformed coding"
Careful though! Often times, the code you don't understand has the most important design decisions in it. Some teams take years to recover from decisions to scrap things they don't understand. Make sure you fully understand it first, then it might be the right call to replace. But usually by the time it makes sense, you know how to fix it anyway.
@@username7763 Definitely. I was careful to reverse engineer what the code was doing and double check with the team that set the original requirements to determine if particular behavior needed to be preserved. You should never wantonly rewrite something thinking you’re going to magically fix everything, but if you exercise good judgement and caution to preserve desired behavior, as you say, by the time you determine you should rewrite it, you’ll know what you’re doing and will probably improve on the original.
Tractability is the single most compelling reason to document your code meticulously. If your future self doesn't care what decisions went into your code then tractability is irrelevant, think automatically generated code. However, if your code is going to be read, re-read, re-interpreted, and used as a reference or jumping off point then it's really important for people to understand the ideas that went into that process. The assumption that the process you followed to developing a module was intuitive and therefore intuitive to all experienced developers is exclusionary at it's core. The notion of intuition is a completely subjective mark.
Only if that code is immutable. Maintaining comments is a lot harder than code because there's no compiler to check them.
@@Turalcar I recently thought about this and I'm starting to flip back to using comments. Why? Because the assumption that code is going to be unmaintained is a dangerous self fulfilling prophecy. Of course, I write my code in a legible, clear cut way, but what if I want to include a chart to illustrate the way an adapter connects two or more application layers? I feel like "just adding it to confluence" is a bit -ded. Having deep documentation but then separating it from the code, doesn't seem like eliminating unmaintainable comments.
Given the AIs capability of maintaining code and such, I think a deeper code ownership might become more viable and "orphaned" throwaway code might become more distinct. Yet, of course I also use AI slop when it's beneficial.
@@FenrirRobu That's almost the opposite of what I said: comments aren't as bad in code that won't be maintained because they are less likely to diverge.
In total, they bring negative value: you either need to maintain them (which is harder per-line than code because no static checks) or they'll mislead you at some point.
Almost all of my work is maintenance so the code is already better than what existing LLMs can produce.
@@Turalcar And while I understand that argument, I am starting to disagree with the position. Yes, code that changes a lot and has comments will require more comment edits than code which is basically a textbook and never changes.
However, I am leaning towards the position that such code - dynamic but not "maintained with documentation" should be scrutinized more. To be clear - I see documentation (clear, precise and concise one) as a part of the "maintenance" spectrum and maintaing as being part of quality. With the opposite being code that is garbled by excessive edits with meaningless or confusing variable names, unreachable conditions, misleading comments and archaic commented out code as the unmaintained part.
In my last corporate job we had a lot of "temporary" code that actually was not very temporary at all, but there was the assumption that it would be. In reality the developers left and there was a code ownership crisis due to turnover. In that case the code was both valuable and a cost sink, because it kept the system running but also it needed to be rediscovered.
So I think that the "low maintenance code" (not accusing you of doing that, to be clear) or "build fast and break things" mentality is overused nowadays. It seems like the default assumption is that we can only write bad code at first so let's just commit it in with the MVP as long as it runs. While of course, other projects exist with high requirements for each code change.
I don't believe it matters, whether the process you followed while developing a module was intuitive or not. And it's really not obvious to me that knowledge of that process would matter at all for future readers/users of your code. I can't think of a time I cared.
If something is complicated, then it's faster and more reliable to directly read the code, rather than reading a developer's rant about how they _think_ the code works. Especially since that documentation is never going to be complete enough, and might even be misleading or plain wrong, at times. A documentation is fine too: but it's a comfort thing, mostly useful to provide examples on how to use a tool. Unless you're developing a framework, you don't really need it. What you need is clear code. Code that rarely, if ever, needs comments or explanations.
Haven't watched yet, but sweet to hear code is cheap or free! Finally I don't have to code things myself and can hire people to do it for literal pennies!
Makes my life so much easier
Code is worthless, if it doesn't solve a problem. Then it's worth as much, as the solved problem is valued.
Your understanding of your code for anything but a finished product is more valuable than the code itself in a substantial fraction of cases.
Holy shit. Are you the author of "How to hire senior developers: Give them more autonomy"? I read it years ago and it pointed me to Naur's article which I also read and both have shaped how I really think about programming since.
Oh cool that you read it! Yup, that's me :) Thanks for the nice comment!
Don't listent to this guy.
I've license my own source code for hundreds of thousands of dollars
If nobody uses your binaries, then, of course, your source is worthless, BUT
if ALOT of people use your binaries, your source code is 1,000% GOLD.
@@philomaticsyou wrote books?.. now you are a 10x engineer
Can i do a interview with you podcast like in the future?
@@vaisakh_kmor just a bored college professor
What about an old code that consistently passes security audits each year? You can assign value to anything, but that doesn’t necessarily make it profitable. From my experience with various CRMs, on-premise solutions, SaaS, ML, pipelines, algorithms, and other software types, it’s not the latest framework that defines the code’s value...it’s the profit it generates.
Nothing 'generates' profit. Profits are extracted. And also, does every byte have to be profitable in isolation?
Basically you are saying that programming is the neverending everlasting project support. Which implies that there's nothing to brag about how many projects you've done, but rather how many projects you're involved in and support at a time is telling how good you are. In other words understanding the business logic quickly is a must
This still sounds like oversimplification of more complex problem :) The code clearly has value. You basically say, that it may not be economical to increase its value in certain circumstances, which is applicable to everything.
Interesting point of view. But to clarify, I think my main point is more that there are diminishing returns, and that further adding documentation/code does not further increase its value.
@@philomatics There are diminishing returns with almost everything, just consider what we do to "satisfy" Moores law. In the beginning we just scaled masks down with few simple tricks, now we are pouring millions of dollars just to shave off bunch of atoms. Same goes for building thermal insulation - there is point at which building is considered passive, but there is still loss of heat. You can mitigate half of that loss by doubling insulation thickness, but there is point at which it stops being worth it. So in this regard, I would say "such is life".
As value is subjective, I would say, that these things are defined by market demand. But company environment does not have such mechanism, so it is easy for some manager to pursue a pointless goal. I would say, that pointless goals are made of blanket statements, so here also applies, that the value of goal making is in the process. See, I could have said, that management has no value :)
Anyway, sorry for rant, I don't even know what this channel is about, just clicked on random video.
@@philomatics I was considering my latest interest a very different proposition: games for old microcomputers/consoles and emulators. In that case documentation could be a lot of non-commercial value to the community, and even heightening and extended the creator's reputation (and perhaps even some economic benefit). And for the employing game company (like Nintendo) keeping that code secret for it's viable commercial life, or second life, would be valuable. These are two extremes that don't follow your thinking at all, as niche as the cases may be. I do think you have generalized much too much, it is an oversimplification that applies mainly to a certain kind of code, although it may be a large segment of what average code monkeys work on.
main problem with documentation of code is, the code changes all the time, so the documentation is outdatet super fast
Super interesting point comparing not reading other devs code to being a writer that doesn’t read. We take a lot of snippets from stack overflow but we don’t often dig into a package to try to understand it. You’ve inspired me to start doing that more!
Code review dude, code review. And do it for the good reason: sharing knowledge in a reciprocal way. That's it.
probably this video was life changing. You condensed some hard theory into 17 minutes gracefully, extremelly well done!
Thought experiment: You have a compiler that has an "approve build" button. You may build and run test builds that only function on your dev system as many times as you like until you "Approve Build for Distribution". As soon as the build is approved, all of the source code used to build it is deleted. That approved build is locked in and cannot be changed. Was any value lost?
Let's modify that a little. You can now add extension modules to any approved build you found online. But once you approve that extension for distribution, the extension's source is also permanently discarded. Was any value lost?
Now for both scenarios, let's assume an end user has purchased one of these builds and has found a bug in a feature that is critical for them to use the software for what they intended. Was any value lost? We can write a new module to extend the old one. Or an entire new build from scratch specifically designed for this client's needs. Was the value proposition shifted at all?
I feel like the message the video is trying to get across has some genuine merit, but the optics in how it's being presented is probably going to give people the wrong idea and do more damage than good for it. *Especially* with that thumbnail. Though for anyone taking the thumbnail itself on surface value, I urge them to consider "If you were to delete all of your source-code for the project you're working on right now, are you still going to be able to make meaningful progress tomorrow?" That's gonna be a yes and a no for some and others, but I just don't want anyone to get pulled in by the short catchy one-liner and then do something regrettable for it.
(That and it's kind of a hard swerve from the previous trend of Git-specific topics, and I'm assuming the largely git-focused video description is probably the remnants of a slightly edited template than it is meant to be relevant to this specific video.)
I mean give him props for the clickbait title ya gotta appeal to the YT algorithm anyway. I found this video very interesting though.
This is shown surprisingly well when you use AI to code. Once you pass the context window, it's basically like having a new programmer each time, as it can't remember what it was doing at the start to get the program going. Your code has to have enough details for the new coder to understand and continue it, which is incredibly hard/impossible to accomplish. So the best the next guy can do is try to catch up to things that are documented, it'll still completely miss all the undocumented steps you took to get there. The coder's understanding of the project is far more important than the code.
This seems highly industry-dependent. A lot of the code I've worked with doesn't change since it makes money and contains trade secrets...
Yeah this video really should have had a disclaimer that it is incredibly specific and that a lot of source code is EXTREMELY valuable. Also, I've absolutely been able to go into code bases with hundreds of thousands of lines of code or more, and been able to modify things or add features on day one.
And think of the value of so much source code when it comes to trading & finances, or proprietary curation algorithms, or some of the closed source AI models, or the value of source code when it comes to TRAINING models. There are an infinite amount of ways that just the source code itself can be valuable and useful.
@@cooltrashgamer It's not the code that is valuable in most of those cases (well except business code directly, or formulas when you already possess all the theoretical knowledge except this formula), it is the way the code does it that is interesting. It is like a map of how to complete this task specifically that is important in that code.
@@rvvon1214 That is such a bike shedding statement, it's not the instructions that make the computer do things that are valuable! It's the computer doing things!
Getting a computer to do things can be massively valuable, and pretending like source code -> machine code mapping somehow means that only the machine code is valuable and not the source code is an asinine sentiment.
@@cooltrashgamer What's very specific is code that exposes "secret sauce". Most code hides no secret sauce, just vaguely explained structures that do nothing special in the end.
@@randomuser66438 Yeah, but even in no secret sauce examples, if it was trivial to RE any program, everything would be inherently crackable immediately. Cracking to even get a program to run on another computer without actually altering behavior can take months of hard work and research.
Having the actual source code would be valuable, which is why some leaks of source code that aren't even hidden behind a server are still valuable to buy.
Very nice video and information, just two observations:
1. Getting the source code of a project is useful mainly for copying specific techniques (how is he grabbing the screen content?, how is he communicating without NAT? etc) It is the understanding of the field the code is written for and the interactions of its modules (objects, etc) that requires effort and understanding from the programmer and it takes time to achieve. This is why training a programmer in a specific field (scientific field, engineering field, a framework ...) is a serious investment of the company and also why sometimes it can take days of studying and/or planning just to write a few lines of code.
2. Being able to get into a code easily, just to fix a small thing, requires the code to be so tightly separated that it consists of small black boxes so that changes to each black box can be easily estimated without the need to understand the whole architecture or interactions with other parts of the code. In practice, this is very difficult to achieve and very costly, plus the need for high skilled software architects. Also, it will lead to paranoid levels of abstraction of the whole construct.
If it's some companies I've seen, then it could be worth millions, as there's still people stupid enough to store their admin passwords in source code on the cloud.
True. Plus if you could how a code base's internals are operating, you could seek out attack vectors for exploitation. I've even seen code that in-lines server and port settings depending on IF DEBUG\DEVELOPMENT statements. Code Theft = Data Theft = Reputational damage + Fines + Class Action lawsuit.
A side note, but when thinking of the product being the “solution” to problems. I suddenly remembered that many “solutions” turned out to be good ideas that even the creator didn’t know.
For example, in Math, the guy who first came up with calculus wrote in the documentation that “this is just a cleaver hack please don’t ship it into prod”. But it turns out, the solution is actually super useful and is basically what the entire modern math is based on.
I was sleepy before watching this, but now you've got my gears spinning. I definitely want that follow-up language video. Btw, this is one of the reasons why the language Zig insists on no hidden control flow.
Same here
I feel that the best theory transfer languages we have today are DML and DDL in SQL. The "metadata" of relational database structures and transactional processes defines so many inherent characteristics of theoretical models that you can literally use it all to auto-generate code that does 80% of whatever you need done in the vast majority of applications without any use of ML in any way. I have seen this in practice many times, and did it myself decades ago. Tables, views, and stored procedures get you nearly all the way there in the majority of CRUD applications with zero code needing to be written. And SQL is already practically natural language, so there isn't even a need to go nuts with trying to use "AI" to bridge the gap between NL grammars and context-free grammars.
The concert pianist metaphor does not work because there is not one single correct way to play a piece. Also, I can very easily write down interpretation notes about a piece that accurately convey the changes in dynamic and tempo necessary for a specific interpretation. We literally use written notes all the time.
i mean having the original developer is the best way. but you caaaaaan get by just reading the code. with enough experience, that gets easier. programming is an art. you were spot on with the pianist teaching you to play a song as she does.
This has to be the best coding channel i've ever stumbled upon. I was making a consultancy platform for my college department and with this video I understood why is it too hard to explain to teachers ( as a part of evaluation ) what we actually build. The entire problem was mapping different roles to different silos and make controllers that interconnect. And I truly agree, the source code actually is not worth a lot.
code isn't useless; it's a valuable product of understanding
A reasonably done codebase may have general-purpose routines or particular algorithms that might save a competitor time. And not surprisingly, those are the things usually sought.
Good point! Research code/ideas might also fall in the same category.
The value is not the code, but the knowledge about how to solve particular problems.
So of security is too good to steal the code, try alcohol and an attractive person of the opposite sex on the developer.
@@sealsharp”try alcohol and an attractive person of the opposite sex” Greater lengths have been tried to steal information.
my impressions: value correlates to intended change.
-complete code is desirable with non-existent management (valuable code)
-incomplete code is tenuous with dynamic development driven by momentum (valuable leading programmers)
-neverending code is tenuous with constant management (valuable programmer economy)
-complete code - from open source with minimal module-granular functionality - is valuable (value in code)
-uncompletable code - of software developers with minimal foresight - is cheap (value towards programmers)
-decrepit code - from software companies employing minimal simplicity - is worthless (value towards company)
hence, valuable code is free and timeless, everything else is a business venture.
Interesting perspective, thanks for sharing! Might indeed be a scale.
Dude, where has this video been all my career??? I’m still young, but still!! Good stuff!!
Systems engineers choking while listening to the tech mess described here
I’m choking. I’m not currently a systems engineering and I have never been a programmer. To me, all that matters is validated and verifiable requirements. Every line of code should be written with the purpose of satisfying a requirement. A line of code that doesn’t meet a requirement should not be written.
I've been saying this at work for years. It's not the solution that is our edge, it's the fact that we can come up with these solutions. If someone takes them, they will just be stuck in our old past. Great vid! 👍
It was your comment at the end that made want to comment. I wonder how common it is to start a channel for one reason then fall down into a different hole. For me tutorial hell exists on both sides of a tutorial and I really don't want to be on any side 🤭 I don't know which hole you fell into, but I'm glad to hear that are are crawling out with this video. 👊
I love the fact that the company called panic, didn't panic when most companies would in that situation.
Interesting, video! I did find the statements quite black and white. I do think there are ways to make it easier to transfer this domain knowledge, one way is to do more Domain driven development. Even reading code as you stated at the end is a way to transfer this knowledge, were at the beginning of the video you state that knowledge can only be transferred by working closely with other developers. Open source libraries are a great of of developers using other peoples code and also contributing to it.
The domains will have to mimick/represent real world concepts (or at least they usually are), the trick is we usually don't try to mirror that concept 1:1 in our code, because that would be really hard and time consuming, let alone that we don't mostly need many of the properties of the real-world concept in our code, and that makes the ddd basically useless or highly inefficient to say the least in communicating this theory.
Wow, this is a fundamental insight into some of the deeper questions that are in the back of my mind during work. Great explanation on e.g. why onboarding new developers has always proven impossible simply by documentation on processes. It always seems to depend on close 1on1 interaction and co-developing ...
If my programs are worthless, clearly you don't need a copy of them.
This video could not have come to me at a better time.... This really opened my perspective and reignited my motivation. Thank You...
I think "source code" as portrayed here doesn't really address all of the types of source code. Code that is developed for a very specific context often is difficult to generalize, and so the theory of the code is bound to its situation for which the solution was engineered. However, source code and documentation can be quite useful when they are more widely applicable and can be generalized. This requires a theory of code that abstracts the process of writing code into solving separate smaller problems, these problems individually being of interest apart from the whole solution the project is intended to address. I would argue that code and documentation so constructed is quite valuable, but rarely does the perspective on a problem transcend its immediate needs and therefore this is quite rare.
This is a very good point and probably a good middle ground for my admittedly pretty one-sided portrayal in the video. I think one example for such code might be research code, where the core idea represented by it has value itself.
Modders understand better than most professionals how to absorb the intents and theories of the programmers from the code base itself. It's not impossible, and gets easier with practice. My very first programming job was to assume responsibility for abandoned yet wildly popular code. My own love for the work made me more dedicated to take what was there and make it better than to abolish it all and replace it.
Code is ephemeral, concepts are eternal
I was always haunted by the idea of source code leak or theft. Your video gave me a new perspective to think about. One of my struggle lies on a proprietary financial trading software I wrote for myself which gave me 40+% return last year, but I am stuck to sell it out for fear that my code could be hacked. Now your point is really worth considering because what really worth is the theory behind and not just the code alone. That's so real and to the point. Thank you for your video explaining that
1:57 microsoft would never steal someone elses code...? Priceless 😂😂😂😂😂😂
The value of source code is in the experience and expertise of those professionals who coded it, understand it, and upkeep it.
Code rots so fast. Even if code had value *at the moment it was written*, because it was solving a problem that needed a solution asap, after a while the value depreciates and the problem goes away for many possible reasons.
That's circular reasoning. If code is written for a problem ASAP, it could rot fast. But what if it's code for ASCII lowercase to uppercase conversion? Sure, we can obtain this code in seconds with Google, but it's a simple example of evergreen code.
But if it's not valuable, then what about code for crystal growth? Or a grammar book?
While I extend this to trade secrets and patents, I do believe that code, architecture and decisions can absolutely be part of a competitive advantage. Like C has not really been fully replaced even in 50 years, and C# is being replaced by languages that just implement the same features.
If you had a superb C compiler, it could be valuable for a long time. Especially the source code, since it would be a pain to edit it without the original source, whether you know the original theory behind each decision or not.
Other examples are MP3s, JPEGs, PDFs.
@@FenrirRobu right, good luck finding a meaningful use case for your ASCII lowercase to uppercase conversion in the world of UTF. C compilers rot faster than anything else (as a former full time Clang contributor I know what I am talking about). Yes, there are some very foundational things that are eternal, like BLAS and LAPACK, TeX and Metafont, bc, and so on. But hardly any private company ever written proprietary code of this scale of importance.
@@vitalyl1327 it's true that many companies have not made important code, and many problems become less important, like with UTF-compatible uppercase conversion, the old ASCII code becomes only one conditional branch.
I'm interested if C compilers' changing code is the result of fast innovations or other factors, because there was a long period where the actual C spec did not change much.
Other similar products are SQL databases, file systems, system utilities, emulators, mathematical libraries, simulators, maybe some parts of graphics libraries.
It's still the wild west, but it's possible that Transformers and Diffusers might be long standing specs.
Whether the implementation changes constantly or not, there are many bugs or not, market shifts or not is circumstantial. As a whole, I will say that there's a sea of rotten code out there, but not all code is doomed to be rotting.
There are plenty of programs that have been in use unaltered for 30+ years and to change one line of source code might require a year or more of testing costing millions of dollars.
What you call "optimizing for transfer of theory", I might call "information design" (though I only discovered this term recently). Over the last 20 years I often find myself coming back to the question of the ideal way to bring this kind of practice to programming. For example, the ways to allow much richer, more clearly specified, and more legible programs without increasing the cost of maintainability or explainability. I'm sure you have very different ideas to what I've been pondering but definitely something I'd love to see more of.
Absolutely agree. This may also explain why so many different languages and frameworks exist.
I agree with a lot of your thesis. I think it is weaker for tools than it is for targeted applications. Imaging trying to "rewrite from scratch" a monster like Mysql or Eclipse, rather than starting with the existing source code.
I am an Indi developer, I put code for my commercial projects on display if an interviewer asks me for projects, duing that time when my code is open I do push any new code changes until I lock the repo again.
When RUclips recommended this video, I did not click it because it looked like one of a million others like it: "X is trash! Here's what I think!" RUclips would not stop recommending it, so I relented. The theories and your rhetoric sound really convincing and I am encouraged to do my own research because of your video.
Theory making view of programming is especially important now with large language models being able to read our codes instantly. I felt this video pretty thought provoking when I think about how I could archive/transfer/modify technical knowledge with new tools.
Great vid, this is why mentors are so key. You just shift the world to the senior dev when onboarding a new dev.
Abstractions are helpful for prototyping but an antipattern for understanding. Especially object oriented programming. Now i can’t just ask “When is this called?” or “What functions own this data structure?” I have to ask “When is this constructed?” “When is it destroyed?” “What is its lifetime?” “Where is it stored?” “What does it store?”
I mean, that's the same with interfaces, composition, and pretty much any layer of abstraction
a lack of abstraction is also just as harmful
"which platform-specific quirk is this leveraging?" "why do it this way?" "what problem is this even solving?" "where is the business logic?"
@@MagicGonads abstractions fomt make those problems go away and OOP certainly doesnt do anything special to prevent those problems
You just blew my mind. And you were able to articulate something that I've been feeling for a long time. Please do a video on your theoretical programing language! Maybe we can open source it and it will be a living experiment for the theory building programming language.
Incidentally, I think that dev notes are the most useful part of code, and I personally try to include as much dev notes written in non-technical language as possible. I now realize that I was using dev notes as a way to pass my theory building knowledge. I would write the "why" behind my code.
I think a language like you mentioned at the end would be very helpful for many programmers so keep up the effort.
I think there is a difference between continious access to source code and one time access. Also some things have a robust internal implementations, that can't be easily copied just by looking at the product. For example chat gpt will lose a lot if theit model's source code was leaked
Logistically, this doesn't hold for any of the extremely large LLMs like Gemini or ChatGPT because the number of people with the resources to run or train anything similar is extremely low and because in the case of most machine learning neural network based models the "source code" doesn't matter as much as knowing the training dataset, the training parameters, and the output weights. And even if one has all of those available openly, because of how the training tends to be randomized, one is unlikely to get an identical outcome even if they used the same dataset and nearly identical dataset if the seed is different.
Fundamentally, the process of making a machine learning model is really not that hard and most comp sci students would be fully capable of doing so by the time they get their bachelors of science degree. But unless they have wealth in the billions, they're not going to be making multi-trillion parameter models in the near term with consumer grade hardware.
Au contraire, my friend. The models are already super simple. The pre training that givesOpenAI value is what would be super expensive.
They somehow managed to be valuable by guerrilla tactics of taking all the data it needs without concern for "copyright" before they went ahead and whined about how dangerous companies like it were for profitable creative works and "public safety", which is so laughable that they can act like aYakuza yet pretend to be angels 😂
@@SimGunther They have lots and lots of optimisations that would help their competitors. They won't be able to use the code as is, but it has lots and lots of hidden info, that can be extracted and is very valuable
@@SimGunther "The pre training that givesOpenAI value is what would be super expensive."
And the loads and loads of post-training/fine-tuning to correct myriad undesirable behaviors, and frankly to make their products seem smarter (far closer to AGI) than they actually are.
Them releasing their actual model specs and training and fine-tuning processes would almost certainly be more valuable than the actual source code (especially to the research community), and would be entirely in line with their founding principles (which included _opposing_ opaque gatekeepers; they quickly became the thing they were supposed to be guarding against).
My personal hope, though, is that they and all the other companies who straight up stole for their training copyrighted data or other assets that at least require attribution (e.g. code licenses, Creative Commons licenses; as far as I know, they don't provide any attributions for such, which is clearly abusive and illegal) are sued into oblivion for obvious rampant and willful violation of copyright laws and various license terms. There is blatant malicious intent in this activity. They don't deserve to be allowed to stay in business behaving like that. As far as I'm concerned, any executives complicit in such choices should be facing criminal charges. An individual doing the same would be imprisoned for a long, long time, and probably bankrupted by fines and court losses.
This makes a lot of sense, at work we have a lot of systems that are constantly changing to fit the needs of our users better. I haven't been programming for long, but the amount of times I've seen super experienced devs make mistakes just because they were unfamiliar with the project is surprisingly high. Code is much more valuable when you have devs that are specifically familiar with that code.
I can tell you with absolute certainty if everyone can just compile and use Adobe for free, they will be out of business in less than a year.
Yes, the bulk of this video is intriguing, but that intro example is way off. If a competitor released a free copy from stolen code, they would be sued into oblivion. Panic wouldn’t be like “oh well, it doesn’t have our bugfixes”. Therefore the only way to ship stolen code is to conceal that fact, which isn’t itself commercially viable, to the actual more interesting point of the video, in that the real work is understanding the code, which that writing from scratch can be faster. Not to mention the ability to deconstruct the code and verify that parts of it are stolen etc. If companies didn’t care, they would just open source everything
@@omnipi > wHy Wont MiCroSoFt jUsT SteAl the coDe.
Bro literally never heard of the concept of copyright or DMCA.
TBH the examples shown feel more like damage control to me.
I do believe the core argument holds true though. It's hard for people to get on board.
But the argument of somehow people can understand the entirety of a system is ridiculous. I wonder if this guy ever worked on a large project. Literally no one understands Linux as a whole.
Overall, this video robbed me the wrong way. It's rare to see such a true statement being completely undermined by the examples.
Will they? If they just publish the code once, and never update it ever? I highly doubt it. Who would dig into all that code and continue to work on it?
Side note, I shudder to think what the Adobe code base must look like after all these years 😅
@@philomatics do you really need first party update though?
@@philomatics you can either sell code or hosting.
BTW, I'd rather people sell their code.
This is one of the most deep, everything-explaining type videos about coding I have watched; instant subscribe
Pity that it is completely misguided.
I believe that 'code' is essentially worthless without the people who built it, but this primarily applies to non-mature products. If a group had access to the source code of mature products like Office, MATLAB, or Tableau, they could disrupt the market by creating clone products and attracting investors to build from that point onward.
With the advent of large language models (LLMs) and their improving capabilities in understanding and reasoning, it is only a matter of time before an AI assistant can guide me through source code I've never worked on. This would help me get up to speed in a work-from-home environment where interaction with other developers on the project is difficult and formal.
So, in the end, code may not be worth close to zero.
Office has competitors like LibreOffice and OpenOffice which are just about as good and it still has tons of value. I don't think someone with the source code would do better. Particularly since MS would quickly add incompatibilities here and there jsut to keep their edge.
I feel writing code is like tending to a palace garden. It's a never ending work of getting to know all the plants, maintaining them through different seasons, experimenting with new ones, adapting the look of the garden based on fashion and practical needs.
The value here is the constant care, the knowledge and the efficiency in achieving the result. The garden will deteriorate within a few weeks if the Gardner is paid a lump sum for his work and let go.
Great analogy! Might steal that one.
I enjoyed this presentation but I disagree with it entirely. In fact I go so far to say that it is a harmful perspective. Here's why:
1. Failure to express the logic in documentation is still failure in documentation. Scientists still manage to communicate the most sophisticated ideas known to man in publications that their peers can grok. Software engineers do not do this because documentation is not seen as part of their craft, whereas in science writing is part of the craft (publish or perish) yet in software engineering not so much.
This is one of the reasons why some people insist that software engineering is not engineering. Can you imagine a structural engineer not documenting anything about the 6 lane overpass that he's just designed in his head?
2. The talk of the relationship between a component and the real world is avoidable by writing pure functions. The less a function knows about the rest of the world the better. This is also makes testing possible.
3.
Justifying your decision is what comments are supposed to do. When you return to some old code and you no longer understand why you did that shift and swap its not because you've forgotten the syntax for sift or swap but because back then you thought it was super obvious why these operations were necessary. Future you however realized that it was not super obvious after all. If you don't have the patience to explain why you are doing something don't be surprised when future you or no one else knows why.
4.
Human interaction is great and perhaps the fastest way to get knowledge across, but it does not scale and requires patience (which not many people have) and willingness to sacrifice productivity (which many orgs think they cannot afford) while this training is going on, time and other geographic constraints. It can and should supplement documentation but should not replace it. Many ideas have passed down from the ancients to us because someone in 123 BC decided to write it down.
Document your code, extensively and write top down wikis that start from the topmost modules and explain the relationship between them and work your way down. It is difficult but so is writing code; yet devs are willing to pay the price for writing code but unwilling to pay the price when it comes to documentation.
5. The value is not in the source? Tell that to Microsoft and ask them to rewrite Windows from scratch, or SAP or Bloomberg to rewrite their terminals. This is a ridiculous assertion. The knowledge in the head of the dev delivers no value to a customer. Only the source does that.
you guys talk way over my head - I think I disagree too - but my argument is simple: if it saves time it has value even if it is ancient
I had this thought recently when making a new startup, where we had to build a new workflow automation from scratch. People ask us -- why don't you just fork n8n? I think of it as having a high degree of programmability over the system you design. You can impose and translate your will on the development of your software platform, and you know the most efficient way to mobilize your team's human capital to adapt to new opportunities. This level of control and understanding is hard to replicate if you're simply forking someone else's open source project.
it is called knowledge based tech, the knowledge is in the company and the people
It's all.tacit and irreproducible
The source is just one expression of the culture of the people involved at that moment in time
i thought companies hate depending on people they can't easy replace if they get annoying with how much money they want to earn
@@Henry-sv3wv depends on the size of the company and the roles of the people
This stuff was great! As a system developer for 25 years, I know this to be very true, but I have never been able to articulate it so well!
My source code for Musique is literally worth billions. I plan to sell to Mark Zuckerberg for billions 😎👍
Just in case the deal falls through, I am offering a buck fifty. ;-)
Great ideas presented here. One main problem. You say you would hate as a programmer to have to document theory, but that is actually the precious resource that needs to be preserved. I challenge the notion that this is impossible. In actuality, the problem characteristic of the theory held in mind is that it is analog, and thus is in the very domain that humans are suited to manipulate. Consider how rich and compelling stories can be transferred through sequences of text: machines and lazy people (hacks) suck at this. A valuable "programmer" will be somewhat of an artist; able to succinctly convey discrete meaning from an infinite field of constructs using the codification of language.
A surprise to be sure, but a welcome one! I'd love to see more videos like this!
Finally, a reasonable explanation for all the phenomena I've been describing for the past 25 years!
Thank you for that, and greetings from Vienna! ^^
endlich eine vernünftige erklärung für die ganzen phänomene die ich eh schon seit 25 jahren umschreibe!
danke dafür & lg aus wien ^^
I don't think programmers don't read other's code.
Great video. I recently decided to code a CMS, and thought that I could just take bits from WordPress to make the process faster. I immediately realized that just reading the code was useless, without talking to the devs that wrote it. Though the WordPress code is well documented, I was still having trouble understand why the devs opted to use one method vs another. I'm now just coding the CMS completely from scratch as it's just faster to implement my own theories.
I will tell you the value of source code: try sell Microsoft to a buyer and tell him he can’t get the source code with the sale. And see how much you get for Microsoft. 😂😂😂
Man one of the real golden nuggets of this whole video was at the very end: We need to read other peoples source code and review it to get better at programming. This has been a HUGE leap for me in programming skills over the last 3-5 years now.
I've been able to position myself as an engine developer due to my interaction with open source engines (UE and Godot) and digging in and solving problems.
You should do a whole video on this. And so should I.
Thanks!
My favorite quote on this subject is that programming languages are for humans, not computers. Otherwise we would program in machine code.
Captivating video!
Some parts I figured out myself, but couldn't have expressed. This video and the article compiled and expanded it. Make more videos like this
👍👍👍
Not that I dont say that it's not true, but as someone who have seen lots of coding projects I also think this is a wrong view. The 'new code is cheaper then refactoring/maintaining old code'. The not maintaining old code is what makes code old code. And a mix of old and new code is what a project makes spaghetti, chaos and worthless.
It’s not always possible to keep maintaining old code. It’s not worth it.
@@krishnabharadwaj4715 Not always, but more often then not I think not really new code is made old by not maintaining.. I know everything has a shelf life.
But I feel like, in the code world the shelf life is the moment it is put on the shelf.. And that is the result ~I think~ of these kind of views.. ..And therefore I think this is a bad view of things.
I found this video insightful. I hope the CEO of my previous company watches it to understand the true value of employees. It's difficult to foresee the severe impact layoffs can have on development velocity until it's too late. Clean code can devolve into a Frankenstein's monster, leading to more bugs and downtimes that erode the trust of users and investors.
The code still has value. It can do job, even if it's buggy
Dude! The idea of a language that prioritizes communicating the theory? Go! It’s so explicit and upfront and consistent that it forces you to surface your “presuppositions”, not giving you macros or other compile-time code-gen facility. It can be painful to write, but I think this describes why it works so well for team projects!
Great video, however I think you are missing or confusing some things here.
The theft for example of the actual physical source code is a massive deal. Just because right away the company says "oh that code is already old and we are 1000 commits ahead of the old master" means nothing. That is called PR and damage control.
In the industries "Corporate Espionage" is a very real thing and companies spend billions on protecting their assets which includes source code.
If I were to walk into a corporations HQ with a USB drive and go up to a computer, sign into their code repos and click download all or something and walk out. What will happen to me ? Will I get arrested ? Will I have to give back the code ? OF COURSE.
Maybe that codebase has some algorithms that the competition wants to shorten their development process. Maybe the code has concepts that the competitions developers have never even dreamed of. Maybe their is a whole new programming language that when used can shorten development time by 90%.
The point is that source code itself can be both worthless and highly valuable at the same time.
I don't see Apple, Microsoft for example publishing on a daily basis their source code to their respective operating systems. Why ? Because they know if either company gets a hold of the code it will reveal things that neither want the other to know about. How to implement X, or how to implement Y, etc....
I mean to some extent yes, but in my opinion the bigger and more complicated a codebase is the less valuable it is to leak it. It would be catastrophic PR-wise that security was so low that something like that was allowed to happen, but in reality you can't just sell someone else's product on the open market that you built by simply stealing their code. The law would slam down on top of you so fast you'd have the wind knocked out of you. As for gaining valuable insight into how it works, if the codebase is huge and complicated you wouldn't know where to look, and if you did you'd probably be able to figure out the details by yourself more easily than stealing it. Most of the small efficiency hacks will be pretty opaque to you, and if you're building a different product for a different set of users they might not even apply to your use case. You can't just drop-in solutions from someone else's software unless you know why it's going to be efficient/do what you want/work at all, and once again that requires you to figure (a lot of) things out on your own... again. Unless you own a company with such a novel, valuable and well-kept secret technique that no one else in the entire world is using it in any open source project (I mean something like a solution to a major open problem like a fast algorithm for cracking factorization-based encryption e.g. RSA, which would give you a massive competitive advantage), your source code getting leaked probably will not mean much for your competitors.
Unless you're doing something very stupid like storing API keys in there. In that case you may be fucked.
> In the industries "Corporate Espionage" is a very real thing and companies spend billions on protecting their assets which includes source code.
Oh, you are not completely wrong here. But 99% of the source code is about as harmful a secret as, say, the lobby and outer layout of a company HQ.
Would you consider, say, boilerplate code to handle command line switches efficiently a trade secret? Or a C++ module that implements a standard that is widely used in the industry, like a TCP/IP stack, standardized switches or perhaps even something that enables Active Directory RBACs in a straightforward manner?
Any code written by IT (as opposed to R&D) is basically throwaway boilerplate code that is of no use to anyone else. The implementation has no direct value; but it does have indirect value insofar as automating specific tasks within the company. The code is generating value each and every day; but the person who wrote it did so once and the cost is already paid for.
That said, this implementation could reveal intimate details about manufacturing processes and how to best hack this specific site, so the code is not completely worthless either.
I know of a company whose source code was stolen and the code was offered to a competitor. That competitor just reported the thief. On the other hand, I have decompiled some programs to understand how they worked and shared that knowlege with other people, meaning the code source wasn't even required. Reverse engineering doesn't require having the source code, and it's probably way easier to just study the program from the outside most of the time.
I'm pretty sure the only thing valuable to an outsider in source code would be bugs and holes that pirates can take advantage of.
Loved this vid, highest value vid I've seen in a while on YT, not going to lie. Subscribed, and def would love to see your proposed ideas of incorporating the Theory Building View into IDEs more. This is such a meta topic, it's never even crossed my mind! I just told myself in the beginning "Of course writing it from scratch is faster most of the time" but then you started diving right into exactly why. Perfect for my typically low attention span xD, cause I would've stopped at that point.
1:36 …. Always love when a small start-up in a funding round is concerned that „some big company“ would steal something. Seriously, going through that pain and keeping it a secret at a company of more than 5 people is already hard. No, if they would want to do that, it would be much much much cheaper to just buy you instead of taking all this risk outside of a process. Phew
Also, the complication is not in the code for the most part, is in the business mechanics, clients, market, revenue, etc. The code alone means very little.
as a principal I often quote "nobody cares about your code" to dev teams, most useful code is lightweight and easy to replace and the behemoths that a lot of devs write are ultimately useless, most services I fix I do so by replacing the code entirely and my instruction to the teams I hand it off to is "heres how it works, if you dont like it go ahead and replace it"
Fascinating video, congrats!
Would really love a deeper look into programming paradigms that utilize this theory as a sort of framework for approaching problems in general before even touching an dev environment.
Don't listent to this guy.
*I've license my own source code for hundreds of thousands of dollars*
If nobody uses your binaries, then, of course, your source is worthless, BUT
if ALOT of people use your binaries, your source code is effing GOLD.
Is it really the binaries or your continued development and support of said binaries? Genuinely asking.
@@philomatics I don't understand the question. A company will want to license the source code for a version of the binary. We provide future source code releases to t hem too for addition money. The company cannot distribute any derivitives of the source or binaries.
Would they still pay for your binaries if your company would just vanish afterwards? In other words, is the promise of your continued support part of what gives your code its value?
Not to be that guy, but if you're selling binaries, then it is the binaries that have value. The source is only worth anything if you will need to provide different binaries in the future made from derived source.
@@philomatics They have the source code and can build it at will and/or add additional features/options/etc. Once they have the source, they really don't need us. That's the other point of getting the source.
It also depends on the quality of the documentation which can vary massively from mere function signatures with a (hopefully) a short sentence explaining its effect vs thorough tutorials that are well presented and easy to follow.
All the developers of apps that suddenly have some Chinese competitor that built exactly the same looking product but with much more aggressive marketing might see this differently.
Otherwise I mostly agree.
Its not hard to reverse engineer someone else's code.
@@batatanna have you ever lifted some custom VM? that's also packed/obfuscated/fuzzed dynamically and streams in modules from the internet and decrypts itself in the vm and each time the module is polymorphically different and has some sort of polymorphic executor in the vm that changes it's execution each time a function is used, that has also advanced timing checks inlined everywhere that are also polymorphically built? It's not that hard for someone to reverse something of value inside a binary, that is unprotected and has large set of boilerplate code, but try that in a protected binary lol which also has strong integrity checks and anti debugging.
@@depralexcrimson I stand by my point. You may not redo the exact same code, but by studying the functionality you are very capable of creating new code that does exactly that.
Theory transfer is largely the purpose behind "Clean Code" and by extension "Design Patterns". There are other flavors, like "self documenting code" etc. Both are still vulnerable to lazy practices though. I think the closest we've come to mandatory theory transfer is strongly typed, strictly typed languages. Few languages do both, but the ones that do are used in critical systems. Basically, we need to "slow down to go fast". (Taken from either "Clean Code" or "The Pragmatic Programmer", I forget which.)
Isn’t theory transfer the purpose of a requirements document? The purpose of the code/program is to meet the requirements and ultimately satisfy the Statement of Work and the contract.
@@brianernzen2509 Yes, but humans are ultimately the ones maintaining that code. Maybe with AI we'll be working at much higher levels of abstraction, but natural language can be just as difficult to decipher. It really comes down to communication skills.
So why isn’t microsoft publishing the source for windows xp or at least windows 2000 (workstation) if source code is worthless?
What's the benefit of publishing it for Microsoft? They probably have some secrets they don't want to reveal (vulnerabilities, backdoors).
That sh*t code is surely worthless, as we have Linux... :)
I've been thinking about this problem as well and have also pondered ways to capture the design decisions that go into writing code. Basically, the code answers the question "what does the program do", but the most important questions are "why does the program do X" and "why does it do X in the way that it does".
Behind every program lies a conceptual map of the problem space that only gets partially expressed by the code. Trying to understand this conceptual map by reading the source code is like reverse engineering software from assembly into idiomatic high level code: certainly possible with enough time and experience, but very inefficient.
On the other hand, approaching the code with the conceptual map already figured out makes it trivially easy to understand the code.
only 28.9k subs?? keep it up dude, this is high a great, high quality video. Loved watching!!
I love this idea. I come from physics to coding. You can turn equations into code and vice versa. Every code is a representation of the underlaying phenomenon that it describes. A scheduler for sales is it self a model of sales. I even think that science is getting to a point where this kind of software representations will be more important than the symbolic ones just for practicing. Because even when you have the mathematical symbols you need to turn them into code to make predictions to then test the theory. You can skip all of that with just representing the theory as code.
Wrt sharing the code in my opinion one of the best approaches to that kinda of "theory" exposing coding would be the blueprint system from unreal. I think it allows people not used to big blocks of text to grasp the ideas behind certain things and have the represented visually.
Amazing video!