This is a weekly roundup of awesome DEV comments that you may have missed. You are welcome and encouraged to boost posts and comments yourself using the #bestofdev tag.
Your 2018 in Numbers offers a really fun way to look back at folks' yearly accomplishments. Basically, you're meant to hop in and drop a list of personal metrics from your past year using mostly emojis. Check out the format here in @helenanders26
recap:
In the discussion What’s your favorite JS interview question? , @ufocoder
offered up a satisfying question:
What will output these example? Why?
for (var i=0; i < 10; i++){
setTimeout(function(){
console.log(i);
}, 1000);
}
How to fix it to output numbers from 0 to 9?
Meanwhile, @eljayadobe
displayed a sense of humor in Don’t set a resolution this year.
My New Years Resolution: 5120 wide by 2880 high.
In A junior, a mid and a senior dev walk into a bar, we're offered a cautionary tale on DB migration, and @scotthannen
reminds us just how important testing is:
Hopefully yours is not a culture of blame.
In order for this migration to work, you would have had to be extremely careful to get it exactly right. If it blows up, it's easy to say that you should have been more careful. And of course, you say that you'll be more careful next time.
That sounds good, but an environment in which everyone just has to be extremely careful or everything blows up is going to face catastrophic failures often. I've been there.
Developers make mistakes. That's reality. It doesn't have to break production systems if we understand it and work with it, not against it.
That's one reason why we write unit tests for our code. We catch little mistakes. If we didn't make small mistakes, then why write unit tests?
We also test the behavior of our applications, including QA tests. If we never introduced bugs, why test our applications?
Then we deploy our code. That can be a complex process, as you experienced. Do we test that deployment process? We test everything else, so why would we not test the part that has the greatest potential to crash everything?
That means having a staging environment which perfectly mirrors production, where we can test our deployments. Containerization also helps.
Was it your personal idea (or S's or M's) not to have a staging environment for such tests? I bet it wasn't. The risk of catastrophic failure was built in to your deployment process. It was a matter of time.
"Let's all be more careful" is not an answer. I doubt that you or anyone else were careless. Humans simply aren't capable of mentally calculating every variable and visualizing how complex systems will behave. (We do okay sometimes, but relying on that is a horrible idea.) If we could do that then we wouldn't need computers. We could just do everything in our heads.
Testing everything, which includes having the environment for such tests, is the answer.
Finally, speaking of screwing up, reading Even the Big Ones Mess Up outta make you feel a bit better. We know how @ben
feels:
Every time I encounter a 500 error in the wild I breathe a sigh of relief.
See you next week for more great comments ✌
My 2018:
📝 25 blog posts (since August)
📖 100k blog reads (since August)
🛩 9 trips
💾 2 database migrations
🛠 5 AWS services used at work
👩🏫 12 analyst workshops presented
👯♀️ 10 junior analysts on boarded
📚 30 hours put into AWS study (since August)
👩🎓 2 team ‘awesome awards’ and year end winner
☕️ So much coffee ...