Computational thinking for creatives

Tadeh Hakopian
Tadeh Hakopian
Senior Program Manager at Amazon
DevRelCon 2021
8th to 10th November 2021
Online

Tadeh reviews how a group of designers with zero coding experience were brought into computational thinking and how that enabled them to feel more confident and use coding in their projects.

Watch the talk

Key takeaways

Takeaways coming soon!

Transcript

Speaker 1: Thanks for joining everyone. I am Tadekopian, and this is computational thinking for creatives, decoding barriers to entry. Let's get going. A little bit about myself. I am a little bit of developer, a program manager, a technical program manager.

Speaker 1: My background is in architecture, the building architecture, experience in the built environment, but also working a lot with, like, development cycles and technical subject and code. So I'd come from, I guess, a tradition traditional profession that's running into the evolution of digital technology and data and applications that are in to what we do day to day. And this is where I ran into a problem that can probably many of you can relate with. The starting point is we wanna teach our own in house architects and builders. Again, excuse me.

Speaker 1: Builders, not developers, not computer architects, actual building architects like this fellow on the right, how to take advantage of digital technology, computers, coding, what have you. But they didn't know this stuff. They were propping a more conventional method of, like, designing. So how do we introduce technical matter in an intuitive way? That way, they can use it to improve their designs, make a better building based on analysis, based on API kits, based on all sorts of digital technologies that they can take advantage of for every kind of solution where the structural design, building efficiencies in floor plan spacing, environmental analysis for more sustainable future in our building environment.

Speaker 1: So we wanna teach them these technical matters that they haven't really experienced from their point of view. So I wanted to share them in a way that would be easy for the average designer who they're very intelligent. They're very capable. They're very comfortable with learning all these new things, but may not be used to something as logically oriented as coding and programmatic design. So I want to show them what computational thinking could do to help solve this problem of educating them.

Speaker 1: And before I go into that, wanna talk a little bit about creatives because I can't apply this thinking unless I know my audience. It's always important to know your audience, to know what they're about. My audience were creative people. They like to draw. They they love putting things out and just drawing on them, marking things up, solving problems with their hands, making models out of, you know, parts.

Speaker 1: And we want to teach them something that was digital that was not gonna be something you just mark up. They had to work through on code or something like that, And they didn't have much exposure to that world, very few of them anyway. I was one of the few of the company 300 people who had any exposure to it. So I didn't know where they were coming from before I can introduce anything to them. And the concerns I had was creative people of any Stripe, even if they're very sophisticated in what they do, they have a lot of education and training, may not feel comfortable with code and text programming.

Speaker 1: Maybe look like it's too technical, abstract, intimidating, like, what is this? This is the matrix. That's how a lot of people feel. And this is kind of the reality a lot of people in many different professions all around the world are feeling is, like, they kinda feel like the the code's taking over and but they need that software and technology and those tools to succeed in what they wanna do because codes become a normal part of everything. So how do I reduce that anxiety for people who've never seen this before, getting used to all the great technology out there, and not make them anxious?

Speaker 1: Simple. Patterns. Architecture patterns. This is an awesome common ground between building designers and computer scientists. They all came from the same background.

Speaker 1: Christoph Alexander's design making the pattern language, which has all sorts of patterns that everybody's seen in computer science and coding patterns, anti patterns, thinking patterns. That's a common ground between how architects think, designers think, how people developing systems think. So I always go to these patterns. And one way to refer to this is just computational thinking, which is expressing solutions as steps, like an algorithm that could carry it on by computer or even a person. It's just all a process.

Speaker 1: And these are the main steps of computational thinking. Abstract a pattern to represent the problem in different ways. So you break the problem down and abstract it into a new way of thinking about it, a series of steps. Then you logically organize and analyze the data. You break the problem down after that into smaller parts so you don't get overwhelmed.

Speaker 1: You approach the problem using programmatic thinking, like represent things, create logical operations, iterate. Then once you break it down, you can reformulate the problem into ordered steps. That's algorithm making. So you have to take it from an abstract everything, break into pieces, and then order the steps. That's where you get your algorithm and identify based on these algorithms possible solutions to get the most efficient result.

Speaker 1: And then once you have a result, you can generalize the solve the process to a wider variety of problems that you can read over and over again. In architecture, they call it heuristic. In other places, they might just call continuous improvement or continuous development. Very straightforward stuff. It just seems a little rigid what we naturally do.

