Never underestimate a smooth workflow
To be productive, you have to be constant. To be constant, you have to be organized. To be organized, you have to be happy about what are you doing. This are three simple rules that I try to apply to my work. The first two are quite straightforward and they don’t really need explanations. The third one, however, is more delicate. What do we mean with “to be happy about what we are doing”? Why this is connected with “to be organized”? Well, the answer is positive feedback. When I’m happy with what I’m doing I’m able to stick to the workflow I’m using. At the same time, a good workflow means less time spent debugging, less trivial bugs committed, less troubles during deployment, in other words: an happier developer!
This positive feedback loop can really increase your productivity. The real problem is, how can we find this magic smooth workflow? I don’t know. I cannot tell you the magic solution to every developer problems. You have to find this by yourselves. The only thing I can do now is telling you my actual workflow. This may be a good starting point for some of you. :)
Quadarto: a didactic project in Haskell
The last week I spent some time build a small tool for abstracting an image into a mosaic, for fun. To do this I’ve used Haskell, of course. However, this is my first “complete” program I’ve written in Haskell. Before that, I’ve read a lot about Haskell and used it for solving tons of ProjectEulers’s problems. However writing program that performs real stuff, such as loading an image, do stuff and write a new image is a completely different things. Using Haskell for the Project Euler problem is almost like cheating, using Haskell for a _side-effect-full _application can be a pain in the neck if you are not prepared.
So the idea was to do this trying to be as much idiomatic as possible so that this code could be used by new haskellers in order to learn something on the language. It is still not really idiomatic, but I’m working on that.