I don't know if Telegram, Slack, Discord, GitHub Actions, GitLab CI, Jenkins, or Kubernetes will be around (or without massive breaking changes) in 20 years, but email absolutely will be.
> In industrial scale software development, gaining access you are fully entitled to can sometimes take weeks.
4 years in consulting. I've spent the first WEEKS of a project twiddling my thumbs waiting for a laptop, just to spend more weeks waiting on access to source code, tooling, etc.
My friends on the strategy side could start and finish entire projects in that time.
Sometimes it's not about doing nothing but only being allowed to do the same stuff over and over again to do because there is "no budget" to rewrite the codebase to automate the process.
I knew a guy who would brag that he used Outlook as his build system 20 years ago. Builds would take 9 to 24 months depending on the complexity of the project. But, as the CTO of a mid-sized software company, it worked for him.
Other than the theme, what's the difference between typing what you want into Slack and maybe getting it can typing it into ChatGPT and maybe getting it?
Memories of waiting for months to get access to a MS SQL database and ending up putting an Access database on a network share for multiple user access instead. A horrible, horrible hack solution. But it worked!
I volunteered at an archaeology lab run by the state govt a few months ago.
Knowing I was a data engineer, one of the archaeologists asked me to take a look at the cataloging system he’d cobbled together on his own: a shared-drive Access database with a full-featured CRUD interface that the whole office had been using for years.
I was able to clean up one stray bug he had, and confirm his suspicion that one particular action was running slow because it had to touch multiple files by necessity (he’d rolled his own sharding) — but generally speaking, it was a work of art more effective than anything I could’ve ever come up with. Sometimes the “dirty hacks” are the best solutions.
The best thing you can do in a situation like this is spend an enormous amount of time just documenting everything. Document all of the behaviors.
You will need that before you even start on any kind of a re-implementation
The avoidance of dirty hacks are not because they don’t work. They do and can be pretty X-effective when you’re short on X. But the end result is that when you need to switch away from the hacks, then the interest paid on X can be enormous. If X includes time, it may never be repaid.
> A horrible, horrible hack solution. But it worked!
I ended up building an Access app at an enterprise-y company I used to work at because it would have taken years for IT to build it. The app did something super specific and kept needing super specific additional features, and there wasn't anything on the market that met our needs. The Access UI talked to another Access database on a shared network drive. I just found out that it's still being used heavily by several people every day, 17 years later. You pretty much nailed it, Access is hacky, but it works!
Long ago, I used to work at some bank, where SVN branch merging was always super painful and instead of solving people problem, there was holy, e-mail based system running on our common dev machines.
After recieving properly formatted email, script was executed to apply git merge between svn branches.
In case of merge issues, the email was sent back with feedback.
If everything was okay, a proper sign-off blessing by one of the technopriests as late check was applied and merge concluded.
Unless that was a different project altogether?
Deleted Comment
4 years in consulting. I've spent the first WEEKS of a project twiddling my thumbs waiting for a laptop, just to spend more weeks waiting on access to source code, tooling, etc.
My friends on the strategy side could start and finish entire projects in that time.
Not necessarily worse, but the stereotype fits! You are, at least, soon doing tangible things.
I've gotten so bored at work lately I've been coding for fun again
I might be stupid, are you saying a build would take 9 to 24 months to finish?
Either its the wrong unit (minutes?) or the wrong definition of "build"?
Knowing I was a data engineer, one of the archaeologists asked me to take a look at the cataloging system he’d cobbled together on his own: a shared-drive Access database with a full-featured CRUD interface that the whole office had been using for years.
I was able to clean up one stray bug he had, and confirm his suspicion that one particular action was running slow because it had to touch multiple files by necessity (he’d rolled his own sharding) — but generally speaking, it was a work of art more effective than anything I could’ve ever come up with. Sometimes the “dirty hacks” are the best solutions.
I ended up building an Access app at an enterprise-y company I used to work at because it would have taken years for IT to build it. The app did something super specific and kept needing super specific additional features, and there wasn't anything on the market that met our needs. The Access UI talked to another Access database on a shared network drive. I just found out that it's still being used heavily by several people every day, 17 years later. You pretty much nailed it, Access is hacky, but it works!
Edit: grammar
After recieving properly formatted email, script was executed to apply git merge between svn branches. In case of merge issues, the email was sent back with feedback. If everything was okay, a proper sign-off blessing by one of the technopriests as late check was applied and merge concluded.
It was really fun using filters in Pegasus Mail (no SOAP) to automate mailing lists, PGP key signing with e-mail validation etc.
That's cute.