Pair programming

When I was a couple years in my career as a software engineer, not long after finishing university, I got into a work setup where doing pair programming was for the first time possible. I remember this was something I wanted to get doing, because I felt I had a lot to learn from more experienced software developers, by sitting and working together with some of them.

So, I grabbed every chance I had to do more of pair programming, and the results were incredible, in my subjective assessment. I remember spending many days working with a colleague that was not too many years more experienced than me at the time, but that had worked on larger software systems longer than I had.

In particular, I remember us spending many hours in “debug” mode, going through a particular piece of code and trying to understand and come up with some fixes. And I remember having literally headaches at the end of a working day, which was a sign of the many successive hours of highly concentrated intellectual activity.

While for me the main benefit was clearly getting insights on the practical methods used by a more experienced developer, and learning from it, my colleague also benefited a lot from my concentrated attention and at least some of my ideas on how to proceed with the tasks we had at hand.

And all that came recently to mind again, because of a book I am currently reading about programming, which made me reflect back on my personal experience with pair programming.

One of the chapters in the mentioned book brings a lot of hard evidences, mostly based on published articles and studies, that point out to the fact that pair programming, together with formal code inspections, are the most effective methods to, among other positive things, reduce code defects. The evidence shows that they are actually much more efficient at that than other more “popular” alternatives, such as unit tests, regression and integration tests.

And that does not come as a surprise, based not only on my earlier experiences with pair programming, but also personal experiences later on with code review sessions, and overall assessment over code quality in different contexts, as I moved to work on many different systems, companies, and software products. With different job titles and responsibility levels.

At the end of the day, much of the quality in a software system reflects down to how single individuals do their daily work tasks, and pair programming is just a great tool to achieve more of what many people seem to look elsewhere for.

3-D Seismic Interpretation

3-D Seismic Interpretation (M. Bacon, R. Simm and T. Redshaw, Cambrige University Press, 2007, 225 pages) is a book that has long stayed on my bookshelf. Now I have finally finished reading through it, and it was very useful. 

Firstly, because I started this year working with Seismic Interpretation again, and this book gives a good overview over the main techniques and processing that seismic data undergoes. From the data collection, on land or shore, to the pre-processing steps, up to the structural and geological interpretation of it.

Secondly, because it puts a lot of emphasis on visualization of seismic data, in modern 3D software environments. The book goes through some key aspects of how seismic interpretation has evolved from paper and pencil to modern 3D scenes, and the consequences it had for horizon and fault picking, for example.

Thirdly, the language and the level of details was quite right for someone, like me, that is not an expert in the field, but still wants to understand the main principles behind different steps on the seismic interpretation workflow.

If this sounds interesting to you too, you won’t regret giving this book a try.

Latterbomber

For en uke siden, ble jeg ferdig med å lese Latterbomber – Vitser for barn. Dette har sikkert vært den morsomste bokopplevelsen jeg har hatt i hele mitt liv.

Alt startet når kona mi fant boken på et boksalg, og tenkte det kunne vært fint for oss å lese sammen med barna. Så da startet jeg å bruke boken på leggingstid, med å bladde gjennom og lese et par vitser jeg synes var morsomt for dem. Det ble fort populært! Noen dag senere, så bestemte jeg meg for  å lese alle vitsene fra starten av, og det har bydd på ganske mange morsomme kvelder, da de skulle høre 2 sider med vitser før søvn.

Og det var ikke bare noen få ganger som hendt at en av oss har fått latterkrampe på grunn av denne boken 😊

I tillegg, så startet vi en tradisjon av å spørre på frokostbordet hvilke vitser som husket vi fra dagen før. Og det var også en bra måte å øve på minne, samtidig som vi gjenopplevde en del latter.

Det som også er interessant er at jeg før hadde tenkt mange ganger på vitser som en måte å være morsom på. Jeg vet at barna typisk synes at jeg er en morsom kar. Jeg har alltid likt å leke med barn. Mens, blant voksne, kan jeg lett le, men veldig sjeldent klarer jeg å få noen andre til å le (jeg tror at jeg blir fort for seriøs i voksens verden). Derfor hadde jeg tenkt at å ha en del vitser klar i hodet kunne vært en fin måte å få andre til å le, når situasjonen for det oppsto.

Men, dessverre, har jeg lest mest av boken nå i pandemien, og da har jeg ikke klart å dele mange vitser med kollegaer og venner ennå, i disse tider med få sosial interaksjoner. Men jeg gleder meg å kunne prøve på det når vi begynner å treffe andre oftere i framtiden igjen!