My smaller team settled on Asana and I really like it. It's much more approachable than JIRA, and while not as powerful, much more so than Trello. Subtasks/relating tasks to other projects is great and I can easily see a birds-eye view of my upcoming pipeline (referencing tickets on other projects) at any time.
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
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.
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".
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?
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.
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.
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.
True. Don't take this the wrong way: As a programmer, I would also add that it was a pleasure to work with a real UX API again, and not have to deal with HTML's crazy issues, centering text, jQuery, browser incompatibilities, etc. I always had a <div> that didn't quite work the way I wanted.
In the end, a native app looks much better for fewer lines of code (assuming you can stand Objective-C).
Yup. Just unsubscribe from the popular sub reddits like pics, reddit.com and focus on technology, science, askscience and reddit is still as good as ever.
Because it is easier to create slapstick than meaning.
Humor may be a part of life and discourse, but in certain cases, and especially on the internet, it distracts from the real issue at hand, as most slapstick fails to convey meaning. If you can make me laugh and then think, then more power and karma to you, but most of us are unable to produce such witty insight on the fly all the time. We try. We fail, and we spam. That's why HN doesn't like slapstick jokes. If one person starts using slapstick then it creates a chain reaction that distracts from the real issue at hand.
Such slapstick doesn't create meaning. It ends up destroying it.
Except that it at least prevents the discussion devolving into a long chain of jokes, like you see on Reddit, and generally keeps this kind of thing to a minimum overall on HN.
There's a place for those chains of jokes, and that's mostly on Reddit (which I enjoy browsing often). But I would prefer to keep the discussion here on HN a bit more meaningful.
I think mkr-hn's point, though, is that Reddit may have joke chains, but HN has "tell-people-why-they-should-not-joke" chains. They're probably both equally time-wasting (this whole thread is a good example, and yes I'm aware of the irony of adding to it. Shit happens.)
I don't want to speak for him, but I'll give my opinion of why:
Reddit tends to be overrun with memes and jokes, and HN has always been more about lively discussion and facts. Reddit used to be like that a couple of years ago.
I like good jokes, but when I want some, I go to bash.org or the like ('Humour' folder in my GReader has more feeds than 'Technology'); but HN is not for jokes, it's for good discussion, so let's keep it like this.
