All programs need some form of logging built in to them, so we can observe what it is doing. This is especially important when things go wrong. One of the differences between a great programmer and a bad programmer is that a great programmer adds logging and tools that make it easy to debug the program when things fail.
When the program works as expected, there is often no difference in the quality of the logging. However, as soon as the program fails, or you get the wrong result, you can almost immediately tell the good programmers from the bad. Continue reading
I got an e-mail last week from three students at Halmstad University doing a three month project on what programmers want in a job, and how companies can attract talented programmers. Here are my answers to their questions, in order of importance. Obviously people have different preferences, so it would be interesting to hear what items you agree and disagree with, how you would rank them, and what you think is missing. Continue reading
I recently finished the Coursera course Algorithms: Design and Analysis, Part 2 by Professor Tim Roughgarden of Stanford. I’ve already reviewed part 1, and here are my thoughts on the second part.
The main theme of part 1 was the divide and conquer paradigm. In the second part the main themes were greedy algorithms, dynamic programming and NP-Complete problems. The lectures were excellent, with clear and easy to follow algorithm development and proofs. At six weeks, it was one week longer than part 1, and I found it quite a bit harder than part 1. Here’s more on each part. Continue reading
I recently gave a presentation on what it is like to work as a software developer to first-year engineering students at KTH taking an introductory programming course. I wanted to give my view on the main differences between professional software development and programming for a university course.
First I talked about challenges with large-scale software development. Then I listed several development practices used to cope with these challenges. I went on to present ways to become a better programmer, and ended with some fun facts from work.
Every once in a while I read something along the lines of: “most developers just want to write new features, they don’t want to work with maintenance and bug-fixing”. If that’s true, then most developers are missing out on the fun and benefits of finding and fixing bugs. Continue reading
Even though more than 20 years have passed, I still remember wondering what it would be like to finish university and start working. Up until that point, I had pretty much spent my whole life in school, with only a few, non-programming summer jobs thrown in. My expectations of what it would be like to work as a software developer were mostly correct, but there were a few surprises in the first few years, and here are the top five: Continue reading
For seven years I coded in C++ using Emacs. Four years ago, when I changed jobs, I switched to Java development using IntelliJ IDEA. Without a doubt, I am much more productive writing code in IntelliJ IDEA compared to using Emacs. Here’s why: Continue reading
I love coding. Ever since I bought my first computer (a VIC-20), I’ve been fascinated by computer programming. For many years I never thought of why I enjoyed it so much – I just knew I did.
But that changed when I read The Mythical Man-Month by Fred Brooks. Most people associate that book with Brooks’s law: adding people to a late project makes it later. But for me, that is not the best part of the book. The best part is one page at the end of chapter one, entitled The Joys of the Craft.
There, Fred Brooks quite eloquently put into words what I love about coding. Continue reading
I recently finnished the Coursera course Design and Analysis of Algorithms I, given by Professor Tim Roughgarden of Stanford. This was my second on-line course from Coursera (last fall I took Introduction to Databases, which I wrote about here), and I thought it would be interesting to compare the two.
Here are a few programming quotes I like:
“A complex system that works is invariably found to have evolved from a simple system that worked.”
“Enlightened trial and error outperforms the planning of flawless intellects.”
“It’s OK to figure out murder mysteries, but you shouldn’t need to figure out code. You should be able to read it.”
And two quotes from the Agile Manifesto:
“Working software is the primary measure of progress.”
“Simplicity — the art of maximizing the amount of work not done — is essential.”
Posted in Programming