Dear Indian Companies,

Why do you hire for a role and then say: "We dont have that role but then we want you to grow up to be a Generalist"!

6 years as a build, release and SCM guy at Moto and Nokia back then, I shifted to this big Indian IT corp coz Nokia was shutting down...

A week into my orientation (which is a crazy weirdness inducing ritual in and of itself), the new manager I'm supposed to be working with comes up and says- "Here's the code repo, there are 2 open jQuery issues, fix them!"

I'm not really sure what to say at this point because jQuery is nice and all but thats not who I am.. I'm the infra / DevOps guy. And this is circa 2012 when DevOps as a term was just hotting up...

Tell me to setup a multi-stage pipeline and automated test cycles, I'll do it drunk, but oh no! bug fixing on a jQuery script? Noooo!!!!! I just dont have the chops for it.

So long story short, I get reported to HR for insubordination - Yeah, Go Figure!

Cue: HR meeting
HR: You wont work?
Me: I cant work on jQuery. I am a sysadmin / devops guy... Give me a project that involves those skills and I'll work.
HR: But we hired you to work on jQuery.
Me: But you did not mention jQuery / UI / UX in the job description - Pulls up email and shows JD for interview which says Symbian, Build, Release, Configuration Management but NOT jQuery.
HR: ....
Me: :-/
HR: But we want you to be a generalist.
Me: #wtf
HR: We want an engineer to be able to do anything he is tasked with!
Me: Can I know my last working date here?

And thats how my career at a glorious IT corporation just went poof!

When I think back on it, I feel good that I chose to do what I wanted to get better at and what I loved working on...

And this is the problem with IT companies in our country - They play with people's aspirations and passions... To the point that all thats left of a software engineer is the looking forward to pay day so he can start the damn cycle all over again.

Welcome back to practiseSafeHex's new life as a manager.

Episode 2: Why automate when you can spend all day doing it by hand

This is a particularly special episode for me, as these problems are taking up so much of my time with non-sensical bullshit, that i'm delayed with everything else. Some badly require tooling or new products. Some are just unnecessary processes or annoyances that should not need to be handled by another human. So lets jump right in, in no particular order:

- Jira ... nuff said? not quite because somehow some blue moon, planets aligning, act of god style set of circumstances lined up to allow this team to somehow make Jira worse. On one hand we have a gigantic Jira project containing 7 separate sub teams, a million different labels / epics and 4.2 million possible assignees, all making sure the loading page takes as long as possible to open. But the new country we've added support for in the app gets a separate project. So we have product, backend, mobile, design, management etc on one, and mobile-country2 on another. This delightfully means a lot of duplication and copy pasting from one to the other, for literally no reason what so ever.

- Everything on Jira is found through a label. Every time something happens, a new one is created. So I need to check for "iOS", "Android", "iOS-country2", "Android-country2", "mobile-<feature>", "mobile-<feature>-issues", "mobile-<feature>-prod-issues", "mobile-<feature>-existing-issues" and "<project>-July31" ... why July31? Because some fucking moron decided to do a round of testing, and tag all the issues with the current date (despite the fact Jira does that anyway), which somehow still gets used from time to time because nobody pays attention to what they are doing. This means creating and modifying filters on a daily basis ... after spending time trying to figure out what its not in the first one.

- One of my favourite morning rituals I like to call "Jira dumpster diving". This involves me removing all the filters and reading all the tickets. Why would I do such a thing? oh remember the 9000 labels I mentioned earlier? right well its very likely that they actually won't use any of them ... or the wrong ones ... or assign to the wrong person, so I have to go find them and fix them. If I don't, i'll get yelled at, because clearly it's my fault.

- Moving on from Jira. As some of you might have seen in your companies, if you use things like TestFlight, HockeyApp, AppCenter, BuddyBuild etc. that when you release a new app version for testing, each version comes with an automated change-log, listing ticket numbers addressed ...... yeah we don't do that. No we use this shitty service, which is effectively an FTP server and a webpage, that only allows you to host the new versions. Sending out those emails is all manual ... distribution groups?? ... whats that?

- Moving back to Jira. Can't even automate the changelog with a script, because I can't even make sense of the tickets, in order to translate that to a script.

- Moving on from Jira. Me and one of the remote testers play this great game I like to call "tag team ticketing". It's so much fun. Right heres how to play, you'll need a QA and a PM.

*QA creates a ticket, and puts nothing of any use inside it, and assigns to the PM.
*PM fires it back asking for clarification.
*QA adds in what he feels is clarification (hes wrong) and assigns it back to the PM.
*PM sends detailed instructions, with examples as to what is needed and assigns it back.
*QA adds 1 of the 3 things required and assigns it back.
*PM assigns it back saying the one thing added is from the wrong day, and reminds him about the other 2 items.
*QA adds some random piece of unrelated info to the ticket instead, forgetting about the 3 things and assigns it back.

and you just continue doing this for the whole dev / release cycle hahaha. Oh you guys have no idea how much fun it is, seriously give it a go, you'll thank me later ... or kill yourselves, each to their own.

- Moving back to Jira. I decided to take an action of creating a new project for my team (the mobile team) and set it up the way we want and just ignore everything going on around us. Use proper automation, and a kanban board. Maybe only give product a slack bot interface that won't allow them to create a ticket without what we need etc. Spent 25 minutes looking for the "create new project" button before finding the link which says I need to open a ticket with support and wait ... 5 ... fucking ... long ... painful ... unnecessary ... business days.

... Heres hoping my head continues to not have a bullet hole in it by then.

Id love to talk more, but those filters ain't gonna fix themselves. So we'll have to leave it here for today. Tune in again for another episode soon.

And remember to always practiseSafeHex

TFW your client's git policies are so draconian that the dev teams use "develop" as trunk, and completely ignore the release process.

I wrote up 50 pages of git standards, documentation and procedure for a client. Bad indian director 9000 decides the admin (also Indian) who specializes in Clearcase and has no git or development experience is more qualified to decide and let's him set the policy.

FF to today:

- documentation, mostly contradictory, is copy pasted from the atlassian wiki
- source tree is the standard
- no force pushing of any branches, including work branches
- no ff-merge
- no rebasing allowed
- no ssh, because he couldn't figure it out...errr it's "insecure"
- all repos have random abbreviated names that are unintelligible
- gitflow, but with pull requests and no trust
- only project managers can delete a branch
- long lived feature branches
- only projects managers can conduct code reviews
- hotfixes must be based off develop
- hotfixes must go in the normal release cycle
- releases involve creating a ticket to have an admin create a release branch from your branch, creating a second ticket to stage the PR, a third ticket to review the PR (because only admins can approve release PRs), and a fourth ticket to merge it in
- rollbacks require director signoff
- at the end of each project the repo must be handed to the admin on a burned CD for "archiving"

And so no one actually uses the official release process, and just does releases out of dev. If you're wondering if IBM sucks, the answer is more than you can possibly imagine.

Every year, my company organizes an internal seminar week for its engineers and developers. I helped plan it this year and, since I also ran a few sessions, was absolutely exhausted by the end of the week.

