Programming Warm Up

In software development, productivity is all about getting in the Zone. When You are in the Zone, you are one with the code and writing software is easy as typing. When you are not, a whole day can pass without doing much work because thinking is just so hard.

One of the things I do to get myself into the zone are little “warm up” sessions before I start to code features that are hard for me to approach. I choose small problems that I particularly enjoy as warmups. Little treats, you might say. For example, I may start programming a feature by refactoring some remotely relevant code, commenting on legacy code around it or focusing on a small part of the feature that seems interesting.

To the outside viewer (a.k.a my boss when I was a developer) it may appear as though I’m wasting time on things that are not the core of my work – “We have no time to invest in code refactoring right now, we should ship this feature”, but I argue that this time is not spent but invested in making the development faster, and that the time it takes to develop the feature after investing it is much shorter.

Think about it – in many other areas of our life, the concept of warm up is very prevalent. Athletes warm up before an exercise to make it more effective and less dangerous. Singers warm up their vocal chords and musicians warm up their fingers before a show, and when I took an animation course, we were taught to start every day with a several minutes quicksketching session to get our creative juices flowing.

Why should programming be different?

Concentration and focus is a problem of acceleration and when you try to move from 0 to 100 kmph you should take the car that gives you the largest boost at the shortest time, and this is what programming warm up is all about.

Please Don’t Use the Word Voodoo

Not many things irk me as the term Voodoo, when it’s applied to software engineering.

“I found a piece of code that solves this bug, but it’s completely Voodoo”

“Working with this library is like doing Voodoo”

Don’t. Say. That. It makes the problem you are working on seem like there is some unknown force that makes it impossible to solve in logical and analytical means. It makes it sound like the problem cannot be solved at all. It makes you sound like you are powerless against it. It makes you sound like you gave up.

It makes you sound unprofessional.

There are no ghosts in your computer. Everything has a logical explanation, you just haven’t found it yet. And wherever you use the term Voodoo, you can replace it with the words “I don’t understand” and get a perfectly valid sentence, that invites further analytical investigation, questioning and rational decision making.

“I found a piece of code that solves this bug but I don’t understand why it works”

“I don’t understand the library I’m working with”

From here you can continue to ask questions and make informed decisions. You can always invest more time in understanding the piece of technology you are dealing with. But you can also ask how much time it is going to require, what is the risk if you don’t, and if it is worth your time.

Please don’t use the term Voodoo when you talk about software engineering. We all are professionals here.

Transfer Files from Your Mac to your Windows Azure VM

  • Install Remote Desktop on your mac
  • In the Azure console, open the dashboard of the VM you want to transfer files to and click “connect”
  • Download and open the rdp file and make sure you can connect to the server
  • Create an entry for your server in the Microsoft Remote Desktop window
  • Right click your server and choose “edit”
  • In the Redirection tab, click “Enable folder redirection”
  • Click the “+” and configure one of your folders as a shared folder
  • Disconnect from the server and connect again
  • You should see the folder in the server’s drives list

Now you can transfer files using this folder.

Reading List on Scala

Work in progress.

  1. http://www.scala-lang.org/
  2. Programming in Scala (by the man himself)
    Easy reading, clear explanations. Seems like the book was written with Java developers in mind, which is fine by me, being one. After working with the language for a while, I wanted do dive more deeply into some of the language features than what the book covers.
    It is still a good starting point, though.
  3. Twitter Scala School
  4. Effective Scala
  5. The Neophyte’s Guide to Scala
    Simple and clear explanations. Good stuff.
  6. The Scala tag in Stackexchange’s code review site (beta)
    So, learning language constructs is easy, but understanding how to think like a Scala developer and write idiomatic Scala is hard. Those of us who are lucky have senior developers who can guide us and from whose code we can learn, but those of us who must teach ourselves need to find alternative solutions.
    This site is a great resource. I skim the Scala section from time to time and read code reviews to get the feel of the language.
  7. A good article on transitioning to Scala