An interview with Will Storey, Software Architect | InDevs, Volume 1, Issue 3

Narsimham Chelluri
Nov 8 · 4 min read

Ok, obviously we need to hear more about this programmer whose code it was a challenge just to read.

Without telling me her or his name, who is this person? What got them started with development? How do you fit in there? What kind of code do they write? What kind of code sensibilities do they have? How did that shape you?

Tell me about some of the teachers you had and anything you remember vividly from what they taught you.

But most importantly, tell me about the continual spectrum of getting better, and about struggling independently with code. There is, in my opinion, something magical about sitting with a problem or a set of problems or an assignment or something and just slowly, meticulously, acrobatically, getting it done… I want to hear how that is for you!

And Will’s responses:

He’s a staff engineer at a company in Toronto. As I understand it he is more on the ops side of things now.

Like me I think he got started writing IRC related code. Maybe even mIRC scripts but I might be making that up! Later he was into Tcl, as was I.

I’d say he was usually ahead of me in technical sophistication. There were projects that I would not have known where to start where he created the initial working version. Once the base was there and I could see how it worked, I could hack on it to add features, but I’d never have done that without his leading the way. His work exposed me to possibilities.

Today we wouldn’t call them very exciting projects, but things like being able to talk to a MySQL database in a Tcl script in an IRC bot was beyond me at the time. He made a bot that let you add quotes from a chat channel and they would show up on a website or be replayed back in the channel. We still have a form of that bot actually. I must have rewritten the code about 10 times since then!

I’m not sure what kind of code he writes these days. My impression is not very much. I think instead he is responsible for keeping his company’s systems running and doing things like scary migrations.

My impression of his code was that it was compact and clever. Dense. Succinct. I realise that’s kind of mixed praise for code, and I had mixed feelings about it even then. I’m not sure I ever saw him write a comment, for example! But it always worked and after understanding it I was always impressed. It was the kind of code I could never have written.

These days I still have mixed feelings about such code. I typically write much more verbosely and write a lot of comments. Though on comments I vacillate about how much I write. Today I write far fewer comments than I did earlier in my career.

I suppose it probably shaped me to not write code like that :-). There was definitely an aspect of forcing myself to wrap my head around it that was beneficial though.

The strange thing is this: When I edited his code, I often ended up rewriting it to be more verbose in an effort to simplify it. But then I came back to it later and thought: The old version was better. It had beauty.

As far as teachers, there is one I often think about. His class must have been only the third or fourth semester after I started taking computer science classes. He was super smart and really opinionated. He had a lot of sensibilities you could say! The way I recall his teaching was that he had an aphoristic way of stating how code should be. Some of his opinions stuck with me.

One was that he did not care if the programs we submitted to him had bugs or limitations, as long as we commented them. He wanted us to write summary comments on each program in a header comment, explaining what the program does at a high level, and to document the limitations. As long as we mentioned the bugs in these comments, he didn’t care about them. My take away was that no code will be perfect, and it’s important to know where it falls down.

Another was that programs should be readable top to bottom, like a book. He was a big proponent of having programs laid out in a sensible way. He said he would be printing out all of our programs and reading them that way, so having to jump around ruined readability. This idea has always had an impact on how I organise my code and got me thinking about readability early on.

The way I think about learning to code is that there’s only so much someone can tell you. You just have to sit there and wrap your brain around how to do something. More often it’s figuring out why something that you think should work is not working! I think a lot of my learning to code was suffering through figuring things out until a lightbulb went off.

I was never one to ask for help when I got stuck. I would just pound away at a problem until I figured it out. Even today I’m not great at asking for help. There is something important about the struggle and coming to an understanding yourself. Once you come to an understanding of something that way, you’re likely to figure out similar problems quicker in the future. Though of course getting unstuck with the help of someone else is great too. They can help you realise a blind spot or see another way of approaching something.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade