Because of the Corona pandemic, our whole company has now been working from home for 12 weeks. Before, we mostly worked in the office, although occasionally people would work from home, for example when waiting for a delivery. This abrupt switch has made for a great natural experiment on the differences between these two ways of working.
Many developers on both Twitter and Hacker News argue that remote work is the future, and that they want to keep working remotely even after the need for it because of Corona is gone. For me, it has worked quite well so far. However, I miss some things. Others were not quite what I expected.
I really enjoyed reading Artificial Intelligence – A Guide for Thinking Humans by Melanie Mitchell. The author is a professor of computer science and an artificial intelligence (AI) researcher. The book is her attempt at working out if the singularity is near (or at least likely), or if we still are far from creating any true intelligence. In the process, the reader gets an excellent overview of the state of the art in areas such as image recognition, game play, and natural language processing. Even though it is aimed at general readers, I found it to be very good in technical content.
In the fall of 1999 I got the biggest productivity boost of my entire career as a software developer. In the October issue of IEEE Computer magazine, there was an article by Kent Beck called “Embracing change with extreme programming”. In it, he outlined Extreme Programming (XP), which includes much of what we now refer to as agile development.
By then, I had been working as a software developer for seven years. The standard development methodology at that time was waterfall: document-heavy year-long projects, frozen requirements, change control boards, manual testing at the end of the project, and so on. Software development succeeded despite the methodology, not because of it. Reading the article was a real eye-opener. I felt it was describing how I naturally worked – in short cycles, with fast feedback, and frequent redesigns.
(And yes, I meant to write this last fall for the 20th anniversary, but I didn’t get around to it then. But hey, better late than never, even if the title has 20.5 in it now)
I really like Secure by Design. The key idea is that there is a big overlap between secure code and good software design. Code that is strict, clear and focused will be easier to reason about, and will have fewer bugs. This in turn makes it less vulnerable to attacks. This is easy to say, but Secure by Design is full of techniques for how to actually do this. Here are the ideas from the book that I liked the most.
Here are more good programming quotes I have found since my last post.
“Microservices are just dynamic linking over HTTP”
“kubernetes – turning things off and on again, at scale”
@decimalator Continue reading
Posted in Programming
In the book club at work, I just finished reading Grokking Deep Learning by Andrew Trask. It is an introduction to deep learning, but there are some problems. It spends a lot of pages on the basics, and in the end moves on to some fairly advanced topics. It is also contains many small and irritating mistakes. However, it does have some great insights into deep learning. Continue reading
A few weeks ago I spoke at the EuroSTAR software testing conference in Prague. The conference had one and a half days of tutorials, followed by two and a half days of talks. Around a thousand people attended. I was impressed by the sense of community and by the number of activities offered. For climate reasons, I chose to travel there and back by train instead of flying. Continue reading
I really enjoyed Classic Computer Science Problems in Python by David Kopec. It covers many different problems I hadn’t read detailed explanations of before. For example: neural networks, constraint-satisfaction problems, genetic algorithms and the minimax algorithm. Unlike many other books on algorithms and programming problems, this one builds up complete (but small) programs that are easy to explore on your own.
I like to use Test-Driven Development (TDD) when coding. However, in some circumstances, TDD is more of a hinderance than a help. This happens when how to solve the problem is not clear. Then it is better to first write a solution and evaluate if it solves the problem. Writing tests only makes sense after the solution is viable. Continue reading
I often get contacted by recruiters asking if I am interested in changing company. Even if I am happy where I am, I briefly check out companies I have not heard of before. One reason is that you never know, maybe the new company is a fantastic opportunity that really is interesting to me. Another reason is that I don’t know how things will change – maybe I will want to change in a year’s time or so. These are the things I check when I am trying to evaluate a company I haven’t come across before.