Category Archives: Learning

Chapter 7: A Tool for Developing Self-Awareness

(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

That might just be what I’m doing here. :-)

 

Previously: Chapter 6: The Three Great Obstacles to Innovation  Next up: Chapter 8: Developing Idea Power

Chapter 6: The Three Great Obstacles to Innovation

(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.

 

Previously: Chapter 5: But I Can’t Because…  Next up: Chapter 7: A Tool for Developing Self-Awareness

So I switched jobs again

This is not a lolcat.Like I wrote in a previous post, I’ve now began my first week as a developer working for Sininen Meteoriitti. Today was day two. Time to put down a few impressions.

First, the most important thought that bubbled up in my sleep-deprived consciousness today (while watching The Big Lebowski and recovering from a rather heavy pizza – there goes the diet!) was that I’m now part of a larger community of developers that give a crap. Obviously not a very well integrated part, this being day two and all, but a part nonetheless. This has some rather profound implications, chief among them that I no longer have an excuse to not get shit done.

In previous positions, I’ve had ideas on how to build up the collective competence of my team, to do geeky, fun stuff while learning in the process. So far, my follow-through rate has been abysmal, and I’ve always had at least one obstacle that I could point to and say “see, that’s why I can’t make this work.” Possibly I’ve even been right a couple of times. This time, though, I’m told from the get-go that if I’ve got ideas, I’ve got support too. It’s all up to me.

Today I got several interesting nudges from Jouni, wicked bastard that he is. :) One of them resulted in an idea: learn F# and hold a brown-bag lunch presentation where I introduce it to others. I’m not committing to a date, but it would combine two goals of mine: practicing the art of presentation and learning a new language. So yeah, I think I’ll put that on my to-do list. Starting with the “learn” part.

I also got my first assignments, and in the process realized how poorly I really know ASP.NET, especially the Visual Studio tooling. The stuff I do know was probably current sometime back in 2004. Crap. Far from being a technical leader – if this is the yardstick, I’m a crappy follower.

Speaking of leadership: I don’t think I mentioned why I’m blogging my answers to questions presented in a book. I suck at sticking to doing something, be it physical exercise, a diet or answering difficult personal questions in the name of learning. The point of these posts is to force me to think about each question, and write the answer down. I hope the content is interesting enough to warrant the search engine hits I seem to be getting…

In Chapter 4 I set myself a goal of practicing my guitar playing for 15 minutes every day. It’s a sad testimony of my piss-poor commitment that I managed to miss two days from the last seven. I also recalibrated my expectations: instead of trying to play and sing at the same time, I’m concentrating on playing riffs right, with a metronome. It seems to be working, too. Who knew? 😛 I’m combining daily practice with what I got from reading The Talent Code: I’m trying to split the problems into chunks, then practice the chunks in a way that allows me to fail in a controlled way, and then hone that failure away. Once that’s done, I can do the same thing with the chunks, and so on. (I’m paraphrasing heavily here.)

On the study front, I failed again to sign up for the study techniques course. This time I remembered it, and even had a reminder to sign up. Unfortunately, while my other spring courses opened up for registration yesterday, registration for that one ended last Friday. They’re doing this on purpose, I frigging know it. I did manage to sign up for two grueling math courses that should keep me occupied for the spring. In fact, when I plotted them on my weekly calendar, the idea that I might have tackled more seems absurd. I also decided to not re-take the exam for Theory of Computation. I’m not going to learn anything significant in the exam, and improving the grade would only serve my ego.

Also, finally got me an iPhone, which explains the gratuitous cat photo. This concludes my status update. I promise I’ll follow up with Chapter 5 soon.

Chapter 4: How Leaders Develop

