Jumping on the "Jira isn't the problem" bandwagon, 99% of what people hate about Jira now is that the people who manage it make Jira hard to deal with.
I'm at an early startup and we use Jira; it's great because I'm an admin and I can make Jira reflect whatever I need it to reflect.
It's also highly compatible with compliance nonsense -- if you can say, "Every change to code is tracked in Jira" (the decision process not the literal diff) the auditor's eyes glaze over and they just move on.
You know, I'm currently using a monorepo concept for the backend of a project, and I think I'll soon split it up into multiple repos, with a shared base Docker container for the generated code they all share (ORM database models).
The problem with my plan is that I know from experience that making changes to the shared Docker layer is a pain in the ass to get it to propagate across your other projects as you're developing it, at first. Once you learn the incantations to chant, it's quick.
I just don't want to have to teach my team the incantations. It takes time!
If we get another round of funding and/or I find out I'll need to care about this project for more than a few additional months, I will likely make the switch, but at this point I can probably white knuckle my way into whatever exit we end up with.
And honestly, I think this is how the decision should be made; entirely dependent on a) your team and b) your anticipated future state of your work environment. No right answers here, just more or less complex ones with better or worse tradeoffs.
That's what World of Warcraft does, it has a Global Cooldown system to help account for unstable connections.
It's only 1 second or so, and lots of actions are off the GCD, but all you would need to do is extend that time and put more things on the GCD and you'd effectively get what you're looking for.
I don't think it'll slow things down as much as you're hoping for, though.
What you want and what is the best way to communicate are not always aligned.
And I'm not dictating anything, or being dogmatic and condescending, but I guess it's easier to think I am if you're trying to have an Internet Argument Moment.
If you think variable naming is the only tool in the “self documenting code” toolbox, I recommend learning substantially more before dismissing the concept.
I explicitly said not to write “why” docs to explain specific value choices, but rather document the context around the setting, and what happens when the value is raised or lowered, and why you might want to do that, so I’m thinking this isn’t a topic you’re grasping very well.
You’ll be fairly lonely if you reject working with everyone who’s read Clean Code, and truly alone if you won’t work with anyone who understands something better than you.
Care to elaborate on why your experience tells you this?
I’ve put this into practice numerous times with positive effect, so my more relevant experience tells me this is a winning strategy, compared to in line docs, which are objectively worse in nearly every way.
It's not faster because you can just name the variable whatever it is the value represents, so by adding a second descriptor (the comment) you're introducing needless complexity.
It's not better because you really shouldn't be changing a value you don't understand the context around, which means reading much more than a one-line comment.
You can just name the variable to explain what the number is, and if you need more info, there should be a "Why?" doc somewhere explaining the context generally, WITHOUT tying itself directly to the current choice (otherwise you'll have to update the "Why?" doc every time you update the number in the code, which is almost certain to go out of sync).
No need to interweave documentation and code, in most cases. Sometimes, when we fail to write good code, sure. But let's try to write good code!
You lose every battle when you leave a company. That's just something you have to accept. They get to put whatever narrative out there that they want, and you won't be there to defend yourself.
Why didn't I think of this sooner? Here I was, slaving away until 6-7pm every day, when I could have just got up from my chair and walked out of the building!
Honestly anyone who is passionate about which time to switch to has put way too much faith in the whole academia-to-reality pipeline. Those folks get shit so directionally wrong so often on more important things, I really don't think any academic's model of the consequences of ST/DT will be anything remotely close to complete.
We should all just chill, and be grateful for the relief.
Am I the only one who thinks this is well intentioned but kind of silly?
I don’t know a lot about this space, but I don’t know especially how many skills translate from offense to defense.
Is this basically just a call for folks to turn in their 0days and access or something? Seems wt least marginally more useful than trying to train up a bunch of script kiddies to fight GRU…