Keynote: Scaling from One to Billions

Hi everyone, my name is Daniel Roy Greenfeld, and this is my talk on scaling from one to billions, how to change this world as a software engineer. Let's get into it. First of all, I want to say hello to everyone in Portugal. I really, really wanted to be there, but it was not meant to be. I had to um basically Give the talk from here in the United States in Southern California and Los Angeles to be precise. So I wish I was there. Uh Porto is a city that's on my bucket list. Maybe someday I'll be able to get there, hopefully soon. So, what does this talk about? What I want to talk about

is how what we do as an individual scales up. Uh and then more importantly, what happens when what we do actually scales up? And it's uh actually it's a very deep topic and I'm delighted that I was invited to talk about it. So let's go. But first I want to step back in time, or rather the beginning of this story starts in 2004, a long time ago. And it was so long ago that I I had quite a bit more hair. And uh actually it as you can see it's rather curly and if I would straighten it out it would reach down to my pants. That's how long my hair was. And

at this time, at the end of 2004, I got an interview at NASA, which is incredible. It's like as a space nerd, it was my dream come true. I had wanted to be an astronaut growing up. And but there was a downside to it, which was that I couldn't imagine I was going to work for NASA. I mean why would they hire me? I have no computer science degree and at that point I only had seven years professional experience. So I I just knew I was not going to get this job. So I came up with a plan. I didn't despair. Rather, I decided to treat the interview as a practice session. And

I took my inspiration from Jackie Chan 's incredible 1984 movie called Meals on Wheels, which had been released about 20 years before. Uh I got invited to interview at NASA. And uh in this fight, he's fighting against uh Benny Erkades, who's the greatest uh one of the greatest kickboxers of all time, who appeared in a couple Jackie Chan movies and in the movie Jackie Chan's character is just getting beat up. And as hard as he tried, he can't beat this you know, this guy. So he decides to treat it as a practice session. And so he tries different things and it worked. He ended up beating his opponent and winning the day.

So I decided to do something similar, which was I would test new approaches to typical interview questions. I mean why not? It was Bound to fail, so why not just try different crazy approaches to interview questions? And basically have fun. I mean, how often do you get to interview at NASA, right? I figure it was like my one shot. I can't win, so why not just have fun and you know enjoy the moment? So how did it go? How did my interview where I was trying out new techniques with NASA go? And it was going okay, it was pretty typical, getting a bunch of code questions, and then the interview asked me this question This is really common, which is

what is your biggest weakness? And typically my answer was something like, oh I get so wrapped up in my work that I take it personally and so I try harder and I work longer and that you know this is a response that I mean this is a common response, right? But that's not what I did this time. This particular occasion I said I'm stupid and lazy in an interview. And the NASA interviewer, like this was what was on her face. She looked at me like I was crazy. And what she said was, are you gonna explain that? And so I did.

I went into it in depth. And so I started with them stupid. And in summary, I said, I can't figure things out. I can't remember things. And I'm too stupid not to ask stupid questions. So let's go over each one of these and and I'll explain what I meant. Uh and what I said in terms of I can't figure things out. I always look for libraries first. If I am trying to figure out a complex programming task. Instead of rather than trying to figure out something at a low-level library, I'll look up for a package or a tool that does it for me. And my favorite example is Arc Parse. Which is I I struggle and have always struggled with arc

parse. And this is a public admission of something that I'm sure some of you in the audience have no problem figuring out. But this Like adding subcommands for like a foo and a bar subcommand to a script is something that is really challenging to do an arcparse. I think this works. Uh maybe. But rather than do it that way, I leverage, prefer to leverage in these days a library called Typer, which is built on top of Click. And in this you can see at a glance that the foo function, if you enter a y and an x value, it multiplies them together. If you use the bar function, if you have a string, it adds double parentheses around the string.

So really straightforward. At a glance you can tell what this does. This is not so simple. And uh inherent there isn't anything inherently wrong in this. It's just that rather than spend oodles of time trying to figure out how to get arg parse to work exactly the way I want, I prefer to use tools like Typer. So I can focus on my business requirements and deliver results to my end users or stakeholders. So that's something that I'm a really big believer on. And if you're curious about the library I mentioned, it's called Typer. It's by Sebastian Ramirez, who's also a fast API fame. Definitely worth checking out.