Speaker 1: But in this case, it's very comfortable and compatible with architecture thinking. And the essentials to cover here is inputs and outputs, data flow, data type and recursion. That's what we wanna talk about to the creative's parent, how to understand abstract problems to steps. These are the fundamentals of data processing that either in a database or designing a building really, honestly. And we have some awesome open source help that I could not have done any of these examples you're about to see without the open source maintainers out there for our favorite Python and these specialized tools like Dynamo and Grasshopper that are low code mediums.

Speaker 1: And who doesn't love Blender in all its three d glory? Always support the open source maintainers out there. Otherwise, I would not gone anywhere with the training regimen of our own company. And since these are architects and architects like to think in terms of visuals, they like to see things. So we wanna give them something visual.

Speaker 1: Blender and other three d software solutions can provide that so they can see what they're doing. If they ever wanna show anybody anything, charts, graphs, visuals is a great way to go, and I highly recommend everybody to go down that route of using some kind of visual medium. It is so much more satisfying to see the results. And, yes, this is applicable, computational design and encoding. I'll show you in a minute.

Speaker 1: But first, some data flow with this peanut butter and jelly sandwich. It's as simple as what you see here. You want a peanut butter jelly sandwich. So that's the kind of the big idea, right, that we're trying to abstract, and you break it down into parts. Well, how would I get there?

Speaker 1: Well, to get a sandwich, I need two loaves, eat one with peanut butter, they want jelly. But to get two loaves, I need to cut the bread into pieces first. Right? And then I also need the ingredients of peanut butter and jelly. So we work from the left of, this is what I want, and you and then you start working right to get to the results, the end results.

Speaker 1: You draw it out. You diagram it. You have some fun. And you think, okay. That's pretty straightforward.

Speaker 1: I broke it down. I understand the steps. I have a little bit of algorithm now. But you could take this diagram, this visual chart here, and go further and use a low code medium. This is an example from one of those open source software.

Speaker 1: It's called Grasshopper. In this case, it's we're just making coffee. And so I want a cup coffee, a 110 degrees, 12 ounces. On the left here, I have the inputs water, temperature, coffee, and cup. I put the water together with temperature.

Speaker 1: I put the coffee cup together in a coffee cup. Then I put the cup cup and water together into a liquid being poured into the cup. Then we decide how much liquid needs to go into that cup, 12 ounces into the final node there, and we get the water cup. Simple steps broken down that anybody could follow that will not stress them out, and they can understand exactly what you're talking about. No jargon.

Speaker 1: No real challenges understanding what they're trying to do. They can visualize this. And they could take that logic and train them in this very familiar way to get to more sophisticated steps. And this is the same thing. I wanna get a tower.

Speaker 1: So what do I do? On the left here, I build some coordinates, x, y, and z, our favorite coordinate system, and I put in some things like a facade and floors and levels. I then process it. I combine the coordinates, the four points of the building, and then I translate all of that with the different facade and floor systems into a final output. Just like making the water, we're just mixing, matching, and playing things together.

Speaker 1: This is through a software called Dynamo, another low code solution that can use logical thinking, computational process to develop. And what do I get at the result? A 100 story power. I could take the left side here of the wireframe and put it into a model format that anybody can use with this medium that it's easy to follow, easy to understand, easy to grasp. Because they could see based on the x, y, and z they put in here, going back to last slide, they could see, okay, my x, y, and z, 30 feet by 60 feet, and you could change that.

Speaker 1: There's a slider. You can move it around, you can change your building size. This is the kind of thing that connects people from the code idea, the computational thinking process to results. And you can have a lot of fun with this. You can create all sorts of different combinations of shapes, explore design, explore what's possible.

Speaker 1: People love this kind of thing. If ever feel like you can't get a concept across the people, I highly recommend trying different ways of showing it in a visual medium. Doesn't have to be three d. But this kind of, like, step by step kinda, like, highlight like we see here is very attractive to people. It makes them think, okay.

Speaker 1: I understand why you're doing something. I understand the concept. And, again, this might be necessary for just about every field of profession you can imagine. So I highly recommend trying out something like a low quote medium, something visual. There's all sorts of solution out there.

Speaker 1: And you can go further. Now we established the basics. I could take the same constant to create some kind of interesting geometry. I'd show them with computational thinking, the data processing, the inputs, and the outputs. Now they can break down a con abstract concept into steps and create that algorithm.

Speaker 1: You can see here where we keep this kind of a hoop of building here and go further and make this nice, very satisfying progression into a more natural and organic looking facade that we can have some kind of nuances of the design and refine it. And that's all it is. And people can get a slider. People get the rotation angle slider and how that can translate to geometry. This is one of the most satisfying peep things people do is when they get to that point, they can actually control what they're doing.

