I’ve been watching Halt and Catch Fire, AMC’s fantastic dramatisation of a team of engineers in the 80s trying to build an IBM clone, and it struck me that the characteristics the engineers exhibit in the show (like: creativity, ingenuity, pragmatism & vision) are things that we can all learn from when producing something creative.
Note: the show also has a fantastic title sequence that, a super example of tying together the music and visual. Hat tip to the Antibody who are doing some interesting work in this area.
1. Edge case
An “edge case” is a term that’s used to define something a user does that’s outside the scope of a project. Engineers love using them because it allows them to disregard something extraneous or pay attention to something that’s important to the software. It allows them to be efficient and continue building for the main use case (sometimes edge cases can be a powerful signifier that you haven’t quite found the correct solution to the problem you are trying to solve so it’s essential not to ignore them).
To diagnose a edge case:
-
Triage - Is it important? Does it make a creative difference to the outcome? Is it from an important stakeholder? Is it coming from more than one source? (e.g. more than one person thinks that your use of music doesn’t quite fit with the creative)
-
Investigate - Explore the edge case: try to get an understanding of the context of where the input is coming from. For example: if its more than one person who thinks that the music doesn’t fit, try to get emotive feedback as opposed to logical feedback. Questions that invoke more verbose, explanatory answers are better (try ways to get people to avoid: “I just don’t think it works”)
-
Implement - Once you have a solid understanding of the edge case: work towards resolving it. Developers do this by splitting the issue into smaller segments and attacking them in a sequential, logical order.
2. Building something with limited resources
Whether building a physical product or the software that goes in it, you are always dealing with a limit to the resources at your disposal. For early personal computers it was desk space, nowadays it’s whether the device fits in the palm of your hand. These limiting factors are often the most interesting/divisive parts of product design (for example the iPhone 4 aerial/case issues).
As an engineer you’re always attempting to balance form and function in a optimum way; sometimes that can be a hard thing. Working with music is similar in most respects. You’re balancing the creative needs of the client, timelines, budgets, delivery, etc. These are the things limiting your resources.
3. Efficiency
Software engineers are always looking to make things more efficient… but efficiency is a strange thing. Efficiency isn’t necessarily faster. When I think of being more efficient it’s often more about how you work with other people. As Sean Hickey’s post on the evolution of a software engineer brilliantly illustrates: as you become more professional and gain experience you learn that sometimes keeping things clear and simple is better than lengthy and complicated.
So, when working with other people it’s essential that you communicate as clearly as possible in a way that they’ll understand. It’s one of the main principles we adhere to when improving Synkio and it’s why we’ve invested time in making it so simple for you to build a project on Synkio and communicate effectively with music professionals.
Note: Even if you don’t 100% understand the code that’s in the examples on Sean’s post… you’ll appreciate the general principle.