I love this library. It's it's the way it works, it's almost like a framework. But I I digress. So then I'm also too stupid not to ask stupid questions. And to be more specific, or rather let me give you a hint, uh, there aren't any stupid questions. In fact, the only bad question is the one that you do not ask. And I've seen this mentioned in software engineering, in you know, construction, in martial arts. Uh there's if you're working with good people, no one ever punishes you for asking questions. And the corollary to that is that

you can't impress people by not asking questions. Or rather, don't try to impress people by being quiet. Go and ask those questions. And here's why you should not be ashamed. The reason is that no one cares. And no one really remembers who asks this stupid question. I promise you, I can remember times at events and classes where Someone asked an outrageously crazy question. And unless it was and not offensive, I'm talking about like one which you know is predicated on ignorance No one really remembers who asks those questions.

Or if someone is asking those questions and someone remembers, oh, I remember when this person didn't know anything and now look at them. They're like the super senior engineer. What happened? They It's like they grew up. So no one really cares in the long run about the questions that you ask at a professional level. And in fact, I believe so strongly about this. I've written an article about it. You can find it on my personal site. It's called Obey the 30-minute rule. And it is basically Built off of this idea of don't be afraid to ask questions. And the 30-minute role works like this. Don't waste more than 30 minutes. on a problem

without asking questions. And the fact of the matter is that there are times when you simply cannot resolve something unless you ask questions. where there are pieces of a puzzle which are not apparent, you can't find on Google or Stack Overflow or other resources. You have to ask questions. Um, and of course, you you're not stuck to 30 minutes. Some people like 60 minutes or longer. The important thing is don't be afraid to ask those questions. And From a software engineering point of view, it's awesome when you're not stuck on a problem or spending hours or days or weeks on something and you're liberated and encouraged to ask questions. From a corporate or company point of view, encouraging your software engineers

to ask questions means that they're not wasting expensive developer time trying to figure out something they can't figure out. It's better, it's more cost effective for your organization if your developers are encouraged to ask questions. So please. Whether you're software engineer, engage in it, if you're a software manager, I heartily recommend this tool. And I know a lot of you out there who lead engineering teams are probably agreeing with me. Just it's it's super common. One more thing about ask questions. This kid right here at his first computer, um who's who happens to be me. was not really good about allowing other people to ask questions.

Don't be like me when I was um a teenager or an adolescent. Please allow others to ask questions and make requests and learn as well. Don't hog instructor time. And finally, I can't remember things. I really can't. And this is why I lean on doc strings, either doc strings in the function or um uh the you know comments you know sometimes if you look at my code you you may see and I know some of the people work with me have seen it where I'll comment every line um just so I'm trying to figure out and specifying it and it's just it's just really useful.

The other thing is type hints are Awesome. And I know that there's all kinds of things that can be done with tools like BS Code or PyCharm to, you know, co-completion, stuff like that. For me, the golden gem of type hints is that it means I don't have to work so hard to specify what parameters do or function arguments do in doc strings. It's just really obvious. And a good example is when in using typer, you can see if I'm using calling the function foo, y accepts a float and x Accepts an integer that defaults to one. And I didn't have to document that. That's just really obvious from the type pens. And same thing with bar

where z is a string. So yeah, type ends epic. Use them. They're great for people who are stupid like me who can't remember and also don't want to like spend the effort to write things out. And also another thing is when I'm following a talk or tutorial, I write down everything, including the slide. bullets. Everything gets written down. Uh it's just for me and for most people Writing down notes enhances learning. I know that some people just sit there and listen or I've seen people do screenshots. Don't don't do that. Write it down. That forces your brain to learn

Um, and I know uh a lot of you um you know some of you maybe some of you have better memory than me. I don't I have no pretensions. I don't have good memory. I write it down and then I can reference it later. You can see here I actually used to use Read the Docs to track my stuff and I would live note at conferences and classes and post about on social media. I even wrote a blog entry about it. And I built up this huge body of knowledge. And the awesome thing about it is this documentation made me look good. I can to this day pull out old tech details that others don't have because I do follow this practice of when I'm in classes and talks and tutorials of just writing down everything I can.

