Every couple of years or so I seem to come full circle and arrive at the same conclusion, there must be something wrong with me. You see, I hate coding and listening to music at the same time! That’s right, all my friend seem to be able to do it, most people I know swear by it, even popular media tries to push us that way, but I just can’t do it. Music distracts and annoys me when I am coding, am I the only one?

There are 2 schools of thought when it comes to listening to music and doing creative-analytical activities like coding. It all hinges on your right brain (as opposed to your wrong left brain :)).

• Some people believe that doing a right-brain activity such as listening to music, fully engages that half of the brain. This means that there is no leftover right-brain capacity to devote to your coding task. This will not prevent you from coding effectively, but it does prevent you from being able to do things that are normally associate with the right side of the brain such as, intuitive leaps of logic when debugging, or seeing large patterns in the code and bending them into different shapes. Instead your coding will be more logical and formulaic relying on prior knowledge and opinions you have formed about coding style and practices.
• Other people believe that listening to music will actually stimulate the right side of the brain making you more able to deal with coding tasks that require right-brain input (such as the ones I mentioned above). This means you’re a more creative, intuitive and a better coder overall when music is playing.

So What About Me

From my own personal experience I have found that I can focus a lot better with no music. I can code fine when there is music playing, but I do tend to be a little more distracted and it really does seem like I am less intuitive and creative when this is the case. Everything I know about learning styles tells me that there should be many other people like me. But, I suspect that the opposite is also true, there are plenty of people who would be more effective coders with music.

So What About You

Much depends on your learning style and how your brain is wired. Because the right side of the brain is involved nothing is immediately obvious, the only way to find out what group you belong to is to engage in some experimentation. You need to try out both styles (with music or without) and observe your effectiveness carefully. Many of you are probably thinking that you already know you’re the musical kinda coder, thing is, I’ve got a sneaking suspicion that some of you are wrong.

We all like music (well, most of us), and many developers believe that because they enjoy music, they should listen to it when they code. This is not necessarily the case. I love music, but much self-examination has told me that coding and music don’t mix well in my case. Music can help you retain information and can help you form associations that you can use to retrieve that same information more easily. But it is only one of the many ways people can form such associations and if you’re not wired as a musical type of learner, it may not be an effective tool for you and may actually be hurting your effectiveness as a coder. Just like I encourage everyone to figure out their learning style, I would also encourage all developers to take another look at whether music and hackery are a good mix in their case. If for no other reason then at least do it for my sake, I don’t want to be the only non-musical coder :).

__

_For more tips and opinions on software development, process and people subscribe to skorks.com today.

_

Image by shankar, shiv

I’ve recently written about redirecting the output of commands (standard out and standard error) to a file using bash. That is part of fundamental bash usage, but what if you want to redirect the output of a command to a file but also have that output go to the screen. Well, the bash shell has a handy little command that allows you to do just that. The command is called tee.

Rather than redirecting the output of a command to a file using the standard technique e.g.:

alan@alan-ubuntu-desktop:~/scrap$ ls -al > blah.txt
alan@alan-ubuntu-desktop:~/scrap$

You can instead pipe the output to tee and use that command to save the output to a file and at the same time echo everything to the screen e.g.:

alan@alan-ubuntu-desktop:~/scrap$ ls -al | tee blah.txt
total 8
drwxr-xr-x  2 alan alan 4096 2009-09-29 21:16 .
drwxr-xr-x 37 alan alan 4096 2009-09-29 21:14 ..
-rw-r--r--  1 alan alan    0 2009-09-29 21:16 blah.txt
-rw-r--r--  1 alan alan    0 2009-09-29 21:09 file1.txt
-rw-r--r--  1 alan alan    0 2009-09-29 21:10 file2.txt
alan@alan-ubuntu-desktop:~/scrap$

Simple but very useful in certain situations.

Echoing and Saving Both Stdout And Stderr

Normally you’re only able to do the above with stdout. After all, you can’t pipe both stdout and stderr to tee. But we can combine redirection with the tee command to both echo and save the output and error streams at the same time. We first redirect standard error to point to the same place as stdout and then we pipe the whole mess to tee in order to both save and echo at the same time e.g.:

alan@alan-ubuntu-desktop:~/scrap$ ls -al 2>&1 | tee blah.txt
total 8
drwxr-xr-x  2 alan alan 4096 2009-09-29 21:16 .
drwxr-xr-x 37 alan alan 4096 2009-09-29 21:19 ..
-rw-r--r--  1 alan alan    0 2009-09-29 21:22 blah.txt
-rw-r--r--  1 alan alan    0 2009-09-29 21:09 file1.txt
-rw-r--r--  1 alan alan    0 2009-09-29 21:10 file2.txt
alan@alan-ubuntu-desktop:~/scrap$