(This is part 4 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.  Do you have some skill that you have improved over a long period of time?

“Can you plot your progress, and can you apply your methods of learning to that of learning to be a better problem-solving leader?”

I guess programming is the best I can do here. The method, so far, has mostly been solving real-world problems. Applying the same methods for learning leadership would require actually trying to be one. Sure, it’s possible. But we’ll have to wait a while to see if I’ll do that or not. Then again, the question was can you, not will you.

2. Can you describe a plateau you are now occupying?

“Are there signs that you may be approaching the ravine [the drop in skill just before a rapid rise to the next plateau]? Are you trying to stay out of the ravine, or learn what you can from tumbling in?”

I write reasonably good code, and I have a good overall grasp on the landscape of programming. However, I still haven’t managed to do anything properly with functional programming, because it’s damn hard. That’s a ravine right there. I’m actually trying to leap in, but I get tired of it fast, and eventually quit.

3. How long has it been since the last time you climbed to a new plateau?

“Are you still enjoying the feeling of being on the flat? What are you doing to get ready for the next one?”

The plateaus, ravines and sharp climbs in my progress seemed to come in two-year cycles in the beginning. I’ve been doing this for ten years, but the last time I observed a sharp increase was about four years ago. So either I’ve been on the same plateau for four years, or I’ve been paying less attention to the change.

I’m trying to study Computer Science, to brush up on the theory behind the practice. That’s my number one strategy for preparing.

4. In the course of your life, what have you learned about learning?

Learning requires intense focus, passion and a tough skin to tolerate the constant failing. It’s also a lot of work.

5. Set yourself some personal achievement that you can practice for fifteen minutes every day for a week.

“Keep a record of your progress. Next week, pick another achievement.”

I’ve been practicing the guitar riffs to HIM’s cover of Wicked Game. Now I’m going to try to sing and play at the same time. :)

 

Previously: Chapter 3: A Problem-Solving Style  Next up: Chapter 5: But I Can’t Because…

Chapter 3: A Problem-Solving Style

