CoRecursive: Coding Stories - Story: Cocoa Culture

Episode Date: December 2, 2021

The last episode, I said I wasn't sure there was such a thing as culture, but that's not the case. Every place I've worked has been a bit different, and often those differences had huge impacts on the software we built. The team where people roll their eyes at UX feedback will not have as simple of a product as a team where the user experience is highly valued. If software performance isn't valued, the end result won't be performant. Today, I found an expert on observing developer cultures. Hansen Hsu worked on the AppKit team at Apple, and he's here to talk about this mushy concept called culture. How does it manifest? How does it affect what people build? And how can it lead to beautiful software? Episode Page Support The Show Subscribe To The Podcast Join The Newsletter

Here's a question. If you went into a tech company and watched software being built, what would you see? You might see people working with headphones on, you might see people talking in meeting rooms, or having animated discussions around a whiteboard. But it would take time to see the things that mattered. Who had the power, what ideas were valued, and what ideas weren't. Last episode, I said I wasn't sure there was such a thing as culture. But that's clearly not the case. Every place below the surface is very different. Some things are valued at one place, and then they're discouraged at others.

It's just sometimes hard to pinpoint these differences, but the differences do matter. The team where people roll their eyes at UX feedback is just not going to have as easy to use of a product as a team where the UX person is highly respected. If performance isn't valued, the end result probably won't be performant. This is Co-Recursive, and I'm Adam Gordon-Bell. Each episode is the story of some piece of software being built.

And today, I found an expert on observing developer cultures. My name is Hanson Su, and I am currently a curator at the Computer History Museum. Hanson was on the ground at Apple during an important time in its history. In the transition at Apple, it forced the transition in Hanson so that he starts as a dev on the file system team, but he ends as a museum curator. I guess this is part of what your interview is about, but that journey actually is a pretty interesting one. And on this journey that he's going to take us on, you're going to learn some specifics about this mushy concept called culture and how it manifests and how people interact and what they build and ultimately how it can lead to beautiful software and almost a religious devotion to an app framework. This story starts with Hanson's first day at Apple as a software engineer.

I joined in October 99. I can still remember the day. My start date was October 4th. I was in the classic Mac, Macintosh operating system team. The classic Mac operating system is what predated Mac OS X. It was old and it had some issues. I joined them right after they had shipped Mac OS 9 itself, 9.0. So that was a very successful release.

Parallel to OS 9, OS X was being worked on by a team from Next Computers. Next Computers was a company that Steve Jobs had founded and that Apple had acquired specifically for its operating system. The prevailing sentiment within OS 9 was that, oh, they're going to be working on this research project forever. Like, you know, we don't know when they're going to ship. In the meanwhile, we're keeping the lights on, right? We're continuing to ship new features to our users who are buying these brand new iMacs and iBooks. And, you know, the turnaround was going when I joined.

So Apple had come out of the darkest era. You know, the iMac was a hit. The iMac, they're like the colored ones, right? Yeah, the colored ones. Yeah, it was that era. You know, there was a contingent within the classic team that felt that, you know, there were ways that technically that they could actually introduce more modern operating system features to classic Mac OS gradually. They had plans to do so. Within the classic Mac team, plans like that might have made sense. I mean, previous attempts to replace the Classic operating system had failed. But this time was different.

I mean, if you really look at it from the corporate level, there was no way that the corporate was going to let them do that, right? Mac OS X was coming. Were you disappointed at all when you joined that first group and the curtain was pulled back and it seemed to be a mess or what was the feeling of that? It's like being a cast member at Disneyland, right? Like if you see if you actually see the back lot of Disneyland, the magic is pulled away. Right. And it's like it's not the same. Right.

It's you know, you you don't always want to know how the sausage is made and, you know, and being smack in the middle of like OS nine at a time when, you know, the, the winds were clearly shifting in OS tens direction. It was like, you know, the, the, the politics of the, of, you know, the higher ups, but it was, it was definitely being felt. So I was originally on the file system team and three months in, they said, okay, well, we're not doing any new features in the file system. So we're going to reassign you to work on, to help work on the multi-processing APIs

