(Editor's note: transcripts don't do talks justice.
This transcript is useful for searching and reference, but we recommend watching the video rather than reading the transcript alone!
For a reader of typical speed, reading this will take 15% less time than watching the video, but you'll miss out on body language and the speaker's slides!)
All right. Can everyone hear me now? Awesome. OK. I want to thank Gary first for having me. And I wanted to also thank you so much for being such an awesome audience. Like, I've just been sitting in there laughing along with the talks with all of you. So I'm really, really excited to talk to you today.
So other than being excited to talk to you today, I also have a side quest. And my side quest is to madly annoy Gary and to delight Justin. So we'll see how that goes. So again, hello. I am Suz Hinton. I work at Microsoft. If you want to argue with me online you can find me at noopkat. Please don't do too much of that because sometimes it's scary.
So not a lot of people know who I am at this conference, which I love. So I've put together just a quick, sort of, slide show of, like, how to get the gist of who I am. This was me at the airport a couple of days ago. I've been in the US for many, many, many years and I still am completely terrified of ordering a meal with the cashier, because they just ask so many questions and I get really overwhelmed.
This was when [INAUDIBLE] followed me about a week or two ago. Everyone does this, right? You're like, oh god what have I been tweeting? And this is me wearing a strange contraption. This is sort of what I really like to do in my personal time. I just 3D print stuff and put it on my head. And then I look like a complete nerd and I take a photo of it. But this is a light up tiara that I run a live coding twitch stream, pretty much almost every Sunday. And I wanted to give my twitch viewers a way to interact with me more than just chatting. So they were able to put hex codes into chat. And it would just change the color of my tiara live, which is really fun.
So sort of talking about all of these disasters that I do in my personal time today. And so I was going to get up here and I was going to make myself look clever, inspiring so that you think I'm really smart. But I realized leading up to the conference that because this is code de-construct, that would be doing a disservice to you all.
So this is a really scary talk for me to do because I'm making myself quite vulnerable and I'm not very good at that sometimes. I'm known to my colleagues as a highly professional programmer who takes her job incredibly seriously. And there's a reason why I take my job seriously. It's partly because I'm a perfectionist, but partly because I feel that I don't have much of a choice but to do so. I'm a woman and so I'm judged much more harshly than my male peers. And more importantly, I am here in the US as a nonresident temporary worker. And so losing my job is a deportable offense for me. And so I like the life that I've made here and so keeping my job lets me keep that life as well.
And so I'm very nervous to present this, but I don't perceive myself as having the luxury to do that. And I feel that I can trust you all to take this journey with me today. So I'm going to show you my whats and I'm going to tell you why I do the things that I do. And I'm going to do this in the hopes that as an industry we can acknowledge that we should be making room for folks that sometimes think about problems differently, even if you don't agree with them.
So this is basically a talk about tools and the languages we use. And again I'm not really talking about my professional life I'm talking mostly about the stuff that I do in my personal time. So it's a tale of crutches to show you the more human side of programming. And I'm going to be telling you some stories about how I abuse software in ways that people tell me I shouldn't, but I do it anyway.
So I fell in love with computers when I was a young child. And you know, most people go on to become professional programmers when that happens. And that was true for me. But I didn't get into computers because I wanted a job in programming. I did it because it was creative expression for me. And I just loved being able to take my art that was on paper and put it on a computer screen. That was so much more magical and technologically advanced, as far as I was concerned.
And so this year was the very first line of code I wrote, I believe. Some of you are woofing. So this is Basic. This is on the Commodore 64. I think the Commodore 64 had already been out for about nine years. So I was a little bit behind to the game, but it's fine. And so for those who aren't aware, this particular register address that I'm poking, with the value 0, that pertains to the border around the actual screen of the Commodore 64. Like, graphical user interface, if you could call it that. It was just a console. And you can change the color to black. And this blew my mind. And so I read the Commodore 64 graphics manual and I was creating pics a lot on the Commodore 64 after that once I learn how to create squares on the screen.
This was my second programming language that I worked with. Some of you also might be familiar with this. It's Logo. And so this is like the total part of Logo, where essentially as Logo was designed to be mathematically delightful language for children to use. And so I found that delightful, mission accomplished. And so this code here is how you draw a square. And so it's very sequential. It's very easy to reason about. It's forward, right, turn 90 degrees, forward, another 50 right, 90 degrees again. That's how you draw a square. I thought this was really cool. Even though I was kind of doing poking registers a few years prior. I still thought it was really, really awesome.
Next programming language. This is Director lingo. And it probably doesn't really look like programming. And some of you may not have actually seen this before. So it reads like a sentence. It's like I'm talking to a person and not a computer. And so this says, if sprite five is visible, then go to the frame. And the frame was just like a different kind of screen, I guess. Or you could consider a different page if you're making a cd-rom, which is what I was actually making. So let's break this down a little bit, even though it doesn't look like programming.
So this here is very clearly a condition. If sprite five is visible. And then we have the other part of it, which this bit is actually optional. So you can say, then go the frame, which to me I just didn't like that. It felt really just not quite smooth. So I always put go to the frame.
And then Go, it's a pretty original programming concept. Like, what it actually does. But it doesn't really do what a normal programming language does with this. So this was sort of one of my first experiences of a strange programming language that didn't really survive for very long. But I loved it because I thought it was really poetic. And I think I was a teenager when I picked this up. So I just thought it was great. And I felt very inspired by it.
But lingo died out. And when Lingo died out I discovered a new program and a new programming language to use it with. And it was my first ever hammer. And I want to tell you about all the really dumb things I made with this. So this is ActionScript. So this is the third language I learned. Maybe the fourth. So this is ActionScript. It's a subset of ECMAScript. It was used in Macromedia Flash. Then Adobe bought Flash. And then they came out with ActionScript 3.
So I thought it was great. And then I just started making everything in Flash after that. Oh no, it didn't work. One sec. And so here is a game that I made. And Flash didn't really support 3D, but I didn't really care. So I just kind of 3D modeled this house. And I threw custom textures on it. And then, but-
This is supposed to be funny and not impressive. Thank you, though. And so anything that someone told me Flash couldn't do, I just tried to get around it. And so this was a game where you had to explore. And there was this weird teddy bear that you talked to. And you had to find where your parents were being kidnapped. And it was a little bit dark, but I liked it.
So games, I loved making games. I loved making websites in it. So my first ever full time job as a programmer many, many years ago was making those really intense, like, complete browser takeover websites with the really long loading screen. And things like that. And it sold lots of things like cars and stuff because I worked at an ad agency. And so that was my job and that was such a dream for me. I'm like, I get paid to use my favorite thing.
I got sick of trying to skin WinApp. So I just made my own MP3 players because it was way easier to skin. And I was controlling how it was skinned. I used it as a micro controller interface. So I picked up the Arduino when that came out. And I was like, well I know C++ so I'll write just a quick script on the Arduino. But I wanted to do things on the screen on my computer. So you can use a proxy program called, Tinker Proxy to take the serial data coming from the device, let's say from a sensor or something, and it will proxy it to it TCP WebSocket, which you can listen to locally with Flash. Because there were security implications of doing anything else. And then I could actually turn a dial in Flash and then it would grow a circle or something in Flash. And I thought I was a complete magician when I did that.
And then I had this really weird habit of making fake malware because you could export Flash as an executable and it was cross-platform. So I would antagonize my boyfriend at the time by just setting up Windows Scheduler to randomly run my Flash executables. And it would just randomly pop up on his screen.
So Nathan, if you're watching this, I'm sorry, but yeah, it was fun. So I loved Flash and ActionScript because it was faster prototype, it was cross-platform, and it was really easy to make stuff look good. Right. And that has been a pattern throughout my entire programing career. These are the three things that I want. I've added to the list. But they're still the main three things that keep me productive and keep me satisfied with what I'm making.
Now we all know how this ended. Flash got a really bad rap because it was just endlessly full of security vulnerabilities. Then the iPhone came out. And the iPhone came to Australia around 2008. It was the 3D edition. So we didn't even get the first one. And there was uproar about Flash not running on the phone. And I'd, sort of, like, moved out of that Flash job and I was kind of doing a bit of PHP and a lot of front end. And so I didn't mind as much.
But I was kind of watching my favorite program that I used in my personal time go out of vogue. And I think it went out of vogue for good reasons. It had security issues, it didn't work on smart phones, and there were accessibility issues. It was so hard to make an accessible website with Flash. And that's just a really appalling thing for our industry. So as much as I was sad, I know that it had to die. But I'll tell you a secret. I still use it all the time.
So I use it to make gifs. And I use it to make gifs to make slides and explain technical concepts. And so Flash is now called, Adobe Animator. So you know and it's still the best animation package I've ever used and I just love it and I feel it human and I pay for it. Here's another very subtle animation that I made. It's crocodile. And I was trying to explain that the crocodile is the [INAUDIBLE] MIDI protocol that runs on devices. And I was kind of explaining how that works. I have a talk called, "Babbling with the Merfolk." So if you want to check out this crocodile, she's over there.
But Flash was a big time hammer for me. Right. And so I put all my eggs in one basket. And then I lost out really big when it fell out of vogue. And I never really got over it to be honest, as you can tell. And so you can pry Flash from my cold dead hands. But I mostly moved on.
I'm try to remember time period. But there was a time period where I pretty much didn't do a lot of personal coding. And then one day I thought about Excel and I thought about solving a problem with it. And Excel has been mentioned several times at this conference and I love that. Because I love Excel and I want to show you all a dumb thing that I do with it.
So this is-
So this is some pixel art that I was trying to produce. And I wanted to put it on a web page. And so I drew it out first to rehearse it. And this was before you had Canvas. So you had to make a bunch of divs. So I'm trying to plan out these square divs that I'm going to make. And you might think, that's really cute, but what's all this mess going on? And then you look a bit closer and you're like, wait, what, is that CSS? What is that? And so essentially, I didn't want to use a server side language to dynamically produce the pixel art and the CSS.
And so Microsoft Excel saved my bacon because I was able to generate several hundred of those individual class names so that I could absolutely position all of these divs. Which, thinking about it you could just make a JSON object with Enums and then be done with it. But I refused to do it.
But when you think about it, this is actually really beautiful. And you know why? It's because Excel is actually a form of functional programming. And to prove that, this is the international Functional Programming Conference. This is the set list for 2003. And flanked by functional automatic differentiation with Dirac impulses. I'm not even sure how to pronounce that. And a sound and complete axiomatization of delimiting continuations is this talk here, which is called, A User Centered Approach to Functions in Excel.
I know that there's been a lot of papers, but I really want you to read this one too. It's beautiful and I actually identified with the programs that they're talking about. And so I wanted to share a few choice quotes from this because I think it's really important. And there's actually a lot of meaning and depth and empathy in this paper.
So it's basically saying, "For many people, the programming language of choice is a spreadsheet." Which is true. Katie touched on this today. I think Evan touched on it really briefly yesterday. And it's absolutely true. And this is especially true of people who are not employed as programmers, but write programs for their own use. And so they're often defined as end user programmers.
So there's a whole community of people that we don't really interact with and we should. And also, I identify much more with the end user programmer. Because in my day job, I write very serious code and very, I like to think, very good code. And then I mentor other people to write good quality code. But in my personal time, I rebel against that because I have so much fear about keeping my job that I blow off steam with these really dumb things.
So I definitely identify more with the end user programmer. The number of end user programmers in the US alone, and this was like back in 2003, is expected to reach 55 million by 2005. As compared to only 2.75 million professional programmers. So I'm sorry, but we're outnumbered.
And so they then go on to talk about the cognitive dimensions of designing a language to be user friendly. And like this table was just life giving to me. It just made me feel really, really good because it's something that we should all be thinking about. I mean, look at this abstraction gradient. What are the minimum and maximum levels of abstraction? Can fragments be encapsulated? And it keeps going and going. My favorite one is, can a partially complete program be executed to obtain feedback on how am I doing? I think that's a wonderful thing to think about.
So anyway, I don't want to spoil the entire paper for you because quite short. But I will end with my favorite quote and I hope you like it too. It is, "We hope that the paper may also serve to remind the functional programming community of a large, but mostly ignored group of functional programmers, namely end users." And I don't know about you, but that's a sick burn. I love it.
And if you want to know more, I'm not the best at explaining this, obviously. And so I would highly recommend that you watch the talk "Spreadsheets for Developers" by Felienne Hermans. It is just absolutely delightful. She did her thesis on functional programming in Microsoft Excel. She implements selections sort live and shows the visualization of it, which is incredibly beautiful. And then she covers how you would do it without the visualizations. It's magical. Definitely recommend you look at that. So there you go.
So this has me here, a while ago. We were starting to get along. And I was also like, I don't have a degree in Comp size. So everything that you've seen so far is why I somehow became programmer. So I knew that I had a lot of gaps to fill. And so I was watching a lot of the MIT OpenCourseWare. This one is on divide and conquer technique. It's about the convex hull, which is trying to find the smallest circumference that you can draw, to case all of the points, including the ones that you are drawing through.
And having that visual feedback as I was programming it, it would just keep redrawing it. And other than processing, I don't really know of any other kind of environments that act that quick to spin out where I don't have to configure it. And so jsbin was totally my friend when I was trying to fill in those CS gaps.
And so I used Python, I used tkinter, however you pronounce the GUI. Library and then I used ABR dude, which is c++ executable to Flash to change the information on the actual device.
And I had a little problem with this. First of all, this is not accessible. I booted up a screen reader after I'd done it and it didn't work. It was cross-platform, but it was not accessible. Also, it's really fugly. I didn't like the way it looked and I'm a front end developer and I get really weird about that stuff. And I just had a pretty bad developer experience with it. I think maybe tkinter maybe wasn't for me. So if you've got any other recommendations for Python GUI interfaces, let me know.
But here's the thing, it's not like these modules were just available for me. I actually spent a month or two writing brand new no-JS hardware interface modules that could speak the communication protocols that these microchips, and the programmers that would program the microchips, needed. And so I started a family of no-JS modules, which I'm probably best known for code AVRgirl, which is a gender bender of AVRdude, the other tool that we can use.
And it took me like, I just went on the world's longest yak shave to do this. Because when you look at it, so this is like one line of my code, kind of simplified. And this is a buffer of opcodes that I'm preparing to send to this microchip. And this reads the first byte of this ATtiny85 signature. And you read the signature to verify that, oh yeah I'm talking to the correct microchip. I'm not about to break something else that's plugged into the computer.
And so I'm from Australia where we still run most of our internet on copper. And so I'm very sensitive to download speeds. But also, I think that it's an accessibility issue. And so I really wasn't happy with that because the Python app was actually 5 meg with all dependencies.
So I was like, well this isn't good at all. So I literally just threw it out and I never released it. Because here's the thing, my nice experience wasn't with the problems that I was causing for the users. Right. It wasn't worth it.
And then I found this blog post, which has been mentioned. I was like, oh my god. I did it again. It's like, no this is my Flash. I was trying to diversify my tools and then I thought I found something cool. But I'm working on it. I'm trying to diversify. I'm learning lots of other things. I'm trying to do things in different ways. I'm trying to be good about it and it's going actually really well. So I want to show you what I'm working on next, really briefly before I close out this talk.
So I'm at the moment designing my own audio protocol to encode data into audio signals. So the left channel is going to be the clock. And then the right channel of this area audio will be the data. And then I have a device hooked up that can listen to those audio signals, convert it back into bits and then bytes, and then send that through a serial port to a computer. So it's essentially a data translation device. But in trying to store that data in audio.
I mean, the web audio API is so easy. Like, if you look for the clock I created an oscillator that makes like, I can do noises at different frequencies to simulate the signals for the data as well. And then I can play the bit. And yeah, it's great. But, yeah, I'm still on a journey. I'm trying to rehabilitate. So I'm not quite there yet, but I still think that having something that you're super comfortable in can still make you really productive. And I'm still searching for the next thing so that I don't have my eggs all in one basket. But I wanted to cover some points before I close out.
So I try and live by this because in your professional life, you just argue and [INAUDIBLE], and it's done to death. And I find myself doing this when I mentor juniors. I'm like, yeah, that's one way to do it. And then they see my pause. And they're like, "yeah?". And I'm like, but maybe you shouldn't. There's this other way. And so I don't care. And a lot of the time, this is where a lot of the magic can happen. And here's the thing. Professional programmer is not the only kind of programmers. If you see someone making cross-stitch patterns in Excel, good. Don't tell them to do it differently.
I have a lot of artistic friends. They program a lot. And they just create the most beautiful things in processing. And just all sorts of different tools where they're kind of abusing them in a similar way that I do. But they're making things that are better than what I could ever make. And so really, the end result in a lot of these cases is the most important thing, and not how they got there. So just, get out of people's way and maybe tolerate that a little bit more, especially when someone is having fun and it's not harming anybody.
So you do you. And that'll give me permission to keep doing this stuff. But always remember, for both yourself and also your users, think about if a tool is actually helping you, or a language is helping you, or if it's starting to hinder you. So I was starting to really hit a wall with Flash because I'm hooking up this like tinker proxy to communicate with it. And that's when I really should have sat down and learned a low level language. And so it can be really fun, but it can also hinder you. So just try and keep that a little bit in balance because eventually you can be more productive in things that are a lot more powerful. So I'm still learning that lesson. And I encourage you to think about that.
Growth mindset. Sometimes I cling to tools because I don't think that I am smart enough to learn others. And so that is something that I've started to get over. But it's taken probably the last four years of my career to just try and believe in myself a little bit more. And know that I'm still capable of learning more, and more, and more. And I think that that's one of my favorite things about this industry, is that we can learn, but we can also teach. And so keep that in mind. Always be learning. Always be looking for dumb ways to do stuff because you never know how that's going to turn out.
And I wanted to thank you for coming on this weird, vulnerable journey with me because I really think it's an important thing to think about. So thank you.