(This is part 7 in a series of posts where I document my progress through reading Becoming a Technical Leader: An Organic Problem-Solving Approach by Gerald Weinberg, answering the questions at the end of each chapter)

1. How many reasons have you thought of already for not starting a learning journal?

None, really, since the blog posts I write qualify as one.

2. If you have a journal of any other writing you did in the past, take it out and review it.

“What do you notice first? What personal changes does it measure? Are you depressed or elated that you’ve changed so much, or are you depressed or elated that you haven’t changed very much? If you don’t have any records of your own past, aren’t you sorry you can’t measure your progress?”

I tend to think whatever I did in the past sucked. Turns out that while my knowledge (especially of the “shit you know you don’t know” variety) has expanded, my writing was just as good (or bad, whichever way you want to look at it) back then. 🙂

3. Once a day for the next week, do some familiar task in the following way:

“As you do each step of the task, say to yourself (out loud if possible): ‘Now I’m doing such-and-such.’ For instance, you might say, ‘Now I’m opening the drawer to get a pair of socks. Now I’m choosing a color. Now I’m matching the one blue sock with its partner. Now I’m closing the drawer. Now I’m sitting down close to my shoes to put on my socks. Now I’m putting on my right sock.’ You may pause at any time to ask yourself questions such as, ‘Why am I putting on my right sock first?’”

I tried this on a small-scale production deployment – I kept saying what I was doing out loud, to a microphone. I was recording a log of what I was doing, and the things that affected my decision making.

The first obvious effect was that others in the office looked at me real funny. The second was the more interesting one.

Every now and then someone comes to me asking for instructions. Typically it involves a programming or sysadmin task, and I find myself unable to articulate the exact steps, or the things I do to determine my next action. Thinking out loud while doing things made that possible.

This tied in nicely with something else: I was discussing the nightmarish 17h production deployment with our CTO, and he kept asking me questions about why we made various decisions. Eventually I was forced to admit that I couldn’t remember. That prompted an idea that we should maintain a log of some sort when we do these things.

4. Which shoe – right or left – do you put on first in the morning?

“Promise yourself a five-dollar present if you can put the other one on first tomorrow. Put a note on the breakfast table so you’ll be reminded to check your bet after your shoes are on. Keep doing this until you succeed.”

(On a side note, I’m also reading through “Pragmatic Thinking and Learning – Refactor Your Wetware”, and it proposes similar exercises.)

Left. On the first day I remembered this later in the day. On another day I was already putting the first shoe on, when I caught myself. 🙂

5. What are your legs and feet doing right now?

Moving to a beat and shuffling restlessly.

6. Set some personal development goal for yourself for the coming year.

“Note in your journal your reactions as you set this goal, and note your progress toward that goal in your journal.”

I already have – I want to learn to give presentations. I’m way behind on my progress, but my first presentation is coming up in a week or so. 🙂

7. Read at least one autobiography of someone you admire.

“Note in your journal those parts that are particularly surprising to you, and those parts that move you most.”

The only autobiographic book I’ve read, and am likely to read, is Obama’s “Dreams from my Father”. While I might not personally admire Obama – I don’t have that sort of a connection to him, since he’s not “real” to me – I do admire him somewhat.

The surprising part was his addiction. I didn’t see that coming. The most moving bit was his own sense of self-worth, or lack thereof, when he was doing volunteer work.

8. As you read this book, write the answers to these questions in your journal

I’ve been taking part in a project, immersing myself in SharePoint to better learn it. We had a production deployment deadline on the Friday, just before last weekend. It didn’t exactly go as planned – some bits weren’t as finished as we thought, others were altogether missing. I worked a 14-hour day on Friday, and then we came back on Sunday. That was even worse. We began working around one in the afternoon, and I got to bed around 6:15 in the next morning, after a mad 17-hour dash to force the thing together by sheer willpower.