with this other guy. So I was doing some unit testing for that for like a couple of months. And then it was announced, oh, we're not doing any new features for that either. So, okay. So then now what I'm going to do. So so then my boss assigned me to write this app showing the, you know, showing these two bars for for the the dual processors that didn't go anywhere.

He kept telling me, no, keep working on it. This is not busy work. This is not busy work. It turned out to be busy work. I mean, I learned a hell of a lot doing it, but it was a dead end technology, right? Nobody was going to, you know, be writing classic Mac OS apps, you know, in the future. And, and so then, then one day I went to my boss and said, okay, well, I feel like I'm pretty much done with this app. I mean, you know, there's always more I could do, but I feel like I've gotten to a point where this is pretty good.

So, you know, what next? And he said, I don't have anything for you. You know, I'm going to talk to HR to see if we could get you reassigned somewhere else to another division in the company. Stay tuned. Getting reassigned probably wasn't a given. Apple in the year 2000 had significantly less employees than it had in 1995. The company was in a multi-year staff contraction, and Hansen just had to wait on his boss and see where he ended up. And then the next week, he takes a different job.

First, he went to somewhere else at Apple, I think in OS X. But then within six months after that, he was at Adobe. So I was on a sinking ship. My boss jumped overboard before I did. Hansen found a way off that ship, though. You see, it wasn't just the operating system from Next that people were excited about. It was also a framework for building applications on that operating system. And the team building those Cocoa frameworks, it had an open rack for a QA position. So I knew, you know, this is where the power lies

within the company, right? This is the Cocoa frameworks are the new hot thing. You know, this is what developers are going to want to use. And so I, I, I jumped at that opportunity to, to go there. I was a full engineer, full software engineer, full developer originally in the OS nine division, but I was still very junior, you know, and the only other opportunities that, you know, that were available to me anyway, anywhere else were QA opportunities. So I was hoping that I could start off in QA and then work my way back up in engineering. And that ended up not happening. But I knew the Cocoa Group is where it's at.

So I basically situated myself within a very central organization within the company. So he starts out his new team. And I have to say, it's almost like I was in two different companies. I moved from building one to building two in an infinite loop. Physically, the distance wasn't that far, but culturally, it was night and day. You know, it was like moving from the old Emilio era Apple or prior to next. I mean, the culture was totally different. Everything was Unix based. And also, and this was something that affected my job directly, was the attitude towards testing was actually very different. In OS9, they had a dedicated QA division. And so QA people reported,

you know, we're in this other division. And, you know, so they, you know, they had a lot of, you know, power to say like, okay, you know, you got to fix this, you know, et cetera, et cetera. When I got to the OS10 group, they were only just starting to create QA within the organization because at Next they had always been very lean and mean. And so their attitude was, well, we do need some QA, but we should have distributed QA. We should have a QA person in every team. And so that's why that opening opened up in in, in the AppKit division. And,

and I became that person. Like you said, it was, if it was felt very different, like what, what made it feel different? The culture was different. Maybe, maybe that's what I was trying to get at is I felt like the culture was different. Um, the priorities was different. There was a sense of confidence. certainly. There was a sense of like, we know that like, this is the direction that the company is moving in. You know, the company is fully behind us and we don't have to worry about that. Like the other team was, they were worried that they wouldn't have a job, you know, in six months.

They had all these long-term plans, but clearly like at some point they were going to be sunsetted right like they were going to be moved into quote maintenance mode which is essentially like you know yeah you're going away at some point and also like you know just i guess just the technical culture in the app kit group it was well um this is how it was done at Next, and we're clearly technically superior. Like, it was just assumed that we're just technically superior. In a lot of ways, they were. They were technically superior. You know, there were a few little things here and there that maybe, you know, they weren't.

But like, in a lot of ways, they were. And so just the confidence of the team, that was different. Besides technical superiority, there were other differences. The next developers ate their own dog food, as the unfortunate expression goes. They used their own product. They did their work on the latest operating system builds. Which meant that any really bad bugs could affect your productivity. I remember there was maybe one or two times

where there was a change to something in the networking and that just broke everything and then it had to be rolled back and people lost a couple hours of work. So that was what would happen, right? Whereas that would never happen. There's no way that you could dog food on OS 9 because a crash would bring down your

