Lose a little credibility now, or a ton of credibility later? Sounds like a pretty short-sighted tradeoff, and a good opportunity to find a less shitty employer.
I admit that I'm currently in a position of privilege where I don't have to worry about immigration status or insecure housing. I do try to use my power to shield those less fortunate.
Precisely. I was remembering someone else's complain on a co-worker thay had. It was bad for this reason(s), and to make the situation even more infuriating they were able to sell themselves quite well. So they changed jobs, always 'capitalizing' on their frauds...
You're thinking like someone who exists beyond this quarter's profit margins.
I mean, you do, but as your boss, I'm required to tell you that you need to maximize short term results, and take all the responsibility for medium and long term calamities caused by me telling you to do that.
Hahaha, I'll do whatever you want boss, but you're sorely mistaken if you think you're getting away without a written record of you signing off on telling me to do stupid shit.
I feel like the "we don't know what this function does" meme is kinda bad. There's no reason beyond maybe time crunch why you shouldn't be able to dissect exactly what it does.
Despite this, the notion of a load-bearing function is still very relevant. Yeah, sure, you know what it does, including all of the little edge case behaviors it has. But you can't at this time fully ascertain what's calling it, and how all the callers have become dependant on all the little idiosyncracies that will break if you refactor it to something more sensible.
It has been several times now where a part of my system of legacy code broke in some novel fantastic way, because two wrongs were cancelling out and then I fixed only one of them.
even if you can figure out specifically WHAT a function does, it's not always clear WHY a function does, and honestly, if this function wasnt labeled in the code, no way in hell would I know what it does.
It has an entire wiki page dedicated to explaining it, and it involves enough math that most people wouldn't be able to follow along.
Nothing this atrocious lives in any current codebases I work on... but if you work at an old enough company, some of the load-bearing code will be tricky to figure out what is calling it, but also it was written in a time where little hacks were needed to eke out performance.
You only have to experience it once for it to be a memorable enough thing that you will cite it for the rest of your days.
Or more realistically, it IS comprehensible, but the level of effort necessary to comprehend it is not worth it. So you leave it as "undecipherable" and move on.
I feel like these memes have to (mainly) stem from badly documented or broken libraries. The only times where I don't understand what I'm doing are when I try to figure out what someone else is doing
The most recent library I wrote for my team at work is painstakingly documented, and everyone has been invited to the multiple recorded training sessions.
They still act like it's black magic and just push all work and questions to me.
Lol, welcome to the party. I'm not in a programming position, I'm on a systems engineering team. Most of my team mates can do some PowerShell scripting, but I have some programming classes under my belt.
I have a PowerShell script that is complex enough that I'm confortable calling it a program instead. Roughly half of the code is comments or logging the program flow. Every run generates a step by step log of all actions taken. I have 2 Word documents that summarize the process to different levels of detail, and a fucking flowchart for the visual peeps.
I'm still treated as the only person who could possibly flip the clearly labelled read only and route email to our team only switches and troubleshoot it.
To be fair, I recently learned during a vendor meet and greet that the vendor's tech guy in the meeting had previously made a consulting firm to sell exactly what I built this program to do. Probably means I'm in the wrong line of work.
Yeah, you can actually run C# code "inline" in it without having to compile to an exe, which is simulataneously really cool, kinda janky in practice, a bad idea, and pretty cursed.
There's definitely some weirdness with the syntax, and some odd footguns, but I've found those in most languages I've used for any considerable amount of time.
I work in an almost exclusively Windows environment, and the base version of PowerShell is preinstalled on all Windows stuff since I think Windows 7, with some really good integration with the Windows sysadmin tools. Not sure I'd reccomend it outside of that sort of environment.
I once saw something about how if you are trying to build it yourself instead of using a pre-existing library you come off arrogant.
Can I build it better? Probably not. But do I want to deal with a dependency in my fun side project (unfun), when I could just build it myself (fun)? No.
I probably should to get more practice with it so it is less painful, but…
If the tests pass, then everything is fine... Unless we expected the tests not to pass...then it's time to burn the codebase down and try again after a long vacation to clear our heads.
Of course, I'll usually settle for fixing the test suite after a long weekend. But in my heart, I'll know what I should have done...