How about not spending your weekends on fixing bugs that could have been easily predicted and not rushing because you underestimated the time you will spend on a project?
Well, read about my f*ups guide to learn from my mistakes and avoid your own!
Do backups regularly
Let me tell you a story. In one of my previous jobs, I was the person responsible for making manual backups for WordPress websites. I did it every month, but one month I forgot! Guess what happened... Yeah, our website server was attacked, I didn’t think it would be significant as I made backups regularly. I thought I could just upload the last version I had, but after checking the folder on the NAS server and looking for copies, I nearly had a mini heart attack! It transpired that that month, there were a lot of changes to the website. As a result, I spend two weekends making the changes and cleaning the server. I never forget to backup now!
Pro tip – It is also good practice to make backups before making plugins and theme updates!
Double check the sandbox version with someone before releasing it
We have all been in a situation when a client asked for “a little amendment”? Something along the lines of “Please, make this change quickly in the live environment, it’s small and won’t affect anything”. It’s an accident waiting to happen! You agree because it’s a “small” change/fix and of course, you decide not to test in the sandbox because it’s 4pm on Friday and all you can think about is the weekend. What could possibly go wrong? Well… everything!
It happened to me a few times in my developer career, but the story I will remember forever happened on Christmas Eve… The client had asked to introduce some changes to a WordPress-based website. It wasn’t complicated but there were a few changes and very little time to implement. I still remember applying changes late in the evening when all of the guys from my team were already sipping drinks at the work’s Christmas party. I was trying to fix one tiny change that didn’t work, it became apparent that one of the elements had the ‘!important’ attribute added to its style. Of course, it was a great evening and a fantastic party (I DID NOT GET TO ENJOY).
But I learned an important lesson from this - when you are pushing some changes that are not tested in the sandbox they won’t usually work. Finding issues can be quick but fixing them can take a long time, that time it resulted in my weekend starting at 7pm instead of 4pm!
Now I always remember to check the fixes, changes, and features in sandbox before deploying them. It is important to ALWAYS do it, even if it’s a “small” change. It’s also good practice to check the changes with someone else.
Take your time with the estimate
At the beginning of my career, when I received a project to do an estimate, I usually rushed it because I didn't want to spend a lot of time on this and of course, I didn't check the details of each element in the project.
Time for the story number 3 ;)
I was working on finishing a website project for a client. The last part of the development was adding a blog section. Before I progressed with this piece of work, the PM asked for an estimate. Well... I didn’t analyse it properly nor did I ask any detailed questions. I just took a look at the designs and picked one in less than 2 minutes! During coding, it turned out that they were all supposed to have some extra features and be based on Google Analytics… long story short – a few questions and a couple of minutes spent on choosing the right design would have spared me a few hours of adapting the design to the website.
What did I learn from this? Always remember to take time to complete an estimation. Don’t ever think; “this page is very simple, just search box and a list of posts”, and instead ask the questions and pick a solution carefully. You will save yourself a lot of time in the long run!
Summary
I’ve shared with you a few of the f*ups I’ve made over the years. I made mistakes and I am sure I will make more in the future. It’s impossible to avoid them because programming is so dynamic and ever-changing. But it’s always better to learn from somebody else’s mistakes instead of your own ;)
Let me summarise, these tips will help you avoid mistakes in the future:
- Remember to make regular backups
- Let somebody else check your work in a sandbox before deploying to production
- Don’t be in a rush to estimate the job, always research thoroughly
- Don’t deploy a product to production at 4pm on Friday... It will be 7am on Monday before you know it ;)
- If you don’t know something, do some proper research or ask your co-workers for advice.
Thanks for reading and I hope my f*ups help you avoid mistakes!
Top comments (15)
About estimates: The best answer is: "I don't know (yet), Let's talk about it tomorrow."
This comunicates it's hard to estimate.
It also gives you time to think about it. Even if you don't: the things you know can settle and you get a clear perspective.
Keep in mind: You are the professional expert. They want to know something from you. So if it is your professional opinion that you can't answer that yet, they have to take it. Otherwise they shouldn't have asked you in the first place.
Be a professional. YOU own this conversation, because you ARE the Expert.
One that Steve McConnell recommends:
Do you want an estimate or a commitment?
An estimate looks like this: 4-6 months
A commitment looks like this: we'll have it deployed to customers by 5pm on the 12th of December.
That's right :)
Great points! Thanks for sharing your experience with f*ups, as it's not always easy to talk about them 😃
I think it's also very important not to try to decrease the feature estimates just to satisfy some pressure that it shouldn't take so much time. If you know something will take time, just estimate it as it should. If you decrease it and rush through the implementation, you expose the code to f*ups and increase implementation time thanks to all the bugs it will create 🙂
These are very good suggestions.
Don't deploy on Friday, is a big classic I think.
Loved it to always test things. Usually more complex projects can have 2/3 environments before production as dev, QA, tag, production.
And about backups, they could be automated, maybe with a notification system if something goes wrong.
If you are alone in project, you need to think about everything, but making more environments are the best way to test things :)
Most cloud providers have options for automated snapshots/backups. They really safeguard you in the events of ransomware attacks and the likes!
My two cents...
Never take an error message for granted because you know how to apply a workaround on the server.
Yep... Makes sense in retrospect. But since I'm the only one to deploy the code to acceptation and production, I did know how to apply these necessary changes. But this time, update scheduled to run automatically at 8pm, because of personal circumstances I totally forgot to check the production environment after the update. And because these personal things made their way into the early morning, the production environment was down for over an hour. My colleagues did a good job in fixing things, and I was able to help them a little by chatting from a distance, but it really felt bad...
And in retrospect, the acceptation environment already had this error for a longer period.
The fix was really simple. That day, we did an extra update of production with this fix. And it went flawlessly.
I think most of these f*ckups are related to the good old "assumption... is the mother of all f*ckups". Yep, including mine.
Thanks for your stories/tips as well @michal_emphie
Yep you got right, assumption is the worst
One of my big fuckups- Some years ago, I was working as the front-end developer at an e-commerce service company, providing smaller online retailers with recommendation services. The way it worked was that we loaded, on each client page, a JS config file containing client-specific customizations, a platform-specific library, and a file containing the core functionality. This also predated JS build tools as a real Thing, so we had to load each file separately rather than a single bundle.
Well, one day I was asked to add a certain feature for a particular client; this was a simple thing, just converting a piece of data from some computer-readable form to something more human-friendly, so I just put the function in the platform file and put the lookup table it referenced in the core, so it'd be available to other platforms if they needed it. It all worked fine, so I uploaded it to our CDN and waited for the change to propagate out.
A few days later I got a call about our code breaking that client's site. Apparently the new platform file had propagated out, but the core file hadn't, so when my new function went looking for its lookup table, it couldn't find it and broke the website of actually our largest client.
Lesson learned:
Yep, learning on own fault's is really hard thing, I'm glad you have found any conclusions after this :)
Great article!
Let me share one fuckup of my own in return.
I've been deploying WordPress plugin to repository with important change to database schema. I've consulted it with other developers in my company, as it was supposed to be a bit longer operation, but executed only once, directly after plugin update. It all went well during QA, new version seamlessly introduced change and acknowledged that update has been made and isn't required anymore - as expected.
I did not take into account one matter. Instantly after plugin update there may be multiple requests during period between dispatching changes to database and storing the info about successful execution. Enough to trigger the same change more than once, resulting in never ending process, usually finished by PHP timeout instead of expected flag about completed migration.
Well, it have influenced some website owners, fortunately not a large amount (out of around 10k users) as the bugfix was introduced at most an hour after first deploy. Nevertheless, I managed to DDOS not only some of our users, but also main website of my own company 😅
What did I learn? When it comes to database, always proceed with the highest caution and generally befriend with mutexes.
With Wordpress plugins you need to be really careful :)
Very useful thanks for sharing
Hey there can you help me with php and my sql connection with website