your whole system it's the whole unix culture right like we you know we're able to live on you know a rock solid foundation and even though like we're you know we're working on essentially beta software pre-beta alpha essentially we're living on essentially beta software, pre-beta, alpha, essentially. We're living on it. We're using it as our daily machine. Like we're very aggressive and we're living with the bugs. It's a responsibility of not just me, but everybody to report the bugs that they see. Before me, there was no QA person. That was how they did it.

Everybody found bugs. Everybody was a QA person. So that was another reason why it just felt like a different organization. Just the whole process was different. Apple was so important to Hanson. And now he was on this central team where people were leading the charge into the future. And Apple as a company was undergoing this great renaissance. Everybody knew that that was my dream job. I mean, I was over the moon for a decent amount of time.

I mean, it was amazing that first, you know, the first couple of years where it's like, wow, you know, I get to be part of the rollout of this new operating system based on the next technology. And this is I'm in the middle of the revolution, right? Like this is amazing. And, you know, working at Apple is really great, but I do think that like over time, the day-to-day sort of grind did eventually wear me down because it is kind of like nonstop and there's always so much work to do. You just can't do it all. After you ship the first, the first one, then, you know, you maybe get like a month break to like, you know, do some side projects.

But the train starts again, right? And, you know, the train, you know, starts to build momentum again. And it's yearly, right? Every year there's a new release. And it starts to feel pretty relentless after a while. It's like there's always the next release. There's always another release. And, you know, maybe I don't have the best work habits,

but like when, you know, when you sort of bust your ass to get the current release out, you know, there's a certain amount of burnout and then you got to do it all over again. So like, you know, there's, after a while I was like, wow, like, am I just going to keep doing this

over and over and over again? Besides the grind, there was like, wow, like, am I just going to keep doing this over and over and over again? Besides the grind, there was a couple other factors making Apple seem like less than a dream job. I don't know if I should be revealing any of this, but one thing was that I was in a QA job, and I had hoped that that would lead to a development job. And I needed to be a lot more proactive for that to happen. I would have needed to be, you know, writing a lot of code on my own time, you know, doing a lot more to learn on my own time than I was doing. I realized that, like, I do kind of treat work as kind of like a nine to five type of thing. I'm not nine to five more like you know like ten to seven or something like that you know but like when i'm when i'm off i'm off

like i i don't i don't want to code on my my free time so like you know i i think my actual abilities they're good they're competent but they're not anything to write home about, right? I'm not like, you know, the 10x developer who can single-handedly like turn something around, right? Like I mostly learn through repetition, through, you know, doing things multiple times, you know. Some 10x developers don't think that either. I guess part of it was a crisis of confidence. You know, I'm surrounded by brilliant people. I'm surrounded by the cream of the crop, essentially, right? These are brilliant people that I'm with. Like, these are the best of the best. And here I am, I'm just like sort of a

mediocre guy. Like, that's why I'm the QA guy. That's why I can't get out of it. While he was feeling downtrodden about his job, Hanson also wanted to broaden his horizons. I wanted to get a firmer base on the world and how it works and history and the social sciences and philosophy. And I just had an interest in that. And so I started taking some night classes at the local community college in Cupertino. And the philosophy professor that I had, I went to her office hours after the quarter ended. And I sort of broached this idea of, you know, what would it take if I were to leave my job and, you know, actually study this? What would it actually take? Would I be able to do this? I got, you know, very good

marks on my papers. And, you know, that professor was the first person to make me think, you know, this is something that I am actually good at. Like, I'm a dime a dozen at Apple. Like, there's, there's plenty of people who could replace me. but you know, this kind of academic work I could actually do. And, and for the first time, I, I began to feel like this could, this could realistically happen. And then, and then of course, another thing was you remember in 2005, Steve Jobs gave that commencement speech at Stanford, right? The famous commencement speech. And he talks in the speech about, don't live your life for someone else. Don't tie yourself to someone else's dream. Do your own thing.

And so the irony of that was it actually woke me up and motivated me to think about, wait, I'm just a cog in the machine here at Apple. It totally makes sense, right? Steve Jobs wouldn't work as a cog in the machine here at Apple. It totally makes sense, right? Steve Jobs wouldn't work as a cog in the wheel at Apple. Right, exactly. Yeah. And then of course, the last thing I have to mention, which is a personal thing,

