Five examples of ways I've been creative as a software development recently
Recently, I went along to an event for young people wanting to get into creative industries. I’m a developer and I'd gone along to provide some moral support for a designer colleague who did a brilliant talk about his career path, but on arrival found myself adorned with a 'career consultant' sticker bearing my name and occupation.
After the talks, we were sent forth to mingle with the young aspiring creatives, answer questions and offer advice. I adopted an attitude of sheepish apology, repeatedly explaining why I was there and preemptively reassuring them I knew I wasn't the person they were there to talk to. I offered some generalised career advice, but with one or two exceptions steered clear of talking specifically about software development.
The next day, after some thinking and talking to colleagues, I realised this had been a mistake. Software development as a career choice has huge potential for creative expression and I should have taken the opportunity to champion this to a captive audience. It can be difficult to explain the creative opportunities though; they can be a bit abstract and there's a perception problem: for instance there was a popular idea among the people we spoke to that coding equates to maths, and maths is not for creative people. I don’t think either of these assumptions are true, but they seemed pretty common and ingrained.So here are five concrete examples of ways I've been creative in my job recently:
Pretend to be a user and try to break stuff
We had a bug in an app we recently developed that we were struggling to reproduce in a development environment. To fix stuff, a great first step is always to see it happening for yourself. The only contact we had with our users was remote, so we had a limited amount of information about what had happened and what they were seeing. I had to use this information, combined with guesswork and general knowledge of how people interact with technology to play around with the app and see if I could make the bug appear. There was also an element of psychology: what weren't they telling us? Had we annoyed them by asking them to try too many different things and made them start lying to us (when my internet at home breaks, I will turn the router off and on once or twice, and thereafter I just lie if the helpdesk tells me to do it again)? Trying to get into other people's heads is something we need to do a lot as developers: everything we do will need to be used by another human, whether they are the users of the products we develop, other developers needed to understand what we've done so they can build on it, or ourselves in a couple of months coming back to our code and trying to work out what it was we were thinking! Getting into someone else's head requires imagination, empathy and, of course, creativity.
Find interesting ways to teach people
I'm putting together some materials to teach some of the non-developers in our company a bit of coding (more on this in a future blog post!). The idea is for them to get a bit more context on what we do every day – it's entirely voluntary and it's really important that it's accessible and fun. The first session is going to be a crash course in using the command line and I've been enjoying putting together an exercise that involves search for cats in a maze of directories. I've also got some really bad developer jokes in there, because everyone loves those!
Try out something new to see what it's like
We needed better logging on one of our systems to help with diagnosing user issues. This is a case where using another company's solution was the best option; we don't like to build things from scratch when someone else has done it already – it's a waste of time and that makes it not fun. But which company to use? After doing some googling and talking to colleagues I got a list of half a dozen or so options: a couple were tried and tested options that had been around for years and we'd used multiple times on other projects and a couple were new offerings no-one I work with had tried before. I did some more reading around and chose one of the brand new ones, because it sounded like it did what we needed, because it's useful for me to try out new things so I can report back to the rest of the team, and because it's fun to explore something new. With software development evolving so rapidly, we get lots of opportunities to try out pioneering solutions: it's exciting and it definitely requires creativity.
Collaborate with designers to solve visual and interaction problems
We were building new features into our app that used animations in ways we hadn't done before. How to implement this was a creative process in itself (I tried stuff out and changed my mind a lot; see my next point), but what was really nice was how this led to collaboration with our designer. The flat designs I had to work off were brilliant, but once we put the navigation and animations in, some things looked and felt different from what we’d expected. Working out how to change things was very much a back-and-forth between the designer and me. We frequently sat next to my computer while I changed code and we looked at the app and made decisions together on how things should look. One issue we had was making a header marker move smoothly with a swiped screen movement. I got it working on faster phones, but on older models we needed to support, the interactions were too resource intensive and became jumpy. I tried out a solution where the header would move after the page had been swiped more than half way. This was much less resource intensive since the header movement didn’t need to exactly track the page movement. I added an animation to the header to give a bouncy feel and this made it really satisfying to interact with. The designer was pleased with the finished result - it had a slightly chaotic feel that actually fit perfectly with the branding we had in the app. By investigating, understanding and working within technical constraints, we were able to arrive at a creative solution that actually improved upon the origin concept.
Decide how to solve a problem, try it out, then change your mind
We needed to get data from one database to another one, and we needed this to happen automatically, every day. In a way, this is a really simple, common task, which is exciting because that means there are dozens, if not hundreds, of possible ways to go about it. So I had a think, and I did some googling, and I talked to a couple of colleagues. The first solution I tried out kind of worked, but because of security considerations it ended up feeling a bit messy. So I reconsidered, came up with another option, ran it past a colleague, backtracked and changed things.
This last point is telling, because almost every development task works like this: there is no single correct answer, just a lot of subjective decisions to make. Subjective decision-making requires imagination and leaps of inventiveness, which is as good a definition of creativity as any. In fact, what I should have said to those aspiring young creatives is: absolutely consider a career in software development. We need as many creative minds as we can get, and you will get to use your creativity on exciting problems every day.
We won’t share your email address with any organsations other than our technology providers. There’s an unsubscribe link in every newsletter we send.
You’re a small agency, with a steady stream of briefs coming through the door and a growing reputation. And yet, you can’t help but feel you’re not doing y...
At Made by Many, sprint planning is a key ritual that the full core team attends on day one of a new sprint, especially during the Proof of concept and Go ...