I am currently a reformed software engineer.
Day-to-day, I mentor engineers, and one of my mentoring goals is to improve an individual's and their team's practices. But, as a mentor, I feel that it is a bit hypocritical of me to not be "practicing what I preach". So with this project, I am seeking to reform my own engineering and engineering management practices.
One practice that I have found difficult for some engineers is communicating effectively. I found some who consider communicating their ideas as an afterthought and don't really focus on improving their communication. I can sympathize. Part of the skill/joy/difficulty in programming is taking the fuzziness of the real world, and analyzing how to encode that into a logical form like code. Now, it is easy for an engineer to stop there, just get the joy/thrill/achievement and move on. The trick is that the code doesn't stop there. It lives on, and other engineers find it.
So my mentoring concern is that after the analysis is done and the code is written, we should communicate our intentions and solutions. This can be anything from caring how you name variables to the clarity of your tests to the choices behind the libraries that you used to even the overarching system architecture you designed. I would expect that we try to communicate these intentions to the others that see the code next. Sometimes, the best communication may not be clearly stating details about the solution, but focusing back on the problem that you were trying to solve. It is easy to forget that what seems obvious to the engineer writing the code isn't always obvious to anyone reading it later.
As part of this blog, I will try to explain why I made the steps that I did in developing this application. I want the engineers that I mentor to do a better job of communicating their intent, so I would like to improve myself in the same. As an engineering manager, I do write the occasional work blog post to communicate my thoughts an engineering-wide basis, but the detailed choices that go into the day-to-day rarely percolate outside of the office and into the blog. So, I feel that I need a different forum to practice.
Another inspiration for this project came from an excellent book that I read by Gerald Weinberg, Becoming a Technical Leader. Weinberg states early in the book that if you are really serious about improving yourself, you really need to be devoted, and his suggestion is committing to three months of daily journal writing. In fact, he suggests that if you aren't willing to start on the journal today, to put the book down and come back to it when you are willing. I went through this exercise many years ago when I first read the book, and I do highly recommend it. I found it really insightful to see what I was thinking during my development.
I recently picked up Weinberg's book again after these years, and I still see the wisdom in his journal advice. Consequently, some of that "personal journal" nature will likely leak into this blog, as I focus back on monitoring my improvement.
In the end, my primary goal in founding this blog and the resonance project is to improve myself in a variety of ways. Of course, this is all a bit selfish in its origin and intent, but I do really hope that others get something from my thoughts, or can learn from my technical write-ups, or even use the code directly.
Well, enough of the meta discussion, let's continue on and focus this project log on the first release!