Echoing and Saving Just Stderr

We run into a bit of trouble however, if we’re only interested in saving and echoing stderr and don’t care about stdout. The trouble is, you can’t pipe stderr, pipes only work with stdout. As you may have guessed we can use some fancier redirection to get around this obstacle :).

File descriptors such as 1 for stdout, 2 for stderr (and 0 for stdin) are not the only file descriptors we can use with bash. Other numbers can be treated as file descriptors as well and most of the time they are just sitting there unused. What we want to do is use one of these extra file descriptors as a temporary variable to allow us to ‘swap’ stdout and stderr e.g.:

• first we point 3 to where stdout is pointing (the screen), i.e. we essentially make a copy of the stdout file descriptor and assign it to 3
• we then redirect stdout somewhere else so that it doesn’t interefere with what we are really interested in
• we then redirect stderr to 3 (where stdout used to point), i.e. in essence we assign the file descriptor that used to be referenced as 1 and is currently referenced as 3 to be referenced as 2 :)
• the pipe is attached to the file descriptor itself, so doing this swap means we will now pipe error output

alan@alan-ubuntu-desktop:~/scrap$ ls -al 3>&1 1>/dev/null 2>&3- | tee blah.txt
alan@alan-ubuntu-desktop:~/scrap$ ls -al
total 12
drwxr-xr-x  2 alan alan 4096 2009-09-29 21:51 .
drwxr-xr-x 37 alan alan 4096 2009-09-29 21:40 ..
-rw-r--r--  1 alan alan    0 2009-09-29 21:58 blah.txt
-rw-r--r--  1 alan alan    0 2009-09-29 21:09 file1.txt
-rw-r--r--  1 alan alan    0 2009-09-29 21:10 file2.txt
-rw-r--r--  1 alan alan  385 2009-09-29 21:46 yadda.txt
alan@alan-ubuntu-desktop:~/scrap$

Hmm, this looks like nothing has happened and the _blah.tx_t file is empty, so we got no output. This is because we didn’t get any errors on the previous command, lets simulate an error by breaking our ls command on purpose e.g.:

alan@alan-ubuntu-desktop:~/scrap$ ls - garbage 3>&1 1>/dev/null 2>&3- | tee blah.txt
ls: cannot access -: No such file or directory
ls: cannot access garbage: No such file or directory
alan@alan-ubuntu-desktop:~/scrap$ ls -al
total 16
drwxr-xr-x  2 alan alan 4096 2009-09-29 21:51 .
drwxr-xr-x 37 alan alan 4096 2009-09-29 21:40 ..
-rw-r--r--  1 alan alan  100 2009-09-29 22:00 blah.txt
-rw-r--r--  1 alan alan    0 2009-09-29 21:09 file1.txt
-rw-r--r--  1 alan alan    0 2009-09-29 21:10 file2.txt
-rw-r--r--  1 alan alan  385 2009-09-29 21:46 yadda.txt
alan@alan-ubuntu-desktop:~/scrap$ cat blah.txt
ls: cannot access -: No such file or directory
ls: cannot access garbage: No such file or directory
alan@alan-ubuntu-desktop:~/scrap$

Now that we’re getting errors, everything is working as expected, our blah.txt file has the same output as the tee command printed to the screen, which in turn is the standard error output of the ls command. By the way, notice the little minus after the 3 when we do the last redirect, this is not just cosmetic. It allows us to close the file descriptor 3 now that we no longer need it.

It is all reasonably simple, but surprisingly slippery if you try to fully wrap your head around it.

There are lots of interesting and useful Bash tips like the ones above in the Bash Cookbook which is one of the books that I am going through at the moment. Check it out if you’re interested. Although I am sure I’ll be blogging about many more interesting bash tricks as I myself learn about them (or am reminded of their existence), so you can just wait for that :).

Image by temporalata

I’ve had a lot of fun the last few days following the controversy cause by Joel Spolsky’s post, The Duct Tape Programmer. I actually wish the software development part of the blogospehere would produce more posts like it, because it induced such a tremendous response (both positive and negative). Ultimately we all benefit when everyone chimes in and shares their opinion on an issue (we all get to learn from each other). Of course now that I have said that, it would be remiss of me not to add my own 2 cents into the mix :). The way I see it, Joel stresses 3 distinct points in his post.

Good Programmers Ship Product

Some believe that because Joel has a successful track record of shipping software he must be right (with some caveats). I have to say that I completely agree with this one, shipping is key. No matter where you work as a developer, your job is ultimately to deliver value, to the business, to the customers – whatever. Software that has not shipped can’t deliver any value and is by that definition useless. So far so good. The place where I began to have an issue was the clear connotation that ‘duct tape programmers’ ship software while everyone else is just holding them back. To be blunt that is crap._ You don’t have to be a Joel-style ‘duct tape programmer’ to be delivery focused_. Anyone who has ever worked on an agile team can tell you that.

