Choosing tech like a Karaoke song
Have you ever wandered into a karaoke bar? You may be there just to enjoy the atmosphere, or actually, sing yourself? If it’s the first one, you still may have an opinion on what others choose as songs, right? And that is perfectly fine, you may even voice your opinion to a random person, or the people you went into this somewhat fictitious Karaoke bar.
Once you mustered some courage to sing, then you’re faced with a dilemma, what to choose? If you think about it you might end up with some similar thoughts around song choice like myself:
- Make a mental list of your favourite songs, recent or old, doesn’t matter at this point
- Take your audience into consideration: who do I sing to — or better, sing with?
- Make it real, but make sure you don’t try to wreck your vocal chords, and damage yourself with the song (and other people’s ears!)
Let’s say you did all that, chose the perfect song, sang it well, clicked with the audience. You had a lovely night. And the next day when you wake up you realise: hold your horses! I’m a software engineer, and these principles remind me of some other problem space 🧐
Choosing tech for your project
Software people are regularly faced with this dilemma: what tech should I choose / recommend / advocate for my next project? This project can be for my own amusement, or maybe a startup idea. God forbid, it is work related and I need to write an async worker that produces some cloud infrastructure based on a set of inputs.
Every time this happens, people are either trying to be more adventurous (remember the 3rd point there?) or sensible and actually pick something they know, and are comfortable with.
Let’s go through this process, like we’d choose our song for this amazing karaoke night.
1. Your Tech List
Round up all you know, like every language, framework and library you worked with. Then start to mark the favourites, or just the ones you had worked before with. You can do this on a piece of paper, a whiteboard or a Trello board — it doesn’t matter about the medium, what matters is the process.
You go through these and really think about it, what is it that you’re comfortable with, and what is it that you’d love to work with again or maybe just don’t hate it by the time you finished? Get those songs languages and frameworks listed and continue to the next step.
2. Who is your audience?
When you’re choosing tech for a project, you really do choose it for life. Or at least while that software / API / app lives, although it may be alive for more time than you think! Especially if you write software and expose it to the tubes of the internet. Some APIs that were written as a prototype are still considered production nowadays.
Back to your list — now, you have the things you’re comfortable with, now we need to match it up with the “list” your audience (team / colleagues) are as well! There may be some overlaps and total outliers, which are there for your amusement but may cause friction sooner or later within the group.
Much like a song choice, I could choose some obscure Indie-pop song that only ever played a few times on the radio (still I could be mad for it), but no one else knows? They won’t have a chance to sing along with the chorus, or even enjoy the performance.
3. Be realistic
For real, you don’t need to wow everyone all the time. I mean, we all know that Bohemian Rhapsody is a great song, but there are much simpler bangers out there. Just like songs, in tech as well tried and trusted is much better than the fresh off the press framework.
Also, it’s better to play to your strength in this situation. Especially if time is a big constraint for the project, you don’t want to waste a bunch of time researching, trying, spiking (essentially rehearsing) something new. There’s always a time and space of that too, just not when it is time to perform.
In essence: make sure you pick a technology that will show your strength, you can work and perform with it well, and it doesn’t hurt if your colleagues like it too and can take part in your “performance”.