Speaker 1: With these computational processes and low code, they really start to click without scaring them off. What's great is when you take this low code approach, you can eventually teach them code. The on the left is that Dynamo low code medium where it's a bunch of visual graphs to connect the dots to make something, it just translates directly into this the right part here, which is Python code. So if you ever need to show somebody any kind of code or something like that, wouldn't hurt to try to the visual scripting first, low code medium, and then translate it, like, on the right here into Python or another coding language to help them understand what it looks like in a more compact text format. That's the payoff.

Speaker 1: That's where you can get people to say, ah, this makes sense now. Otherwise, if I started from this point of view on the textual programming, like everybody else does who learns computer science or development or any kind of programming, I would have lost everybody I've talked to. I've talked to dozens of people this out of this process. So we did a little training course in house to really, you know, scale this up and get user participation. We wanna focus on computational design, parametric design, generative design.

Speaker 1: Those are our goals and how we taught them. They're all a little different, but they relate to these the example we saw, those building designs. And just to make remind you that there's different learning styles. What I show is very visual. Some people prefer to be touchy feely.

Speaker 1: Other people like to listen. Other people like to see text and diagrams. Learn what the visual styles are for your audience. This might you might have to do this kind of discussion, training, demonstration hundreds of times. I feel like I've done that many times.

Speaker 1: So try to figure out what works, and visual seems to work across the board for just about anybody I've worked with. And here's my team. Worked together as a team at HMC Architects. Always worked with team, always communicate, always communicate in house. And here's an example of that computational thinking in a real project in the Bay Area Of California where we took a facade system like I see here on this library and use computational thinking to provide not only a aesthetic, like a a nice facade design of those louvers, but also, like I see on the top left, energy analysis that we can use to justify the amount of louvers we have and also make it a comfortable space so people don't worry that we have not enough warmth or cool for the in interior, though that's architects have to be very mindful of heat gain and make sure they're using as little air conditioning as possible.

Speaker 1: And that's what it looks like. That's what you saw. It looks like this. It's this long computational design low code graph here, but it gets to the point and solves the problem of how we get those lures in with this process. All those code all those nodes you saw here result in a diagnostic, a energy map, heat map of the floor plan that we then use from the left to the right to create panels that we can then input into the models we're using to document, design the building.

Speaker 1: Very great successful example of how you could take computational thinking, process it, and make a successful solution. And remember the key concept that we covered here, coding, computational design is more important for the average person these days. That's why I had to develop this process. You have to create a compatible training style to get people comfortable with the concept. Competitional thinking establishes a baseline of thinking.

Speaker 1: All those steps I showed you earlier, break down abstract parts, create a formulation, break break it down to smaller pieces, create the algorithm, try to create some solutions efficiencies. You have to create that baseline thinking for it, and that could be used for anything whatsoever. You can use it for cooking food like we saw with the coffee. Use resources and styles compatible with your trainees. Don't assume this is why I talk about decoding barriers to entry.

Speaker 1: Don't assume people already know what you're talking about or they're gonna be comfortable with your style. They may be completely alienated from your style. Figure out what's comfortable with them. Take a survey. Learn.

Speaker 1: Reduce the anxiety. Make it simple, straightforward. If you're not teach we're not we're assuming you're not teaching computer science graduates here. Reducing the average person, and the more you get that message out to them and reduce the anxiety, the more they're interested in what you have to show. And, you know, create a structured course.

Speaker 1: If you have something you it doesn't have to be a whole course. It could be a training example, anything. Structure it to the point, step by step, anybody can follow it. Let people try skill on a project and share the results, and it'd be easier for you to work with them based on the steps provided. You know, you have the structured course and review, upgrade, and continue training forever.

Speaker 1: I think this is a great time period in where we can facilitate the learning and advancement to everybody with these kind of comp computational tools and coding tools and all sorts of development kits we have here, but never get complacent. That that was something I learned. You always have to find a new way to move forward and things change so fast. And support your maintainers. I could have not done any of this without the open source support from all these different solutions, Dynamo, Grass, Hyperblender, Python.

Speaker 1: Always support them. Give them some love. Give them some money if you can support them as they are just doing such a great job helping me and my company do something that brings value to what we create. Here's some contributors. If you want contact if you want these in a little more detail, please contact me, but these are all the different contributors you saw today.

Speaker 1: Special thanks to the developers out there. Again, without them, I could not have done any of this. I would have been on my own high and dry. If have any questions for me, you can contact me in any of these platforms, LinkedIn, Twitter, GitHub, and you can follow-up with me on the doc the documents, the content information. Just wanna chat.

Speaker 1: It's all good. But it was a pleasure speaking here today. I hope you guys learned something, and continue on with DelRailCon, guys. Thanks.