I've been the core dev on an 18 person team, I wrote 80% of the jira tickets and did about 35% of the code. 6 month of coding project to first launch. I used jira to remember. I wrote tickets for missing features, kludge's and bugs to be fixed, etc. I yelled at the managers to prioritize and estimate faster so I would know how on track we were or if we needed major strategy pivots.

Yes I'm an assembly line robot and the plant foreman. Jira and delegation helped me pull off both

Totally. I actually don't know how people that work in big enough organizations can possibly not like Jira (or a tool like it).

I would go crazy with the amount of things I would have to remember, their status, how to prioritize, how something was previously done and when, etc.

You'd probably end up recreating a rudimentary version of it in a spreadsheet

Pretty sure that's what the majority of programmers are. I know I am. My identity isn't wrapped up in programming. I build stuff for a company that pays me lots of money and then I go home and do stuff I like.

We need to get rid of this wild west mentality where disorganization is lauded.

> My identity isn't wrapped up in programming.

Fair enough and quite common I suppose. Generally for some a job is just that, for other (perhaps just some lucky few) it's a calling. I'd think the share of the former was large among programmers ("coders") in the early days of computing, when that wasn't a highly regarded job (seen alike data entry). Then a few years after the micro computer revolution, many of those who grew up and where fascinated by home computers entered the work force. Those you essentially just needed to feed and perhaps point in a direction. Then the Internet bubble happened and many realized that there was hard cash to be earned. There we have the career IT guy (who's just as happy to do something else which pays at least as much). It's not that they perform worse (in situation where discipline and organization is paramount they can be expected to outperform geeks), but the work style is quite different.

> We need to get rid of this wild west mentality where disorganization is lauded.

I don't think people celebrate their lack of discipline, but rigidity stymies creativity (and don't ask me how long it'll take me to fix a bug). I don't think Silicon Valley happened accidentally in California rather than in Prussia.

This doesn't refute the GP's point though. I've done both the very light management and very heavy Jira, and Jira makes it easy to track what's actually going on. If you want to know what a coworker is doing, you can just check Jira. If you need more work, you don't have to go to strategy and take their time, just look at the backlog.

> Jira makes it easy to track what's actually going on.

No it does not, and I said that above more than once. it makes it easy to track what's in JIRA, that's all. To the extent that it's accurate, it constrains what's "actually going on".

Exactly.

What's going on is commits and merges.

They live in GitLab. There is also tickets in GitLab, which all developers are happy to use. There is a wiki as well, which, gosh, is just markdown in another repo! Markdown you can build beautiful PDFs from! And websites!

But nope, we need JIRA and confluence, because for some reason GitLab isn't good enough. Now the tickets are separate from the actual work, there is another platform with a complex and slow ui, and our docs formerly markdown are now in some proprietary confluence RTF, which can export to word and PDF - with no custom styling.

I haven't used gitlab's wiki specifically, but the reason why you would use something like confluence is because you get a wiki with a wysiwyg editor, so less technical people can use it without having to learn markdown and there is less friction to making docs. It's not specific to confluence.

Hell google docs would probably beat confluence in a corp if they let you make a wiki structure out of it vs. it's current 'pile of documents' organization model because it has a better wysiwyg editor and inline comment system.

I'd argue that Markdown is easier to learn than confluence wysiwyg, and also more useful in the long run. Especially as there are many GUI Markdown editors with buttons and preview windows, that give you best of both worlds.

The constraint for the org I work in is that GitHub has a per user license fee that makes it difficult to justify getting a license for everyone in the org since we have a lot of non developer staff. But everyone has access to confluence/JIRA. Does Gitlab also have similar license restrictions?

GitLab is an Open Source software that we host ourselves, no BS pricing scheme that silos the company unnecessary.

Do you prefer to... not have all the details in front of you for a task you're about to work on?

Generally as a senior dev part of your job description is to figure the details out. Not have them provided for you.

As a jr or early mid level you can expect to have the majority of the details ironed out and nicely laid out for you to work on, but someone at some point had to actually figure it out and put it in the ticket. Whether that is you or someone else likely depends on your level, the stage of the company, etc.

edit: anyone who is downvoting this, please leave a comment with where you disagree. i'm unsure if i'm being received negatively on content or on tone

I agree with your assessment, having experienced a gradual shift from junior to senior myself.

As for why the downvotes, hypothesis 1: People might misconstrue your position as "senior ICs are supposed to design the system entirely on their own". I understand you as "management provides the direction and some design constraints, seniors fill in the details, juniors just implement specifications from the seniors", which matches my experience.

Hypothesis 2: Maybe it's a culture thing? I'm guessing from your user name that you're from Europe, and I'm from Germany. Maybe the downvoters are literally coming from a different place? (Don't know how it would be different over there though.)

Generally the details have been sorted out at some level otherwise how did you estimate it? And the ticket was likely estimated 2 months ago and you may not have been a part of that. I prefer a ticket with as much detail as possible so I'm not making the wrong assumptions.

Of course there are details to figure out. Why wouldn't I want all the information from design and other teams in front of me when I'm figuring those details out? I'm struggling to see why a detailed ticket is a bad thing.

> anyone who is downvoting this, please leave a comment with where you disagree. i'm unsure if i'm being received negatively on content or on tone

I would, but that's a detail that a senior dev like yourself should be able to figure out without people just providing it for you.

Theres worse things to be than a highly paid assembly line robot that also likely has vacation time, health insurance, a 401k and the option to walk away from one factory to work at another.

And certainly there are better things.

Sure, with probably very different stability and risk profiles as well as entrance requirements.

How do you prefer to gather the context for something that may have been hashed out months or years ago by different people?

The idea that a task can and should be "hashed out months or years ago by different people" is part of the JIRA mentality. And it is absurd.

I dislike Jira, but it's quite untrue that it's absurd that there needs to be context and a record of discussion for tasks. People leave, focus changes, memories fade.

It's not a unique occurrence that I wonder "why the hell is it done like this?!" only to find it was a decision I was part of with developers who had left in a least-worst-change trade-off. Jira or products like it help us avoid repeating the same mistakes.

Put another way, part of the art is not just the code, but the code that's not there. Jira/tickets are one way of managing that data.

And at other times, it's just a tool for bureaucracy, I get that.

heh you would be surprised. I literally closed a ticket from 2014 this week which had a lot of relevant information and prior discussion. Without the record of it somewhere I would of had taken much more time.

I also always search jira for a particular issue that I am having to see if someone else has already solved it or a reason for it not to be solved. Sometimes it works quite well saving me a lot of time.

... have you ever worked on a project involving multiple teams?

I say this as someone who loathes JIRA but still exists in the real world where you need to collaborate to design something.

You might actually be the assembly line robot if your work is so simple that you can do it without any sort of planning, design or collaboration.