Episode 8: Something Creative (About Coding Diagrams)

When one thinks about “coding”, you would never guess that it’s actually a creative process or has anything creative about it. It’s one of those subjects where you’ll only know what it has if you really indulge yourself in it. The more you find out what you can do, the more you realise you are not just a coder but an “imaginative engineer” I mean, you could make a Unicorn world that shoots cats every time a user is sad. Really, you can.

As a designer entering a coding school, this was probably the happiest day of my life. “Yay! Finally! Something Creative!” Let’s get to it.

Question 1: Why is making diagrams or designing your structure of code important?

It saves time? It clarifies everything? It’s easier to edit before implementing code? It benefits you by changing a draft than your final, which is the solutions of your code? Yes, all of these are correct.

I like to think of this creative process, as making a map of what you are going to do. It’s almost key for any “imaginative engineer” to know how it’s all going to be laid out and how everything is going to fit.

When coding, diagrams are normally sequential diagrams, done with blocks and arrows.I’m not going to post one here because all the google images look awfully confusing, so I’ll draw a simplified one.

My bad example, for instance.

Question 2: How does one go about designing diagrams for code?

Well, normally, a coder will be talking a cilent about building some new world or problem, whether it’s creating an app or god knows what. The cilent (if he’s skilled at communication) will clearly express what this new world, app, other thing needs to do and list them. This is called a “User Story” but to be honest, out there in the real world, I doubt that everyone is perfect at remembering, considering and communicating every need of the program for the user.

So, a sample user story that would look nice would look like this:

In order to use public transport As a customer I want money on my card

So, if we have this, now we need to figure out how to structure this. We’ve done this before (or I’ve mentioned this before) is to make a Domain Model from the user story. Look it up, if you’ve already forgotten. So let’s collect the nouns and the verbs from this user.

Objects(Nouns) | Messages(Verbs)Public Transport | UseCustomer |Card | Want (money)

Advice: It’s always better to lay this out before doing anything. It’s always good to do it line by line. It starts getting confusing when you decide your smarter than the text and jump line by line.

Let’s get into the tricky bits. Why does Customer not have a verb? Well, i mean it doesn’t if you look at the line, but that’s beside the point I’m getting at.

Customer is the User. In our code, we don’t have to include any parts of the User, because the User will be the one using the creation we’ve made. Yes, in Domain Models is always good to divide the elements into Objects, Messages and USER so you can start eliminating what words you don’t have to focus on. I assume (it’s bad to assume, don’t do it) that there will always be on USER, just how like there is one type of audience. So, Line 2, we can put it aside.

Now, we have to choose between two pairs to decide which is the focus. Well, one is always going to be the focus and one is always going to be the outcome. Although, this is a very good User story sample, it’s sentencing definitely confused me (so if it confuses you, then good, I’m not the only one who can’t interpret English).

In this case, “to use public transport” is our outcome because we want our system to “want money on the card” to “use public transport?”

It’s all right, it’s hard to grasp so let it all soak in for a bit.

Great you’re back! So, the conclusion is that in our nicely worded User story, we will always have a USER, a focus (function) and an outcome. In our case, line 1 is the outcome, line 2 has the user and line 3 is our focus.

In our focus, this means that we want our…

Class to be a noun: “Oystercard/card”

and our

method to be a verb: “want money”

If we really think about what we mean, we can change it to “balance” because we want our card to have money on it.

You’re probably thinking (Dania, you are so wise, since you’re a design student, you probably know how it all works already)

You can take a look at my user diagram with my pair partner and see all the errors we’ve made. A good tip is to always remember that these diagrams ( as much as you can edit and play around with) eventually are meant for code.

Don’t get caught up in diagrams. They are good plans but your goal is to code it out. Sadly, code is not all about drawing fun diagrams or pictures.

Original User Diagram:

What the diagram should be

Tribute to Edward for giving all this wonderful knowledge on diagrams by reviewing our diagram. :)

Classy Ed

Fun fact of the day!

What is the bloomsbury taxonomy? Is it an economic term that sounds beautiful? Is it a version of tax that sounds professional? Does the company “bloomsbury” support this structure of tax? One can interpret this is many ways if one person does not know what this is.

It is a learning method, and comes handy when learning code or learning how to solve problems in your code.

• Remembering
• Explain
• Eval
• Analyze
• Create

Though, don’t kill yourself over it. It’s not a mantra you should follow if that method for learning doesn’t work for you. Keep it in mind though, it comes in handy when you have no idea where to start or forget.