Watched Robert “Uncle Bob” Martin talk about “The Future of Programming” and wholeheartedly recommend it. In the talk, Uncle Bob brings up interesting points about the growth of the programming profession:
Roughly every five years, the number of programmers double.
Conversely, half of the programmers at any point in time have less than 5 years of experience.
The industry lacks an appropriate amount of teachers, so all the new people will make all the same mistakes over and over again.
Programming does not grow up this way. On top of that, programmer mistakes in everyday devices now are causing lethal damage to real people. Self-regulation inside the profession (which, like traditional crafts, I guess could reduce the onslaught of newcomers) and proper teaching are essential to keep growing and making code more reliable a foundation of modern societies.
That’s part of why I write, too. Because I found it was extremely hard to learn creating applications properly, not just hacking together something that barely works. I want everyone else to have a head-start compared to me. While educating myself, I discovered ancient wisdom in books from the 1970s – stuff you can still tell (or should I say: sell) people today, like how to decouple parts of your system. As if we, as a profession, suffer from collective amnesia. Old wine in new skins.
Now that I know some rough estimates about programming’s exponential growth, this makes sense. There just isn’t enough time and care put into teaching these practices properly. It’s hard enough to equip students with sufficient knowledge to become somewhat dangerous in front of a programming environment. The rest then is delegated to on-the-job training, which I imagine is pretty disappointing for all parties involved.
According to Ed Yourdon, in the 1970’s global state was actually widely preferred over passing parameters to functions or subroutines. I had to laugh when I read the paragraphs on the most common objections, but this seems to have been a serious issue.
It’s a good time to update my book for Swift 2: guard clauses improve readability, and do-try-catch error handling shows problem points. Protocol extensions are huge, but I had no use for them in the sample code, yet. The update is live now. If you haven’t bought the book in the past, grab it until August 1st to save more than 50%: use the coupon Swift2Yay. The coupon is good for 10 copies, so be quick.
Like I promised last weekend, I am going to write about the process of cleaning up the already rotten source code of Calendar Paste. In order to break massive view controllers into manageable pieces and un-tangle everything, I have to make sure that I don’t break the current implementation. Calendar Paste didn’t have any automated tests in place. To change this fact is my first priority.
This weekend, I have just released my book on Mac software architecture. It’s called “Exploring Mac App Development Strategies”. In this book, I discuss how one can adopt practices for designing clean code and use it in spite of Apple’s rather invasive framework suggestions.
I’m adding a file monitoring feature to the Word Counter. This is a huge change to the application’s source code. To tackle this problem with style, I mulled things over for a while and considered my existing application’s design. I wanted to try out a few new things, so it was a no-brainer to start a sample project from scratch and fiddle with it.
Nat Pryce released Code Guide, a tool to create interactive code documentation. See his blog post announcement. It’s written in Python and works for Python and Java code. But since Python and Ruby comments look the same, parsing Ruby code works, too.
When I developed my iPhone event template builder Calendar Paste, I took a lot of notes during development. In 68 plain text files I collected everything I’ve learned during the planning, design, programming and marketing process of the app.