And this documentation can be used on later projects. The canonical example is two scoops of Django. Uh it started as my note-taking of Django back in the day and I got a chance to work next to um, you know, the early core contributors to Django and uh, you know, this is back before a lot of practices and ideas were really written down and what two scoops of jang was initially was c a collation of all those thoughts into a form that could be distributed um as a book. Um and documentation helps other people too.

It is uh well known that Django 's success uh especially early on was was in large part due to the depth and breadth and quality of the documentation and uh other projects too have had similar success due to this style. For example, requests and fast API. Absolutely those projects explosive growth can be attributed to their documentation. Furthermore, the quality of the documentation has certainly benefited the creators and maintainers of those projects. uh not just in how they write this code, but their career trajectory. Because let's face it, if you are working with

a maintainer of one of these projects, Django Request or Fast API, you know that They have a significant amount of um documentation skill that will be useful in a commercial project. Okay, moving on. I'm lazy. What does that mean? So, in a nutshell, what I'm lazy means is I don't want to do anything twice. I don't want to debug something when it was working before. And I don't want to look hard for how to do things. And so let's let's cover it. So I don't want to do anything twice. If I write the same code twice, I stick in a function. That's, you know, don't repeat yourself or try.

And then I use type hints so I get to write less docs. Remember, I'm lazy. I don't want to write docs. I write a lot of them. And the more shortcuts I can do, the shorthands I can find for documentation, the better. And then often I will stick that function into the utils module so that way it can be easily found. And then I'll put that function on GitHub so I don't lose it because copy pasting between project to project. is uh you know well one you um you might have to look for it two is uh if you have tests for it then you have to move over not just the code but also the tests for it I don't want to handle that, so I I put it on GitHub. And then I'll put the project on PyPI so I can install it easily from anywhere.

You know, I so I can just do uh pip install blarg and blarg installs. And the truth of it is, I feel that this kind of laziness is one of the foundations of open source, that as Project creators and maintainers, you know, a lot of times open source libraries solve hard problems And rather than try to reinvent the wheel each time, we use these libraries. So yeah, I would like to make the argument that open source is uh you know founded off the idea that we should all be as lazy as possible Okay, so moving on. I don't want to debug stuff that I've had working before. And I've done a lot of manually

testing of code, especially in shops where, you know, that's how you test stuff. And the challenge with that is that kind of repetition is boring. Um humans um You know, a little bit of repetition can be good, but after a while repetition gets really hard and frustrating, especially something as detail -oriented as code. And when we get bored as humans, we stop paying attention. We start making mistakes. So yeah, we we you know the the problem with um doing manual testing of code is is it's boring and it's error prone and we get in trouble because our code doesn't work. So the answer to this, of course, is write task.

And so that way you can avoid having to do more work. Because again, I like to be lazy. Something else I want to mention about tests and having test suites for your project is make it really easy to find how to run tests. Uh it's always really frustrating when you come into a project and you have to like drill down into the documentation really deep to find how to run basic tasks. My belief is uh you should put the tests right into the README. And in fact, the README should cover these three things. Everything else is you know, um it's extra bits of niceness, but these are the three critical things

how to install a project, how to run the project, and how to test the project. Again, everything after that is, you know, to use uh colloquialism, it's icing on the cake. It's not necessary. It's nice to have But if you want cake, you have to bake that cake and these three things are the cake baking, if that makes sense. Alright, so that was kind of my answer. And uh Yeah, it was uh it was kind of funny because normally I'd have like died of stress, but again, I I wasn't gonna get the job, right? But I did. I got the job. Uh and yeah, I was lucky. I I was fortunate enough to have been interviewed by someone who is visionary

Probably one of the best engineering managers I've ever met, Sharon Campbell. She is incredible. And honestly, Sharon, if you happen to watch this, I've mentioned it before in public, I reach out to you Please contact me. Octopus could use your talents. I'm sure other companies could as well. And I hope you're doing great. It'd be great to catch up with you. Okay, so um uh so yes, uh moving on. I worked uh NASA from 2005 to 2010. It was incredible. I got started in Python. Uh thank you, Crescentin, who actually is not far, well, relatively speaking, he lives in Barcelona now

