The first time I tried pomodoro, it was exhausting. Staying completely focused and working for 20 minutes straight tired me out! I couldn't believe it! I thought I was very focused, all the time. I thought my productivity was good. I couldn't even work for 20 minutes!
--
I used the demo of TimeSnapper for awhile once. It's a neat program. It monitors the applications you use throughout the day. It can even play back a video of what you did all day, greatly sped up of course. You tell it which applications are productive, and which aren't, and it has this neat timeline graph that shows green for productive time, and red for unproductive time. In using it I quickly discovered something that I was not consciously aware of, but was very interesting. As I was working, if I hit a point where I had to either wait for the computer, or I didn't know exactly what to do next, I would switch to an unproductive application.
For example, if I was coding an algorithm, and I hit a particularly difficult part of it, I'd pull up twitter. Or hit up google reader. Or check my email. It was like some kind of weird nervous twitch. Any time I had to ACTUALLY think, I'd go do something that didn't require thought. And I was totally unaware that I was doing it.
--
Recently I was taking a screencast of myself doing some work at the prompt. It was just a proof of concept, so I hadn't planned it out, and I was sitting in front of the TV at home. I knew what commands I wanted to record, but I hadn't really thought through the examples. You could see I was typing fast and quickly moving from command to command. But then I'd hit a part where I had to make up some nonsense content to put in a file, or think up a commit message, and there would be this really long pause. The pause was way longer than it actually took me to come up with the content. What was happening was, as soon as I needed to do some creative thinking, I'd glance up at the TV and get lost for a few seconds. And again, I was totally unaware this was happening until I watched the video.
--
One of the things I've been struck by when I watch Gary Bernhardt's Destroy All Software screencasts, or the Katacast he did, is how fast he is. Now, he practiced this stuff, it's not like you're watching it come off the top of his head. But even still, he's FAST. But I realized, the thing I'm most impressed by is really not how fast he can type. I mean, he can type fast, and very accurately. What's most impressive is how he is always prepared for the next step. He always has the next thing he needs to do queued up in his brain.
Once I noticed this, I started trying to figure out how to get closer to that during day to day development. In a surprising twist, what I've found so far is the best way to go fast is to go slow. That's kind of a cliche, but it's overwhelmingly true. If I give myself the time to think things through, I waste a lot less time in starts and stops and blind alleys. And if I take just 1 second longer to fully visualize all the steps of what I'm about to do, I'm able to execute it faster, smoother, and with a lot less stress.
--
We recently re-did our office arrangement. We tore the walls down and made sure everyone was sitting with their teams. There have been some nice benefits. For one thing, it's way more fun. There are many times when spontaneous design and organization decisions are made just because everyone can hear you. And I think we've built a better sense of team in the process.
Of course there are downsides. It can get noisy and be distracting. Especially when random conversations and jokes break out. I think it's just human nature to have this desire to not be left out of conversation. You can put in head phones, but I find sometimes even music is enough of a distraction that I can't get my thoughts straight. And because I don't want to be left out, I usually keep the volume just low enough so I can track what's going on around me.
So there is a trade off with this open spaces, everyone together layout. You gain some productivity in instantaneous meeting-less decisions. You gain some camaraderie and some fun. But you can't close the door and shut out the world so you can fully focus when you need to. I'm still not sure how I feel on this one. The focus and productive obsessed part of me likes Peopleware's advice of everyone in their own office with a door. But the social part of me likes the team room model.
Sunday, December 18, 2011
Thursday, December 1, 2011
Powershell: Extracting strings from strings
I was playing with NCrunch. It didn't work for our solution due to some bug w/ named parameters in attributes. So I removed it. But it left behind all kinds of little .xml files. I could see these files in hg st as "?"'s and I wanted to remove them.
So I used this simple powershell command:
That version is using the .NET regex class directly and piping the object that matches outputs. You can make this shorter, though slightly more confusing in some ways, using powershell's -match operator:
If hg outputted objects instead of text, this would have been much easier. But this shows how you can lean on regex's when you have to deal with strings.
So I used this simple powershell command:
hg st | %{ [regex]::match($_, ". (.*)" } | %{ $_.Groups[1].Value } | %{ rm $_ }The regex captures the name of the file, skipping the "? " at the beginning of the line. The Groups[1].Value extracts that file name. And rm removes it.
That version is using the .NET regex class directly and piping the object that matches outputs. You can make this shorter, though slightly more confusing in some ways, using powershell's -match operator:
hg st | %{ $_ -match ". (.*)" } | %{ rm $matches[1] }This is using the magic $matches variable which is set to the results of the last executed -match operator. The reason I say this is slightly more confusing is that it depends on the order of execution of the pipeline. This wouldn't work if the pipeline ran all the -match's and then ran all the $matches. But because the pipeline is executing each %{} block once for each object, it does work.
If hg outputted objects instead of text, this would have been much easier. But this shows how you can lean on regex's when you have to deal with strings.
Subscribe to:
Posts (Atom)