Little steps

Big projects are made of lots of little steps. The wins are small. You post a position. You finish reviewing applications. You make your selection. You prepare to on-board them. On-boarding complete. Did you catch the dramatic moment or cathartic ending? No? Probably because there wasn't one. There are only little steps.

I've seen a lot of projects pop up over the past few years, most of them in tech, all with great missions. People with big, feel-good ideas get a nice crowd going and dive into their project with big hearts and full force. But a few months later, they stop. The tweets post less often, the newsletters are thin, the spirit fades, and the story gets cold. And I am always surprised.

When I started the CodeNewbie Podcast, I remember a podcaster with a much bigger audience and years of experience telling me that the key to a successful podcast was showing up and pressing record. I thought this was strange. How else do you have a podcast at all without showing up and pressing record? Seventy-two episodes later, I know what he means. Having a show sounds fun, but the truth is, it takes discipline and a good process to keep doing it every single week. It's late nights spent editing and cleaning audio for a midnight release, weeks spent researching and testing audio equipment, emailing back and forth to book guests and maintain a healthy backlog of interviews. It's doing those little steps over and over, and for most people, that's not an exciting way to spend their free time.

I don't mind the little steps. I've always been very process-oriented. I like structure, organization, efficiency. But I miss those cathartic moments. I miss being able to step back and take it all in at a distance. I'm too in the weeds to really appreciate where those little steps have lead to. It makes it hard to take a compliment seriously. I nod and smile my thanks, but I know in my heart that what I did wasn't special or genius. I just show up and do the work.

I am not a tinkerer

I am not a tinkerer.

I have never been the type of person to take apart a toaster to see if I could put it back together. I would never read the manual for a Ti99 just to see how it worked.

When I was twelve, I was a great tap dancer. I competed with a dance company where the second youngest person was 18. I loved it so much. But soon after, my father made me quit because I didn’t want to be a professional dancer, so what was the point. Whether or not that’s the best way to raise a child is a different topic, but that one story pretty much sums it up -- everything I did and do needs to work towards a goal. It needs to move me forward in a tangible way.

I don’t code for code’s sake. That's just not me. I code to build something, to solve a problem. I don’t really do hobbies, because I find them pointless. I am not a tinkerer.

So when I hear things like “curiosity drives innovation,” it really bothers me. Not because it’s wrong, but because it’s exclusive. It’s exclusive to the tinkerers, to the type of people who do things just because.

Without the context of a clear problem to solve or a goal to achieve, answering the question “How does this work?” doesn’t speak to me. Because frankly, I just don’t care. My driver is not curiosity. I don’t ask questions for curiosity’s sake. I ask questions because I need the information to achieve a goal.

When I first discovered programming, I spent a lot of time wondering how I never knew about it. How was it that such an incredible thing never came into my life sooner? When I thought of the people I knew who were coders, most, if not all, had discovered it at a very young age in the informal manner of tinkering. They just wanted to see how it worked, and so they fiddled and poked and made things happen. I never fiddled, so did that mean coding wasn’t for me? If I’m not the kind of person to read a Ti99 manual just because, maybe I wasn’t meant to be a programmer.

When I first started learning to code, this thought kept me up at night. When I’d get really stuck and everything was broken, it ate me alive.

This idea that if we were just curious enough, we would have found programming at an early age is biased towards the type of person that is motivated by tinkering. It puts the blame on those of us who discover coding later in life for not being curious enough to have found it sooner. It implies that curiosity is the most important driver. 

If you’re a tinkerer, and you found coding because you poked and prodded, that’s awesome. But that’s not the only, or even necessarily the best, way to have found it.

Curiosity can indeed drive innovation, but it’s not the only driver.

First Day at Thoughtbot

I haven’t interacted with that many humans in a long time. For the past four months, I’ve been mostly coding alone in my apartment, which the occasional google Hangout to break the silence. Luckily, my small talk game was still strong. But even better, I didn’t need it.

Everyone was real nice. Not “really” nice, but real nice, which is the opposite of fake nice. Fake nice is when you plaster a smile and talk about the weather for an obligatory 3-minute minimum, then cross off “spoke to new girl” on your checklist. Real nice is when you lean in and offer a detail warm enough to make me forget I’m the new girl. Real nice is when you’re not trying and I can’t tell. I’m always surprised at how real nice tech people can be.

