Please tell me it doesn’t still happen when you emulate a different day of the week. Or is that non-trivial to even do because of technical debt? Either way, RIP weekends.
If we reject the theory that it could be someone’s elaborate revenge, Saturday may be the first day of the week that may become workday or non-workday because of incorrect assumption about the first day of the week. If everywhere but one place in your software the day numeration is correct it would be a hard bug to spot.
Also, if it is in Java, I vaguely remember there being a lot of ways to express weekday, so a lot of ways to shoot off your foot (solely on Saturday)
For bonus points, this failure is in a cron job that sends out recently queued messages. It runs once every ten minutes - last weekend we had 12 failures: four were in a cluster on their own, one was in a run of two, and six were in a single continuous run.
Please note that this server is unused by our business so no messages ever get naturally queued. Every day we sync the live production server to this server at about 9 PM - assuming an employee was queuing up a message before the snapshot is taken there might be a number of unsent messages in the snapshot - those messages will all be sent by the first cron job after the sync.
It is a wonderfully awful problem that has me wanting to pull out my luscious locks.
Yup, luck is appreciated and I’m trying to get more eyes but unfortunately I’m a senior dev that has the second highest seniority at the company so I feel guilty dragging others into it.
I’ve always hated recursion. It’s always seemed like a cutesy programming trick that’s not reliable in all conditions.
You could blow the stack in an edge case that you didn’t think of. So it should never be a standard pattern. It’s only good if you need to rewrite something for optimization and recursion is appropriate. But in many cases recursion is slower.
“Look at what I can do in 5 lines of code!” is for programming contests, not for anything important.
I mean no, but also… yes? Like having a one person dev team is a little ridiculous for a game selling as well as Manor Lords. 50 people is a lot, but do you really think the game would have less features a year from now if the dev hired like 3 people to help?
Obviously development would slow down in the short term, but a one person dev team is asking for disaster
Ideally the solo dev and visionary would cease development and move into a product owner role. Bringing other devs up to speed on the code base while also maintaining quality, vision, and cultivating a team is no trivial task. Not to mention this particular dev may not want or be able to such things.
I worked for a loooong time in a medium size development company (about 200 developers, mostly doing large web portals). My team was some kind of central DevOps in charge of architectures, cloud, technology stacks… we were ALWAYS involved in EVERY deployment, and we were directly in full charge of the big ones.
After many years of constant work alongside the DEV/QA teams my team had gotten REALLY good doing deployments (we mostly sailed on each of them, since all was well tested, prepared and automated), and the project leaders simply trusted us. In the scarce occasions we said “sorry, this is not ready for prod” they knew it was true and didn’t pressured us. And our customers were happy, since needing a rollback was EXTREMELY rare.
One of the most important things we managed to agreed with all the team leaders:
Fridays are read only.
No, that doesn’t means we all can go home: Friday is now “Documentation Day”.
Of course, if shit hits the fan, we are ALWAYS ready to deploy fixes.
I think in about 10 years I only had one call on a weekend.
That “wet dream” was only possible after several years of hard work of dozens of people, and only because many other small pieces fitted in their proper place.
Hi, manager! You said you want environments for your developers without needing my intervention in every step? Of course, here you have infra and config automation: this is how you can create (and backup! and restore!! and destroy!!!) DEV, TEST, QA, PRE and DEMO environments, all ready with your specific stack and versions and code and data. And this is how much will it cost to you, and this is how you define a budget limit in case something gets out of control. Everything is repeatable and 100% reproducible in seconds, so please do not hesitate to test and test and test. (And no, sorry, I won’t let you touch PRO on your own, because that can cost a lot of money and we need to keep proper security).
So, you are asking me if we have heard about code versioning? Yes, of course! Here is a proper git structure, with predefined branches, segregated groups and permissions, and strict (and automated) revision requirements for every PR. I own the organization, you own the repo, QA owns the tests, and your developers own their branches and are self sufficient. Oh, and please remember we freeze the main branch 48h before the deployment, and time only begins counting after all the automated tests have passed and QA has given their final approval! No cheating!!
Oh, you have a picky customer who wants a guaranteed instant recovery in case THE WORST happens? Here you are, a highly available blue/green deployment, so you can deploy the new version without touching the old and only switch when everyone gives the final OK. And please remember to warn them it does cost DOUBLE the money!
Believe me, is not a wet dream, is just a lot of initial effort and A LOT of trust and confidence in the work of those around you.
And you have no idea how satisfying was begin work a Tuesday at 9AM sending a message “Hi, we are starting deployment in PRO” and then less than 5 minutes later reply saying “Hi, all is finished and checked OK from all parts, thanks to everyone and see you next week”.
programmer_humor
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.