was that I had gone through this terrible breakup situation in 2001. And, but, you know, this was a person in my church community. So I still had to see that person every week. And at some point, I just had to get out of here. About two years in, it was just like, yeah, this is not healthy for me. I need to leave. And so without that, I think the other things were all important. But I think the fear of actually leaving my job and also, you know, this was my dream.

Why would I give it up? Like, you know, I don't think I would have had the necessary forcing function to force me to leave. But once I'd made that decision, then I was like, okay, well, I guess I got to go all in. This is a career change for me. I have to treat it like such. I can't look back because if I do look back, I'm not going to be able to do this. So Hanson moved to New York to do a master's in history. And in some ways, he became a different person.

He went from an electrical engineer to someone who talked about historical narratives and the social construction of truth, which really made him think about this power struggle he had seen going on in apple that transition from the old guard to the new next world the idea that like technical arguments alone um they're not the final deciding fact that you know the the final deciding factor is is power right who has the power to make the decision? If it wasn't the next people in charge of the company, the decision could have gone the other way. And then he was thinking about what he should study for his doctoral research. I'm going to do a PhD in history.

Maybe the only thing that I think I can actually do in that level of detail is history of computers, because that's what I know. And, and, and also I have this special access to the Apple culture. I should leverage that, that as a, as my strength, right? Like anybody else can do a history of China or, or, or whatever, but this is something unique that I bring to the table that nobody else in the social sciences has, is this experience of being from Apple.

So did you reach out to people at Apple to try to talk to them? So I did initially try to reach out to Apple itself to see if there was a way I could do something involving Apple. So I reached out to Scott Forstall, who was my, my boss's boss when I was there. And, you know, of course, Apple is Apple. They don't want anybody like doing,

doing like an ethnographic study of them. Like, you know, like, you know, they're a black box company, right? Like they're opaque. That's just, that's just who they are. So I knew already going in that like, yeah, like I know them, but I'm not going to get special access. Hanson had a backup plan that was maybe even better. As a QA for the Cocoa team, he sometimes had to test third-party apps. And so he was very aware of the third-party AppKit developers. And they were an interesting group. They were super passionate about AppKit developers, and they were an interesting group. They were super passionate about AppKit and the Cocoa framework. And also as a historian, it was kind of a more nuanced story. Because then it's not just like a history of Apple itself or like, you know, it's not

a corporate history. It's actually a story of this community, but it's a community that is devoted to one company or at least a technology from one company, right? Cocoa Technology going back to Next and through thick and thin, right? They were there so many years. There was a question of would Next survive? Would Next survive as a platform, as a company? well, we'll leave when you pry my cold dead hands away from my app kit because it was so much better

than every other development environment at the time. Having worked on the Cocoa team, Hanson knew who the big names were and he had met some of them at the Apple Developer Conference, which was called WWDC. They were using the framework his team was building. So of course they would want to meet with him.

But now it's several years later and something new is happening in the Cocoa world. The iPhone app store is out and people who aren't card carrying members of the cult of Mac are trying to learn Cocoa and Objective-C. This framework to an outsider, it can seem really strange. It was dynamic and based on small talk message passing, but it's also based around C and you had to manage memory. It was very different from the software development paradigms web developers or Windows developers would be used to. And I thought, okay, well, you know, actually training people to become new Cocoa developers is a critical stage, right? That's where, you know, just from academia,

like that's where, you know, in a Foucauldian sense, that's how newcomers to a community are disciplined and the norms of that community are transmitted. What's Foucauldian? Sorry. So this is from Michel Foucault. He's a pretty well-known theorist. He's written a number of books, one of which is Discipline and Punish, which he discusses the idea of education being a place where values are learned, right? It's not just about learning skills or learning knowledge. It's also about

learning to be a person in that society. You know, people go to school to learn how to be a citizen, right? How to interact with your peers, how to interact with people, like morals, essentially. Okay, this is really cool. Like, how does a newcomer to the Apple development world learn the local conventions for structure and code and building apps that look like they belong on the iPhone? Apple developers have a reputation for caring about every pixel. Where do they learn that? If you want to learn how communities of developers built up a culture and transmit it forward,