My first day was on a Friday, which is investment day at Thoughtbot. Everyone does something tech related that’s not necessarily client work. They learn a new language, play with a new API, write a blog post, whatever. It’s pretty low key, which made the awkwardness of a first day less awkward.

As an apprentice, I get assigned a mentor each month. My mentor was on his last day of a client project, and it was crunch time. He was super nice and really supportive, but I felt bad that he was so busy. I hate bothering people, which made asking questions a lot harder than it should have been. It’s a stupid thing to stress out about. As though something terrible would happen when you bother people. The worst they’d do is tell you to leave them alone, or they just ignore you, but I still get really stressed out about possibly annoying people. It’s one of those things I just gotta get over.

We paired for a bit. We worked on a small feature for the app he was working on. When he asked how I’d approach a problem, I had a great deer-in-headlights moment. Instead of focusing on my understanding of the problem, I was playing the game of what-would-he-want-to-hear-right-now-that-makes-me-look-like-a-genius, which is pointless since I can’t read his mind. But I told my brain to shut up, as you must do, pulled myself out of panic-mode, and gave an answer. We solved the problem and moved on.

My favorite rule of learning is to be selfish. Be selfish with your learning. Ask all the questions, propose all the answers, sit in the front row, raise your hand at every chance you get, and hog all the TA time. We don’t sit in rows at Thoughtbot and raising my hand would be weird, so in this context, it’s really just the first two.

When you’re being selfish, you can't worry about being wrong or looking stupid. You can’t afford to. There’s no time for that. And as an apprentice, I’m supposed to be learning. It’s ok that I’m the least knowledgeable person on the team. But I forgot my rule, and I held back. I wasn’t the selfish learner I was supposed to be. When I did ask the questions and propose the answers, it was great. But the times that I didn’t sucked. Working on that for next week.

But the most uncomfortable thing I have to get use to is how they communicate. I’ve worked for three startups and worked with a bunch more. “Flat leadership” and “transparency” are words they like to throw around, but I’ve rarely seen it in action. At Thoughtbot, transparency looks like a general Slack channel that is my primary means of communication. Conversations that might only pertain to you and one other person are still put in that general channel. The default communication is open and inclusive, a beautiful concept. But it also means that any questions I have or issues I run into are publicly broadcasted to the whole company. This is terrifying. It’s one of those situations where you’re convinced that everyone is staring at you and laughing, but in reality everyone is too busy to care or pay attention. It’s that gap between what you know and how you feel. It’ll take some time to close that gap.

They had these amazing Argentinian chocolate caramel sandwich thingies (I don’t know what they’re called), that I think one of the developers brought it. I’m trying to be more healthy, and I recently replaced my weekly tub of cookies with a bag of apples. My proudest moment that day was eating half of the caramel sandwich, then having an apple instead. That’s commitment.

Also, there was unlimited coffee that I didn’t have to make myself, so I peed a lot. 

That is all.

I like plans

I spent the last four months working on CodeNewbie. In that time, I launched our community forum, produced a weekly podcast, redesigned the website three times, managed a small team of contributing bloggers, did over a hundred customer interviews with people in our community, and tested out two educational products, one of which I’m really excited about.

It was just me and my ideas, and it was painfully lonely. My brain constantly second guessed every move I made, annoyed I couldn’t do it right the first time, or the second, or the third. I always knew that ideas weren’t as important as execution, and I found that out first hand. Most of my mistakes I could laugh at, but a few really hurt. They weren’t anything big, nothing worth tweeting about, but they popped up in private emails and conversation.

I find it hard to forgive myself. It’s something I have been working on, and I’m getting better at it. But when you’re working in silence in your living room office with no one else to blame, it’s hard.

I didn’t appreciate how much of an extrovert I am before this little experiment. Every google hangout was a chance to talk to actual humans! If we talked during this time period, and I sounded creepily enthused, my apologies. It will probably happen again.

But what I misunderstood the most was the concept of a plan. I like plans. I like process. We spent weeks, Rob and I, trying out different audio software for the CodeNewbie Podcast in different places and conditions. We tried recording from a cheap mic, a headset, an expensive one. We listened back using different quality headphones. We did fake interviews with a shitty internet connection, in a noisy room, and we let them run for hours, just in case. We tried different audio settings, and after two weeks and four guests, we finally got it right. And that’s how I like to do things. I like to have a plan.

