☂

Code quality matters to me. When I started programming professionally I quickly realized that better code generally means lower stress levels and higher productivity, which was a huge incentive to improve. There are three tools that I find invaluable in this regard: acknowledging my own limits, testing, and code reviews.

Accepting your own limits is important in order to stop writing heroic code. Apart from a few really twisted minds, the high-profile programmers we admire are not superhumans empowered with magic brain power. More often they “just” know how to keep even the complex things reasonably simple to work with. Today, whenever my design starts to feel like a too great struggle uphill, I know it’s almost certainly wrong. And that’s a good thing.

Testing took a great burden off my chest – each time we were about to ship an update to our calculator app used by hundreds of thousands users, it was a great relief to run the test suite covering dozens of intricate corner cases and be reasonably sure that I didn’t break anything by adding the new features or fixing bugs. And not only that: the need to test modules in isolation forced me to decouple my designs. And that’s a good thing.

But at the end of the day there are simply too many degrees of freedom when designing code architecture, too many blind alleys. There are too many subtle errors that won’t be prevented neither by good design, the compiler, the automated test suite, nor user testing. And this is where code reviews shine – for nothing will help your code more than a careful, critical reading by a second pair of eyes. Being the only programmer in our team, this was a luxury I had to do without. And that’s a sad thing.

Which is why I am now offering Objective-C and iOS code reviews as a paid service.

I am not a wizard programmer that will make your code dance and your cat sing, but I am competent in what I do. I know the language, including the C bits that you wouldn’t bring up as a conversation topic during the Sunday lunch. I have reported bugs in the SDK. I was writing code for the platform when iOS was still called the “iPhone OS”, and our team has shipped our first iPad app before the iPad started selling to the public. I have written libraries used by dozens of iOS apps. I’m in the top 10% of Stack Overflow in C, Objective-C, iOS, multithreading, or Xcode.

Show me your code and I’ll make it better.

Dostal jsem za úkol vyrobit plakát na jarní koncert Noty, smíšeného sboru místního gymnázia. (Obojím jsem prošel a v obojím užil spoustu legrace.) Jelikož v pátek ráno vypadla elektrika a bez elektriky není práce, vytáhl jsem plynový vařič (na kterém mě kromě plynu hřeje i pocit převahy nad civilizací) a po ranním šálku čaje vyrazil ven na inspirační procházku. Šel jsem jako obyčejně k Otylce, malé kapli v remízu uprostřed polí pár kilometrů od našeho domu.

Read More

My girlfriend is going to end her music school studies this semester with a performance of Sergei Prokofiev’s first piano concerto, so I got the commission to create an invitation. Being a geek, my first concept was to record the first few bars of the piece as MIDI and juggle the bits to create some nice graphical effect.

Read More

A few things you can try when you are stuck in code design:

Break it down. Tearing code into a separate library will force you to make the interface nice and clean. The “congitional load” will also go down: you will have smaller amount of code to consider when thinking about the application design. Which brings us to a related point:

Abstract. A library is a black box. Black boxes are good. You don’t have to trouble yourself over their inner workings, all you have to deal with is the outer interface. Abstraction is one of the key tools for dealing with the computer, because if you were to deal with memory bits or circuit signals instead of higher abstractions, you would drop with a foam in your mouth in about two seconds. So make your life easier and abstract aggressively – for example, don’t hesitate to separate code into standalone classes or functions.

Backtrack. During design you must commit to some choices that will shape the following work. If you find yourself in a dead-end, don’t forget that you can backtrack and reconsider some of the previous choices. Making big changes is more work and more risk, but the potential advantage is huge.

Compromise. Sometimes you bang your head into a wall just because the immediate requirements are too strict. What if you could compromise on X? Would that make a difference? You might be able to fulfill the original requirements later, building upon the simpler design that was made possible by the compromise.

Keep it simple. Don’t write heroic code. When design is too complex, it’s usually going to hurt. When it hurts, undo. This is basically the main commandment of design that all of the others stem from.

Finish it anyway. Best design comes from iteration. Most of the time you can’t make the design perfect at the first attempt. In fact, most of the time you won’t get it right at the second attempt either. If you’re stuck for a long time and no matter what you try you can’t get further, simply get it working somehow. You might find a good solution later.

Don’t despair. Design is hard and always will be. There are too many choices and no silver bullets.

When I started programming fifteen or so years ago, I was very much focused on syntax. What’s a correct sentence, what’s not. After I got over these baby steps, I continued with higher concepts like proper memory management, data structures and algorithms. After some time you absorb most of the common tricks and technologies and the building blocks cease to be an issue. When I need a component that does X, I can usually write it myself, find a library that does X well or wrap/tweak somebody else’s code.

What’s left is what I see as the core and the hardest challenge of programming: complexity management. Even trivial applications take a non-trivial amount of code to write. If you don’t structure the code well, the complexity of the whole system quickly raises until it becomes impossible to maintain and evolve it anymore.

In other words, in programming design is not a question of aesthetics, it’s not some added value for those who care. It’s a bare necessity, like a machete in a jungle. You either cut your way through the chaos or perish.

I have been programming for at least fifteen years now, been to college to study computer science for a while and programmed professionally for about two years. I shipped several iPhone and iPad applications. After all that, if somebody asked me to describe my skills today, I would honestly say I am becoming almost competent, or just above lousy. Interesting times ahead – I am looking forward to another decade of adventure in programming fumble.

People often ask why singletons are considered such a bad idea. After all, the implementation is quite simple and you get a warm feeling of solving a design problem in such a simple and clean way. For me, getting rid of singletons was the single most influential thing I did to improve my design skills. I would like to share this advantage with whoever is interested, which is why I am writing this post.

Read More

A few weeks ago we wanted to add a new feature into one of our applications. The feature was quite simple, but despite that it turned out to be a bit messy to implement correctly. One of the reasons is something that could be called the difference between systemic and mechanistic complexity. By mechanistic complexity I mean the amount of energy required to make the feature work in isolation, whereas systemic complexity is the amount of effort to make it work with the rest of the system.

In planning we tend to forget about the systemic complexity and judge features just by their mechanistic complexity. And because the systemic complexity is usually much higher, we end up underestimating the required effort. While not a groundbreaking observation, I find it very useful to keep this in mind.

The difference between “systemic” and “analytic” thinking is treated very well in The Web of Life by Fritjof Capra.