Saturday, 10 PM. Everyone is having fun. Except you, handling project’s emergency.
It’s no wonder you’re angry. Everyone would be, right? But what’s worse, you are not the only one having a bad time now.
Think about it. You are handling an emergency time now - and emergency time is a moment when your client is worried too.
The application doesn’t work - the money is being lost.
And those emergencies will happen again and again - most likely it is not the first time you are sitting here, fixing nasty bugs and regressions.
How it affects your relationship with the client? I bet you may feel unsafe here. Trust is a ratchet - it’s easy to lose, but hard to build. It’s your call to keep the damage as minimal as possible. Every emergency, every problem that is not fixed smoothly greatly affects the trust that client has in your skill and professionalism - unfortunately in a negative way.
But, there’s more.
Think about your users.
They have their job to do - they want to achieve their goals with your app. When emergencies happen, they’ll just lose time. They’ll complain. They’d like their money back if they paid for your app. Do you think that’d make someone happy? Certainly not.
You need to realize that we, programmers have a one particular type of problem that is extremely hard to explain to our clients. And we do it all the time. Such type of problem is called regression.
Just think about it, see it through your client’s eyes:
Imagine you’re going to the mechanics to fix the broken brakes in your car. You leave the car. They fix the brakes. You take the car the next day. You go for a short ride. The brakes seem to be fixed, all is good. You pay for the service.
You drive home, nice views, good weather, good music. You open the window. They are damaged, you can’t open them.
Absurd! There are only a few businesses that can have problems like that - and software development is one of them. It’s totally unfamiliar for clients doing their business. If they’re selling food and change spices in their dishes, they’d expect that taste can be better or worse. They don’t expect that their supply lines would get cut. It doesn’t make sense!
Yet, you are here, making regressions like that happening in your projects. We, programmers, are doing such bugs every day.
These consequences are the easiest to understand. They affect your wallet and your ‘work’ stuff. But having too many emergencies have another, even more dangerous effect on yourself.
You start to be doubtful about your skills.
Do you feel confident as a programmer when emergencies and problems arise on production environments? How can you be? Is it clear for you that you are still professional or you’re feeling lost and doubtful? We all want to be professionals - and production problems greatly undermine our confidence. Would you be happy even if you fix an issue? Will there be any doubts? I had them every time after failure happened and it was my team fault. And it sucks. You can be depressed for days, even weeks. How would you be productive if you start feeling bad about yourself?!
You need to have a plan and learn from mistakes.
But the thing is - it’s not that easy. There are hard feeling everywhere when something breaks on productions. Emotions, panic mode - all that stuff can happen and you need to answer this question - can I be a professional, have a plan and be confident? Without emotional stuff that can undermine your progress?
Someone needs to handle the emergency and bring the application back to life. Can you be this “someone”?
What if I tell you it does not need to be that way?!
What if you accepted an accident and handled it without emotions and panic?
What if you knew that it’s your job to handle the incident and act with full professionalism, control, and confidence?
What if every emergency happened only once and made a lesson to learn from? What if you were prepared for every known issue and acted immediately, armed with your experience?
What if you were the first one to notice every problem and you were ready to tell your client about what happened, why it happened, what has to be done and cannot be done, what are the options? What if your client saw that you’re on duty?
What if you were not scared of Fridays because if something happen, you are grounded? How about happy Saturdays and Sundays, with no more weekend works?
What if the art of being responsible could be learned?
In fact, it can.
Responsible Rails
“Responsible Rails” is our new book on this subject.
We, the Arkency team, saw much. We supervised >100 Rails projects, within 8 years. We are used to big amounts of money (millions a month) involved in our projects. We saw mistakes, and what’s more - we made mistakes. But we learned from them. Now we want to share our knowledge.
The book is a collective work, it’s written by multiple authors, everyone being an Arkency member with their own histories, preferences, and conclusions.
From Rails developers to Rails developers.
Thanks to this book:
- You’ll know how to communicate professionally so you do not just solve the problems, but your client knows your significance
- You’ll get a step-by-step execution on how to act when accident happens, so you’re prepared for every scenario
- You’ll learn about 13 real-life stories, so you don’t need to experience them. Senior developers learn from their mistakes. Smarter ones learn from other’s mistakes too.
- You’ll learn proven methods of analyzing and preventing problems.
- You’ll develop good habits that will help you avoid emergencies.
- You’ll know how to work on production environments with some helpful DevOps best practices.
In the other words - you will become the more responsible, reliable, predictable and professional Rails developer.
There is no software engineering without disasters and when those happen it is crucial to know how to handle them as real professionals. This is what ‘Responsible Rails’ is about.
For junior developers it is must-read where they can learn how to handle critical emergencies and do not go nuts doing so.
For seniors there is a whole bunch of real life examples of - downtimes, failed migrations, regression bugs - with descriptions why it happend (and why no one expected it) along with solutions so it is always great to learn from someone else’s fuck ups :)
What’s inside?
The book consists of four main parts:
Part I - Being responsible. The answers to important questions: What does it mean to be responsible? Do you need to be responsible? Is is really that important?
Part II - What to do during emergency. The frameworks for dealing with production incidents.
Part III - Real-life stories. 13 reports of various accidents we faced. A great collection of mistakes to never repeat, good decisions and valuable conclusions.
Part IV - Preventing incidents. A bunch of advice how to minimize the number of problematic situations.
All that together makes more than 100 pages. It is sold for $49.
This is a beta version of the book. If you buy the book now, you will get all the further updates for free.
Q&A
What are the supported formats?
Right now we are supporting PDF, .ePub and Amazon Kindle (.Mobi) format. In our opinion, it is most convenient to read the book as PDF. You will receive all three formats in a nicely packed ZIP file.
What if I don’t like this book?
If the book doesn’t satisfy you, just reply to your purchase receipt email and I will issue a refund. No hard feelings.
How will I get the updates?
We will send them to you via email to the same address that you provide during the checkout process.
Who should read this book?
If you’re working as a Rails developer, especially if you’re responsible for deployment. If you have any Rails project in production, if you lead a team, communicate with clients or freelancing, this book is a must.
Who is this book not for?
If you just started out with Rails, we recommend other books to start with. This book is not recommended as your first book on Rails.
This book is not for you if you never want to communicate better with your clients because you think it doesn’t matter.
Do I need lots of DevOps knowledge to read this book?
Not at all. We wrote this book for Rails devs, juniors and seniors, and CTOs. You don’t need to anything about DevOps. We’ll teach you here most of those best practices which are required to handle and prevent emergencies.