I met my wife near the end of my time at NASA. I open sourced my first code, which is what has become Django Crispy Forms. I learned about climate change and I coded a lot. And I want to focus for a minute on climate change. And at the Wells Working at NASA was when the global um The global the current uh viewpoint of climate change really got cemented that the scientific consensus came that we are warming up our planet through adding too much carbon to the air. um and we're facing, you know, global climate change in the decades to come. And I re I started to do

uh more as an individual to try to address climate change. I recycled, I composted, I did what I could to reduce my carbon load. But I always wondered if it really made a difference. And the reason why is my effort as an individual and my small circle of associates. was nothing in comparison to gigantic fossil fuel interests with a hundred years of marketing experience who had um you know as we've seen with the failure of you know the COP uh conferences over the decades, you know, politicians well they'll say one thing, you know, they keep signing off on, you know, expansion of drilling

and and um other things. So Uh and there's also just people who, unlike fossil fuel who has known about global climate change since the nineteen seventies, there are still a lot of people who deny the ninety-nine percent scientific consensus. So Um yeah, I was I I always wonder what difference I could make. And um I as an individual, does it matter what I do? Uh so let 's return to this later. I know it sounds like a depressing topic, but But we'll get to it. There's there's a point to all of this. Um and the other thing I did at NASA that that I mentioned is I coded a lot. And let's let's get into that a little bit before we return to the topic of climate change.

I wrote an article a few years ago called Code, Code, Code, and I'm gonna summarize it really quickly here. And that is, if you want to get good at anything, you need to practice. If you uh you know when you're at this event you're getting exposed to tons of new ideas and libraries or and different approaches to doing things and tutorials and some those of you who are fortunate enough will be working with core contributors from different projects it's super exciting what when you learn this stuff go and practice it use it try to build something with it Always be trying stuff out even after this. When you go on to other things, other events

or classes or things that you learn, always be typing, trying things out. Uh you know, and speaking of typing, pair programming is great. I know a lot of people who swear by it, and uh but you know, and that's where you have one person typically typing and the other person's looking over the shoulder But if you're pair programming, you're trying to improve, try to be the person typing. You will learn faster if you are typing. If you're taking a class, and I know that there's tutorials here, always be typing. Try to keep up with the instructor. Don't get distracted. Focus on the fact that you're here and this time is gold to learn from the experts. that are here at Django Khan. If there's no exercises in the class, if it's just like straight

up lecture, honestly, um, or you're watching a spectator sport of Coding or talking about code. You can learn as a spectator. I'm not gonna say that you can't learn and that it's useless. You're just not gonna learn as fast. And on top of that, You can't achieve mastery as a spectator of anything, including code. Um, and the corollary for this in, you know tech and and startup circles is, you know, there's the movie The Social Network. Uh and when it came out for a few years after that, there's all these people go to events and they would want to be tech CEOs. And I remember this one really frustrated VC telling someone, you can't become a tech CEO just by watching the social network.

You have to understand the tech that you're trying to build out. Um you can't w and and a similar corollary is you can't win at sports by watching sports on TV. Sure, you may learn about the game and the rules and stuff like that, but that doesn't make you a good soccer or football player. To master anything, to master coding in particular, we have to practice A practice makes perfect and always be typing, always be trying to use what you're learning and expand on it, be it silly projects, serious projects, try stuff out. And again, the article that I wrote, code, code, code, there's a link

also included at the end of this deck. So After I left NASA and I saw my open source work being used at every NASA center and uh as well as in other parts around the world. I saw um it was really exciting seeing that my open source effort was really paying off and What was funny is because I was doing all this open source work to practice, to learn more, to execute on what I was learning. And also because there's a lot of times I was solving hard problems and rather than copy and paste from project to project and remember how things worked and how they plug in.

I I just learned how to do pip you know setup packages and do pip install XY and Z of what I had created And yes, there was, as I mentioned, there was a rush when other people complimented my work. I was like, great, yeah, someone's doing it. But really, uh it was it was to practice. And um here's a a bunch of things that I created back in the day. Um there's what became Django Crispy Forms. Django packages is something that my wife and I created in our first year together. And we also, in 2012, we worked on the Django class-based views documentation refactor. We started that at DjangoCon until then the docs were