But I’d always assumed success. Without a plan, the worst that would happen was a shitty success. A silver medal, maybe a bronze, but a medal either way. With all the low-production podcasts that were doing well, I knew I didn’t have to make the CodeNewbie Podcast sound great. But I wanted to, and I did, and it does.

So when I thought of our first educational product, I had a plan. I did a few dozen customer interviews. I got great feedback on the idea, the problem I was solving, and the way my solution addressed these problems. I got feedback on the landing page, and made adjustments. I decided it was ready for a small group to test, and I put it out there. I had a target number of signups I was looking for, and a short window of time to make it happen. I’d revised it with my mentor, and everything looked ready. I got the number of sign ups I wanted in the allotted time, but my conversion rates were very discouraging. I considered that test a failure, and I wasn’t ready for it. That was the biggest lesson I took away from these four months. You can have a great plan, do your little tests, and still fall flat on your face. You can never tell how people will react to something until you put it in front of them.

I think it wouldn’t have been as big a blow if I had a partner, someone to share the frustration with and keep me centered. But I absorbed the blow myself and it took awhile to get over it.

I care a lot. I care a whole fucking lot. I think I’d get further if I cared a little less.

I was venting to Rob about it recently, and he said, “Never confuse strategy with outcome.” I love a punchy line of wisdom, but I savored this. I think it pinpoints what’s been the hardest part of this journey -- emotionally separating my strategy from the outcome. Just because it didn’t work out doesn’t mean it wasn’t a good plan, and it doesn’t mean the plan had no value. In fact, it’s the plan that made the outcome so clear.

Aight, I gotta go. I have a plane to catch.

Pieces

When the women in my life tell me to be strong, they mean that I should be silent.

That I should forgive your list of never ending wrongs, and forget, so you can fool me again. What you did or how it’s left me is irrelevant. Your mistakes are my burden to bear.

They tell me not to cause so much drama, because that’s all asking questions does. There’s no room for voicing opinions or holding people accountable or demanding respect. That’s not what sweet, quiet, forgiving women do.

They tell me the burden of adhering to the values of my culture, no matter how much it devalues me, is mine. It is my job to treasure your flaws, to ride the ebbs and flows of your mood, wherever they might take us.

They tell me this is strength. 
And they prove it, flashing the pieces of their broken hearts with pride.

I don’t know where it comes from, why it’s so easy to toss aside these values that should be too deeply engrained to question. I see the stupidity of it so clearly. 

But I can tell that you don’t, so I tell you …

Strength is not how much you put up with, how complacent you choose to be.

You are not strong because you let people walk all over you. 
You are not strong because you’ve turned so many cheeks you lost count.
You are not strong because you hold your tongue.

I tell you.

I tell you that complacency is not strength. Silence is not strength. Blind forgiveness is not strength.

I tell you.
Over and over, I tell you.

You nod, and you hear me with glazed eyes. And I know you don’t feel me. 

So we sit and I hold you. 
You and your broken pieces.
I just want you to be whole again.

#TIL: Why's my site so damn slow

I've been wanting to learn and read up on site performance and optimization for awhile. Finally got a chance to. So today I learned ... 

  • I really like learning about performance stuff. What makes the site slow, fast, etc. I think it’s because there are actual metrics involved, something I can point to and say, “Well that sucks. And it sucks by 7.8 seconds.”
  • what Eager Loading and N+1 queries are. And they make sense! These sources really helped --> http://build.thoughtbot.com/performance/, http://www.slideshare.net/MattKuklinski1/boosting-the-performance-of-your-rails-apps, 
  • Our site is slow. I knew this before, and assumed it was because we were making inefficient queries to our database, but it turns out, it’s not the app stuff, it’s the images/css/js stuff. I used PageSpeed Insight to analyze our site, and it gave us a very pathetic 35/100 on desktop, 30/100 on mobile. BUT, it was also helpful and gave suggestions on compressing images and stuff which led to ...
  • looking more into vector vs. rastor, and actually opening up and playing with our images to see what made a difference in file size and by how much.
  • found commons.wikimedia for logos in svg and in different size in png and it is awesome
  • apparently caching in rails is actually as easy as everyone said it was. I don’t know why I didn’t believe them --> http://www.codelearn.org/blog/rails-cache-with-examples
  • slides for talks on topics that are new to me are actually a great starting point. Even without the speaker there to walk through the points, looking at the screenshots, code snippets, and even just having the terminology to look up and dig into was awesome, and super helpful
  • I knew about asynchronous javascript, but didn't really think much about (or really heard much about) the opposite, which is apparently called parser blocking javascript. Great article on the topic and how it can affect your site's performance
  • feels good to finally dive into New Relic

