On looking up a mountain.
Sometime around 1994/1995 I was working at company called ISOCOR. Those who remember it probably remember it very fondly. It was a company that specialised in developing standards-based messaging and directory products. X.400 and x.500 stuff. All pretty technical, all written in C.
It was a wonderful place to learn your programming chops; full of super engineers, plenty of world-class programmers, and people with enough time on their plates to help you out too.
There was one valuable lesson that I learned there that I find myself telling people from time to time.
I was part of the X.400 server team (go team “Cheetah”!). Many of the team worked on porting to various Unix flavours at the time, but I was lucky enough to work on other aspects of the code.
I was given the task of developing an SNMP agent to monitor the X.400 server. The X.400 server had it’s own ISO management stack, so the theory went SNMP Request in, make managment request, get response, convert to an SNMP Response, respond to SNMP Request.
So I began by reading the SNMP specifications. The RFC, text based specifications. That took a week or two. And at some point, I realised that there was a potential issue: SNMP meant listening on a well-defined port. If anything else on the machine was listening on that port, our agent wouldn’t be able to run. And it wasn’t unusual that the operating system offered an SNMP agent for monitoring the machine itself.
So. I started investigating how this should be solved. And the results were a mess: There was a proposal in the SNMPv2 spec, but this was just proposed and not adopted. There was a de-facto standard which some vendors used called SNMP-MUX, and there was an unofficial SNMP v1.5 which also handled it. Added to this, some vendors even had their own proprietary solutions.
But, in hindsight this was a bit of a red-herring. At that point in my career, the project was daunting, and I guess I was afraid I’d screw it up. I felt I was stuck. I could see barriers ahead, and I couldn’t envisage the solution. And I hadn’t actually got started. I was a few weeks in, and no code written.
It was time to come clean so I went in to see my manager.
“Have you got a few minutes?”
“Sure, what’s up”
(There was no way to sugar coat this) “I’m really struggling with this project, and I’m way behind where I should be”.
At this point, my manager was well within his rights to blow a gasket, but instead he got me to open up a little about where I was with research and so forth. Then he said:
“Tell me, what’s the very first thing an SNMP agent must do upon startup?”
“Listen on a socket” I replied.
“Do you know how to code that?” he asked.
“Yeah. That’s simple” I said.
“OK. Can you go off and write that code, and come back to me when you have it done?”
“OK.” I said.
He’d given me a 30 minute task. I went into my office to write the code to listen on a socket….and came out about 6 weeks later with the SNMP Agent complete.
You see, once it was listening on a socket, I reckoned “It will need to expose it’s MIB”, followed by “Well, I’m going to need a parser for the SNMP packet format”, followed by the next obvious task, and the one after that.
I was struggling not because I didn’t know how to do parts of it, but rather because of the size of it.
So now, every time I’m working on anything that the task feels too big, or if someone comes to me struggling near the start of the project, I bore them with the story of my SNMP Agent, and try to find a trivial first step.
I’ll always be grateful to Tom Lane because it was he who taught me projects can feel like looking up a mountain, but usually all you need is to decide where to put the first step.