I slept about five hours, then went back to work for a nominal four hours. On Tuesday, I was at the office for a full day, but I felt like my brain was drained. I was barely functioning. The same was true on Wednesday, at which point I decided to take Friday off altogether. Thursday was a national holiday, so all together it meant four days of rest, which did me a world of good. In addition to that, I went to TEDx Helsinki on Wednesday at noon, so it was a rather light week. Still, I kept feeling the effects of the all-nighter for a long time.

I’ve been reading “Pragmatic Thinking and Learning”, and I came across a passage that described this phenomenon rather well:

“Not only are you less creative when battling the clock, but there’s a sort of after effect: a time pressure ‘hangover’. Your creativity suffers on the day you’re under the gun and remains depressed for the next two days as well.”

Yeah, I can attest to that.

The twisted bit is, our work culture rewards this kind of behavior. There’s generous overtime pay, the appreciation of superiors, acknowledgement of the heroics by peers and what have you. It’s all geared towards working under time pressure. That is, towards working less effectively. Not to mention the time wasted recovering.

(Mind you, I’m not talking about timeboxes – it’s a good idea to limit the time you allocate for a single activity – but real time pressure is a different beast altogether.)

It’s curious, how after reading my “Slack” and “Peopleware”, I’m still just as susceptible to being pulled in as I ever was.

(This is part 6 in a series of posts where I document my progress through reading Becoming a Technical Leader: An Organic Problem-Solving Approach by Gerald Weinberg, answering the questions at the end of each chapter)

1. Knowing what you had for dessert is an application of general self-awareness to the question of health.

“How aware are you of your own health and how it affects your leadership style? How do you feel right now? Take an inventory of your physical condition, and describe how it currently affects your performance as a leader.”

I’m in poor shape, although I’ve been worse. I feel tired, and I’ve got all sorts of aches and pains all over the place. On occasion, it plays merry hell with my ability to focus, and I’m sure that if I were healthier, I’d also seem happier, which would certainly have a positive effect on people around me.

2. Poor health is an obstacle to innovation and just about everything else.

“How is your long-term health affected by your career? What is your health going to be like in the future? If you have a hard time answering that question, what makes you think your health is not under your own control? What are you doing to keep it under your own control? How will it affect your career in the future?”

Stress and longer work days affect the way I eat – the more tired I am, the less likely I am to prepare a proper meal. Instead, I tend to opt for a pizza. In the future, I’m going to go for less stress and a healthier diet. Keeping that in mind might affect the choices I make, career-wise.

3. In answering the previous two questions, did you respond that your health was “no problem”?

“What does that tell you about yourself?”

No, I didn’t. It tells me I’m not fooling myself. 🙂

4. Do you know your IQ?

“Do you let other people know? Does knowing your IQ affect your ability to lead? How?”

Not accurately, but I’ve done the Mensa online test, so I’ve got a rough idea. I don’t let other people know, because I’m fairly sure it would only serve to provoke feelings of either superiority or inferiority in others, neither of which seems beneficial. It’s been quite a while since I last thought about my IQ before reading this question, so I can safely say it doesn’t affect my ability to lead in the least.

Come to think of it, I tend to assess people based on their performance, attitude, competence and suchlike, instead of any perceived ‘intelligence’.

5. Do you like to take tests?

“If you knew you were assured of doing well, would you like to take a test? What if you were assured of doing poorly? What if you had to take the test, but were never to find out how well you did? What do these questions have to do with leadership style?”

Yes, I do. If I knew I’d do perfectly, I wouldn’t bother . In every other case, I’d do it just to confirm whether the assurances would hold.

If I wouldn’t have the chance to process how well I did, I wouldn’t see the point either.

If this says anything about my leadership style, it’s that I base my work on feedback.

6. Find some multiple choice quiz and go through it in the following way:

“Instead of picking one answer, take each answer in turn and give a good reason why that could be the answer. Then give a good reason for some answer that isn’t among the choices.”