(This is part 3 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.  Observe someone you consider a leader.

“Make a list of this person’s activities when working with others, and see how many of them fit into the categories of understanding the problem, managing the flow of ideas, and controlling the quality. Are there activities on this list that you never do? Why not?”

For this, I’m going with a project manager I used to work for. His way of working was first to get a cursory understanding of the problem. Sometimes he’d go deeper, sometimes he’d decide it was something he didn’t need to understand it thoroughly, so he’d just dish it out to the team. At that point, he would “fan the flames” for every spark of an idea anyone had, and if there was nothing, he’d try seeding the discussion with an idea of his own – sometimes a sane one, sometimes a clearly ridiculous one. Anything to keep the floodgates open. He also had a knack for figuring out ways to test our solutions. A little bit of something for every category, then.

I’d say that while I’m fairly apt at understanding problems and testing the quality of solutions, I’m not very good at encouraging ideas. In fact, I tend to either quietly think to myself or dominate the whole discussion, being more of a participant than a moderator.

2. Observe someone you don’t consider much of a leader.

“Make a list of some simple opportunities for exercising leadership that this person misses. Do you miss these same opportunities? Why?”

I know one person whose role in the team officially sets him up as a leader. Yet he would much rather delegate the day-to-day leadership to someone who is officially in a position of less responsibility. I do think I miss some opportunities just like he does – sometimes even on purpose, if I’m not feeling up to it.

Back when I was officially a “senior software engineer”, my mistakes were of a different sort. I put myself up on a pedestal, but then didn’t actually live up to that image, and didn’t really lead at all.

3. Do you ever have trouble getting people to pay attention to your ideas?

“How do you react to their ideas?”

Sometimes I see people so stuck in their particular train of thought, that they won’t actually consider any idea that doesn’t fit their mental model of the problem. It’s tolerable for a while, but if repeats often enough, I tend to flip the bozo bit on them. After that, I typically dismiss their ideas without thinking them over – not consciously, though. Sometimes I manage to catch myself in time and actually consider what they’re saying, after which I assess the idea on its own merits.

4. What techniques do you use for gaining perspective on what you are doing when you are working in a group?

“when you are working alone? How might you improve your ability to see your own actions?”

Usually, if my approach doesn’t work and I get frustrated, I launch into meta-mode, circling around the problem and my mental model of it. If I’m actively working with a group at the moment, I’m likely to fall quiet and zone out. When I’m already alone, I don’t need that extra distance. Sometimes I use instrumental music to focus. I tend to reflect on my own actions a lot afterwards, but if I’m in a particularly emotional state, I can’t view my own actions very subjectively even in meta-mode. I need to learn how to keep my cool.

5. Next time you work with a group, list all the things you do to exercise leadership.

“If you don’t have at least ten items, do the assignment again, and keep doing it until you get a list of ten things out of one activity. When you have your list, put the items into categories of understanding the problem, managing the flow of ideas, and controlling the quality. Does your style tend to favor one category over the others? Which of your actions don’t fit into any of these categories?”

This one is hard to answer now, because I’m about to leave my current team, and most everyone else is on vacation. I’ll have to come back to this one later.

6. Overall, what new actions would you need to practice to strengthen your style as a problem-solving leader?

I need to set my own need for approval aside, and instead of obsessing over being the one who solves the problem, learn to be the catalyst for it.

 

Previously: Chapter 2: Models of Leadership Style Next up: Chapter 4: How Leaders Develop

Chapter 2: Models of Leadership Style

(This is part 2 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)

This chapter develops a model for discussing an environment for leadership. The model has three parts: Motivation, Organization and Ideas, abbreviated MOI.

[Edit: I missed one question when I typed these up. The missing question was number 5, and what I posted as question 5 is now question 6]

1. How would you characterize yourself in MOI terms?

“What were you like five years ago?”

Currently I’d say I’m highly motivated and fairly well stocked in ideas. In the last five years, the biggest change has been in the idea department, as I’ve gathered experience, read up on new ideas and tried them out. My motivation has been fairly high all the time, and stable at that. I’ve never been very organized, ever. I’ve even tried a bunch of ways for keeping organized. Some of them even worked (for example, making a daily list of things to do). I tend to abandon them after a run of success, though, after which the inevitable decline happens.

2. How much are you willing to do to change your MOI profile?

“What specific actions do you have planned for the next five years? next year? next month? tomorrow? today?”

The previous answer highlights one of the things I know to be my, let’s say *cough* less strong aspects. I don’t really feel much of a need to change the M axis, and the I axis is covered in my constant push for learning. However, the O axis clearly needs work.

I’m willing to give almost any sane method a try. It doesn’t make sense to try fixing this problem on the very long term, but evidently the short term isn’t right either. Perhaps a month of practice coupled with weekly notes on how well things worked would be a good start.

3. Can you think of specific events that triggered an agreeable change in your MOI profile?

“Do these events have anything in common? What can you do to increase the frequency of such events?”

The last clear milestone I can think of was when I began to have a kind of focus in learning. It was approximately five years ago, when I realized I couldn’t expect my co-workers or bosses to tell me how things should be done. The previous one was triggered by uncertainty of my own proficiency at work. The events are almost polar opposites, but both drove my motivation which in turn helped me stock up on ideas.

The best way to drive this sort of change is likely actively going outside my comfort zone.

4. Do you have a different MOI profile at work than you have in your life outside of work?

“What does this tell you about yourself?”

I think the differences are negligible. I very much identify with my professional persona, for better and for worse, which is probably the main cause for the similarity. One interesting difference is that outside work, I’m more comfortable taking a leadership position and being a catalyst, possibly due to the less severe responsibilities involved.

5. Is your current leadership style contributing to your happiness?

“to the happiness of the people around you? to making the world a better place for everyone?”

Outside work, yes. At work, a little less, maybe. I don’t think I have a significant contribution in making the world a better place, but just like you can die from a thousand paper cuts, a thousand tiny little things that are better make up for one bigger thing. In that sense, yes.

6. At the moment, does your principal motivation for change come from promise of reward of fear of punishment?

“Is this the best mode for you? If not, what can you do to get more of the other kind? How about some other kind of motivation entirely, such as an increased sense of self-worth?”

I could have chosen to stay where I am now, as I am now, and gain rewards for that. On the other hand, trying to step outside the bounds of what I usually do is, at least in my mind, more risk-prone, and as such, more likely to result in ‘punishment’. Therefore I’d say neither of the two apply. Instead, an increased sense of self-worth is a fitting description for my motivation for change in general, not just this particular exercise in changing.

 

Previously: Chapter 1: What is Leadership, anyway? Next up: Chapter 3: A Problem-Solving Style

Evolving code and the language of programming

Some days ago I stumbled across this passage in a blog post titled “Code fast”:

“Students simply cannot code fast enough to express themselves. When confronted with a problem, particularly a small algorithms problem, my first instinct is to write a little snippet of code for every solution I dream up. I can do this, because I write code very quickly.

My students can’t. They simply do not have the practice at expressing themselves rapidly using these thinking machines which surround us, which means that any and all of their programs are arduous constructions which must be carefully planned in advance because the cost of doing it wrong is many hours wasted.”

This managed to give shape to a thought I’ve had on more than one occasion. While the time I spend at the university is too little for me to observe this in students, I see it a lot at work.

I keep being amazed by programmers, who would rather tack on an extra ‘if’ clause and make code more complicated, rather than take a step back and recognize that it could be dramatically simplified. This usually happens when either the problem statement – or their understanding of it – changes.

Where I see code as a living thing, they see it as a static construct. The first time I really paid attention to this difference in views was when a co-worker in my current project came to ask me for assistance.

A while earlier I helped draft a solution to a problem we had, but I didn’t spell out the exact details. Instead, I just explained the gist of the idea and waved my hands about regarding the implementation. This wasn’t quite enough to get him started, though, so he came to me to ask for more specific things.

I don’t have much faith in UML, and I didn’t feel like drawing a picture anyway, because I didn’t yet have a clear design in mind.  Instead, I explored the problem and potential solutions by writing code.

First, I wrote a bit of structure that got me started. Next, a bit of actual, working code. A moment later I needed a similar block in another place, so I quickly extracted out a method. Then, after a few additions and modifications, the extracted method became unnecessary, so I inlined it again. I wrote a conditional clause, and the next moment inverted it because I felt it would be clearer that way.

When I was finished, the co-worker fell quiet for a moment, then said: “well, this was certainly a learning experience. I believe I saw four different versions of that code in under a minute.”

It’s a language in more ways than one

“Programs must be written for people to read, and only incidentally for machines to execute.”

Harold Abelson and Gerald Sussman

Expressing yourself requires a language. Expressing yourself in the form of a program requires a very specific kind of language, and that language is called ‘programming’.

A writer should always be willing to change their text to better convey the message. A programmer should always be willing to change the shape of the solution to better match the idea behind it. Unwillingness on the writer’s part leads to sentences that are tiresome to read. On the programmer’s part it leads to programs that are hard to understand.

Willingness alone is not enough, though – to pull it off, you need fluency in your language. When you’re a beginning programmer, programming is a foreign language, and you have a small vocabulary. Imperative programming suits this skill level pretty well, because you can just string together a run-on sentence that you call your program.

After a while, you become more proficient, and learn how to shape longer expressions. At this point, the programming language plays a larger role, as it encourages certain sorts of expressions and limits others. The differences here are most pronounced between classes of programming languages – rather a lot like families of natural languages.

Finally, there is the culture behind the language. You can’t expect to be proficient in a foreign language without at least a cursory understanding of the culture that shapes the language. In programming, that culture teaches us to think in abstractions, keep our abstractions cohesive, our dependencies minimal and our interfaces clean, among other things.

A programmer in touch with the culture is far better equipped to communicate a solution to both the computer and the maintainers of the code than a programmer having trouble putting together a succinct sentence.

Parting words

I’m not sure I’m even close to anything resembling a conclusion here, and I’m finding this post particularly hard to wrap up. There are a lot of related things I would like to write about, but this is already the fourth revision of this post, and as they say, “real artists ship”. In the end, I’m leaving you with a promise to return to the subject, along with yet another quote:

“A language that doesn’t affect the way you think about programming, is not worth knowing.”

Alan Perlis: “Epigrams in Programming

Becoming a Technical Leader

(… in several really really difficult steps.)

A day before Christmas Eve the postman was kind enough to bring me a copy of The Deadline and Becoming a Technical Leader: An Organic Problem-Solving Approach. I read them both in two days. Such a quick read does neither of them justice, but it’s particularly not suited for Becoming a Technical Leader, which is more of a “getting to know yourself” work book than it is a how-to-manual.

The book is divided into five parts, each dividing a particular theme into chapters. At the end of each chapter is a list of questions for the reader. The book suggests that the reader keep a journal of things learned (an idea neatly mirrored by the protagonist in The Deadline). Among the things to document in this journal would be written answers to each question.

I thought I’d give the book another read, and this time, pause after each chapter to write down my answers to each of the questions, and perhaps learn something in the process. I’m going to post each chapter’s questions and answers as an individual post, and link them all back here when I’m done.

 

 

 

Mathemagics

I’ve been listening to and transcribing the StackOverflow Podcast 31 in the last couple of days, and something Jeff Atwood said struck a nerve:

Spolsky: Maybe you just don’t like the kind of math they teach in American high schools. I mean, maybe you would like discrete math or set theory or that kind of stuff. The stuff that’s like really interesting math.

Atwood: I think historically the problem has been that I just didn’t really have — couldn’t really grok it at some fundamental level, like I could do it, like you could just show me a problem and I could solve that problem. But I couldn’t really extrapolate that to anywhere interesting. At all.

I can relate to Jeff here. That used to be, and to a very large extent, still is, my problem with math. While I can mechanically apply a solution I’ve learned, actually extracting the underlying principle and being able to identify analogous problems doesn’t come nearly as easily.

Fortunately, university math tends to be taught differently than high school math, and there is a heavy emphasis on being able to prove things and understand why things work, not just learn and apply them. That, and hindsight from the way I botched my high school studies should ensure that I learn at least a thing or two this time.

Listening to that bit in the podcast made me wish I had more time to devote to studying in general, and math specifically. Too bad I’m busy with my Data Structures course (final exam tomorrow) and work. Still, I’m keeping an eye out for math textbooks that seem interesting enough to grab my attention even outside the lecture halls.

Speaking of Data Structures, I have this funny feeling that I’ve both let myself down in terms of what I got from the course, and simultaneously learned more than I thought I had. Simply being familiar with some simple tree and graph traversal algorithms has given me the kind of insight into programming problems I didn’t used to have. It’s great, being able to recognize a concrete problem as an instance of something more abstract I’ve seen before, because it opens up a wide variety of known solutions to the problem. :)