Floodgates of Assholery: My Experience Speaking at RailsConf

I admit it’s been kind of a bubble. My Flatiron crew is kind, curious, and we have the common thread of being (relatively) new to this whole programming thing. And in that community is a huge sense of comfort, a cushion, a warmth. 

In contrast, everything I’ve heard about non-Flatiron programmers has been pretty awful. We had a whole lecture about not being an asshole, which implies some sort of asshole-epidemic that we had to guard ourselves from once we entered the “real programming world”. The prevailing sexism and racism that seems to plague every tech event I see on Twitter certainly doesn’t help. I can’t open my feed without reading about yet another thing that happened in the tech community. And as an Ethiopian woman, that’s not exactly the welcome I was hoping for when I decided to be a programmer.

And so when my talk for RailsConf was accepted, these were the thoughts that consumed me -- that I was finally going to see the racist, sexist, assholery of the tech community on full display. I had this image of standing on a dark stage alone, removed from my Flatiron home, trying to convince an angry crowd of asshole white men to take me seriously. The added pressure of being a first-time speaker and a first time tech-conference attendee didn’t help. The usual pressure of me being a perfectionist certainly didn’t.

My first interaction with RailsConf programmers was at the Speaker Dinner. I happened to walk in at the same time as another female speaker, and I decided then and there that she was my new best friend. And by best friend, I mean that I wasn’t leaving her side until the dinner was over. I don’t think she was aware of our best-friendship.

I counted the number of women. Three that I could see so far (there would later be more). Then the number of black people. One. Me. Sigh.

I hoped that everyone would just leave me alone and let me sip my free beer in peace. But of course, people just have to talk to you and be all friendly and shit. And so I met Sean. He told me about his bees, and the work he was doing helping researchers save collapsing beehives with an app he built. We talked for awhile. He was fuckin awesome.

We sat for dinner.

Fancy steak and an incredible panna cotta with some crazy combination of things that I would never think to put on panna cotta. But I’ve never made panna cotta, so that’s not saying very much. I sat with Rosie and Sonja, who went to Flatiron with me, and four other men. I braced myself, trying to focus on my food and avoid all eye contact. But these fuckers just had to start a conversation.

We went around the table and introduced ourselves. Where are you from, what do you do, what’s your talk about. Everyone at the table sounded impressive. They’d been programming for years, doing crazy sounding shit I can’t even recall. 

When we told them we’d all recently graduated from a three-month programming bootcamp, I expected a few scoffs, especially given all the criticism that bootcamps have gotten. But they seemed genuinely happy for us and our programming journey. Two had given lots of talks before, and gave us advice on how to prepare for our big day. They made me laugh. They made me feel welcome. It was all so very confused.

My confusion persisted the next day when I attended one of the talks. A speaker used the male pronoun in his talk, and actually apologized for it. “I’ve been trying to use gender neutral pronouns, but it’s really hard. I’m sorry,” he said in his talk, his voice filled with guilt. 

Huh?

And my confusion grew when someone gave a talk called Software Development Lessons from the Apollo Program. He told a story about how the first NASA software engineers were women because the men thought programming was too simple and wasn’t worth their time. Only when they realized how complex it was did they decided to take it back. Julian ended by saying that if anyone in the audience thought women shouldn’t be programmers, to think again, because women were some of the first. 

I ended up running into him at a rooftop bar afterwards, and told him I appreciated that story. “You know, I just felt like I had this great opportunity, this platform to say something meaningful,” he said. And so he chose that. 

Huh?

I met a number of incredibly warm people. Men who mentored women, who worked with Rails Girls, who cared about diversity in tech. Men who were curious about my journey, my story, and wished me luck before my talk.

But I hadn’t been on stage yet, so I was sure this was all a huge ruse. Once I got on stage, the floodgates of assholery would certainly burst open and bury me and my little cartoons.