this is the type of research you'd want to do. And so Hanson reaches out to Aaron Hilgus. Aaron had been one of the internal trainers that taught people how to program for the next. And that continued at Apple initially, but then he decided to do his own thing. But even then, he had cachet because he had been one of the next trainers and he had built, built up a lot of that curriculum. And so him doing it on his own for people in the know, at least, you know, he was still the guy, right? He was an expert on teaching people Cocoa AppKit. And now eight years later, Aaron had written the definitive books on AppKit and on iOS development. He ran a bootcamp

bringing developers up to speed at a place that he created called Big Nerd Ranch. Even though it's called the Big Nerd Ranch, it's not actually a ranch. So Aaron will tell you this, like the initial idea behind the Big Nerd Ranch experience is it would be like going on a silent retreat, like being in a monastery or a cloister kind of a thing. But for marketing reasons, that's not going to fly, right? So he thought of instead for marketing reasons, he thought of the dude ranch as the better sort of model for what it would be. So Hanson reaches out to Aaron and says he wants to study him and Big Nerd Ranch. He wants to embed himself in the business and learn and take notes. It's actually a pretty strange offer if you think about it. Imagine if somebody

reached out to your team and asked if they could embed themselves in it and take field notes for a dissertation they were working on. But Hanson also had a certain cachet. He was from the Coco team at Apple. And so Aaron agreed. What did you envision in your mind that you would get out of this like you leave and say like this is a success i'm not quite sure what i was expecting to get i think i think maybe i thought okay i'll be observing their classes number one and and number two i would be maybe taking part in you know being part of the, like the other part of the company, which was the actual development part of the company. So the company also did contract development for third party clients. And so I would actually learn to program by being part of those projects.

So Hanson packs his bags and he heads down to Atlanta. The first couple of days, he actually let me stay at their old offices. And they had only just recently relocated to a larger facility. They were growing like gangbusters because, of course, their iPhone business was exploding. The offices of Big Nerd Ranch didn't look like a ranch at all. They were located in a generic residential area of Atlanta. Like if you've seen, you know, the social network, like, you know, early days of Facebook, they're all in the house, right? Like, or like in Silicon Valley, they're all in the house,

but they're working there. A little bit like that, except that nobody lived there, right? Like, it was still just pure offices, but it was a condo. It was like a, it was a residential condo turned into an office developer space. The reason they weren't actually at a ranch was that this office and the bigger offices that would follow were the center of the app development side of the business. They would build apps on contract, and pretty soon Hanson was building apps for the iPhone app store. I did become a developer working with their other employees working on code. And that part of it, that was really fun. And in fact, I learned a lot more there than I in just, I mean, I was there for, I think, five months in 2011 and then another six months in 2012 or something like that. So 11 months total.

I learned more in those 11 months than the five years that I was at Apple as a QA developer in the actual Cocoa team. I learned more about Cocoa development at 11 months at Big Nerd Ranch than I did as a QA developer on the Cocoa team itself. Why do you think that is? Well, for one thing, Aaron's whole purpose for the Big Nerd Ranch is all about learning. And it's all about mentorship. You know, that's who he is, right? It's all about teaching and training, right? The contract development, it does a lot to pay the bills. But the other part of it is it actually is there so that the developers know what they're talking about when they when they teach the classes, right? It's not like, you know,

those who can't do teach, right? At Big Nerd Ranch, it's those who teach also need to be able to do, because that's why they're, that gives them the knowledge to do the teaching. And, you know, so the whole culture of that company was focused around providing this environment to learn and to be constantly learning. Things had changed in app development since Hanson did QA for AppKit. The new iPhone framework UI kit was very much based on it, but it was a different thing.

But Hanson gets up to speed on it, and then they let him start TAing classes at the iOS bootcamp trainings. And being at these trainings is just what he really needs to understand how the knowledge and cultural norms of this community is transferred to a new generation. This is his chance to observe people getting baptized into a new techno-cultural frame, as he calls it. This is people being immersed into a new software development paradigm in a condensed and immersive five-day experience. So what they do is they rented a place at sort of an out-of-the-way

