• 0 Posts
  • 142 Comments
Joined 2 years ago
cake
Cake day: September 10th, 2023

help-circle
rss


  • As a Data Analyst / Business Analyst, let me assure you: Not all of us are stupid (some are, for sure), but there’s only so much you can do about stupid managers. If they decide that a certain measure is key, it can be really hard to explain why it isn’t that important or where a certain distortion comes from. To compound this, some managers genuinely don’t understand their business processes and are unwilling to have it explained to them. They’ll make assumptions about how things work, then base their demands on those.

    For an entirely made up example, consider a department manager looking to monitor a software development team’s workload. That workload, to them, consists of bug tickets and feature implementations. Not counted here are feature requests because, apparently, fielding them and discussing their feasibility isn’t actual development work. That’s management work, which is the Product Manager’s job… Except the Product Manager can’t unilaterally decide whether something is feasible without consulting those actually familiar with the code, taking up the developer’s time. On the other hand, since it’s an internally developed tool for other units, they can’t just say No to every request or else they risk people calling their team’s funding into question.

    Now, you have the choice between frustrating yourself and annoying the manager by trying to explain all that, or gritting your teeth and just giving them the stupid chart on bugs closed and feature implementations completed over time. Guess which one is healthier for your employment prospects?

    And we haven’t even started talking about the variance in effort of bug fixes or about non-feature work for code stability or QA. Eventually, we’ll reach the point where the measure becomes a target and you have to start reframing bug fixes as features and splitting features up into smaller features just to make the figures look nicer.

    What I’m getting at is this: Sometimes, the analysts aren’t to blame, but the managers making decisions.

    That’s not to say there aren’t absolutely shitty business analysts out there that will gladly figure out ways to polish the figures and then cash the check for making the figures look better.






  • Approximation is an important tool for compressing information into useable forms. All labels are limited approximations too. Such compression is inevitably lossy, but that is a sacrifice for the sake of practicality. The important question is what level of compression is acceptable for a given context. If I describe the location of a chess piece on the board, I don’t need to specify how far off-center on its square a given piece is, so a 0-7 offset along each of the two axes is enough for game purposes.

    When it comes to gender, I think we all agree that [0, 1] is insufficient, but how do we determine what is sufficient? Do we argue that a 2-bit vector (masc, fem) is enough to describe {neither, fem, masc, both} for rough rounding, or do we need more detailed values along those axes, or perhaps a third axis too (or more)?