A few weeks ago I was contacted by the distributors of iDraw Generative Machines with a proposition: I could receive an iDraw plotter in exchange an honest review.
Those of you who have read my blog before probably know that I am really interested in the intersections of art and technology. Those of you who have read my blog before probably also noticed that the blog hasn’t been active for a while. This is due to a lot of things — primarily because I’ve shifted my focus away from coding a little bit to enroll in a year long art program.
I’ve improved my artistic skills tremendously this past year and I’ve continued to code in the capacity of a bootcamp instructor – teaching for Practicum by Yandex, an online program which I’ve really enjoyed working at. However when opportunities like this come along I’m rarely one to turn them down. Especially in this case, because I realized I could do really cool things with my paintings if I had a pen plotter that could draw things like fractals which would be really time consuming for me to draw myself. Not to mention it can also cut vinyl. The possibilities!
What I didn’t realize when I agreed to review the iDraw while getting excited imagining all the things I could do was that the machine is very much a DIY contraption. Meaning, it arrives in a million different pieces and requires a great deal of time and attention to detail in order to put together. Granted I should have perused the links that were sent to me more carefully but I would be lying if I didn’t say my heart sank a little when I opened the box and saw all the little screws and cables inside. It should have also occurred to me that the price tag was simply too low for them to bring you a fully assembled machine – a quick google search will show you assembled pen plotters can go for $250 or more pretty easily.
That being said, I’ve never shied away from a challenge so after recovering from my initial disappointment, I went to work. And let me tell you friends, it WAS work. Of course if you are an expert at DIY or you have a lot of experience with Raspberry PI and that sort of thing, this might not seem so challenging to you. The extent of my expertise with building and assembling things would be putting together furniture from IKEA. This is a whole other level from IKEA, though. First of all, the pieces are much smaller. Second of all, there are more ways to put things together in the wrong orientation. Third of all, the instructions have parts where you have to refer to videos that are hard to see all the details (like which side of the belt faces which way, for instance).
The video above is a time lapse compressing about 2 hours of work assembling the device into about 5 minutes. There were moments when I became very frustrated and wanted to throw the whole thing out of the window but I am glad I persevered. After 2 hours my phone died and I was too focused on assembly to record the rest.
One thing to note – it took me a little while to find the assembly guide for the version I had but once I did things went along much faster. A review of the iDraw wouldn’t be complete without covering the parts I struggled with the most:
Attaching the covers to the back of the two ends where the motors are situated. I would tighten the screws on the opposite side of the t-nuts but the t-nuts would not revolve and so would not lock into the opposite side like they were supposed to (page 28 of the assembly guide) . I seriously just gave up on this. Maybe I will glue them – we’ll see.
Attaching the two panels with the linear bearings together. I was holding it upside down while stacking the flanged bearing and standoff plastic and then forgot it wasn’t attached at the bottom so I lifted it momentarily off the table and everything fell apart. Then later on I guess I didn’t tighten the nuts enough because the whole middle piece fell apart while I was attaching the ends and was MUCH harder to put together that time because I didn’t want to take all the other pieces apart again. (page 14 of the assembly guide)
The belt. Oh my god the belt. I thought I had it right following the video instructions but either something got screwed up after I first ran the machine or I just didn’t quite put it in correctly but this was the most time consuming part by far. You have to tie the belt off at the ends after you wind it through the 4 different sections of the plotter. In my case the ends of the belt kept coming untied and was driving me insane. After hours of fiddling and messing around with the software I finally realized that the belt wasn’t wrapping around the pulley part of the motor but instead had somehow slid up above it. This screwed up the tension in the belt and cause it to slide up in other crucial areas where it needed to be aligned to the pieces which make it turn smoothly.
The pen was going up when it should go down and down when it should go up. I wish I had googled it sooner because as soon as I did I found someone with the same issue and it turns out that you can actually adjust this in the Inkscape Axidraw extension (Axidraw has an extensive wiki which helped a lot for the software portion). There are basically two bars you can adjust, one which is labelled “DOWN” and one “UP.” What is a lot less obvious is you can actually adjust the bars to make “UP” be down and “DOWN” be up. Very confusing, but it worked for my purposes
Okay, so I’ve gone through the whole assembly process and probably made it pretty clear its not the easiest thing in the world. But more important than the challenges of assembly is the result, right? Was it worth all my pain and effort? So far I would say yes. It’s an incredibly cool machine, and for the purposes of my art the sky is the limit for what I can create. As an artist I love to paint free, loose, and a little messy. But having this tool will make it so I can incorporate little details and elements in my work that I couldn’t otherwise. It’s also just really fun to watch it go. Honestly its more entertaining than a lot of reality shows that are out there.
Now that the assembly is behind me I’m feeling very excited again – I have lots of ideas for things I can make and sell. Thinking about opening a new etsy shop and creating some more video content of the machine at work.
If the thought of assembling this plotter sounds intimidating and you’re not sure you’re up for it, there are some plotters which come partially assembled and are for sure easier to work with.
Here is a video of my first time running a more complex drawing on the machine. Note that I had to pause it part way because I realized that my pen wasn’t depositing enough ink so I had to switch pens and shifted the drawing slightly in the process.
Of course I’m planning on using much more than a pen when I work on my future projects. I’d like to experiment with markers, paintbrushes, and of course a laser once I figure out where to get one. It would be cool to do wood burning with a laser but I’m not sure a compatible one is powerful enough. I will update this iDraw review with more info as I figure it out. Of course there are also a lot of options with vinyl cutting. I’m impressed with how it can draw such thin and precise lines.
Before I became a programmer I loved to play games. I played games for many years before I even knew the most basic concepts about coding. However these days I see that people are trying to introduce their kids to programming and looking for ways to make programming concepts more approachable. I think that using existing games people love is a great way to do just that. That is why I wanted to start this new coding for gamers blog series.
If you are reading this you might already have at least some interest in The Long Dark, and may have played it. But I will briefly explain the game just in case. The Long Dark came out on Steam several years ago and had a beta release that was primarily a survival simulator. The game takes place in the Canadian far north where a mysterious phenomenon has caused all of the power to stop working.
In the original simulator, your goal was essentially to survive as long as possible by staying hydrated, nourished, rested, and avoiding freezing to death. You could choose between different environments to try your luck in, some which have a range of man made shelters and some which have nothing but a few caves dotting a barren landscape teeming with aggressive wildlife.
By releasing a minimum playable version of their game early, The Long Dark developers gave players something to continually look forward to and give valuable feedback on as they added more features to create something truly spectacular. Now the game has a fully fleshed out story mode with multiple seasons and difficulties in addition to special challenges. Whether you’re developing a game or an application for a startup, the idea of slowly adding on features and polish over the course of time is the most logical and sustainable way to build a good product. It goes to show that when you learn to code with games like The Long Dark, you might be surprised by how many lessons will transfer over from games to other types of development.
It goes to show that when you learn to code with games like The Long Dark, you might be surprised by how many lessons will transfer over from games to other types of development. Examining games from a developers perspective and extracting a feature to recreate can also help you get into video game coding, so it’s a win win.
While its good to talk about strategy and general practices like building off of something small, I want to get into actual coding in this post. After all you can’t learn to code with games unless you actually write some code! In particular, I want to show you how we can take a feature from a game like The Long Dark and try to replicate it with Javascript code. I suggest starting with something simple, like a hunger meter. We could define a variable like fullness.
let fullness = 100;
Why fullness and not hunger? Certainly nothing is stopping you from calling the variable whatever you want, but in my mind it is easier to call it fullness because then I can set it to 100 and know that means “completely full.” Whereas if I used hunger, I might be confused. Does 100 mean 100 percent hungry? Hunger doesn’t make as much sense to measure by percentage as fullness.
In The Long Dark, you get hungrier the longer you don’t eat. That means we need something to measure time. Since it’s a video game, time also goes by a lot faster than in real life. So let’s say every 30 seconds translate into 1 hour. We could use a Javascript function like setInterval that would get called every time 30 seconds have passed. You can read more about the function and test it out here. Note the double slashes in the code below indicate comments.
let fullness = 100;
setInterval(function(){
fullness = fullness - 5; //subtract fullness by 5 percent
console.log("logging fullness", fullness);
}, 30000); // 1000 is 1 second (in milliseconds)
By assigning fullness the value of itself minus 5, I am essentially decreasing fullness by 5 percent. Then I am logging out the new fullness value to the console, so I can confirm that my function is working. Having to wait 30 seconds to confirm my function is working can be a little bit annoying, so you can reduce the number of milliseconds to 1000 temporarily for testing purposes.
If you’re using a coding editor in the browser such as Codepen (I’ll be including a Codepen link a little further down) the console can be opened up by clicking on the “console” button in the bottom left corner of the editor
So now we have a fullness value that decreases over time, but what about eating? In The Long Dark you can eat all sorts of things. If you scavenge you can find canned beans, peaches, even dog food (ew) to eat. Or you can go fishing or hunting. Each type of food has a different number of calories which affect how much your fullness meter gets filled.
For now, let’s just create four foods. A granola bar, some canned beans, a pound of deer flesh, and a rainbow trout. Let’s say 200, 450, 800, and 150 calories respectively.
const trout = 150; //use const to declare a variable when you never change the value of the variable
const deer = 800;
const granola_bar = 200;
const beans = 450;
Now you might be thinking we have a problem, and you would be right. If we are counting our fullness as a percentage and our food in calories, how will we add them together? Looks like we will have to make some changes to our existing code, after all. The average man needs to eat about 2,500 calories per day. For the sake of simplicity, let’s say that is the number that constitutes 100% fullness.
const maxCalories = 2500; // maximum calories you can eat
let currentCalories = 2500; //calories you need to eat per day
let fullness = 100; // still keeping percentage for display purposes
const trout = 150;
const deer = 800;
const granola_bar = 200;
const beans = 450;
setInterval(function(){
currentCalories = currentCalories - 60; //subtract fullness by 60 because we burn 60 calories per hour while sitting
fullness = (currentCalories/maxCalories) * 100 //calculate fullness percentage
console.log("logging fullness", fullness);
}, 30000); // 1000 is 1 second (in milliseconds)
Above you can see I’ve added two new variables, maxCalories and currentCalories, which make it very easy to do our math in setInterval to calculate the fullness percentage. Just divide currentCalories by maxCalories and multiply by 100. We also are subtracting 60 calories every 30 seconds because that is how many calories we burn per hour when we are sitting. Now we are ready to add an eatFood function. This one should be very simple. Just updating currentCalories, right?
At first glance this would seem to be enough, but ultimately we will want to display the fullness data and update it every time currentCalories changes. In that case, it makes sense to create a function for updating fullness as well, to avoid rewriting the math multiple times. Let’s take a look at the whole thing again (minus the variables).
setInterval(function(){
currentCalories = currentCalories - 60; //subtract fullness by 60 because we burn 60 calories per hour while sitting
updateFullness()
}, 30000); // 1000 is 1 second (in milliseconds)
updateFullness() {
fullness = (currentCalories/maxCalories) * 100 //calculate fullness percentage
console.log("logging fullness", fullness);
}
eatFood(food) {
currentCalories = currentCalories + food;
updateFullness();
}
I moved the console.log message into the updateFullness function so that you can see what happens to fullness when you eat food. In my Codepen example, I have buttons that the user can click to eat the different kinds of food, but since I am sticking to Javascript for this tutorial there is another way you can call the function in the code for now.
Just like we called updateFullness inside the setInterval and eatFood functions, you can call eatFood by typing eatFood() and just adding whichever food you want to eat inside the parenthesis. That means eatFood(beans) would pass the beans variable into function.
If you throw in a couple of eatFood() functions at the top of your code, you will notice that your log statements will become problematic. This is because we don’t have anything checking for fullness being greater than 100 percent. We can fix this by adding an if statement inside the updateFullness function.
This if statement will make it so that fullness gets updated to 100 if eating the additional calories would make fullness exceed 100 percent. Otherwise, the same calculation will be performed as usual. In my Codepen example, I also introduced a death state where if your fullness gets to 0 you can no longer eat food and your status displays as dead. The logic for that is very simple, just checking if fullness is 0 and then setting a variable dead to true. Then inside the eatFood function you add another if statement preventing currentCalories being added unless dead is false.
Another thing you will notice in Codepen is additional if statements for judging what to display for the current hunger status as well as for what color the health bar is. I’ve essentially added a simple GUI for users to interact with. If you want to add this functionality, check out these resources for creating a progress bar and buttons . The only additional Javascript that I am using is document.getElementById and changing the style and innerHTML of the selected element. You can read about that here and here.
There is a lot more you can do from here. You could create a hydration meter using some of the same code we already have. You could get closer to replicating the functionality from The Long Dark by adding a general health bar that begins to go down only when your hunger becomes very low. That would be more realistic since you obviously don’t immediately die when you didn’t eat 1 days worth of calories. I encourage you to explore what you can build on top of this code and can’t wait to see what you make! Hopefully this has helped give you some encouragement.
Hellblade: Senua’s Sacrifice is one of the most harrowing journeys into a mentally ill person’s mind that I have ever seen in a video game. If you haven’t played it, I highly recommend checking it out. You don’t even have to worry about getting addicted because the game has a concrete beginning, middle, and end. One of the unique aspects of Hellblade is a mini puzzle game that involves finding a shape in nature that matches a shape carved into the various runes in the world.
I decided to recreate a simple version of this mini puzzle game with Javascript in Glitch. You can look at it right away here or give it a shot yourself first. In this Javascript game tutorial we will be using HTML5 Canvas and vanilla Javascript, no fancy framework. We will load a background image of some trees and the user will control a triangle shape on top of it and try to find where the same shape can be found among the trees. When they hover the triangle shape in the right spot that matches up where the trees form that shape, the triangle will change color. You could use a more complex shape, but I wanted to keep it simple by using a triangle for this tutorial.
Thankfully the HTML is very simple, just two things we need to do. First we need to do is create a canvas element with <canvas> and give it width, height, and an id as shown below. The width and height should be roughly the size of our image. We will use the id to identify the canvas in Javascript. The entire game will pretty much happen within this canvas, which allows for advanced graphics manipulation that you cannot do with other HTML elements.
Second we need to add our tree background image so our canvas can access the image data. However I will also add a hidden class because otherwise we will see our image twice, since it’s going to appear inside our canvas. We want to give our image an id as well, since the canvas also needs to access it. I called it “trees” because well, its an image of trees. The below code will go inside your <body> tags.
<img id="trees" class="hidden" src="https://cdn.glitch.com/eb083ff0-5e3b-41d0-be19-711a1dcd89f5%2FDSC0063-1024x680.jpg?v=1589402686658"/>
canvas width="800" height="600" style="border:1px solid #d3d3d3;" id="canvas"></canvas>
<script>Our Javascript will go here, or in a .js file if you prefer </script>
Then in order to make your image be hidden, you will want to add this inside your <head> tags.
<style>
.hidden {
display: none;
}
</style>
Worry not, even though the image is hidden our magical canvas will still be able to access the data to display it in all its beauty. Wonderful! Now our HTML file is set and we can focus on the Javascript. The first step is to identify our canvas and get the context, which is what lets us run functions to actually change what is displaying.
let context;
let img;
let canvas;
window.onload = function() {
canvas = document.getElementById("canvas");
context = canvas.getContext("2d");
img = document.getElementById("trees");
context.drawImage(img, 0, 0);
};
I’m declaring the image, canvas, and context variables at the top because we are going to need to access them throughout the code. Having a window.onload makes sure that we don’t try to fetch the canvas before it is loaded into our browser. In the first line of the function, we are getting our canvas, which we need in order to get our context. Then we are getting our image and drawing it to the canvas with context.drawImage. This function takes our image, and then the x and y coordinates (which start from 0 at the top left corner, so in this case our image will take up the whole canvas). If our context was in 3d space instead of 2d, we would also add a third value for our z index, the perspective plane.
So what’s next? Let’s think a little about what we data we need in order for this to work. So far all we have is our tree background image in a canvas. We want there to be a shape that the user can move around on top of the image. While allowing the user to drag the shape around would be nice, the easiest option is to just make the shape follow the user’s mouse around.
In order to do that, we will need to get the coordinates of the users mouse. This is actually the trickiest part, because canvas is not very sophisticated with the data it provides by default. We have to do some math to account for the location of the canvas on the window. The function below will do that for you.
function getPosition(el) {
var xPosition = 0;
var yPosition = 0;
while (el) {
xPosition += (el.offsetLeft - el.scrollLeft + el.clientLeft);
yPosition += (el.offsetTop - el.scrollTop + el.clientTop);
el = el.offsetParent;
}
return {
x: xPosition,
y: yPosition
};
}
This function accepts the canvas element and returns the x and y coordinates of the canvas in relation to the browser window. We will call this function inside window.onload to get our canvas position, which will then be used to get an accurate mouse position. Don’t worry too much if you don’t understand all of it. If we were using another framework such as P5js this extra math wouldn’t be necessary at all.
The important part is next. We are going to add what’s called an event listener, which is a function that will get called every time the window detects a user interaction. We can define what user interaction we are listening for. In this case it will be moving the mouse. While we’re at it let’s also call our getPosition function to get our canvas position and add our mouse coordinate variables to the top, since we will need to access them soon.
let context;
let mouseX = 0;
let mouseY = 0;
let canvasPos;
let img;
let canvas;
window.onload = function() {
canvas = document.getElementById("canvas");
canvasPos = getPosition(canvas); // getting our canvas position
context = canvas.getContext("2d");
img = document.getElementById("trees");
context.drawImage(img, 0, 0);
canvas.addEventListener("mousemove", setMousePosition, false);
//the line above is listening for when the user moves their mouse, and will call the function "setMousePosition"
};
Olay so now we have an event listener but this code will not run because the function setMousePosition doesn’t exist yet. That is where most of the magic is going to happen. We will need to redraw our shape every time the mouse moves. We will also need to check if the shape is in the spot where it matches the pattern, so we can tell the user they have found it! You can add this function below window.onload.
The above code will get us the current coordinates of the users mouse on the canvas. We are passing in e which stands for the element that is being passed into the function, in this case our canvas element. The subtraction is happening to account for the offset of the canvas position on the browser window, as mentioned earlier. Now we can actually draw our shape!
function setMousePosition(e) {
mouseX = e.clientX - canvasPos.x;
mouseY = e.clientY - canvasPos.y;
context.beginPath(); // tell canvas you want to begin drawing lines
context.moveTo(mouseX, mouseY); // move where the cursor starts the line
context.lineTo(mouseX - 25, mouseY + 125); // draw first line
context.lineTo(mouseX + 25, mouseY + 125); // draw second line
context.fillStyle = "#FF6A6A"; //set the color
context.fill(); //fill shape with color
}
As you can probably tell from my comments on the code above , there are several steps to drawing a shape. First we have to tell the canvas we want to draw lines with context.beginPath and then we need to move our cursor. Since we want our triangle to follow the mouse, we move our cursor to the same coordinates.
I want my triangle to be a bit elongated, so when I define the end coordinates of my first line I want them to be just a little bit to the left (-25) and farther down (+125). To keep my mouse centered to the top of my triangle, I set my other line coordinates to be the same amount, but in the other direction on the x coordinate (+25). The final line goes back to our original coordinates, so you don’t need any additional code to complete the triangle shape. Now we can set the fill style to the hexadecimal code for a sort of salmon-y color. You have to call the fill function in order for that color to actually be applied to your shape.
We’re getting close but if you run the code now you might see something is a little strange! Instead of having a triangle that follows our mouse we seem to be painting the canvas. That is because the canvas is constantly drawing more triangles every time we move our mouse and the canvas isn’t getting cleared. Luckily clearing the canvas is pretty easy.
function setMousePosition(e) {
mouseX = e.clientX - canvasPos.x;
mouseY = e.clientY - canvasPos.y;
// add the lines below
context.clearRect(0, 0, canvas.width, canvas.height); //clearing canvas
context.drawImage(img, 10, 10); //drawing our image again since that got cleared out
context.beginPath();
context.moveTo(mouseX, mouseY);
context.lineTo(mouseX - 25, mouseY + 125);
context.lineTo(mouseX + 25, mouseY + 125);
context.fillStyle = "#FF6A6A";
context.fill();
}
The clearRect function takes four values, x and y coordinates which define the upper left corner of the rectangle, as well as a height and width. If we provided something smaller than the canvas height and width only a portion of our canvas would get cleared, but we want to clear all of it. Of course this clears our image as well so we need to draw that back to the canvas again. This all needs to happen before we draw our triangle or it will get covered up by our image.
Now you should have a lovely little elongated salmon triangle floating around on top of our forest image, following our mouse obediently. There is only one thing left to do. We need to give the user some indication when they have “discovered” the pattern. There are a lot of fancy things that could be done here. We could display some text to tell the user they have found the pattern. We could add some fancy animation like in the actual Hellblade game. But for the sake of brevity and to give you freedom to experiment with canvas on your own, lets just change the color of our triangle. This code will be added to the bottom of our setMousePosition function.
Here we are checking our mouseX and mouseY coordinates to see if they match with the coordinates where we know our shape is in the image. You may notice there is a range of 5 pixels in both the x and y coordinates, because it is actually quite difficult to get your mouse on 1 or 2 specific pixels.
I took the liberty of figuring out the coordinates for the image in our tutorial, but if you want to do this with a different image or a different shape you will need to add some console.log statements to your mouseX and mouseY so you can gauge where the shape should change colors. I’m changing the color to a simple purple, though you can obviously change it to whatever color you choose. Check out my version on Glitch here.
Thats it! Hopefully you feel like you are one step closer to mastering Javascript. Now you can plug in any image and see if your friends can figure out if they can find the pattern. It’s obviously not too difficult with the shape and image I provided, but it can certainly be made more difficult with a larger image or a more unusual shape. I recommend checking out the following tutorials if you are interested in expanding your knowledge of drawing shapes and images with the canvas element:
In my last post I wrote about the first session of SpacyCloud’s Live Twitch stream from two weeks ago. The twitch stream was an all day event where the first half of the day consisted of a variety of workshops around creative coding topics, while the second half featured performances from various audio visualization artists and creative coders. Unfortunately I could not attend all the events, but I wanted to write in detail about both the Hydra event and P5JS event. You can read the P5JS post here. Now let’s dive into some live coding visuals!
The Hydra tutorial on SpacyCloud was taught by Zach Krall, a graduate student at Parsons School of Design with an impressive portfolio of projects. Though I had been experimenting with creative coding since college and knew about Processing, the language that P5JS was ported from, I had never heard of Hydra before. Just the fact that it was something new peaked my interest, but when I saw the home page for the Hydra-editor I was pretty much sold. Every time you load Hydra, a different visualization appears on the screen, with the code that wrote to make it overlaid on top. You can copy and paste the code, so in a way each new visualization is like its own mini tutorial.
It turns out that all of the coding for Hydra happens in the browser, and the background of the entire browser window changes to display the product of your code. Personally I prefer this over the two panel system that most web coding editors use, because when it comes to visualizations you want to be able to see them in as large a display as possible. However I could see some people not liking this, because the code is a bit harder to read, even though it does have a background color applied.
Hydra was created by Olivia Jack who wanted to build a visualization engine that took its inspiration from analog televisions. It did that and a lot more, because with Hydra you can connect to other machines and each output your own video stream that can then be modified by others.
Probably the hardest thing about starting out with Hydra is wrapping your head around some of the paradigms, which are pretty different from your typical application. In Hydra, you typically start with a basic visual preset or texture, like noise, voronoi, or oscillation. Check out these basic visuals below. Note that while these screenshots are static, within Hydra all of these are moving visualizations.
You can also pass values into the function to change it. For example, if I write noise(100) instead of just noise() the gray matter gets much smaller, like specks of dust rather than blobs. If you pass noise(100, 100) the specks of dust will start moving around the screen MUCH more quickly. The same can be said for voronoi and oscillation. First number defines the density of shapes, the second defines the speed of movement. Be careful passing in large numbers for the speed, it can be quite painful on the eyeballs.
In order to execute the code you need to hit Shift + Ctrl + Enter on the keyboard. You might have noticed the code inside the screenshots include a second function chained on called out() . This function is basically telling the browser to output everything in front of it in the chain. If you remove out() nothing will render to the browser and you will only see a black page.
We’ve covered voronoi, noise, and oscillation. There’s one more basic render and that is shape(). Drawing a shape in Hydra is simple enough. The number you pass into the shape() function defines the number of sides for the polygon. So, shape(3) is a triangle while shape(4) is a rectangle, and so on.
You can also specify how large each shape is and how blurred its edges are by passing in 2 more numbers into the function.
You might be wondering, what could one possibly do with a simple shape in the middle of the screen? That is hardly interesting to look at. I also thought it was a little bit odd that you couldn’t place multiple shapes or define that border and size of the shape like you can do in most creative coding languages. However, I was pleasantly surprised after some experimenting, as hopefully you will be too.
One of the easiest things to do is create a tile pattern with the shape. You can do this by chaining a repeat() function, where the numbers you pass into the function define how many times the shape is repeated.
If you write repeat(10,10) like in the screenshot above, you get the shape repeating ten times both in the vertical and horizontal directions. If you write repeat(10) then you will have the shape repeat ten times in the horizontal direction, but not vertical. This function is one of the geometry functions, which you can read more about in the documentation.
So how might you apply color to these shapes? If you were using voronoi, noise, or the other automatically generated textures, its very easy. You just chain a color() function where you pass 3 values corresponding to the amount of red, green, and blue.
Because you cannot apply color directly to a shape, the workaround is to use a blending function with shape() and applying color within the blending function. For example, you can blend the red oscillator above with the rectangular tiles in the other screenshot.
Now you can see the rectangles are overlaid on top of the oscillating red texture. There are multiple blending functions, and each one has a different effect. I won’t go into detail on all of them because this post is getting lengthy and I am wary of the cognitive burden,
Suffice it to say there are 6 blending functions in total, called operators in the documentation. The other 5 are add, diff, layer, mask, and mult. If you’ve ever experimented with layer effects in Photoshop, some of these should sound familiar. Depending on the complexity of your visualization, these operators will sometimes output the same result. You are most likely to notice differences when using a range of color and texture.
Let’s take the our oscillator and jazz it up a bit. Rather than using the color() function to apply a simple red color, you can actually pass 3 values into the osc() function directly. The first still specifies the number of oscillating rows, while the second specifies the speed they move across the screen, and the third specifies the range of color. Lets say we use the diff() operator and also tweak our rectangles by making them a bit larger and blurrier. What might that look like?
Now we’re cooking with gas. Just a few extra functions and things are much more interesting. There are many variables we can tweak to experiment even with this relatively simple visualization. For example, what happens if we change the oscillator to a voronoi or a noise generator?
Alright, so it looks like we lost the cool colors but got a more interesting texture in return. Are there other ways to bring back color besides the ones I showed? Absolutely! The colorama() function which brings all sorts of psychedelic fun. It’s the last function I wanted to demonstrate because it can spice up pretty much any visualization, and is probably the quickest to get interesting results with.
I hope by now you have the hydra-editor open in several tabs and have virtually lost interest in this post because you are too busy experimenting. Hydra is seriously one of the most absorbing and exciting creative coding tools I’ve had the pleasure of working with, and the goal of this post was to give you enough knowledge that you can hit the ground running.
Of course there is tons of material I couldn’t cover, and for that I want to leave you with a few references.
Hydra book is a very detailed guide that goes into pretty much every function Hydra has to offer, with lots of screenshots to help you along the way: https://naotohieda.com/blog/hydra-book/
Olivia Jack’s documentation is also nothing to shake a stick at, and has lots of coding examples that you can copy and paste to experiment with. There are also more Hydra tutorials listed here: https://github.com/ojack/hydra#Getting-Started
I had the immense pleasure of attending several creative coding workshops on April 4th. They were streamed live on the SpacyCloud Twitch channel. There were additional sessions involving Hydra, Raspberry Pi, Haskell, and more. However for this post I want to focus on the first session which was a P5.js tutorial. In this post I hope to translate the P5.js tutorial for beginners into a written format, for posterity and to share what I learned. I’m going to review what was taught in the live session. Hopefully SpacyCloud will have another live stream in the future so I can catch up on what I missed. Here is the landing page for the event schedule.
Although I have used Processing years ago when I was in college, I knew I was very rusty which is why I decided to tune into Leandra T’s P5.js tutorial stream. Originally branded as a creative coding language for artists, Processing is mainly used to create generative art, visualizations, and immersive installations. P5.js is basically a version of Processing that is ported to Javascript. Processing was developed my MIT and is built on top of Python. Naturally people wanted to be able to show their generative art online, so it didn’t take long for there to be a huge demand for Processing that worked with Javascript instead of Python. Since P5.js has taken off there is tons of code online that people are sharing, making it a lot easier to learn.
That being said, it’s still nice to have someone walk through every step with you. That is what Leandra did. After showing us an example of what we were going to make, Leandra dived right into the online P5 editor. Whats great about this editor is you can do all of your coding online and see the results of your code side by side. She went over some of the basic functions, such as setting the canvas and background, and drawing shapes.
In the above code (to be more precise, a screenshot from the aforementioned P5 editor) you can see two functions, setup and draw. The setup function is called once when the application first runs, while draw is called constantly every frame (at least 24 times per second). What that means is that while it looks like the circle is static, it’s actually being redrawn constantly. However our eye cannot perceive that so it looks as though the circle is always there.
As you might have guessed, createCanvas is only called once and the two numbers you pass are the pixel width and height of the canvas, respectively. The canvas defines the area within which you can draw. Inside the draw function, background is what defines the background color of your canvas. If you pass 1 number, you will get a shade of gray as if you passed 3 RGB (red, green, blue) values. That means that background(220) is just shorthand for background(220,220,220). Each value can be as high as 255 (white) or as low as 0 (black).
Then of course you have the ellipse. In the screenshot above there are only 3 values passed to the ellipse function: x coordinate, y coordinate, and radius. However, you can actually pass in 4 values, which is why the function is called ellipse rather than circle. Passing in 4 values means you can stretch or squish the shape because you are passing the x coordinate, y coordinate, width, and height.
So far this is pretty boring. Luckily, it only takes a few tweaks for things to get a lot more interesting. Instead of passing the ellipse static values you can pass in things like mouseX, mouseY, or random. Passing in mouseX to the first value of ellipse and mouseY to the second value will make it so that you are essentially painting circles across the canvas wherever you move your mouse, because the ellipse will follow your cursor. If you pass random instead, the computer will generate a random number every frame and draw the ellipse to those coordinates.
You need to at least pass random a maximum number, so that it knows the range within which the random number can fall. If you want circles to cover the whole canvas, you can use random(width) for the x coordinate and random(height) for the y coordinate because P5.js stores the width and height of the canvas to those variables. Also make sure you move background out of the draw function and into setup, otherwise you will only ever see 1 circle on the canvas because the background will continuously be drawn on top of it.
Okay so now we’ve got lots of shapes on the canvas, but where is the COLOR?! Much like you can provide the background 3 values that reflect red, green, and blue you can do the same for shapes with the fill function. For example, if I pass fill(255, 0, 0) I will get a completely red circle like below.
But what if I pass random values instead? What do you think will happen?
Now we’re cooking with gas. Leandra went through similar steps in her live tutorial, to make sure everyone understood the basic principles and the most commonly used functions in P5.js. One of the most popular uses is to create visualizations that respond to sound. These are obviously a huge thing at raves and concerts, and they are easy and fun to make. The first step is to make sure you have the sound library linked in your P5.js editor.
On line 5 in the above screenshot there is a url pointing to p5.sound.min which is the P5.js sound library. If you click the little arrow above the code it expands to view the files that you see on the left hand side. Click on index.html and confirm that you also have the p5.sound.min script on line 5.
The next screenshot illustrates the additional code you will need in order to setup the mic and start receiving data from it that you can use for your visualization. Basically, you have to setup some variables at the top so that you can access your mic anywhere in the code. The variables start off empty but then you pass the actual mic in your setup function and start it so that it actually runs. Finally, you need to get useful data from the mic so you call getLevel to get the loudness which you can use for visualizations. You can confirm that the mic is working by adding a console.log statement so you should see values being returned below your code when you run it.
We’re getting really close now. Only a few more steps to go before the finish line. Now that you know your mic is working, you can try passing in the micLevel and playing some music to see how the visualization responds. You can also introduce a few more functions, such as stroke and strokeWidth. The role of stroke is to define the color of the border of your shapes. Like fill, you pass in 3 values for red, green, and blue. On the other hand, strokeWidth is for defining the thickness of the border. You can see an example below integrated with micLevel for some cool effects.
We’re at the final step. It’s going to involve a slightly more complicated programming concept, so bear with me. This concept is called loops, and in particular we are going to use a for loop. Basically you define a variable, like num, and that variable can increase or decrease until you reach a specified stopping point. Most of the time, for loops are used to count upwards by 1 to a designated end point. So a for loop like for(let num=1; num <= 8; num++) { console.log(num) } will output 12345678. Hopefully that makes sense. There is plenty of reading online about for loops if you are still confused.
Unfortunately it doesn’t look that cool in a screenshot. It will look much cooler for you when you actually have the code in P5.js yourself and play some jams! So first, let me put the code here so you can actually copy and paste instead of manually typing everything out. This was the exact code that was written in the original P5.js tutorial.
let mic;
let micLevel;
function setup() {
createCanvas(400, 400);
mic = new p5.AudioIn();
mic.start();
}
function draw() {
micLevel = mic.getLevel();
background(5);
stroke(255, round(micLevel * 800), round(micLevel*255));
strokeWeight(micLevel * 200);
for(let i =0; i < 6; i++) { // for loop counting from 0 to 6
fill(random(250), random(100), random(255), 255); //1 circle is drawn with every loop, so 6 circles total
ellipse(i*60 + 40, micLevel*5000 + random(50), 50); //micLevel for the y value caues the circles to go up and down with the volume, i*60 means a new circle is drawn every 60 pixels along the x axis
}
}
I also tweeted out a video of my own code and music so if you don’t feel like it or don’t have time right now to tinker with the code here is a short video. Make sure you turn the sound on!
Hope you enjoyed this P5.js tutorial. Stay tuned for another retrospective on SpacyCloud live workshop about the hydra-editor!
Programmers rarely agree on whether or not coding is a creative profession. My interest in coding always stemmed from what I could create with the code. Seeing an interesting visual result from my efforts is usually the most satisfying part. Most programmers are less concerned with how their app looks and more concerned with the functionality. Usually, as long as the app works the way it is supposed to, most programmers are satisfied.
Of course that is an overly simplified model. Programmers often care about how the code is written, whether it is reusable and easy to understand for other programmers. One could argue that deciding on which tools to use and how to organize the different parts of the code involve creativity as well. Creativity is a broad term and I’m not here to make a commentary about whether or not programming is creative. This post is rather about people who identify with the term creative coder. Namely, folks who got into coding because they are interested in how they can express themselves creatively with technology.
There are a lot of good examples of creative coders in some of my other blog posts, here and here. Nathalie Lawhead is one of my personal favorite creative coders. Their work lies at the intersection between games and interactive art. They draws a lot of their inspiration from old flash games and early net art. Games like What Remains of Edith Finch, which are sometimes called “walking simulators” by the gamer community for being primarily focused on storytelling can also fall into the category of creative coding.
Then there are folks who make all kind of interesting art with code on communities like Codepen. From unique loading screens to animated menus to scrolling backgrounds, these are also inherently creative. It’s hard to make a list of every kind creative coding out there because technology is constantly evolving. Tools like Processing and OpenFrameworks allow for especially dynamic and immersive art to be created, from moving and morphing fractals to particles replicating the flocking of birds or cell division, the sky is the limit for what kind of art creative coders can make.
I am a lot more passionate about programming when I am working on something like a game or interactive art project versus enterprise software. Tackling technical challenges can be fun occasionally but I am much more interested in the act of creation and the product I am creating. I am especially excited if the product I am making involves other creative aspects.
I think that is what differentiates creative coders from other types. What made them interested in coding was not the technical challenges or the logic puzzles but the excitement of creating something that is immersive and captivating. Creative coders may or may not be software engineers in their day job. Some are front end developers, fewer are back end developers. For me UI developer was especially attractive as a day job because it merges design and development. Even in these jobs, though, as I write about in another post, sometimes there is not as much creative expression as one might hope for.
That is the other thing that distinguishes creative coders. They always have that powerful longing for creative expression. Creative coders might also enjoy other things like drawing or music or writing. Personally I enjoy all of these things, and didn’t do any programming of my own for many years. Technically, I did tinker with web development in middle school but my first object-oriented programming code wasn’t written until college.
Some creative coders have never even worked for a corporation in their lives. For instance, there are artists who started collaborating with technologists years into their career and discovered a new passion they didn’t know existed. They might have learned to code in their 30’s and used it to create generative art or experimental experiences. Frameworks like Processing have made coding a lot more approachable even for artists and folks who have traditionally felt ostracized from the world of code.
Unfortunately, being a creative coder can put you in a weird limbo between the world of programmers and the world of artists. I felt this very acutely in my career, as someone who graduated with a Visual Arts degree and then began working as a software developer.
On the programming side, there is still a lot of gatekeeping, especially at the corporate level that makes creative coders feel unwelcome and unwanted. Programming interviews are often designed to test your knowledge of algorithms that are typically taught in computer science classes. Unfortunately, since creative coders often come from non traditional backgrounds the chances that they are familiar with these algorithms is pretty small.
There are also negative stereotypes among some programmers about creative folks specifically that will put them at a disadvantage as well.Some programmers out there believe that you are either a logical person or a creative person, basically concluding if you are good at art you cannot write code and vice versa. Obviously, this is ridiculous, but those who believe it can be hard to persuade.
Sadly, these gatekeepers sometimes succeed in convincing people and so some of them never even try to experiment with coding. These same gatekeepers are usually also the kind that make it harder for folks minorities in tech to have their accomplishments recognized. Usually this means if you’re a minority and identify as a creative coder, the path to recognition and respect can be even steeper.
As if it wasn’t bad enough that gatekeepers in the programming world tend to look down on creative coders, there is a similar issue for these coders being recognized by the art community. First of all, the percentage of galleries that showcase generative art, immersive experiences, or experimental games is still very low compared to the galleries that showcase works of painting or sculpture. The few galleries that do, like Artechouse, can be extremely particular about who they choose to showcase. To be chosen for exhibition is akin to winning the lottery, probably even more difficult than landing a programming job at Google or Facebook.
If you identify as a creative coder, you might be feeling a bit depressed after reading all of this. The thing is that regardless of how much gatekeeping or frustration creative coders face, they make some of the coolest projects on the internet. Once you make that first hypnotic generative art piece or that game that you’ve had in your head since you were 10, you won’t feel the same afterward. Ultimately, if you are a creative coder you know it’s so much fun that you would be doing it regardless.
After sharing my post describing what a UI Developer is, I got some requests to write another post specifically about how to get a UI Developer job. It’s certainly not an obvious path. My first job out of college was working for my alma mater in the Art Department media lab, during which time all I knew was that I wanted to transition into web development.
UI development is a mixture of design and programming, which is a pretty good option for a creative coder. When I first got interested in programming I didn’t know positions like “UI Developer” even existed. After that I had a few short term positions where I was focused on just getting my foot in the door. I had some free time and decided to look into various types of UX design courses. I already had a degree in Visual Arts from college, so I thought maybe if I ended up hating being a programmer, UX design would be a good alternative At the time I didn’t know what working in the tech industry would really look like, so I didn’t want to put all my eggs in one basket.
I ended up settling on an Interaction Design certificate offered by UC San Diego through Coursera. It was a series of six courses that taught you how to run A/B tests with different designs, how to conduct research and interviews to figure out the sort of problems users are facing, and how to use tools to speed up the design and testing process.
The final course was a capstone project where students had to actually put into practice everything they had learned and create a high fidelity mock-up for a mobile app. What the app was and the problem it solved was completely up to the student. It took me a year to complete the series of courses since by that point I had landed my first software engineering job. It’s hard to say how much of a difference the certificate made in terms of landing my first UI Developer role later on. If I had to guess I would say it was equal parts my Visual Design degree and the certification.
The Interaction Design certification helped me gain more confidence and allowed me to add a significant design project to my portfolio. However, it’s hard to say how much my Visual Arts degree played into the employers decision to hire my for my first UI Developer role . The reason why I say that is because frankly, most software developers do not come from creative backgrounds. I knew at this point that I had a solid foundation in software engineering because I had worked for 8 months at a startup using Angular. That made my art degree like the icing on the cake, and the certification kind of like the cherry on top.
When my husband got admitted into law school in DC, I applied on a whim to a Data Visualization Developer position and got the job without even needing to fly there. While on the surface the title of Data Visualization Developer doesn’t sound like it necessarily involves user interface design, you could tell by reading the job description that it did. Basically the company wanted someone who could draw mock ups for widgets inside of a data visualization application and do research on how they might work best, while also actually developing the widgets and doing other front end work.
That particular position did not give me any sort of UX assessment as part of the interview process, though they did ask about my certification and Visual Arts degree. Unlike standard software engineering positions where you can usually expect a coding test of some sort, UI Developer positions have a wide range of tests. Sometimes they will give you a mock up of a website and ask you to code it. Other times they might ask you how you would go about creating an application for a specific purpose, or what you might do to improve the design of an existing application. They might even have you sketch out interfaces on a white board.
One position I applied for gave me a simple form with a poor user interface and asked me to code a new version that would be better. In this case I misunderstood the instructions and ended up not getting the job. I thought that I wasn’t supposed to touch the code that was already there and that it would be breaking the rules, but in order to change the form input (which was what made the UI terrible) that was a necessity. That is the other tricky part about UI developer positions. It’s easier to misunderstand the instructions if you are given a test that you’ve never had before, or that breaks the paradigm of what you would expect.
!EMPTY!
It also makes it more difficult to give concrete advice on how to pass a UI Developer interview. If you have any doubts at all, it is best to ask. You might get asked about any education you have in the past, or any portfolio pieces that involve user experience design. You might also get asked to demonstrate your coding skills whether through an online test or something more akin to a standard software engineering interview.
Honestly I wouldn’t be surprised if some jobs hand out a take home test where the interviewee must redesign and code a landing page or something of the like. One UI position I interviewed for actually had me sketch out wire-frames on the white board, live code some CSS, fill out a pen and paper test with programming questions, and solve additional programming problems on the white board with another developer. There was no way I could have predicted what all the assessments would be ahead of time.
The only way to really start getting comfortable with the process is to apply to some jobs and see if you can get any interviews. Depending on how much user experience design skills the job actually requires, you might not even be asked to prove those skills at all. The hiring manager might be satisfied with any past design education and ask a few simple questions, and that could be it.
Oftentimes I have found that UI Developer positions still care more about the software development technical skills than design skills. It is another thing to keep in mind if you are more interested in getting UX experience or don’t want to spend more than a few hours a day coding. Make sure you read the job description carefully, and also ask lots of questions in the interview about what your day to day work will look like. I would hate for anyone to end up in a job they hate because the title said UI Developer but in reality they only get one design assignment per month and the rest of their time is spent on awful legacy code.
Another frustration that is common among UI Developers is that they get hired in companies that don’t have a lot of design resources. That might mean you are the only design advocate in your organization, and it is easy to have your voice drowned out. Being assertive is oftentimes required or else you might get frustrated very quickly having to execute poor user interfaces and feeling bitter at your coworkers.
With those warnings aside, I still recommend considering UI Developer positions if you are the type of person who enjoys both coding and design and like to interface with people on both sides. Make a portfolio website, show off some UX and coding projects, and try to land some interviews! I wish you the best of luck.
A popular challenge that beginner programmers participate in is called 100 Days of Code. Although I never participated in it myself, I see countless tweets with screenshots and progress reports of people sharing bits of apps they made. 100 Days of Code is a great way to keep people in the programmer mindset. It gets them familiar with what it is like to code every day. Still, I wonder if it is the best approach for everyone. For them, One Game a Month could be a great alternative.
I’m here to propose another approach, one that is gaining popularity in some game development communities. It’s called the One Game a Month challenge. Unlike the 100 Days of Code challenge, its designed to be undertaken for an entire year. Unlike the 100 Days of Code Challenge, One Game a Month allows you to take your time. Not necessarily write code every single day.
I know what some of you might be thinking. Well, there are a lot of other components that go into a game — you have to make art, and audio, and design decisions. That is naturally all true. Although, I would argue that adding this creative element to your coding adventures actually makes the whole thing a lot more fun. Especially if you’re a creative coder like me. But I don’t want to land a job as a game developer. I want to work at a hip startup disrupting [insert industry here]. I get that too.. but here is the kicker. I am a self taught programmer, and the majority of my portfolio consisted of – you guessed it- games.
There’s something that gets skipped over a lot when people talk about breaking into the software industry. It’s not necessarily about what type of product you show off. It’s about the coding language you use to make the product. And whether that language is one used by the startup you are applying to. It is very much possible to develop games with Javascript, and Javascript is also one of the most in demand languages.
So back to my earlier point. One Game a Month gives you a challenge that you can work on more steadily. It also conjures (hopefully) more excitement than making another Reddit or Craiglist clone. There are even communities built around specific game platforms such as Pico-8, which are very generous with sharing their code and resources. Although Pico-8 runs on Lua, it bears a lot of similiarities to Python. Lua still teaches you the important data structures and logic that you need to know to become a programmer.
I can imagine some of you might still be skeptical. Maybe you want to see some real examples of games that were made with Javascript. I can understand if you’re not yet willing to buy into this “one game a month” thing. Here’s some different games that you can check out, starting from the easiest to the hardest to code:
Alien Attack: This game is good for getting your feet wet with Javascript, and isn’t too complicated. You have to guess the X and Y coordinates of an alien in order to shoot them. The blog post shows all the code involved in making the game.
Sliding Tile Game: This game has a lot more Javascript, but is still fairly straightforward in terms of the logic. It’s a game where you have to get 8 tiles that are are scrambled back in the right order. But there is only one empty slot where you can move the tiles at any time. This blog post is extremely thorough in walking you through the game mechanics and how to figure out the winning state.
Bunny Defender: Unlike the previous two games, Bunny Defender requires using a Javascript game engine called Phaser. Getting comfortable with a Javascript game engine will make it easier to learn Jframeworks like React or Angular. So, it is a great step forward. It is a mobile game where you have to destroy asteroids trying to destroy a planet of bunny rabbits. You can find some examples of code for this game on Github, but the original tutorial to make the game was on Lynda.com.
2048 : 2048 is another puzzle game where you use the arrow keys to move all of the pieces on the board in that direction. There are many examples of this game coded with different frameworks like Vue and React. Here are a variety of links below:
Multiplayer Battleship: This is a really advanced game that uses Angular and Typescript. I haven’t used this tutorial myself, but it seems comprehensive and a great fun way to get comfortable with a modern Javascript framework.
This past year was a big one for me. I got motivated about starting my own business, and making a name for myself as a creative woman coder and indie hacker. This blog was one of the accomplishments from this year. I had to take a few months off to write my book. This year was in many ways the most productive one I’ve had in my career. So let me summarize my indie hacker year in review:
Published a book about my journey getting into software development
Got that book to #1 most downloaded spot in 3 categories during KDP Select free promotions
Started an email list and grew it to 300 subscribers
Switched from front end to full stack developer
Showed my game at a public event in my city
Was waitlisted to show my game at a much larger public event (Super MAGfest)
Learned about React, Redux, NodeJS, MySQL, Microservices, Typescript, ES6, and Cypress
Grew my Twitter following by 300 users (in the last 2 months!) after letting my account stagnate for several years
Had three blog posts featured on the front page of Hackernoon
I didn’t start 2019 with a concrete list of goals. All I knew was that I wanted to do something that involved both being creative and coding. But I can say for sure I did not expect to accomplish this much a year ago. I was feeling the entrepreneurial itch and I knew I wanted to create and sell something. That was pretty much it. I knew that in order for something to sell successfully, I would need some kind of platform.
Blog
That was where my blog came into play. The thing is, I blogged before and always ran into the same problem. My blog wasn’t niche enough, at least that was what other people kept telling me.
It wasn’t until I read a book about multi-passionate people and how they can be true to themselves. I decided launching a blog might be a possibility after all. I realized that I was interested in game development, web development, creative expression, and indie hacking. I thought I could merge all of those interests into a creative coding blog.
Originally the blog was called “Multimedia Minds” and it wasn’t connected to my personal website. Over time I became dissatisfied with the title and thought that merging it with my website made more sense. I already branded myself as a combination of UI and game development, though I think creative coder is much easier to understand and doesn’t involve having to explain to myriad of skills involved in being a UI developer.
Later on I realized could use my blog as a funnel to interest people in my book. Thus far I had written a wide range of posts I thought I ought to focus more for a while on the tech industry. Then my blog would rank higher for programming related content. So for a few months now I’ve been blogging about different cultural aspects about working as a programmer. From attitudes about work-life balance to how engineers get promoted and what kind of problems programmers can face in the workplace.
Book
I wish I had created more hype and setup a preorder page for my book before I released my book. Despite some of my mistakes I’m still satisfied with the progress I made. I’ve learned a lot about Amazon ranking and keywords, as well as how to run giveaways to drum up more interest. I posted my book to a lot of directories that share free books. I was running promotions where I would give my book away for a limited time. That helped with getting downloads. Now I’m very happy to see my book on the first page of results for my focus keyword.
I started growing my e-mail list as part of my planning ahead for when I was going to sell a product. For the first few weeks I actually grew it the most by giving my book away for free. That was, before I enrolled it in the KDP Select program. It helped to get my e-mail list started but after a few weeks interest seemed to dwindle. I wondered if it made more sense to try to sell my book. It’s pretty funny to think that if I hadn’t made that jump I would never have know how successful my book could be. Looking back on that decision really puts things in perspective for me.
Expanding Reach
Twitter was a good place that I knew could work as a funnel for my book as well as a way to extend my reach. I had a Twitter account for years, but it never really took off and I decided to reinvestigate why that might be. I decided to try out two services that I discovered through Product Hunt. They help to schedule tweets in advance by creating content libraries that can cycle through different types of content that you want to share. This has been a lifesaver for me, because its hard to be constantly active on a platform that updates so quickly. The other tool focuses on following people. It chooses people to follow based on the hashtags that they use and the type of content they write about. I don’t expect to use that tool forever, but it’s connected me with a lot of cool new people. It has broken me out of the rut that my Twitter account was in for so long.
I realized that I could get also more reach on my posts if I shared them on other coding related websites. Initially I contributed to Code like a Girl, but later I got ambitious and decided to submit some articles to Hackernoon. Not only did they accept my posts, but they actually featured several of them on the home page. This was really a big boost for me. I no longer doubt my writing skills or that I have something worthwhile to say. So that’s probably one of the biggest wins I had in 2019.
Game Development
That was a lot of talk about my book and my blog. Obviously writing is a big part of my life, but as a multi-passionate person it is far from the only part. The year in game development was not as productive as some of my past years in terms of actually making games. But it was by far the most productive in terms of finding my game developer community. Actually showing my games to real people and getting connected. After years of fear I take the risk and submit my game to some local events. The first one was at a library in my city. It filled me with so much energy and joy. I showed a game that I had worked on by myself, that had very little exposure. People really responded to it and were impressed that I made it by myself, which meant the world to me.
The next step was to submit my game to bigger events. The biggest event in my area is called Super MAGfest (Music and Games Festival). I figured if my game was accepted to the indie showcase there, I could really feel like a professional. Unfortunately, it was not accepted BUT it was waitlisted which was still a big motivator for me. Especially because the games I submitted were not ones I had toiled over for years. In fact, the one that was waitlisted had taken me less time than the other one I submitted (which was rejected outright).
Day Job
There is still one area of my life I haven’t covered, which is my actual day job. I hope one day to be a full time indie hacker making interesting apps or games for people to enjoy. There is still a lot I’m learning from the startup where I’m currently working. This startup trains everyone as a full stack developer, so I am learning a lot about back end technologies that I did not know. It’s exciting because it fills that gap in my knowledge and means I can really become a one woman development team. It is also a little bit overwhelming considering all the other things I have been working on this year.
So that was a really long post. I wasn’t intending for my indie hacker year in review to be this long but when I started thinking about everything that happened this year, its not surprising. I was going to also write about my goals for 2020 in this post. But considering the length it is already, I think it’s best that I save it for next week. Overall I’m pretty happy with what I have accomplished, and I think I took some really important steps toward actually becoming an entrepreneur. Selling my first product, gaining traction on my blog, and building a social media following are all steps that I feel I have taken. That being said, I know there is still a long road ahead. As a quick preview: building my email list, finding my tribe, and creating a community are all goals I have.
People tend to glorify confidence. In interviews, we tend to think more of the person who expresses themselves loud and bold, with their held head high. This tendency is especially true among Americans, the most obvious evidence being the current President of the United States, Donald Trump. After all, most psychologists agree he is profoundly full of himself. Despite his failures in business and real estate, he continues to believe he is the smartest man on Earth. Unfortunately people like Trump get promoted and the same thing happens with bad engineers.
I wish that the tendency didn’t extend beyond politics, but it does. Entitled, loud, and opinionated engineers get promoted faster than their more subdued peers, regardless of actual skill level. Managers without technical knowledge have no other way to evaluate the skills of these developers. So they end up judging engineers the same way they judge managers.
I’ve seen this first hand in the six different programming jobs I’ve had thus far. It was difficult for me to gain any significant respect in the companies I worked at because I was not outspoken. Being a creative coder has also led to instances where I was underestimated, because sadly some developers still look down on designers and believe that their work is less important. Over the years I’ve learned that I need to open my mouth more and advocate for myself. I’ve gotten better at it, but it still bothers me that silence and creative leanings is mistaken for a lack of competence.
Here’s something I want any manager reading this right now to consider. What if the quiet engineers are not incompetent, or shy, or lack social skills? What if they are just being careful to speak up because they want to verify accuracy? What if they feel intimidated?
When you are starting out as a developer, especially if you are underrepresented in tech, it’s difficult to speak up about things. Even if you know someone is saying something patently false, it’s easy to hesitate about correcting another developer. They might get angry and hold a grudge against you, who knows? Getting the confidence to confront another developer can take months, even years. Some developers never gain that confidence at all, even if they are competent.
I’ve had this happen on a number of occasions. The most memorable was when I was discussing a UX issue with a backend developer who tended to dominate all of the conversations. Despite knowing nothing about UX, this developer consistently argued with me about every choice I advocated for. When I pointed to research and specific examples from my classes, this developer would fire back. He argued he saw the UX choice in interfaces that he had personally used (like JIRA – yes, JIRA). It became quite heated on several occasions.
The promotion of loud engineers is a problem because the more those loudmouths get promoted, the more people are afraid to challenge them. Since they were prone to interrupting other developers even before they were promoted, the problem gets a lot worse when their ego grows.
The other problem with promoting such engineers is that it validates a certain communication style. That is one of blurting out the first thing you believe to be correct, without proper investigation. Over confident developers are notorious for jumping to conclusions. If your team sees that the loudmouth engineers are the ones who get promoted, they are more likely to adopt this communication style themselves. Is it helpful to blurt out the first idea that comes to your head? In brainstorming situations, sure. But when you are trying to fix a difficult bug it can derail the problem solving and send the team down the wrong path.
To be clear, I don’t want to sound like I am demonizing anyone who leans toward the chattier side and likes to talk. A team of engineers that over communicate is better than the opposite. The problem lies specifically in the situation where one overzealous and egotistic engineer drowns out the other voices on the team.
Now that the new year has started, it’s the perfect time for companies to reevaluate their promotion strategies and consider fresh approaches. Sometimes quiter developers need a little bit more encouragement. They might not be sure if they can train people or be confident enough to lead a team. That doesn’t mean that they would automatically make a worse leader than the engineer who is always talking.
Is it possible the loud developer who thinks they are a genius will leave the company if they aren’t promoted? Certainly. But the rest of the developers will be grateful, and happier at work. They are more likely to go to the modest leader for questions, and learn more. It will also be easier for them to explain what they are struggling with without feeling stupid.
There’s one more thing. Maybe you are reading this and going: okay, but what if my loudest engineer really IS a genius? Maybe they have a PhD in physics, or four masters degrees, or they wrote their own game engine and sold it to Bethesda. Even if that is the case, consider deeply if their personality is really good for leadership.
Ask the following questions. Are they the kind of person who is willing to delegate tasks, or do they think they can do everything themselves? Might they become a bottleneck in the future if given too much control? Are they actually good at explaining technical concepts to juniors or do they like to overcomplicate things to make themselves sound smarter?
I know not everyone reading this is going to take my advice. Maybe it’s not practical, and there are too many other problems to deal with. My goal with this article was to highlight why these patterns in promotion are not as great as they might seem at first. Even if only a small fraction reading this actually change their promotion practices, I will feel like it was worth it to write this. As a developer myself, I know that having a positive relationships with my manager and lead engineer makes a world of difference.
The world of technology is a complicated one. With titles like “rock star”, “ninja,” it can be hard to take job descriptions seriously. It doesn’t help that many hiring managers ask for ludicrous credentials. Is a UI Developer a real thing? Maybe they have job descriptions like this:
Job descriptions for UI Developers can look like the one above. Like full stack developers, UI developers are expected to be familiar with more than one area of expertise. While full stack developers know frontend and backend, UI developers are familiar with the front end and how to design user interfaces. In some cases they also know how to conduct user research. I like to call them “creative coders.”
Don’t take the excessive list of requirements seriously. It’s like the hiring manager’s letter to Santa Clause. Don’t do yourself the disservice of not applying because the requirements seem excessive. The person who wrote the job description has nothing to do with the people you will be working with.
I know a lot about being a UI Developer because it has been my title throughout most of my career. When I got my first job with that title I had about a year’s worth of experience with AngularJS. In addition, I had a game portfolio illustrating my programming skills, a certification in Interaction Design, and a bachelors degree in Visual Arts. It might seem like a lot, but I had two years to build my game portfolio and four to complete my degree.. during which I only look about 12 credits worth of actually programming.
There were jobs in which I was doing the work of a UI Developer without the actual title. Tiny startups usually used the title of “Software Engineer.” It didn’t matter to me, because the important part was that I was getting to do the work that I loved. In the long run I worked at a lot of smaller companies. At big companies such positions rarely exist, because hiring managers can afford to hire specialists for everything.
Even though it is less common for large companies to hire UI developers, that doesn’t mean that such positions never crop up. For example, I was hired as a contractor for Deloitte to work on a project that involved customizing an application for an existing client. The application was focused on data visualization and had a number of complex and confusing widgets. They wanted someone with a design and front end skillet to make those widgets simpler.
Downsides to being a UI Developer
Over the years I have noticed some downsides to being a UI developer. The organizations which want to hire a developer with design skills don’t have any dedicated design resources. They also often think of design as an afterthought.
It can be an unspoken assumption that the UI developer will make some small improvements to the design and focus on code. If, in addition to having no design resources, the organization has few front end developers. Some companies even hire a UI Developer that they expect you to be a one person show, coding and designing everything with zero support.
I don’t recommend taking on roles like that unless you really want a challenge and you like the people at the company. When you are working that hard on a project, it’s easy for resentment to build up. It will build up fast when you know the whole thing would fall apart without your contribution. Make sure you have some experience under your belt and you know what you are getting into.
In lieu of design resources, some organizations allow all of the developers to be involved in deciding what the user interface will look like. If you enter an organization like that, you may find yourself arguing with a lot of other people about every little thing. On one hand it can be invigorating at times to have to defend your reasons for making a button blue. On the other hand some developers do not have any design training,. That means reasoning with their opinion about what they find to be aesthetically pleasing can be frustrating, especially for small adjustments.
If you are considering a career as a UI developer, know that the job descriptions can be intimidating. But they are often a wish list that doesn’t reflect reality. If you enjoy working on a mix of design and coding tasks, it could be a great fit for you. Most companies that offer UI developers roles will be medium to small sized, and often don’t have designers on the team. This can lead to some downsides. Like arguing with other developers about design decisions and having to convince upper management that the design is more than some small tweaks.
If you can get past these downsides, though, I would recommend applying for some UI developer positions. Don’t forget, they can hide beneath other titles. Make sure you read the descriptions before dismissing them.