kind of resort in the woods. Not a resort. It's sort of like a set of cabins. So at that time, the place they used was called Historic Banning Mills. It's about an hour outside of Atlanta, and it's in a very wooded area. And you sleep in these little cottages, those little cabins. And then there's a main building with like, you know, so there's sort of communal dining. So we all meet for, you know, our meals and stuff. And then we go down to the basement

and the basement is where the classroom is. The classes are a five-day immersion based around the book, iOS Programming, The Big Nerd Ranch Guide. And it are a five-day immersion based around the book iOS Programming, The Big Nerd Ranch Guide. And it's a big book. The book and the trainings were developed together to take people from diverse backgrounds and get them ready to join the world of iOS development. And so there's, of course, you know, there's a screen where they project, you know, the lectures and also the code. And then everybody gets either a copy of the published iOS book,

or if they're already, you know, if there's enough new material, they might get sort of a beta copy of the next version. So it's in like a, you know, like a soft binder kind of a thing. The teacher is at the front of the class and everybody follows along. Okay, so he types in some code and then, and then compiles it. And then this is what it does. Right.

So people can actually see what he's doing in live real time. And who are the students? Like, where do they come from? So the students typically are, some of them are people who've been sent by their company to take this course. They're not paying it for themselves. It's a very expensive course.

How much is it? I don't think it's as much as 10, but it's definitely more than two. I mean, you get full room and board for a week. So that's part of it. But you know, you're also getting this direct hands-on instruction. And I mean, yeah, you could buy the book yourself. But I say, you know, as I said in the dissertation like it it's easy to be distracted on your own right when when you're in this classroom you're you're there and part of the point is that you're cut off from the world you know also in that location the wi-fi isn't very good like and that's on purpose it's sent in some ways because that you don't want they don't want

you to be like checking your twitter or whatever Twitter or whatever while you're in the class. You're there for immersion. It's an immersion. It's like language immersion, but for Coco, for iOS. And it really is that way, because you're given an hour to do an exercise from the book, which basically is just like, type in this code, and then and then you run it. And then, you know, see if it comes up. And, you know, of course, coding is coding, right? So nothing ever happens easily. So most of it is just figuring out what went wrong. But that's part of the learning process. It's part of the learning process is learning how to how to learning what the compiler errors are,

what is it telling you how to fix those problems. Fixing those problems is where Hanson's job comes in. As the TA, the teacher's assistant, he tries to help people who are stuck before the next lesson starts. And then, of course, then every next lesson, you add on to that application that you just built. The idea is that the application that you built in chapter three, you then add another feature in chapter four and then another feature in chapter five and another feature in chapter six. Until by the end of like the third or fourth day, you've created a whole app with like table views and like all this functionality that, of course, you know, like you wouldn't have been able to do on day one, right? Like it's, you really get to feel a sense of accomplishment by the time you get to the, get to the end. People struggle with it.

Oh yeah. I mean, it's not easy. It's, it's definitely like a case of, you know, fire hose into the brain. Like it's so much information so fast and, and that it's so fast that like it's so much information you can't really absorb it all. You're just copying the code from the book into the thing because you wouldn't, you wouldn't, you wouldn't be able to come up with it on your own, right? You wouldn't be able to write it up on your own. And it's really just about being, getting a reading knowledge of what Cocoa Code looks like, what working Cocoa Code looks like. And then the actual experience of running it, debugging it. I mean, debugging it is the

most important part. And that's where the instructors are to help them get through the breakthroughs, right? It's like, I don't know what's going on. I don't know what's happening. And especially back in those days, there would be runtime errors. There would be things where the compiler wouldn't catch because Cocoa is in some ways a loosely typed language. So if you mistyped the name of an object or a method that you wanted to message, nothing would happen. The program wouldn't crash, or maybe it would crash, but it would be a runtime error.

They're very hard to debug and you know, you have to have somebody experienced who knows what that looks like to go. Okay. That's exactly what's happening. It's a lot of it was, it's just purely about just sort of being immersed in the environment. And then gradually the ideas start to diffuse like ideas that like, you know, so you're introduced like to the design patterns, like delegation and stuff. Right. And that stuff doesn't really sink in when you're first introduced to it,

