I work on the City side of the development world. We’re always getting screamed at for taking 3 weeks to review a plan set by the same developers who want to meet with me every minute of every fucking day.
I’ve got 40 projects in my review queue and all of them are demanding a weekly meeting. When am I supposed to do the fucking reviews?
When you talk to your management and show them how overworked you are and ask for a helper. But don’t just say how much, show them in business lingo so they actually understand.
Fill out your calendar with the meetings and show management how you have no time for meaningful work because of meetings.
I’m on the Municipal side. City Council ain’t gonna raise taxes to hire more people.
I’ll get burned out and leave soon enough. The longest-serving person in the development department has been here just over a year, and we pay nearly double what other cities in the area do.
After success with my senior project, developing a real game with a team of 15 that we’re releasing on Steam, which I feel really good about, I crave the experience of working in a team to develop a game. But of course, my hobby project is a nonprofit endeavor so I can only expect volunteers, and even though I feel I can get the coding down mostly on my own, I feel like I might be asking too much by hoping for an artist or few to join with me… maybe I just need to change up my approach, and offer equal shares of creative control, that way it’s not “help me make my game” so much as “join me and we’ll make our game.”
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”.
This is what I hate about squashing. I love the fact that my crazy journey to a finished feature is there in the log for everyone to see, including myself lol. But squashing makes me feel empty when I write commit messages. Where’s the fun… Just a straight line of perfectionism. Maybe someone has a crazy but cool idea that would be worth picking. 🍒
Maybe. I do more DevOps these days, so tend to have many small changes that can’t even be tested without checking them in and running in CI. I’d have hundreds of “fix unit tests” commits alone
We squash. I’m not really interesting in your local journey to land the change. It’s sometimes useful during review, but after that it’s mostly the state of the main branch I care about. It’s what I need to bisect anyway.
I don’t like commits that are just references to issues. Copy the issue into the commit message so git blame tells you something useful. Unless it’s just closing a simple big. Then the title and issue reference are plenty.
I’ve been thinking about that when talking to my DevOps colleagues, that there’s gotta be a better way to test CI before committing. The whole change-commit-test dance would kill me if on a daily basis. So cumbersome.
programmer_humor
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.