• 8 Posts
  • 93 Comments
Joined 4 months ago
cake
Cake day: June 2nd, 2024

help-circle






  • ever had to rebuild a sprint because Jira failed to properly migrate the old cards over to the new one, but instead throws them all into the backlog randomly and now you have to hunt them down over the next hour?

    No, never. Did you maybe not select the ‘move to new sprint’ option when closing the old one?

    how about when you’re writing an update to a card and you’re two paragraphs in with log examples and the UI decides to dump your entire content when you accidentally click outside the wysisyg?

    That has never happened to me, either.



  • Is this not rude:

    I checked the code and I’m appalled. There are more BLOBs than source code

    No. The commenter is voicing their own feelings and explains why they have them. There is neither blaming nor rudeness here.

    And this:

    I understand that removing BLOBs isn’t a priority over new and shiny features. But due to recent events, this should be rethought.

    It would have been nice if you had explained why you think this is rude. The author expresses understanding that the maintainers’ priorities don’t align with the author’s. This seems to be an uncontroversial statement to me.

    Then the author explains (I agree, it’s more a hint than an explanation) why they think the priorities should be changed. In my view their argument is sound. Again, there is no blaming or rudeness here.

    They should have opened with a complement

    I assume you mean “compliment”.

    I’ve often heard of the “sandwich technique” – start with a compliment, then voice criticism, end with another positive thing. I find this is an appropriate procedure when voicing open feedback, that is, good things and bad things. However, this is a Github issue. Its whole point is to point out a perceived problem, not to give the maintainers a pat on the back or thank them.





  • Teach this to your manager: At the beginning of a task, uncertainty is highest. Under no circumstances should you give an estimate in ‘man-hours’. Even days is too precise. The first estimate should be in months or years (of course depending on the size of the project). Then, as your insight into the project grows, you refine that to months, then weeks, later days. A vague estimate with a lower and a higher bound is way more useful to your manager than a ridiculously ‘precise’ but highly speculative number.

    This lesson was brought to you by either “Code Complete 2” or “Rapid Development” by Steve McConnel, and by my former manager who wanted projects estimated in minutes.