Here’s hoping tomorrow’s exam won’t be a complete disaster. \o/

Exercise, debugging and books aplenty.

Phew, finally managed to complete Week 2, Day 1 of the One Hundred Pushups program, even if it was just barely. This is the third time I’m repeating the Week 2 exercises. I decided I’d keep repeating until I can complete each day with at least the minimum number of pushups in the last set. So far I’ve been living up to the decision, too.

Today at work brought to mind a meta-quote from Code Complete:

“If you haven’t spent at least a month working on the same program—working 16 hours a day, dreaming about it during the remaining 8 hours of restless sleep, working several nights straight through truing to eliminate that "one last bug" from the program—then you haven’t really written a complicated computer program. And you may not have the sense that there is something exhilarating about programming. “

—Edward Yourdon

This lusty tribute to programming machismo is pure B.S. and an almost certain recipe for failure. Those all-night programming stints make you feel like the greatest programmer in the world, but then you have to spend several weeks correcting the defects you installed during your blaze of glory. By all means, get excited about programming. But excitement is no substitute for competency. Remember which is more important.

Props to Jeff Atwood for typing this quote out so I didn’t have to.

Both the original quote and McConnell’s commentary sprang to mind as I drank cup after cup of coffee (and my mug is not lacking in volume), tried to debug JITted .NET code by watching the local variables and call stack (because that was the only thing I could understand – you see, I’m not a Real Programmer), and finally, almost by a stroke of luck managing to figure out the cause of the mystery bug.

I had forgotten how strange that combination of excitement and frustration can be. I almost shouted out loud as laid out a solution in my head and went off to explain it to my team members.

Finally managed to get a copy of K&R C, too. I read about half of it in one sittng, pleased with how the book is written and wondering why I ever bothered with a huge monster like C Primer Plus, which drones on and on about basic programming constructs, and is a bitch to carry around. I also got The One-page Project Manager – communicating the status of a project is something I’m interested in, specifically ways to visualize actual progress. A quick glance at the contents of the book suggests this is not the kind of progress or communication I meant. More on that later.

That’s all for today. :)

1 2