Ah, even medium sized codebases. "Dangerous assumptions"... test coverage - we know only a tiny fraction is covered and those tests are incoplete or wrong. documentation accuracy - we can't even make that assumption as there is NO documentation what so ever. Yep - management decided "the code is the documentation" (yes, we have that line black on white). Use cases - nobody knows. ease/cost of migration - we know that is not true - hence why it is constantly sold to customers (and sales-department always acts surprised when we tell them that would be a lot of work). semantics - the only assumption we have is "the code does not do what the name implies" as we have "checker"-classes that manipulate data......
🎯 Key Takeaways for quick navigation: 00:00 📚 Skills and expertise in writing code 01:05 🗂️ Characteristics of large projects 03:09 🚽 Assuming and making dangerous assumptions 04:14 🛠️ Pitfalls with large codebases 08:16 ✨ Shiny new things and neophilia 09:18 🛡️ Pitfalls and consequences of not following through 12:19 🚀 Strategies for dealing with large projects 14:18 🤖 Automation and code formatting 17:14 🛠️ Setting up clang-format and automation 19:39 📁 Organizing and navigating a large codebase 23:41 🧠 Mnemonic methods for code comprehension 24:41 🧠 Mnemonic methods for code comprehension 27:10 🚧 Gauging difficulty and measuring impact 29:09 ⚖️ Choosing priorities and considering business value 32:33 ⚖️ Considering timeline and changing business priorities 34:37 🔄 Replacing a piece of code 36:03 🏗️ Thinking ahead for code evolution 38:05 🎯 Weighing long-term costs and following best practices 40:06 🧩 C++ as a large-scale software example 42:09 💼 Key questions for the C++ committee and community Made with HARPA AI
With him until 17 minutes but my large code base is not written using Functional programming techniques in c++,. It's all very old procedural c# from 5 years ago and it wasn't even close to cutting edge then. The first part of this video is useful but c'mon there is no FP solution to my problem. No blame on you. Your advice is sound I just think you underestimate the problems out here in Corporate land. Luv and Peace. Watched all the rest of this. I loved C++ at University and used it just once in work in 2003 writing a probing program for Unigraphics. Spent my whole life in c# and javascript in web programs. More Luv and Peace.
Am I the only person who thinks that there are no Ninjas and there are no Beautiful APIs. Reality is astonishingly complex. Abstractions leak. There is no large C++ codebase with zero accidental complexity. There is no large codebase in any language that has zero accidental complexity. There are awkward bugfixes. There are workarounds. There are mitigations. There are many many reasons why the code which is useful won't be pure and beautiful.
While I think what your saying is true (it's true of any engineering system really), I believe one should aim to become as close as possible to a Ninja and try to write APIs that approach beauty. You have to make your best otherwise after some time you will loose control over your product. The ideas mentioned here, to me, are unreachable goals that nonetheless need to be pursued.
Amazing talk 👏 👏👏 Btw, I prefer Samurai to Ninjas: Samurais were warriors who usually belonged to noble classes of Japanese society. Ninjas were trained as assassins and mercenaries and usually belonged to the lower classes of Japanese society.
![Don't constexpr All the Things - David Sankel [CppNow 2021]](http://i.ytimg.com/vi/NNU6cbG96M4/mqdefault.jpg)
Ah, even medium sized codebases.
"Dangerous assumptions"...
test coverage - we know only a tiny fraction is covered and those tests are incoplete or wrong.
documentation accuracy - we can't even make that assumption as there is NO documentation what so ever. Yep - management decided "the code is the documentation" (yes, we have that line black on white).
Use cases - nobody knows.
ease/cost of migration - we know that is not true - hence why it is constantly sold to customers (and sales-department always acts surprised when we tell them that would be a lot of work).
semantics - the only assumption we have is "the code does not do what the name implies" as we have "checker"-classes that manipulate data......
🎯 Key Takeaways for quick navigation:
00:00 📚 Skills and expertise in writing code
01:05 🗂️ Characteristics of large projects
03:09 🚽 Assuming and making dangerous assumptions
04:14 🛠️ Pitfalls with large codebases
08:16 ✨ Shiny new things and neophilia
09:18 🛡️ Pitfalls and consequences of not following through
12:19 🚀 Strategies for dealing with large projects
14:18 🤖 Automation and code formatting
17:14 🛠️ Setting up clang-format and automation
19:39 📁 Organizing and navigating a large codebase
23:41 🧠 Mnemonic methods for code comprehension
24:41 🧠 Mnemonic methods for code comprehension
27:10 🚧 Gauging difficulty and measuring impact
29:09 ⚖️ Choosing priorities and considering business value
32:33 ⚖️ Considering timeline and changing business priorities
34:37 🔄 Replacing a piece of code
36:03 🏗️ Thinking ahead for code evolution
38:05 🎯 Weighing long-term costs and following best practices
40:06 🧩 C++ as a large-scale software example
42:09 💼 Key questions for the C++ committee and community
Made with HARPA AI
With him until 17 minutes but my large code base is not written using Functional programming techniques in c++,.
It's all very old procedural c# from 5 years ago and it wasn't even close to cutting edge then.
The first part of this video is useful but c'mon there is no FP solution to my problem.
No blame on you.
Your advice is sound I just think you underestimate the problems out here in Corporate land.
Luv and Peace.
Watched all the rest of this.
I loved C++ at University and used it just once in work in 2003 writing a probing program for Unigraphics.
Spent my whole life in c# and javascript in web programs.
More Luv and Peace.
Very entertaining and informative talk. Thanks for sharing!
why do i have a feeling Titus raised his hand at the beginning?
that's exactly who i was picturing!
I don't think Abseil is 1M LoC though
Am I the only person who thinks that there are no Ninjas and there are no Beautiful APIs. Reality is astonishingly complex. Abstractions leak. There is no large C++ codebase with zero accidental complexity. There is no large codebase in any language that has zero accidental complexity. There are awkward bugfixes. There are workarounds. There are mitigations. There are many many reasons why the code which is useful won't be pure and beautiful.
While I think what your saying is true (it's true of any engineering system really), I believe one should aim to become as close as possible to a Ninja and try to write APIs that approach beauty. You have to make your best otherwise after some time you will loose control over your product. The ideas mentioned here, to me, are unreachable goals that nonetheless need to be pursued.
Otherwise what should you aim for? As long as you dont burn out a high goal is a sweet thing.
for big things, there are for sure no completely beautiful APIs, for small things, maybe, but even then it's hard
Amazing talk 👏 👏👏
Btw, I prefer Samurai to Ninjas: Samurais were warriors who usually belonged to noble classes of Japanese society. Ninjas were trained as assassins and mercenaries and usually belonged to the lower classes of Japanese society.
Nice ............
first comment! i loved the Software Capital talk! this one is a fantastic follow up!
Thank, you gave me a map.
Very depressing talk. In short - don't change anything. You'll make it worse
that wasn't really the talk, it's more:
"be careful what you change and be willing to revert a change if it doesn't work out"