Agile teams do not fit the ‘duct tape programmer’ definition that Joel puts forward. They try to use the right tool for the right job and over-engineering is a no-no (this does fit the mold), but agile teams are also very focused on quality. That means having processes in place that will assure such quality, unit testing, continuous integration etc. Whether such quality processes slow you down can be debated ad nauseam, what can not be debated is the fact that the quality does not come at the expense of delivery focus. The business is fully aware of the fact that such quality measures are in place and are willing to live with it because they ‘listen to the experts’ and trust their team to have the best interests of the business at heart. But, if push were to come to shove and quality needed to be sacrificed to meet a deadline, a good agile team would do it, they wouldn’t like it, and they would make the business aware of the price they would have to pay, but they would do it.

This I believe, is ‘duct tape’ mentality without going cowboy style. The point I am trying to make is that just like there is more than one way to skin a cat, there is more than one type of ‘duct tape’ programmer. If you’re currently working on an agile team, then congratulations, you could already be a duct tape programmer, maybe not the same kind as Joel likes but as far as I am concerned, if it walks like a duck and quacks like a duck … well you get the picture.

Unit Test Have No Value If They Get In The Way Of Shipping Product

Some people seem a little concerned at Joel’s cavalier attitude to unit tests. Read the post closely, he is not really having a go at unit testing (well he is to some extent), what we’re really talking about is the quality of the talent we work with. Case in point – the ‘friggard’ who writes multi-threaded COM apartments (whatever the hell that is – I doesn’t buildz them Winderz codez :)). The guy is obviously freaking smart, head in the clouds, but smart. The ‘duct tape’ programmer is just as smart, more down to earth but still a bona-fide savant. Wouldn’t it be great if we could all work with superstars all the time? Problem is, software development is a big industry these days, not everyone can be a genius, a great many are either not experienced enough or simply not talented enough to understand the ‘friggard’, but by that same virtue they can’t really be a duct tape programmers, they wouldn’t know which brand of duct tape to use.

What I am trying to say is this, really good people (developers) will create great software, ship it and make it reasonably high quality no matter what the process, no matter how much unit testing. Of course the scale and the type of software matters, web apps or desktop apps are pretty well-understood, but even star people will struggle to deliver decent quality when building something highly complex and cutting edge. However in your regular day to day work, put a bunch of awesome people together, give them an objective, unleash them on it and watch them go, it will be awesome.

Unfortunately most of us don’t work for Fog Creek or Stack Overflow or whatever, millions of developers work for bank ABC or insurance company XYZ where you can’t really rely on the fact that all other developers will quite be at your level of duct tape awesomeness :). And this is where stuff like unit tests saves everyone’s ass, mine yours and the company’s because when you know your team is not Macgyver enough to patch a go cart on the fly, it kinda helps to make sure your go cart is unlikely to need patching in the first place. I don’t necessarily agree with Uncle Bob, there are cases when unit tests can slow us down, but we pay that price for peace of mind.

What if you are lucky enough to work for Melzer and Smelzer accounting with a group of awesome people? Does that mean we can all just go guerrilla with our duct tape and achieve new heights of shipping awesomeness? Problem is, there is that pesky future to think of. You’re not lucky enough to own Melzer and Smelter (unless your name is Melzer, errr or Smelzer I guess, but then you’re probably an accountant) you’re not always going to be working there, people are gonna come after you leave and they will have to use your code, modify it, enhance it and ship it some more. Not all these guys are gonna be duct tape genius material and even if they are, it’s just common courtesy to not leave a dogs breakfast in there hands. Think of it as paying it forward (I’ve said this before and will say it again), cause when you come to a new place, no matter how great your software development kung-fu is, if the software you have to work with is a bunch kitten barf you’re not going to enjoy the stink.

Go Get The Book?

There is no doubt that Joel writes a damn good blog post, I’ve got a lot of respect for him and for what he has done in this industry. Joel is also a clever marketer, the post he wrote was controversial enough that the well-blended promotion of Coders At Work was pretty much seamless (and no doubt he was aware that would happen). Now, I have no idea if Joel is in any way affiliated with the book, or if he simply promoted it because he liked it so much (it does seem to be somewhat similar in format to the books he himself released), what I do know is that he certainly made me want to go and check out the book. As someone who studies online and offline marketing as a hobby, I have to give him major kudos for that one.

Well, there you go, that’s my thinking regarding this whole kettle of fish, hopefully it was at least somewhat coherent :). If you have some thoughts about my thinking, do share them with everyone – in the comments.

__

For more tips and opinions on software development, process and people subscribe to skorks.com today.

Images by Flowery *L*u*za and Jonas B