Hey,
Credit to
misswhiterabbit for the inspiration talking about being a
teacher and it's limitations in song-writing, as it got me thinking about my job and how it influences me, but in both positive and negative ways.
Also apologies for the long post, I'm obviously in a writing mood. This is something I'll also probably add to and edit as time goes on as I enjoyed writing about the similarities and what skills/lessons are transferable - plus any writing practice is good as I'm gearing up to submit a post for review to get on our
public engineering blog.
I've been a software engineer for near 5 years at a very large IT company, and one of the more important things I've learnt over that time is that it's not 'sitting in a dark room writing complicated algorithms' that make you a valued engineer, it's everything else around it.
PeopleDuring the interview process especially and then emphasized consistently is the need to 'network' with others and work as a team. You need to be able to participate in and get along with any team of people. When I started work I was very outgoing with people I knew, but specifically and deliberately very quiet around new people. This became a focal point on reviews and I was forced to become more confident and comfortable around others. Though I haven't done any open-mics or performed in-front of more than two people, I know these lessons have spilled over to my personal life and I'm in a much better position to network in the music world based on this experience.
ProcessProcess is potentially the most important thing about being a software developer. With words like 'Agile' and 'DevOps' being used as buzz-words in the industry, I'll talk about the actual points I've came across and how they've changed my approach to songwriting.
Working in 'Sprints' and Creating a 'Minimum Viable Product'
Part of the Agile process is to work in small, 1-2 week (for us, 2-4 more generally) sprints. At the start of each sprint; developers will commit to what they can get completed by the end of it, and for
only that sprint. The more important part here to reflect on song-writing are the concepts of a '
Minimum viable product' and a
potentially shippable increment: At the end of each sprint, the system should be developed, working and tested for the functionality that was committed to (Such as if the 'whole' system was to read in written forms, categorise them and send out a notification; you may have a working system which will successfully read and parse submissions by the end of sprint 1).
This definitely reflects in my song-writing; as opposed to having a full idea in my head and working on bits all around the song (few lines verse 1, concept chorus, outline structure of verse 2), I tend to make sure to have that 'minimum viable product' which can be performed at any stage - even if it's just a 4-line poem. As with software, it is a good idea to understand somewhat what you'd like your finished product to look like, but this way you always have something to build on and can react to changes; either in customer requirements or personal motivation/inspiration. Plus, you could always perform your song with
only two verses and decide you like it
just the way it is (Thank god I'm my only customer).
Story Board and Work in Progress Limit (WIP Limit)
In software development we generally have a 'Story Board', either physical or digital. In either case it will be split in to categories (typically something like 'Backlog', 'This Sprint', 'In Progress', 'Test/Review', 'Done') with 'Story' items representing functionality such as the ability to 'Create a new Account' or 'Edit Profile Information'.
Whilst this goes alongside the previous sections in it helps to create those 'minimum viable products' where each individual item is fully complete, it also introduces a WIP limit - where a limit is placed on how many items are 'In Progress'. The idea of this is to ensure a nice flow of individual pieces of functionality which can be added to the 'live' bank of code, but also highlights items which are 'blocked' - where developers will get together and 'swarm' on an individual issue. Though I would say 'go where the inspiration takes you' when it comes to songwriting, I have definitely limited my 'work in progress' to around 2 songs at a time so not to get too confused, focus my thoughts and avoid leaving one in an incomplete state for too long.
I think it's also important to know what your 'done' looks like ("
Definition of Done" in the development world). By categorising songs / verses as 'done' you can move on to the next with a clear mind, and always know what you can perform at a given time. The importance here is understanding what 'done' means to you. Hey, you might go to an open mic and perform 3 'completed' songs, then do a quick minute performance of a 'minimum viable product' to gage a reaction - at least you'll know what songs are ready for performance, and have that performable basis of an incomplete song to gage interest (continual customer feedback is also part of the
Agile Manifesto 
).
High Cohesion and Loose CouplingHigh cohesion, at least in software development, means that individual components of a solution have each clearly defined goals and operations. Ths means that you may have a Method (section of code which can be re-used) designed to add or subtract two numbers, and that is exactly what it does; no more, no less!
Loose coupling is the idea that a set of methods (or class, or system if abstracting up) which work together to form a solution to a problem (i.e. a Online Banking) also work individually. This is almost always connected to cohesion, as in the above example the method which adds/subtracts numbers could be part of the banking system, but can be also reused in another system which also needs to add/subtract numbers.
A nice area where I can see this come in to play is with elements of Chord Theory which
Boydie most kidly put together
here. For example, if you wanted to create a Rock Ballad you could re-use a common pattern I, VI , IV and V and apply a different key. As a songwriter, you can
decouple the progressions you've used from the chords they've translated to and re-use this in another song which you'd like to catch a similar essence.
Hence the same for rhyming patterns, cool alliterations, melodies and so on (In fact I used the same finger-picking pattern to create different songs back-to-back - though it's the only one I've practiced I can blag it as an example
)
ConclusionSo I
obviously don't have a song-writing sory-board up in my flat, nor do I rigorously police 'WIP Limits' or stick to working on single aspects of a song until completion before moving on; but they are all concepts which do lay in the back of my head when taking on any task - and perhaps ones which do merit some say when it comes to songwriting.
How about anyone else? Has your job influenced the way you think enough to change the process you take when writing songs, or the content in them?