like maybe on day two or day one. But maybe by day four or day five, you've seen enough of it that, okay, the pattern is there. It's a pattern recognition thing. I can recognize it now. I didn't understand it before but like i kind of can recognize what that feels like now of course like you know you've been bombarded with like more material in those those last two days also that like you won't you you won't retain but at least

the things earlier like by this point you've kind of started to get okay i kind of feel what that is now right so it's it really is just like swimming in the deep end why why why do you think that works like or does it work i think it's i i guess it's i would say maybe the closest metaphor is learning a language it's just it's just being being immersed in the environment and you just gradually start to pick up stuff and not consciously, right? Like it's just being, just the immersion. Meanwhile, as people struggle to learn iOS and Objective-C and Cocoa and UIKit, Hanson also has to keep part of his brain in anthropologist mode. I mean, there's part of me that is like letting myself just be in the moment and just act like however I would. But there's a part of my brain that I can't turn off.

I'm constantly having to keep my eyes open to things that are interesting anthropologically or sociologically or something. The way I picture this working is like the movie Gorillas in the Mist, where Diana Fossey is a naturalist observing gorillas in the wild. I mean, Hansen isn't in the Congo. He's an anthropology student in Atlanta. But just like her, he's observing things for the benefit of his colleagues back home

that he eventually wants to publish. And so I had to do that every day after my day to like write down, you know, and if I could find a little bit of time, maybe I would take some quick and dirty notes to like remind myself, okay, this was interesting. This was interesting.

Like as an anthropologist, like me going to lunch and just palling around with the guys, that's part of the thing too. I'm always studying them. I have to be always aware of everything that's happening. And I'm a participant in it too. So it's kind of exhausting in a way mentally. What would a field note about lunch look like? Oh man, probably very hard to decipher. I don't know if I'm that good at taking field notes,

but I think it would just be more like, oh, this was interesting. Like somebody said something about this and, you know, this, this is interesting to me for this reason, you know, now that I've, I've gone through, you know, graduate school, and I've read all of this material, you know, and I know all this sort of the theory behind stuff. And I know, like, what are my colleagues back at Cornell going to think are interesting? You know, what are people in my field, in what are sociologists and anthropologists and historians going to think are interesting about this situation that I'm in? So me, from 10 years before, as just a regular developer coming in, wouldn't have that, right? But now that I'm coming here as a scholar with all this other knowledge in the back of my brain, bringing that to bear and using that to illuminate what I'm seeing.

That's what's new about it. This new perspective caused Hansen to focus in on normative practices, the little rules and standards that are shared within a community. You should structure your code this way. You shouldn't name your variables that way. Here is how you use braces. Communities might have reasons why they do things variables that way. Here is how you use braces. Communities might have reasons why they do things a certain way. In a university, they might teach these ideas from first principles,

going through them one by one. Big Nerd Ranch would never have you do it that way. They have you work on concrete projects. But as you build something, the community norms are sprinkled in. We're going to write it in this way, and it could be written in this other way, but we're going to write it in this way because this is the more stylish way of doing so. And they may not explain right then why the real reason behind that, because that might be a deep technical discussion. They just say, well, you know, there are reasons, but for now, just know that this is the stylish way to do things. If you want to be a cool Google programmer, do it this way. It's a sort of shorthand to get it.

This is the normative way to do things within this community. Although the trainers at the boot camps varied, a lot of this method for teaching norms comes directly from Aaron Hilges. So he doesn't use the word right or wrong because that that's too harsh, right? It's too black and white. He'll use the word stylish, right? So because the unstylish way still works. It's not totally wrong, right? It still works. It's more of a gentle nudge, right? And so that's how it was done. It was five days of intensive sessions focusing in on the practical. So the idea is to actually, you know, first show them how to do a specific thing. Make an iPhone app that does this, that uses the GPS, and then inductively use that to teach a more general idea. Lessons were

followed by literally typing in code and then debugging the inevitable transcription mistakes. And the second or third time you see something, that might be when it clicks. And then they tell you, okay, this is a pattern you've seen it before. This is called delegation, right? Then you can generalize. Then you can go, oh, there's this a larger pattern. And that's why I'm learning this. And it's much more effective because you're already motivated to learn this because you want to make this thing. And in this way of doing something first and then understanding how it worked after, the knowledge was transferred.

