Quite often in the events industry, we're faced with annoying little technical problems at late-notice by clients who didn't think through their requirement requests. This usually ends up with us technicians having to improvise solutions on the spot, right before something important is about to happen.
In an ideal, well resourced scenario, an example would be an exhibition host suddenly deciding that they want to be able to walk around the hall and make on-the-fly announcements. The problem? The client didn't specify having wireless microphones. The solution? Quickly run up to the stores room and collect a wireless microphone kit, and get it wired into the halls loudspeaker system.
In a less ideal scenario? Presume a similar situation where an even host wants to walk around the audience and interact with them. The problem? You don't have a wireless microphone system because one wasn't specified with enough notice. The solution? Give them two options - that they either have to stick to the stage, or deal with an absurd length of however many spare cables you can daisy-chain together. Chances are they'll go with the latter.
I've had both of these situations on more than a few occasions. The solution comes down to what is technically feasible in a given moment. More often than not, you're under-resourced, and the prospect of finding a solution to a last-minute problem is the last thing you need. What matters is that it works, even if the solution isn't elegant. As they say, the show must go on, and an improvised solution ultimately means one less problem on your shoulders.
I've mentioned in a previous blog that I used to be involved in an alternative festivals production team. Weeks ahead of the 2016 event, we sold out of tickets for the first time. As event policy stated that all involved purchase a ticket, this created a problem wherein some key people were too late to the metaphorical party. Our solution? Release more tickets. This we did, and a wild rush to get them caused the ticket vendors website to crash, and us overselling by 200% or so.
This then very much becomes my problem. My primary role was that of the 'town planner.' Meaning, it was my job to tetris in all participants, their camps, art pieces, stages, vehicles, and a significant number of key infrastructural elements with complex spatial requirements. That's all well and good, but the problem was that the estimated spatial needs now exceeded the amount of available space that was agreed upon in our land-use contract.
Complex problem? Yes, and no. From above, it's just a puzzle, and by following basic logic the structure of the town plan was very simple. The solution to the problem was ultimately to ask for more land, so we asked the land owners for the use of a neighbouring paddock, and they graciously obliged. As a result, my complex task was thoroughly relaxed. All that was needed was that extra headroom, and everything freely flowed on from there.
The moral of the story? Whittle complex problems down to their simplest form, and if you need extra resources, ask for them. In times of need, people can be very accomodating. Occams razor states that the simplest solution is often the best one, and if a complex problem has a simple solution, the problem is likely quite simple too..
Alrighty, the actual web tech stuff. My confidence depends on the technique in question:
For this sprint I was frustratingly delayed by misc life unpleasantries, and as such I was hesitant to ask for help with things that everyone else had already moved on from. A benefit however is that I started thinking outside the box, and this is what made me think to try using an LLM. I don't want to rely on such things however, and like breaking down technical problems with people, so I have in mind to poke myself to get over such insecuriies around legitimate life things and just sing out as I otherwise would do.