C++: Engineers Wanted, Programmers not so Much - David Sankel - C++Now 2019

#Boost #Cpp #CppNow
Presentation Slides, PDFs, Source Code and other presenter materials are available at: cppnow.org/history/2019/talks/
CppNow Website: cppnow.org
CppNow Twitter: @CppNow
-
C++: Engineers Wanted, Programmers not so Much
The software development world is groaning as it transforms into a mature engineering discipline. As C++ software projects both grow and age, a fundamental shift in mindset is happening, that from the programmer to the engineer.
This talk explores the recent shifts in focus from language, to system, to business value in both the commercial and C++ standardization settings. We'll see, in particular, how this impacts conventions, maintenance, specifications, tools, and ideologies.
-
David Sankel
David Sankel is a Software Engineering Manager/TL at Bloomberg and an active member of the C++ Standardization Committee. His experience spans microservice architectures, CAD/CAM, computer graphics, visual programming languages, web applications, computer vision, and cryptography. He is a frequent speaker at C++ conferences and specializes in large-scale software engineering and advanced C++ topics. David’s interests include dependently typed languages, semantic domains, EDSLs, and functional reactive programming. He is the project editor of the C++ Reflection TS, a member of the Boost steering committee, and an author of serveral C++ proposals including pattern matching and language variants.
-
Videos Filmed & Edited by Bash Films: www.BashFilms.com
---
*--*
---

[@jonathanrobert3620]

One of the best engineering presentations I have ever seen. This should be shown at the beginning of every SE program at university.

[@piotrarturklos]

"code review is a hostile environment that simulates working with the code in the future" (paraphrased) This blew my mind and seems excellent for teaching people about code review. You pretty much have everything in one sentence. I bet there is a book that could be replaced with it.

[@phisyka]

I think the idea of measuring the value of of software by its technical debt in monetary terms is fascinating. One way that could be translated to is 'programmer hours' required to fix, and also delays at the later portions of your business pipelines. Although estimating time it takes to do something is difficult, so collecting data for fixing bugs or having errors could be used to determine the cost.

[@raveheart58]

One of my favourite talks recommended to me by a work colleague. I'm on board with this idea of ideologies vs fitness. And not getting caught up in const correctness.

[@jacktaylor1516]

I think code migrations would be a lot easier if maintainers focused more on consistency and correctness and less on feature additions.

[@colinmaharaj50]

7:40 So I like or I should say, I need esthetics, mostly because the code I write, I will be the one to troubleshoot it some years later. Now there are pieces of boiler plate stuff I have written like date conversions, or file io stuff, that I close up and make it have as few lines as possible.

[@piotrarturklos]

Const correctness is a bad example of a bad ideology because there is a high penalty for using it inconsistently: you will fight the compiler errors. It is an ideology, but a one that you have a choice to buy into at the point of language design, not at the point of writing an individual program. Once it's in the language, it's over. You pretty much either use const-correctness everywhere or nowhere, otherwise you aren't maximally productive. But this is also a false choice because all the libraries you use are const-correct, so you have no choice but to stick to it always. (Note, I'm talking about being maximally productive, not merely about being able to produce anything.)

[@andersbodin1551]

Maybe technical debt should be accounted using a risk matrix.

[@abhishek.chakraborty]

Please create a *playlist* for all 2019 videos i.e. C++Now 2019 🙏 like e.g. _C++Now 2018_ : kzbin.info/aero/PL_AKIMJc4roVSbTTfHReQTl1dc9ms0lWH That would be very helpful in making these easily accessible

[@bawbak8800]

To me, it sounds a naive way to compare software engineer with other engineering fields. Firstly, we just call this phenomenon wrongly as software engineer, because most part of that is not engineering at all, and it's literary science and tons of research. Engineering is the step after knowledge being generated by science. Which about software, we haven't reached that point yet. I'm not talking about making a web service with a bunch of CRUD operations, I'm talking about creating a complex software, which you have to care about its details as much as possible to be able to handle its complexity for maintaining and adding new features to it. We don't care about those details (which you might call them aesthetics) just because we are some picky programmers. We have to really care about them to avoid having future headaches and really understand what we are doing. The main mistake that people make is they think developing software is like creating some physical products that you can do it like other stuff or engineering it like others. In this age, developing software is the most complex thing to do, and that's why we have so many shitty software programs with millions of lines of code which exponentially growing plus their complexity. I hope one day people understand that developing software is still a new phenomenon and we need to do it in its unique way.

[@llSoleyll]

The DRY example is totally misleading and not proving anything. The author replaced one fragment of code that needs to be written ONCE per program with another (even longer) fragment of code that needs to be written ONCE per program. So how is that an application of DRY? Replacing a single statement with another single statement is not an application of DRY. Another similar absurd example would be replacing "++i" with "increment(i)"... That is again not the point of DRY, because the number of repetitions is still the same.

[@GeorgeTsiros]

meanwhile, a CPU will execute _quadrillions_ of instructions each day and not fail _one_ A CPU will likely go through its entire life not misexecuting even one instruction. A heart has _worse_ availability, considering at a very old age it misses cycles.

[@youkenez]

One of the key ideas here that "aesthetics" should not be the goal reminds me of the views of kzbin.info who's criticizing contemporary physics that they're trying to find some theory with beautiful mathematics instead of working on what's important, to gain novel insight into how the world works.

[@GeorgeTsiros]

99% "service level indicator" is laughable. If a piece of hardware running at a measly 1 MHz would be expected to fail every _tenth of a millisecond_ . It would _literally_ not have enough time to be brought to power before it halts.

[@volkangundogdu1008]

intentionally too much polarised, lack of objective approach due to prejudged opinions however in overall he performed good to explain the subject

[@MrAbrazildo]

2:35, I'm sick of low quality wine, with plenty of alcohol! 2:48, a brandy, a drinkable alcohol. 1:10:29, but what about exceptions and interfaces? They are slow high-level features. As long they keep being completely optional, I think they are welcomed to the language. 1:29:00, C++ could only has GC as optional feature, as D does, because otherwise the language would not fit the performance demands from certain fields.

[@GeorgeTsiros]

"int main(int argc, char**argv)" is NOT what "don't repeat yourself" is about. First of all, there is not even any _repetition_ here. This _definition_ exists _exactly once_ in each program (the _declaration_ is implicit in the C standard itself). Bad example! Bad!