The Value of Source Code
Summary
TLDRThe video challenges the traditional view of source code as a valuable asset, arguing that its true worth is often much lower than expected. Drawing from real-world examples, the speaker explores the concept of 'Theory Building' in programming, suggesting that the real value lies in the understanding and mapping of the code to the real world, rather than the code itself. It emphasizes that documentation and source code can't fully capture this theory, and personal interaction is key to transferring this knowledge between developers.
Takeaways
- 💻 Source code often has little standalone value, especially in evolving projects where the code changes frequently.
- 🚀 Even well-written, clean code with good documentation is often less valuable than the thought process and real-world mapping behind it.
- 🔑 The true value in programming lies in the theory and mapping of the code to real-world problems, rather than the code itself.
- 🧠 Programming involves building a mental model or theory of how the real world maps to code, which is difficult to communicate through documentation alone.
- 📉 Code, even if stolen, quickly becomes outdated and is often more easily rewritten from scratch than modified by an outsider.
- 👷 Large companies are not concerned with using others’ code because it’s faster for them to build their own versions based on their needs.
- 📚 Documenting every decision or theory behind a program is impractical and can't fully convey the programmer’s experience and intuition.
- 🎯 Programming decisions are often based on intuition, experience, and context, which are not easily translatable to new developers through code or documents.
- 🤝 Effective knowledge transfer in programming requires close personal interaction, not just reading code or documentation.
- 🔧 There’s a need for better tools and environments that focus on the quick transfer of the mental models (theories) between programmers, especially for large or complex projects.
Q & A
What was the main argument presented in the video regarding the value of source code?
-The main argument was that the actual value of source code is often much lower than people think, even in large projects. The speaker suggests that the true value lies not in the code itself but in the theory or understanding of how the code maps to real-world problems.
Why did the speaker consider Microsoft using their code to be unlikely?
-The speaker found it unlikely that Microsoft or any other large company would use their code because the code was poorly written, changed frequently, and was difficult to understand. It would have been faster for a large company to build the software from scratch rather than decipher their code.
What is the 'Theory Building View' of programming as explained in the video?
-The 'Theory Building View' of programming suggests that the true output of programming is not the code or technical artifacts, but the understanding (or theory) of how the code maps to real-world situations. This theory is built up in the programmer's mind and cannot be fully captured in documentation or code.
Why does the speaker argue that beautifully written code still has limited value?
-The speaker argues that even well-written code with complete test coverage and documentation has limited value because it does not capture the full context and understanding (theory) of why the code is structured in a certain way. This understanding is tied to the programmer's experience and intuition.
What example does the speaker give to support the idea that source code itself is of limited value?
-The speaker mentions Panic, a company whose source code was stolen by hackers. Panic did not worry about competitors using the stolen code, as they believed it would quickly become outdated and irrelevant without the ongoing context and improvements made by their team.
What are the three intangible aspects of programming theory that cannot be fully expressed in code or documentation, according to the speaker?
-The three intangible aspects are: (1) the mapping of each piece of code to the real world, (2) the justification for why certain technical decisions were made, and (3) the ability to adapt the code to new requirements based on changes in the real world.
Why does the speaker believe it's often faster to rewrite code from scratch rather than modify existing code?
-The speaker argues that it's often faster to write new code from scratch because understanding and modifying existing code requires rebuilding the entire theory of the program in one's mind. This can be more difficult than starting fresh with a new theory that fits the programmer's own experience and understanding.
What challenges do companies face when onboarding new developers, according to the video?
-Companies face challenges in onboarding new developers because much of the value in a program lies in the theory that exists only in the original developer's mind. This theory is difficult to transfer through documentation alone and requires close personal interaction to fully understand.
How does the speaker compare learning to program to other skills like playing a musical instrument?
-The speaker compares programming to learning a skill like playing a musical instrument, arguing that it requires personal interaction with someone who already possesses the necessary understanding. Just as you cannot learn to play an instrument by reading instructions alone, you cannot fully understand code without guidance from someone familiar with its theory.
What suggestions does the speaker offer for improving the transfer of programming knowledge?
-The speaker suggests that programming tools like languages, IDEs, and version control systems could do a better job of helping transfer the theory behind code. For example, tools could provide better overviews or interactive sessions to help new developers quickly understand and modify existing code.
Outlines
💻 The Value of Source Code in Modern Projects
The speaker begins by challenging the viewer to consider the value of their source code, suggesting that it might be much lower than expected. He reflects on his experience working on a large-scale project that involved complex tech stacks like augmented reality (AR) and computer vision. Despite the advanced nature of the project, a new manager raised concerns about the security of storing source code on GitHub, which led the speaker to question the true value of source code, even for significant projects.
🔓 The Impact of Open-Sourcing Code
The speaker delves deeper into the implications of open-sourcing a project. Reflecting on his startup experience, he concludes that even if they had made their code public, it likely wouldn’t have impacted their business significantly. Codebases in startups change frequently, making them hard to maintain and understand, especially for outsiders. Even companies like Microsoft would find it faster to rebuild from scratch than to attempt to use his team’s evolving, complex, and often broken code.
💡 Programming as Theory Building vs. Production
The speaker introduces the concept of 'programming as theory building' by citing an article by Turing Award winner Peter Naur. This perspective contrasts with the more common 'production view,' which sees programmers as producers of technical artifacts like code and documentation. Instead, Naur’s view focuses on the theory or the mapping between the real world and the code in the programmer’s mind, which cannot be fully expressed through written documentation. This theory-building process is essential to understanding and maintaining software.
🤯 The Intangible Nature of Programming Knowledge
The speaker argues that certain aspects of programming knowledge are intangible and hard to capture in code or documentation. One key aspect is understanding how the real world maps onto the codebase. The speaker highlights that documenting every real-world factor or mapping decision would be impractical, especially in complex environments like a factory setting, where business processes are constantly evolving and hard to predict.
⚖️ The Trade-Offs in Programming Decisions
Expanding on Naur’s theory, the speaker explains that programming often involves making trade-offs based on experience and intuition. Documenting every technical decision or alternative path is not practical, as there are infinite possible ways to implement a solution. This highlights the challenge of onboarding new developers and the impossibility of fully capturing the reasoning behind every design decision in a written document.
🔄 Adapting Code to the Changing Real World
The speaker’s strongest argument is that the real world is constantly changing, and software must adapt to new requirements. He uses the example of a factory app where workers’ behavior changed after production, leading to a need for quick updates. Only developers who understand the underlying theory of the code can effectively implement these changes, as documenting every potential real-world scenario would be impossible.
🛠️ The Importance of Close Collaboration
Naur’s final point emphasizes that programming knowledge can only be transferred through close personal interaction. The speaker likens this to learning a skill like playing an instrument or writing, where written instructions alone are insufficient. New developers must work closely with those who understand the program’s theory to learn how it fits into the larger real-world context and how to manage unexpected modifications.
🚀 The Future of Programming: Theory-Driven Tools
The speaker concludes by addressing the original question: source code holds little value on its own because it lacks the context of the theory behind it. This explains why it’s often faster to rebuild software from scratch rather than modify an existing project. He suggests that programming tools, languages, and environments should evolve to facilitate the transfer of this theory between developers, and he teases his own ongoing research into creating such a language.
Mindmap
Keywords
💡Source Code
💡Theory Building
💡Production View of Programming
💡Code Obsolescence
💡Domain Knowledge
💡Technical Debt
💡AR (Augmented Reality)
💡Mapping
💡Software Onboarding
💡Trade-offs
Highlights
The value of source code, even for larger projects, may be much closer to zero than expected.
A personal experience working on an augmented reality project for mapping large buildings like malls and airports, which required custom-built solutions before modern AR kits.
A former manager's concern that storing code on GitHub could allow Microsoft to take the code and build a competing service was deemed unrealistic.
The realization that open-sourcing the project would have had minimal impact because the code was constantly changing, poorly documented, and complex to set up.
Panic, a well-known software company, had its source code stolen, but they weren't too concerned about competitors using it due to how quickly it became outdated.
Source code on its own is often not the most valuable asset, as it quickly becomes outdated and difficult to understand or maintain without the original programmer's knowledge.
The Theory-Building view of programming by Turing Award winner Peter Naur suggests that the true value in programming lies in the mental model or 'theory' a programmer builds to map the code to real-world problems.
The production view of programming, where programmers are seen as replaceable, is contrasted with the theory-building view, where programmers create valuable mental models that are difficult to transfer or document.
Theory-building emphasizes that the code is just a side product; the real output is the mental mapping between the code and the real world, which is often incommunicable through documentation alone.
The limitations of documentation: key design ideas, justifications for technical decisions, and adaptations to real-world changes are difficult or impossible to document fully.
New programmers need personal interaction with the original developers to acquire the theory behind the code, similar to learning a skill like playing a musical instrument.
The faster solution is often to write new code from scratch rather than modify existing code, as building the original theory in a new programmer's head is time-consuming.
The high turnover in the software industry is problematic because much of the value in a programmer's knowledge is tied up in their individual understanding of the code, which isn't easily replaced.
The example of a factory app demonstrates the complexities in business processes that cannot easily be documented, such as secret smoke breaks affecting data entry consistency.
Future programming environments could improve by optimizing for faster theory transfer between developers, potentially through more interactive or live onboarding methods.
Transcripts
what's the value of your source code
like seriously take a moment to think
about this for your current project if
you had to put a dollar value on your
code what would that be in this video I
want to argue that even for bigger
projects this value is probably much
closer to zero than you might think I
also want to give you a new perspective
on programming as a whole inspired by
touring Award winner Peta Nawa I was
confronted with this question a few
years ago when I was working at a
smaller company doing intern ation
software so basically Google Maps in big
buildings like malls airports and
factories there was also an augmented
reality mode so we could display arrows
on the floor that show your destination
or additional information like virtual
signs or realtime info about machines
and factories it was a pretty cool
project and the text stack was super
interesting there was a low-level
computer vision component written in C++
for crossplatform support a native layer
for IOS and Android crossplatform
rendering and webgo and a pretty complex
admin interface for the web and you know
this project started in the early 2010s
so there was no AR kit or ar core that
made it easy to include some AR like
today we actually had to write that all
ourselves with some computer vision
libraries and we even worked together
with a research institute to get this to
work so basically this wasn't just
something anyone could easily recreate
on the team we just implicitly assumed
that our code was really valuable and
one of our major assets that then at
some point a new manager joined the
company and he had mostly worked in
bigger companies before and he was super
concerned with security so he argued
that we shouldn't keep our source code
in a cloud hosted GitHub repo he was
worried that Microsoft the owner of
GitHub might just be able to take our
code and build a competing service now
that's ridiculous of course Microsoft
would never do something like this like
they would never build an AI that just
uses your private code AS training data
like that would never happen right no
but seriously back then this got me
thinking why did this feel ridiculous
like if we leave all ethical and legal
concerns aside for a moment why wouldn't
Microsoft or any other big company just
use our code if they wanted to build a
competing service and then going even
further I thought what would happen if
we just open- sourced everything if we
put it all in a public repo with an open
license like MIT our investors would
probably have thought that we've got
crazy but other than that what direct
impact would that have had on our
company after thinking about this for a
while I think the answer back then would
have been absolutely nothing would have
changed you know we were still a young
startup so our code was changing pretty
drastically every couple weeks sometimes
we change major parts of the
architecture or rewrite components
because the requirements changed so
quickly as we discovered new things
about our customers and as it often goes
in such a situation the code quality was
pretty bad half the time the build
system was broken testing and
documentation was basically non-existent
and it was unlikely that anyone from
outside the team would even have gotten
the thing up and running even if they
did it would be outdated a moment later
so of course Microsoft would never take
our code they'd be much faster just
building it themselves from scratch than
trying to understand the crummy code
that we just hacked together but okay I
hear you say maybe your code was crummy
but my code is beautiful all right so
let's take a step back and assume the
opposite for a moment beautifully
written clean code with complete test
coverage oneclick build process
well-written documentation of
architecture and components would this
actually have changed the situation I
really don't think so you see in 2017
there was an incident of a pretty
high-profile source code theft the name
of the company was appropriately Panic
it's a company that makes high quality
software for Mac and iOS and they've
also released some games like Untitled
Goose game and firewatch they had the
full source code of most of their apps
stolen by hackers the attackers
threatened that they'd released the
source code and demanded a ransom but
Panic refused to pay and in a blog post
they went through all the worst case
scenarios of what the hackers could do
with the code they said that the worst
thing that could happen would be people
building cracked versions of their apps
that are full of malware but that was
already happening anyways even before
the source code was stolen just like
with most software like don't get me
wrong I'm sure this was a pretty bad
blow for panic and I'm not arguing that
stolen source code can't be damaging but
was Panic worried about competitors
stealing their high quality code in a
blog post they wrote that they weren't
too concerned with that mainly because
it would quickly become outdated that
source is already missing a ton of fixes
and improvements we committed over the
last week alone and 6 months from now it
will be missing major critical new
features in short it's old and getting
older so this is really interesting
right here we have a multi-million I
doll company basically saying that they
don't worry about competitors using
their code so if the value is not in the
code and documentation where is it and
why is writing new code sometimes faster
than understanding and modifying
existing code I couldn't read my head
around these questions until I stumbled
upon this article programming as Theory
building by touring Award winner panwa
if you've ever taking a compiler course
you might have used his work already
since he's the n in backos now form
anotation for specifying programming
languages that is still in use today in
his article na gives his view on this
surely very simple and easy to answer
question what is programming he says
that most people view programming as a
production process and he calls this the
production view of programming he argues
that some empirical observations in
software projects can't be explained
with this view but they can with this
alternative Theory building view of
programming I'm going to explain this
with some real life examples from one of
my previous Pro projects I was working
at a factory where the workers were
still using paper processes to document
their work we made a custom tablet app
to digitize this process now in the
production view of programming we of
course have programmers they get input
from external stakeholders and they
observe a slice of the real world that's
relevant to the problem they then take
this input and produce technical
artifacts as output so basically code
and
documentation the problem with this view
according to Nawa is that the technical
artifacts are the final output while the
programmers are viewed as easily
replaceable Machines That Just Produce
this output in contrast in his theory
building view the focus is on the
programmer who again observes the real
world and as they write the code in
their head they also build a mapping
between the code and the real world each
piece of the real world that's relevant
to the problem needs to be mapped to
some technical artifact that could for
example be a specific class method or
data structure an overall architectural
decision or maybe simply a line in the
documentation the main difference to the
production view is that the code is just
a side product the real product the real
output of this process is the theory the
mapping between the real world and the
code so basically the arrows in this
diagram are the real output everything
else is just a side
product now you might say well why don't
we just take this Theory and put it into
written documentation as
well then it would be really easy to
onboard new developers to our code so
they can be productive really fast but
nowah argues that exactly this step
isn't
possible he writes the code and its
documentation has proved insufficient as
a carrier of some of the most important
design ideas a main claim of the theory
building view of programming is that an
essential part of any program the theory
of it is something that could not be
conceivably expressed but is
inextricably bound to human beings now
that's a pretty strong claim but I think
that now has some really good Arguments
for it he says that there are three
different aspects of the theory that are
just in the programers minds and go
beyond what's visible in the source code
or documentation these three aspects are
intangible so they're difficult or even
impossible to communicate indirectly via
written documentation for the first one
of these aspects now says the programmer
must be able to explain for each part of
the code and for each of its overall
structural
characteristics what aspect or activity
of the world is matched by it so
basically someone new to the project
should be able to point at any piece of
code and the original programmer can
tell us how it's mapped to a specific
object or situation in the real world
and the other way around of course this
direction is even more difficult as now
our rides by far the larg largest part
of the world will of course lie outside
the scope of the code being Irrelevant
in the context however the decision that
a part of the world is relevant can only
be made by someone who understands the
whole
world so basically not everything in the
real world has a direct mapping to
source code and of course we as
programmers have to know and decide
which parts are actually relevant to the
problem at
hand for bigger projects I just don't
see how documenting all this information
would be practical so for example the
factory app that I mentioned earlier was
itself pretty simple but the underlying
business processes were super complex
there were different assembly lines and
machines involved also the environment
was changing and evolving quite often
workers changing their shifts around the
Wi-Fi in the factory would go down or be
unavailable in some areas machines would
break down stuff like that and downtime
in the factory was really expensive so
the app had to be prepared to handle all
these situations so even if we had had
the time and budget to document all this
I really don't see how anyone would have
benefited from that documentation it
would probably have been a couple
hundred pages and it would have been
really difficult finding the information
that you're actually looking for but
difficult is not impossible which is why
I think this is actually the weakest
argument naah makes for the theory
building view so let's take a look at
the other two arguments the second one
is that for each mapping we could have
chosen an entirely different
implementation in the
code so according to naah the programmer
having the theory of the program can
explain why each part of the program is
what it is in other words is able to
support the actual code with a
justification of some sort so basically
an explanation of why we made certain
technical decisions he goes on to
explain that this justification can just
be pressed into a set of rules but
instead requires intuition and
experience in my opinion programming is
a lot about choosing the right
trade-offs based on your experience and
compressing all these technical
decisions which are often based on
intuition into a written document seems
really impractical to me like for major
architectural decisions it makes
complete sense to document this but
imagine you had to justify in writing
every single technical decision you make
I think this would drive me insane and I
wonder how much value this would
actually provide to a newcomer who's
being onboarded to the project also for
each problem there's an infinite number
of possible implementations that we
could have chosen and new approaches or
architectures are being proposed every
day so we wouldn't just have to document
why we chose the current implementation
but also why we didn't choose any of the
millions of other possible
implementations so I think here it's
pretty clear that it's impossible to
document this aspect of the theory
exhaustively but now let's get to Na's
third and in my opinion strongest
argument for the theory building view
which is that the real world is
constantly changing and with those
changes come new requirements we as
program programmers then have to decide
how similar the new use case is to the
features that are already built into the
program like can we implement this
functionality with any of the existing
code or do we need to build entirely new
components or abstractions to cover this
use
case now i writes designing how a
modification is best incorporated into
an established program depends on the
perception of the similarity of the new
Demand with the operational facility
already built into the program I think
here it's pretty clear that this is
impossible to put into any kind of
written documentation since it involves
making decisions on how to deal with
changes in the real world that we
haven't anticipated yet otherwise we
could have just Incorporated them into
the design of the original program in
the first place let me give you another
real life example from the factory app
so after having the app in production
for a while we realized that the data
entry was somehow inconsistent it took
us a while to investigate but then we
found out that this was because of some
secret smoke breaks that the factory
workers took and that management didn't
know about once we figured this out it
was super easy for us in the core def
team to add a simple addition to the
code to deal with this case but I think
if we had handed the code over to the
client already it could have been
possible that they'd spend weeks to fix
this since they didn't know where
exactly to make changes to the code for
this of course it would have been
impossible to write down any hints or
guidance for dealing with this case in
advance since we didn't anticipate this
at all in my experience such things
happen all the time in software and only
those that deeply understand the program
can Implement new use cases while
keeping the original structure of the
program intact naah also brings up a few
similar case studies where a different
Dev team that took over the original
code was struggling to make changes
instead they made additions that
destroyed its power and simplicity they
didn't make use of the existing
abstractions built into the program but
instead came up with their own less
elegant Solutions creating some kind of
Frankenstein code monster so I think
that altogether these three arguments
make a good case for the fact that the
theory can't be put into any written
documentation but does that mean we're
just screwed that we can't ever transfer
the theory from one programmer to the
other nowah says it's still possible but
it requires personal interaction what is
required is that the new programmer has
the opportunity to work in close contact
with the programmers who already possess
the theory so as to be able to become
familiar with the place of the program
in The Wider context of the relevant
real world situations and so as to
acquire the knowledge of how the program
works and how unusual program reactions
and program modifications are handled
within the program
theory he even compares these
interactions to teaching a skill like
writing or learning a musical instrument
a professional concert pianist also
wouldn't be able to teach you how to
play a certain piece just by writing
down stuff or making recordings you need
personal interaction with them to
properly learn from them I think overall
the theory building view really helps
answer our initial questions source code
itself has little value since it's
unable to communicate the full Theory
and this is also why it's often faster
to write a new program from scratch than
trying to understand and modify one that
already exists because then you'd have
to rebuild the entire theory of the
program in your head and depending on
your background it's often easier to
just build an entirely new theory that
fits your experience and perception of
the world I think this is also why
onboarding in software projects is often
so slow and it's just crazy to me that
we're in an industry where turnover is
so high that people change jobs every
few years even though so much value is
tied up in an individual contributor I
think companies would be well advised to
not treat developers as replaceable cogs
in a machine but instead realized that a
lot of the domain knowledge they've
built up over the years can't be easily
replaced and has to be built up again
from scratch I also think that our
tooling so programming languages idees
Version Control could do a much better
job at helping to transfer the theory
from one programmer to the other imagine
a world where you could just open up any
big open source project on GitHub
immediately understand the code and make
changes to it in a single day right now
if you'd want to make changes to a big
project like let's say the Linux current
internal or a browser engine or
something like that it would probably be
a mistake to go in by just reading the
code instead you'd probably want to read
some kind of overview of the overall
structure and modules or even better
watch a video or do a live session with
someone walking you through the code and
explaining the parts that are relevant
to what you're trying to accomplish
isn't it a bit silly that the fastest
way to understand code is not to just go
and read it it's crazy to me that most
developers myself included actually
don't read other people source code on a
regular basis imagine a writer who
themselves doesn't read many other books
or a musician who doesn't listen to a
lot of music that's just crazy I think
this is a failing of our current
programming languages and tooling I'd
love to see a programming environment
that builds on the theory building view
as a foundation and optimizes for the
quick transfer of the theory between
programmers I've actually been
researching and working on such a
language for some years now in private
though it's still just in the idea phase
let me know if this is interesting to
you for a future video this is really
the type of content I actually started
this channel for so I'd really
appreciate your feedback in the comments
below I also have some more practical
videos for using git on my channel check
them out here have a great day and
thanks for watching pH matics
関連動画をさらに表示
FASTEST Way to Learn Coding and ACTUALLY Get a Job in 2024
Stop Studying Programming
Software Engineers and IT Leaders are Dead Wrong about AI
How To Get a Remote Job From a Tier-3 College | #136 The Sanskar Show
BEST WAY to read and understand code
Используй ЭТО чтобы НЕ ОТСТАТЬ! Программирование меняется с ИИ инструментами?
5.0 / 5 (0 votes)