Performance matters
This is a talk I like and it really gave me a better understanding of “measurement bias”. The improvement (or not) can be simply because of a specific environment or, in other words, “works for me” as some programmers say. But we can do better. Nowadays programs are usually concurrent and it’s difficult to pinpoint a bottleneck. This talk explains the theory and gives you ready to use tools to improve performance.
There is also a related white paper: “Producing Wrong Data Without Doing Anything Obviously Wrong!“
https://users.cs.northwestern.edu/~robby/courses/322-2013-spring/mytkowicz-wrong-data.pdf
which explains the topic of measurement bias in more detail. Moreover, the authors claim that: “Our results demonstrate that measurement bias is significant and commonplace in computer system evaluation. By significant we mean that measurement bias can lead to a performance analysis that either over-states an effect or even yields an incorrect conclusion. “.
Simplicity is complicated
This talk is about Go language, but I think the arguments about simplicity apply to many languages and also for the style of coding. It’s quite easy to quickly write a program in a way that it works, but it is hard to maintain and difficult for others to understand. Achieving simplicity requires a lot of thinking. This talks explain how Go language designers achieved that. As Rob Pike put it: “Key trade-off: More fun to write, or less work to maintain?” Personally I think focusing on how easy it is to write code is just wrong. We read code at least 10 times as much.
More on the subject can be found here: https://www.infoq.com/presentations/Simple-Made-Easy/ which makes a distinction between “simple” and “easy“.
Software engineering vs programming
This is a good definition I came across some time ago: “Engineering is programming integrated over time” or “Software engineering is about resilience to change over time” from https://youtu.be/tISy7EJQPzI?t=526
Let’s think about it 🙂
