Well Designed Code vs Usual Crap
Last week at the Pragma Conference I had the pleasure to attend a bunch of very interesting talks about designing better code and application architectures. During one of the breaks I was chatting with a friend and one of his reflections was along the lines of: We enjoy these presentations with great tips about good app architecture, well designed code, refactoring and when we go back to our job we end up dealing with the usual crap: duplicated code, patchy architectures and close to zero test coverage.
Coding as writing paragraphs
There’s an interesting discussion going on in the Cocoa community. It’s about being reactive vs traditional. While reactive programming has been present in the Cocoa community since 2012 with ReactiveCocoa, RxSwift is getting quite some attention lately. The recent discussion happened between these posts: The Reactive Revolution of Swift The Non-Reactive Solution To React, Or Not To React Comparing Reactive and Traditional There’s more, but that is the backbone of the debate I think.
Architects should code
I advocate for Tech Leads to spend at least 30% of their time coding. Pat Kua source That’s just one of the gems in the article. Even if it’s written by a guy that worked in a big company for twelve years, many suggestions are relevant also to solopreneurs. I worked in the enterprise in the past. The first time was at a Java shop, building software for invoicing.
Lines spent
My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger. E. W. Dijkstra source Amen to that. I am trying to write less code. I am still honing that process. Nevertheless I recognize that sometimes I need to write some specific code before deleting it.
Clean Networking Code
I can’t help but think that my networking code was cleaner before the introduction of blocks, before 2010. That doesn’t mean my networking code after that date sucks though :) One of the things I liked the most when I discovered Objective-c and the Cocoa frameworks was the delegate pattern. I saw it and it clicked, just like that. To give you a bit of context I was coming from the world of Java, writing code to generate factories that in turn generated factories.
Writing code in entrepreneur mode
Here is it, innocent Ruby code: t1 = "2015-08-27T11:53:00-07:00" t2 = "2015-09-16T12:33:36-07:00" t1 < t2 #true Some of the DB queries in Podrover involve time. For example: “get all the reviews since yesterday”. During the prototyping phase I always worked with strings and when I came to build that query I still used strings. As long as the format (and the time zone) is the same it should work. If you have a case in which it doesn’t work let me know and I’ll update this post.