On Friday of that conference week (after I'd spent four hours in our engineering building), I come back to my desk to discover that a coworker managed to, single handedly, get our boss to agree to shortening our release cycle to one that, without dramatic infrastructure changes, would require about 8x the developer overhead than today's. ...The test cycle I am supposed to pick up in a month.

When asked about it, he said he was so full of energy, why wait for automaton? What better way to inspire us to improve than to switch right now? The worst that can happen is just a few bugs.

I love my job, but I can't stand this guy. 😒

Excerpts from "Bastard devops from hell" checklist:

- Insistently pronounce git with a soft "G" and refuse to understand people not using that pronunciation, the same goes for jithub, jitlab, jit lfs, jitkraken etc.

- Reject all pull requests not in haiku format, suggest the author needs to be more culturally open minded when offending.

- increment version numbers ONLY based on percentage code changed: Less than 1% patch increment, less than 5% minor increment, more than that major version increment.

- Cycle ALL access keys, personal tokens, connection strings etc. every month "for security reasons"

- invent and only allow usage of your own CI/CD language, for maximum reuse of course. Resist any changes to it after first draft release

Quick rant!!

Deadline in 2 days, working with a team.

Me: yo ! , How's the xyz feature? Is it working now?

Teammate: yah, made it work yesterday.

Me: epic! Can you present it to me?

Teammate: wtf, it's not working today!!

Me: no worries, you can sort it out!

Teammate: the latest release you worked on doesn't work properly.

Me: yah, merged code fucked up, I'm fixing that, I'll push a fix today.

And the cycle continues...

Almost every release cycle

I dunno about coolest, but I did sort of cement my reputation as the "database guy" in my first job because of this.

My first job was with a group maintaining a series of websites. Because of the nature of the websites, every morning we had to pull the records from one database on one network, sneaker net the data to a database on another network, and import the data via custom data import function.

However, the live site would crash after 100 or so records were imported. The dba at the live site had to script out a custom data partitioning script to do his daily duties, but it definitely messed up his productivity.

Turns out, the custom mass import function had recycled the standard import function, which was only used to import 1 record at a time, and it never closed its database connections, because it never needed to. A one line fix to production code was delivered 6 months later (because that was our release cycle) and I came up with the temporary work around, which was basically removing the connection limit. It would still crash with the work around, but only with multiple days worth of data. So basically only on Monday. Also developed the test set for the import (15k+ records).

I am back after 5 years

It's been a long time

After working for a shitty company, I ended up working for a startup for an interesting big project as a software architect

It was a good experience just for some stuff, but I hated every moment we needed to build some demo or prototype for potential customers or allies

I was tired... 2 years of demoing is too much. And finally I got a Senior Devops in this company working in Kubernetes

I finally discovered my role and my position, I want to solve problems for other devs and myself. I help anyway in the final product, because fast and reliable build and release cycle need to be a must

I wish everybody could find their main role. I took 12 years to find mine lol

So I am working on a cloud app, Angular on the frontend and NestJS with heavy AWS dependency at the backend. I took my time to learn the stack and I have a couple of years of experience with each piece involved.
Since I am a Level 1 developer, management thought (and I felt same way) it would be nice for me to work with a couple of Level 3 devs.

Well, they hired Level 3 devs:
- a senior Java developer who never touched AWS, any kind of frontend or Typescript
- a senior c++ dev with the same “never touched” as above

And guess what? I have to train them both in Angular, Typescript etc. Kinda defeats the whole purpose of L3, “they will help you to deliver stuff fast”, and adds load on me (I am already a shared resource on 3 teams).
Oh, and yeah, management already promised to release the app by the end of the year and so far I am the only capable and functional developer on the team who has to deliver everything.

I had so much hope for new hiring cycle lol

Meanwhile, inside the kernel of my device that has a relatively frequent release cycle...

if (!isLatestVersion()) {
forceUserToUpgrade();
}

forceUserToUpgrade() {
extraSleepForCpuSoDeviceBecomesSlowAndUnusable++;
}

How long is your operation system running?

Linux - since the first kernel release I've ever touched.
Windows - depends on the update cycle, mostly 2 weeks up to 6 month.

And there goes another night with reconfiguring my windows session 🤬.

Today we had an hour long meeting on gitflow. The senior developer who felt compelled to arrange this meeting, during his demo couldn't figure out how to merge a hot-fix. "But you guys know what I'm talking about, right?" *Forehead=>Brick-wall*

If I wanted to lose brain cells I'd just start doing drugs, at least it would be more fun.

It's kinda inpressive to me how everything comes to a standstill, as soon as Jira goes offline, because it's been overwhelmed by stuff going on.

Me and another colleague are waiting for it to get back online, so we can annoy the devs with defect reports again.

Which inturn were due a while ago, but the deployment for testing them wasn't done the whole time, so it was not possible to test anyways. And ontop all of that most of the tests failed, so there are a ton of defects.

Fixing them and bringing the tests on PASS has to happen until tomorrow, because that's the deadline for the release cycle.
Ah and it's roughly 45 tickets.
The next release cycle is like in two Months

You know... the usual stuff 😂😂

Sad because I was performing an extensive code integration of a release from an external source and then an employee from another building integrated another release before me
Now I need to request a new release with the bug fixes and it will take various days, maybe weeks (and if another release is integrated before, the cycle restarts).

I might be able to integrate by the end of the next year. Who knows.

Currently in our 4th cycle of manual regression testing for a release and still finding bugs. Automated tests? What are those? That sounds an awful lot like it would take time to implement. Time that could be spent fixing the bugs and getting the release out the door.
When release dates take priority over quality....

Ok, So I am just fed up with these project delivery dates. These are the most irritating aspect of any project.
My current project is already delayed 3 times, because of the optimistic biases of the team lead.

Developers were forced to work over weekends. The QA cycle is taking more time than the dev cycle itself, and it's very irritating waking up with a new bug in the JIRA notifications.
Everytime we reach the delivery dates, there will be multiple bug items on each and everyone's plate that you just can't release the product.

I want to know if anyone feels the same ? How does your management takes care of these delivery dates ?

So this modeler on a Dev call, I have this new shiny model, let's release this to production mid November😳 (Seriously that's how he started out the first conversation).

2 min silence, everybody looks at each other for reaction, just like a TV shows !! 🤣🤣

And the my Manager lists out the things that would be required to before we ship this out.🤐

Modeler : Oh I guess we won't be able to deliver it this year.😤

I am like what were you thinking. Everything is not just import an Excel in R and crunch numbers and write reports and show graphs. is it?

There is a real development cycle that has to do all of the above on not so pretty data, at scale reliably for 100s of clients and not just your laptop.

The urge to get a tea, followed by the urge to release the bladder, followed by another tea...

Being a dev is a vicious cycle

Me in a Nutshell 😅

An Xubuntu user...

Wants to hop out of debian zone..
Does not like rolling release cycle..
Out of box support for proprietary s/w..
Argues with self and tries Manjaro..

Falls back to Xubuntu
End of distro hop 😇

Recently joined new Android app (product) based project & got source code of existing prod app version.

Product source code must be easy to understand so that it could be supported for long term. In contrast to that, existing source structure is much difficult to understand.

Package structure is flat only 3 packages ui, service, utils. No module based grouped classes.

No memory release is done. So on each screen launch new memory leaks keep going on & on.

Too much duplication of code. Some lazy developer in the past had not even made wrappers to avoid direct usage of core classes like Shared Preference etc. So at each place same 4-5 lines were written.

Too much if-else ladders (4-5 blocks) & unnecessary repetitions of outer if condition in inner if condition. It looks like the owner of this nested if block implementation has trust issues, like that person thought computer 'forgets' about outer if when inside inner if.

Too much misuse of broadcast receiver to track activities' state in the era of activity, apપ life cycle related Android library.

Sometimes I think why people waste soooo... much efforts in the wrong direction & why can't just use library?!!

These things are found without even deep diving into the code, I don't know how much horrific things may come out of the closet.

This same app is being used by many companies in many different fields like banking, finance, insurance, govt. agencies etc.

Sometimes I surprise how this source passed review & reached the production.