uh they they were not really clear and there were questions about class-based views so We and a bunch of others came together and refactored the documentation so it's useful. I helped Audrey build out Cookie Cutter. Audrey is my wife and she's the creator of Cookie Cutter. And building off of that, I laid out the foundations of Cookie Cutter Django. And also I took code that I copied from project to project and I turned that into the library called Cash Property. which ended up becoming part of um helped influence how cache property works inside of Python now that there's a built-in function for it And then in 2013 onwards, I uh

worked with Audrey to cr, you know, uh publish this tribal knowledge of Django and it was great. We shared uh stuff that you could only find out by working directly with core contributors. These were a lot of Django secrets and now a lot of what's in two scoops of Django is common knowledge, but back in the day this was uh this was really, really different. So um yeah, it was it was exciting and and seeing people um really take Django and run with a lot further than um than a lot of people had done in the past. Before there was like kind of this click of people who who could really execute on Jiang Un and the rest of us mere mortals would just kind of try to figure out things going along

Uh and then with um and and in fact there was a movement kind of against books and then with with this book coming out it kind of re kindled uh having books in the Django ecosystem and a lot of these ideas um rather than having people figure it out, we were able to share these ideas. So it's really really exciting to, you know, between my open source work and my authorship to um spread this knowledge and seeing the impact around the world. It was really, really exciting. Uh yeah, it was awesome. It's it has been a rush. Um and my work has been used, and Audrey's work, and the same with the rest of the community, it's been used for amazing good.

Two scoops of Django is something that I know a lot of people have used to for interview preparation or to build dream projects that I mentioned. There's been amazing community service efforts that have come out of it. There are healthcare organizations in the United States which have used my open source work and my books. to build out stuff as as well as other people's stuff. I'm not saying I'm the only person gets credit. It's wonderful here from charities and nonprofits doing good works. And also in 2013, um when they caught the spot suspects for the Boston Marathon, the site that they used to like analyze the photos of, you know, all these people had taken. And I'm sure now it'd all be done with machine learning.

Um, that was done by citizens who had been at the race, who built something. Um and in large part they use two scoops of Django as their operating manual. And so so yeah, it was pretty exciting um uh to you know these these incredibly good works and trying to further uh humanity. However, there's there's a downside to it, and that's that my work has been used for evil. And it bothers me. And um so some things that have happened and in some cases continue to happen is my work has been used to help logistics. um for oppression, um for you know, spying on private citizens

uh with on shaky legal grounds. There is a site that I I don't know if it's still I I haven't checked just because I don't like going there, but there's a site that promoted flat Earth and that there's no moon landings, and that was heavily based off of our work. um there was uh you know yeah there's tons of stuff out there where it's like I object to it and on the one hand um You know, I know I shouldn't judge, but I just don't like these things. And one of the things is is a lot of times we're offered work or projects and we get so excited by the idea of building something. As Ian Malcolm said in Jurassic Park, we never stop to think whether or not we should build something.

And I think this is something that's happening a lot. That a lot of us, and I'm not saying I'm perfect, I've made mistakes too. Sometimes we maybe we shouldn't build things or we shouldn't join organizations. And I believe that there are certain questions that we should ask of every employee or client. And that is who has helped and who is hurt. And some the questions that I like to ask or that I'd love for the listeners to ask when they have the potential to take on a project is does this project promote falsehood over truth? Does it subvert election process? Does it intrude on individual sovereignty?

Um, and of course, climate change. Does it spew um stuff in the atmosphere that's gonna change the planet? In other words, does this project help or hurt? Because As software engineers, what we do scales up really fast. It is not uncommon for the work that we do to touch not a few individuals like those people in this room, but potentially millions or even billions of people. And in the case of climate change, um, you know, if we want to bring this up, is it hurting our future? Uh, you know, we have had a series of incrementally hotter years. um in the past seven years. Each one has been hotter than the last. This year, Europe and South Asia uh suffered devastating, you know, heat waves and drought.

And in the US, um, where I live, we've been under severe water restrictions for months. And to the point that I take these super quick showers and when I've had a few opportunities to get out of the drought region in the past year. One of the things I love is being able to take long showers without feeling guilty about it. And I want to show you this picture. And this picture would be a common site in Southern California where I live. Every year in the summer. Most stream beds dry up. And that isn't a drought issue. That's just a seasonal thing. We just we have a wet season, we have a hot season. This would be a typical photo for Southern California. But it's not Southern California.