My slides appeared on the screen and the clock began its countdown. I started speaking. The lights were blinding. I couldn’t see much of the audience, but I was sure they were glaring at me. 

I forgot how much we rely on feedback in a conversation. You can test the waters, try a joke, see if they laugh, drop an f-bomb, see if they cringe. You can adjust how you speak, how you act, to better connect with the person you’re speaking to. But on a stage, there was little to no feedback. The occasional laugh when I wasn’t expecting it threw me off, and the silence that remained was uncomfortable. At some point, I caught the nodding face of Farrah, one of the keynote speakers, and focused my attention on her. That helped a lot.

And when I walked off stage and saw a small crowd waiting to talk and ask me questions, I felt hugely reassured. They seemed to have to enjoyed it. They wanted to learn more.

I ended up meeting some of the most wonderful people that week. And in those conversations, no one seemed to care what I looked like. 

I’m still waiting for the floodgates of assholery. But I’m glad I haven’t come across them yet. To everyone who’s been kind, and encouraging, and supportive and who’s made my programming journey so much less terrifying than it could’ve been, you know who you are. From the bottom of my heart, thank you so very fucking much.

 

 

 

 

 

 

What Would Aldric Think?

A huge part of writing code well is communicating effectively. I hear it all the time. I tweet it. I co-sign it. I get it.

But it wasn't until we sat down with Aldric that it really meant anything. Up to that point, we'd mostly communicated with each other, Vinney and I. We pair most of the time, and we're always in each other's head. I took a lot of that for granted until we found ourselves waiting sheepishly while Aldric poked around our app in what would be our first code review.

He paused at a method.

"So you're returning all the events. That's a lot of events."

"Oh no, it just returns upcoming events."

"But it's called 'all_events' ..."

*pause*

"Yes. Yes it is ... We should probably change that."

It was the first of many face palms. But more importantly, it brought a lot of tangibility to the programming mantra we'd accepted. The problem with "communicating effectively" is that it doesn't identify who I'm communicating with.

Till then I'd likened it to writing a blog post or a personal essay. There is an ambiguous Audience. I'm not sure what it's looking for, or what it's doing here, but it's nice to see you! And I hope you find something here that tickles your fancy. But among Audience, I expect that only a small percentage will really "get" it. And if you don't get my tone or my slang, I can brush you off and claim this just wasn't *for* you. I don't optimize my writing for the Audience, I optimize for the few.

It doesn't really work that way in coding. I'm communicating with every coder. Every coder should get it. And my intent should be crystal clear.

I admit it was a bit exasperating to focus so much on method names. It felt like there were so many bigger design problems to talk about.

But it forced me to confront why it mattered so much. Why naming was such a topic at the Flatiron School. Why it always seemed like such a big deal. And it all comes back to communication. The whole point of communicating is to establish a relationship, a sense of trust, a platform to build on. Naming was the beginning of the developer-outside-developer relationship. It established expectations. It was the first time I was communicating with Aldric. And in my somewhat-ambiguous naming, I had broken that trust. If my names mislead him, he’ll not only begin to doubt more complex decisions I’ve made, but he’s forced to look beyond the name and understand the work each method is doing.

It destroys the role of the method as an api for the other developer. He can’t take my method at face value, he has to see it and understand it before he can use it. Not the best way way to start a relationship.

It was a great reminder of who we were communicating with and why communicating effectively was essential, even in the seeming simplicity of naming. And now, instead of wondering if I’m communicating effectively, I find myself peering at our method names and asking a much deeper question -- “What would Aldric think?”

Need For Speed

My old boss once told me that I have two speeds, 0mph and 100mph. And if I'm not going 100mph, I'm not happy. That’s the truest thing anyone’s every said about me.

I love going full speed. And now I can’t. Because as a new programmer, I have to be slow and I have to be deliberate.

I paid a lot of attention to how long something takes compared to how long I think it should take -- already a flawed premise since I don’t have the experience to estimate how long a feature should take in the first place. But of course that doesn’t stop me.

I often hear myself saying awesome things like, “Yea, we can knock out this feature in, what -- a few days, right?” Stephanie’s learned to ignore these statements, and meet them with a very tactful, “Hm ... that’s pretty ambitious. We’ll see.”

Which is clearly a challenge. That I have yet to win.

But as of late, I’ve decided that paying attention to a velocity isn’t as productive as paying attention to the factors that affect it. And I think about that a lot.