7. Next time you’re in a meeting and several ideas are brought up, apply the technique of the previous question.

“That is, make sure you give a good reason to the meeting’s participants to explain why each idea could be the solution you’re seeking. Then offer at least one more.”

Both of the questions above ask me to do something, but not report the results. Instead of posting the answers, I’m going to go with what the exercise made me think.

In the multiple choice question, I felt like I was exploring the possibilities. It was the same with the meeting, except for one detail: with the other participants, it kind of made me feel like I couldn’t actually answer the question, for a while. Eventually, I did pick an option and put my (considerable) weight behind it, though.

The reason this happens is that the string expansion in PowerShell has no way of knowing that I meant to expand the property instead of printing out the literal characters. Having figured this out, the next thing I tried was:

echo "${_.FullPath}"

Which doesn’t work either. Crap. I’m not familiar enough with the PowerShell syntax to explain why that is, but after a moment of pondering I finally figured out something that does work – expressions:

A while ago I found myself in an unfortunate situation where I had to use Reflector to figure out what I was doing wrong when interacting with third-party components. Unfortunately, a large part of the third-party code was in assemblies that were installed in the GAC, and I was unable to find them anywhere else.

If you’re visiting a web page over an SSL encrypted connection, you might sometimes get an annoying “mixed content” warning. In essence, the browser is telling you that yes, the page itself was delivered over HTTPS, but other bits were not, and that may or may not mean that you’re in danger.

From the developer point of view, having to build every URL so that the protocol is taken into account can be tedious. It might equally well be the case that your framework of choice already handles this. If so, good for you.

However, there’s another escape hatch not known to most people: protocol-relative URLs. You write the url without the protocol and following colon, and the client will choose whichever protocol was used to retrieve the page, like so: //server:port/path/to/resource.html

My esteemed colleague Jouni Heikniemi is a speaker at this year’s TechDays Finland. His topic is “PowerShell for Developers”. We had a chance to hear his presentation beforehand this morning. I’ve been meaning to do so for a few years now, but after the presentation I finally found the motivation to try and write an actual PowerShell script for myself.

The problem

I wanted a simple script to bundle an ASP.NET web application in a directory – basically, copy all the files that are essential to running the app, and nothing more. Something I’d typically use a NAnt or MSBuild task for.

The solution

So I fired up PowerShell ISE (I assume that’s Integrated Scripting Environment) and after a few attempts, came up with this:

Since it creates a directory that can be deployed as an application, I saved the snippet as Deploy.ps1 (in hindsight, Build.ps1 would have been a better name, but I’m too lazy to take another screenshot).

This bit of script is very specific to my needs, so don’t take it as a textbook example of good PowerShell scripting. 🙂

The snag and the resolution

As it turns out, PowerShell scripts aren’t allowed to run, at all, by default. Fortunately, the default is relatively easy to change. Fire up PowerShell or the ISE with administrative privileges, and type:

Set-ExecutionPolicy RemoteSigned

RemoteSigned means you’re free to run unsigned scripts as long as they’re locally created, but scripts downloaded from other sources need to be signed. In case you’re curious, downloaded scripts are identified based on Alternate Data Streams.

PowerShell will ask you to confirm this. In the case of ISE, by means of a really, really long-ass dialog text:

Once you confirm the change, you can restart PowerShell with limited privileges, and scripts will work.

For various reasons, I’ve found myself doing Web Part development for SharePoint 2007. While I suspect I’ll be blogging more thoroughly about it later (possibly even via SharePoint Blues, who knows) , I thought I’d contribute my first useful SharePoint link: The lifecycle of SharePoint Web Parts.

My WebForms experience is rather limited, but on the surface, the list looks a lot like a WebForms control’s life cycle. The reason I needed this list specifically is that I wanted to know the point at which I could safely assume that other web parts would be connected and their data would be available.