And the normative practices, as Hansen calls them, they just came along with all that other stuff. Which makes sense to me. I'm not exactly sure where I learned what stylish Scala code looks like. I picked it up over time, but I know that stylish Go code looks very different. These things aren't explicitly handed down. It's more like they're in the water supply. You know, C++ developers don't get told how important software performance is.

It's just a given. It's just implied, even if never stated. If you're in that community, you pick up that value. And so the solutions built by that community end up being performant. And for Apple products, what they end up being is very visually polished. But how does that happen? One thing when I was reading your dissertation, I was trying to put my finger on, I guess, is like, okay, there's this training at Big Nerd Ranch, but like, where do you come out the other side and like, just really care about aesthetics and, and, you know, only ever buy an iPhone? Like where, where, where does this happen?

The class doesn't turn you into that. Look, you either, you either came into the class already that way or, or you, you know, or not, right? Like, I mean, not everybody in the class is an Apple fan, right? You know, maybe they came from Windows, or maybe they came from web development, and this is something they want to do to enhance their careers, because they're doing this for business reasons, right? But it starts, right? Like, they start to care about some of these things, right? I mean, the aesthetics of an app is more important on the Apple platforms than it is on other platforms, right? Although I

think to some extent that has diffused through the rest of the industry. You know, I think web designers have done a good job of like, you know, caring about design, but you know, there is still a thing about like being a Mac developer and being like caring about like, you know, the pixels in your button or whatever. I don't want to give too much credit to the Bignor Ranch for like inculcating that. Yeah, fair enough. But like, well, like in a broader sense, right? I mean, Bignor Ranch, I guess, is just the representative example. But I guess like, yeah, if you're if you're like an enterprise developer and somebody

just comes up with a design and then you you crank it out or then you go to this other community where like actually like whatever that user experience is is actually part of your job maybe not your primary job but something you care about like that somehow this these ideas about roles or something get get transmitted i don't know i mean i would say the apple design wars maybe maybe where some of this is going on where apple at wwc the Apple Design Awards, they reward aesthetics. Those awards signal to the developer community, this is what we think is a well-designed app, a beautiful app, a good functional app for our platform. The best Cocoa developers or iOS developers will try to

aspire to winning one of those. And it's a badge of honor to win one of those, you know? So I would say, you know, a lot of that comes from Apple. And even if it's not explicitly that, just the fact that you own a Mac, like you're willing to spend the extra money to get a Mac, right? That plays into it, right? You care about that design. You're willing to pay somewhat of a premium, whether it's just the hardware design itself or the operating system. If you already use a Mac or if you already own a Mac, you're already predisposed to that, to the aesthetic part of it. So Hanson started this project with the goal of studying this group of independent Coco and later iOS developers and why they were so devoted to the platform. But I think his observations on how people were indoctrinated into that community and how it changed who they were, it's true of every powerful community.

So in my best anthropologist voice, let me read from his thesis conclusion. Cocoa developers have described learning the framework as a conversion. And what is apt about that metaphor is that it is not only an intellectual transformation, but also deeply aesthetic. Developers are left feeling as if this is the way programming should always be done and are eager to proselytize to others. This deep quasi-religious feeling

is the root of the devotion Cocoa programmers have for the technology and why they place their trust in Apple. A big thank you to Hanson for talking to me and for doing all this research. Hanson received his PhD in science and technology studies in 2015 from Cornell based on the research he did at Big Nerd Ranch and other interviews he did with third-party Apple developers. You can find him at the Computer History Museum, and I'll put a link on the website to his dissertation.

If this is your first time to the podcast, be sure to subscribe. And if you want to support the show, please head over to patreon.com slash adamgordonbell. One of the big changes that's happened since Hansen's research is the introduction of Swift. And on the 15th, Patreon supporters will get a bonus episode where Hansen discusses his thoughts on Swift and how it has impacted the Apple of Swift. And on the 15th, Patreon supporters will get a bonus episode where Hanson discusses his thoughts on Swift and how it has impacted the Apple developer culture.

He'll also be sharing some more details of his time inside Apple. So you'll find that on Patreon, along with the other bonus episodes that I've been putting out. Until next time, thank you so much for listening.