I think about the work I did that day, and I reflect on how I could've been faster, more efficient, more productive. And usually there are concrete answers - I should've played with the gem a bit more before using it. I should’ve asked for help sooner. I should've taken a moment to plan and think through the process before diving into the code. Or just the opposite --- I planned too much, overthought it and didn't see how simple it was until I started coding.

And when the same issue comes up again, it prompts a conversation between me and my programming partner. We pair a lot, and we reflect often. The last time we tried this, I remember this being a huge bottleneck. Let’s try it this way instead. I feel like this has been a common theme. We need to look for a better, long-term solution. It’s less straight up coding, and more about process. There’s a lot more process than I thought -- stemming from the tiny decisions that don’t even feel like decisions we end up making while building this app from scratch. And there are a lot of decisions.

But it’s painful when those issues show up more than twice. That’s when I feel stagnant. You’ve been here before. Haven’t you learned? I trust that speed comes from experience, and experience comes with time. But anything I can do to get there a bit sooner, I’ll do. Can’t wait to get back to my 100mph.

Demons and CFPs

I type out the first few lines of my first CFP, and there they are -- my demons are perched, ready to pounce with plenty of ammo to burry me with. They attack every thought I print to the screen. “Rails is an opinionated framework.” How the fuck would you know? “Our exploratory approach has been a key part of the group’s success ...” Who the fuck cares? And when they grow tired of picking at particular phrases I pen, they fall back on their favorite refrain ... Who the fuck do you think you are? 

They haven’t been this loud in awhile.

How I Accidentally Learned About Single Table Inheritance

I worry about writing bad code and not knowing that it’s bad. So this week I took some time away from coding to read POODR and wrap my head around what “good code” even means. 

There are many reasons to fall in love with the book, but I think one of the things Sandi Metz does best is show you what “bad code” looks like, and refactors it piece by piece, calling out different techniques she’s using along the way until she gets to her final solution. 

The first time I read it, I was able to follow along with her analysis, but not really able to call out the techniques she talked about on my own. I understood but I didn’t retain.

Halfway

 

Six weeks ago I was rolling in bed, too excited to go to sleep before my first day of Flatiron. Six weeks from now, I will be rolling in bed, too sad to fall asleep knowing that Flatiron is over. And today, today is halfway.

At halfway, we talked about our feelings. Every Friday we talk about our feelings. But this Friday, Avi asked us to reflect on the overall experience, rather than the usual weekly review. We talked about growth, about the pursuit of self actualization, about dealing with fear. All of which I agreed with, felt and witnessed everyday. But this weekend was particularly telling of the program’s impact on my personal development, as I stared at my browser and consistently resisted the urge to punch my computer in the face.

I was working on my first Rails app. It’s about frogs. Naming them, giving them colors and tadpoles, then having the tadpoles “evolve” into frogs while retaining their tadpole attributes. You know, your basic froggy features. And it was painful.

Patterns, Peeing & Interpolation #TIL

Day 12 @ Flatiron

  • John McCarthy coined the term “artificial intelligence”
  • John McCarthy had awesome hair
  • Looking at a problem is the way to get to the solution => read your errors
  • Everytime Avi says “code smell,” a little man pops into my head, yells “YO SHIT STANK!” then runs away.
  • LISP: an expression based language. No objects. What you lose in maintainability you gain in performance. Loves parenthesis.
  • When you stop comparing yourself to others, you free yourself from so much cognitive load. And now you have the capacity to kick some ass.
  • Calm is a beautiful place.
  • I average one bathroom trip for every 2 cups of coffee. My bladder is pathetic.

Reflections on “The Top 10 Reasons the Ruby Programming Language Sucks”

 

I guess I wasn’t aware of much time I’d spent learning how to derive meaning rather than create it. 

As a reporter, I wrote stories. I crafted a piece as accurate and elegant as I could muster, and hoped it was captivating enough to hold you in place, still, quiet, until it was over. And while writing is indeed a craft, the point of journalism is to bring meaning to ideas that already exist. Which means that what I created was only as good as its ability to explain.

As a scientist, I worked with DNA. I contributed to the creation of new ways to detect it in limited quantities. The work of a research fellow was surprisingly creative and intellectually challenging, but the point of creating wasn’t to create: it was to explore and explain objects that had always been there, waiting to be discovered.