This is France. This is France of this year. A street, you know, which is supposed to be humid uh climate with uh you know regular rain and so to see this dry up this isn't you know my vision of France is not this and granted I've been I've spent a day in France, so what do I know? But this isn't what I think of. Drought is not what I think of when I think of France. I think of Southern California or the desert. Uh I don't think of a French dry season. Is there even such a thing? And it doesn't have to be this way. Um you know we we can fix our future, including climate change. And the reason why is because as software engineers, we have

superpowers. We can make a change. We can affect millions of potentially billions of people. uh we can not just improve the lives of ourselves and our families and build, you know, neat things like, you know The latest startup that's doing something awesome. It's more than just sharing ideas and knowledge and code to other engineers around the world. We can use that to save the planet. We have this power. Everyone in this room can contribute, not as individuals, but at a scale that is unheralded we can actually make a difference.

Listen, I mentioned before that I when I was at NASA I had this feeling that my ability to affect climate as an individual is tiny, and that hasn't changed But one thing I realize is as a software developer working on decarbonization and the expansion of abundance of electricity My ability to change the course of the direction of climate is gigantic. Uh And the thing is, is I've decided that addressing climate change is going to be my legacy. This little girl was born in 2019. Uh and uh I have to show old pictures because I respect her privacy.

Uh and so it's hard to get um I'm not gonna publish recent pictures of her, but I want her to grow up in a planet that is on the mend. And I know the next few decades are gonna suck. Um because they are. Even if we fix things today completely, um climate has inertia. It's gonna take a while for things to to heal and mend up. And what I don't want is for her to get old enough to understand that the climate of the world has changed. And I did nothing. When she asked me, hey dad, what what did you do about climate change? I want to tell her, I worked on decarbonization. I worked on electrification. Um this is going to be my legacy.

And it's for this little girl. So I invite everyone here to join me in the fight against climate change. Uh, you know, that's my personal mission. I know there's other good causes. This is mine. So again, I'm inviting you. My employer, Octopus, is hiring. We have a booth here. Yeah, please join. Or please check it out. Emma and Matt. They're awesome. They're friends of mine. Um, and yeah, go go talk, you know, line up an interview, come and work with me. But octopus may not work for you. My company, which is into retail energy, only hires out of I think 10 countries.

And so there's a good chance that uh quite a few of you. We we just can't hire. And that's not gonna change. That's outside of our control. So you can ask me, well, why aren't you doing this? Or you might ask Matt or Emma at the booth. You know, we'll give you the reasons, but really it's outside of our control. Um or you might just have the wrong skills. Maybe the the tools that we use aren't the ones that you do. Well we are powered by Python and Django Postgres Maybe those aren't skills that you have and you're just here for the community. That's great. But it means you may not be at workforce. Or you just might not like the company and its mascot. You may not like me. That's fine. That's perfectly okay.

But the thing is is programming gives you superpowers. So even if you can't work for us, I want you to go and work for the competition because it doesn't matter which green firm like ends up being the top of the game. We all benefit. And here's three companies, Aspiration, Atmospher. Bank and hardest aerospace. And there's tons of other companies in this space. There's a lot of um uh money to be made, there's a gigantic commercial effort across the planet. Uh there are some governments who are in alignment with it, but really it is um the fact that uh renewable energy doesn't cost really that much fuel because like sun and wind is free. Uh what that means is that there's l

large room for economic growth in this field. And Uh you know, in addition to um the the financial gains, we're also talking about more stable governments and democratization of energy. uh the people own energy rather than corporations. There's lots of reasons for this. My point though is that I invite you to, if you don't want to work for octopus or you can't Please go find a job working for someone else. It's okay. I'm not gonna get hung up over it All right, about me. Uh my name is Daniel Roy Greenfeld. I am the director of engineering uh for octopus energy in the United States. I am an author, a coder, an engineering manager.

I am the husband of R. J. Roy Greenfeld, who is a fantastic software engineer and leader as well. And I'm a father, and finally, I am a superhero with the cause of saving the planet. Any questions?