• 0 Posts
  • 41 Comments
Joined 1 year ago
cake
Cake day: July 2nd, 2023

help-circle












  • Bullshit and it’s right there in your comment: devs are not the only ones capable of assessing difficulty. The entire team should be doing that COLLABORATIVELY well before any dev touches a keyboard. Code isn’t some arcane black magic and we’ve all built products before, heard these excuses before… so stop saying “that’s not your job, that’s not my job”. Not a good look.

    Suddenly declaring something is too hard and ignoring specs during the build phase is not a part of any dev’s fucking job, though you’d be surprised by the way they act.

    Which is encapsulated perfectly in your comment. You mention it’s someone else’s job to handle business direction problems while ignoring how the problem is actually the dev not doing their job to begin with. The product meets its goals by showing three points of data, but a dev said fuck it and only showed one. That’s not a business issue, it’s a “I don’t want to” problem. Just like in your comment, any issues with “business direction” did not exist until you cited it to cover up for not doing the work that was already planned.

    It’s not scapegoating to point out actual behavior. Behavior I’ve seen for 15 years and behavior you reinforced with your comment. You completely ignore the role of collaboration. It’s insulting to have a dev define your job in order for them to justify making decisions in a vacuum.

    It’s especially maddening to hear this after I’ve spent over a year working directly with the CEO and CPO on a new product, lead focus groups, spoken with 100’s users on the issue, designed prototyped and validated solutions with additional testing… all alongside dev leads to expose any concerns early on. The board is happy, the c-suite is happy, the users like it, and we’re all set except some jackass developer thinks that since they know C# no one else can weigh in on all of their reasons to just not build what the TEAM designed.


  • In my experience it’s been more like…

    UX: “users said they want these three pieces of info”

    DEV: “I typically only look for one of those pieces of info, so I built this to just show the one”

    UX: “users said they want three things for these reasons… only one isn’t as helpful and it’s not hard to add the other 2”

    DEV: “well how’s that supposed to fit?”

    UX: “like the designs already show”

    DEV: “well I’ll put a ticket in the backlog and someone can come back to it, if they have time.”

    PM: “I see no reason to prioritize slight “UX improvement” tickets over shit like new features or bug fixes…”

    REPEAT X1000.

    Then sit through months of user testing where people keep saying exactly what you are saying. “Why not add x? I guess someone thought it’s cleaner that way” but all these little pains add up to “death by a thousand cuts”

    Then everyone complains and scapegoats design.




  • Fireworks is a great example of why Adobe should keep its hands off figma.

    Macromedia built a product IN 1998 that had a lot of the features we take for granted in sketch, figma etc. today. Reusable symbols, a pixel accurate approach to UI design, “states” which were basically like how invision and figma handle hotspots and rudimentary prototyping…

    Then adobe bought it and sat on it, never really taking the product any further. All while the industry progressed and other people developed products like sketch and figma. Then adobe tried to copy that with XD, but never developed xd either compared to figma.

    Had the acquisition gone through I wouldn’t be surprised if figma then just withered on the vine just like fireworks. It’s clear the innovation is coming from outside of the house. _