Code under pressure
Don't do it.
But the servers are literally on fire.
No, seriously. Don't do it.
But I have to.
You're going to regret it. Don't do it.
But the C levels are yelling. My job/reputation/company is on the line.
OK.
Yell back
For the purposes of this post, we're going to assume you aren't under pressure from your own doing. You have done everything you could possibly do to avoid this circumstance.
Yell back. If you're client or company is yelling at you about this dumpster fire. Yell back, strategically. And keep it civil.
Yell strategically. They need to fully understand that coding in these situations is prone for error and dangerous. This should buy you some sympathy, but you know.
If you have a good idea of what went wrong here, briefly say so. You aren't looking for an argument here, you are planting seeds for what you'll talk about in the retrospective. You will have a retrospective.
Keep it civil. Don't yell like an emotional 4 year old. Yell like an adult and calmly. Heightening the emotion of this situation won't make it any better and could make you less effective.
Dispassionately say what went wrong without assigning blame.
Through a series of unfortunate events, we've ended up down to the wire. I needed the guest list yesterday. Let's fix this, if we can.
We’re Lost, But We’re Making Good Time
Hands off keyboard.
Don't build when you don't know what you're building. Talk to the stakeholders.
After you've established that this situation sucks, you need to make sure you're not lost. (That title/quote was Yogi Berra)
Talk to the stakeholders. Ideally you have a high fidelity talk with them. This at least means a phone call. Even better would be a video call. Even better would be a video call with a screen share.
Here's why. Text can be misunderstood. It can be misinterpreted. It can be completely omitted. There's not enough time for a back and forth now.
The video and audio helps capture tones and expressions. So when they stress something, you catch it.
Know what you're building. This should be reducible to an ordered bulleted list. While talking to the stakeholder, have them rank the list.
OK, in this order we need to:
- Change the speaker's image
- Add the 25 guests
- Remove the subtitle
Yes, but add the guests first
Cut Scope
Let's face it. You might not get all this done in time.
That's why we had the stakeholder rank the list.
Prepare them. Tell them you will do your best to get these done, but the last few items may not be completed.
I'm going to be heads down coding. I will ping you with each item I get done and I need you to verify promptly. Anything else before I get started?
Head's down
You probably have an idea of what works to make you most productive. Get all of that ready to start.
Take care of yourself. Are you hungry? Do you need the bathroom? Are you comfortable? These will pull at your attention and focus, take care of these.
Take a breath. Before you start, close your eyes, take a deep breath in, hold, and exhale. Repeat n number of times until your focus is 💯.
Pair if possible. If you aren't soloing this dungeon, have someone pair with you. Extreme Programming had it right with code quality and this is an extreme situation.
Code your face off. With each item ask, what's the quickest way I can do this that's acceptable. Don't introduce security flaws, but also don't test in triplicate.
Check for spelling. You're not done. Check your spelling and don't put curse words in your console. Just say them audibly to get them out of your psyche.
Ping the stakeholder. It's on them. They're your QA now. Move on to the next item. If they ping back, don't check it until you're done with what you're working on.
The Retrospective
Hopefully this isn't your first rodeo. Hopefully it's not your client or C-level's. Also, hopefully you made it through.
Be available during the crucial time. If you made it through, the stakeholder will be pleased. If you didn't, you may be called to the front of the class.
Though it feels like it in the moment, these aren't often as crucial as they seem. Most of the time people have an idea of what they want, but their users have no preconceived notions.
We do want to avoid these circumstances in the future though. That's why it's vitally important to have a retrospective with the stakeholders.
Congratulate and commiserate. They're feeling pressure too. Empathy for them can go a long way for future projects. Keep it positive and avoid the blame game. Use objective language, look for points where you could have communicated what you needed sooner, talk about sign offs, and look to the future.
Training the stakeholder. If you've been working in software for a while, you're familiar with how long things take and what rabbit holes can come up. Your stakeholder isn't.
They need to recognize we're working with complex information and need time to develop it. There are millions of configurations that are wrong and a much smaller set that are right.