A poorly thought out and damaging post for a number of reasons. 1) It starts out creating a straw designer with a set of below-market skills that is easy to ch

A poorly thought out and damaging post for a number of reasons. 1) It starts out creating a straw designer with a set of below-market skills that is easy to chop down. If the assets as presented represent the entirety of what was delivered, I'd say they're weak for a just-okay marketing team and comically below bar for any product shop at any place with one of taste or money. This deliverable wouldn't get you a phone screen. It's not that your designer can't code... it's that they can't design. 2) The comps section makes some claims that don't hold up. A less technical designer can deliver mocks in the listed formats (PS, sketch, zeplin) that, in a competent design/dev environment, require NONE of "slicing, calculating, or converting to pixels like in the 90s." I had the marketing team at my last gig using sketch files that were templated out of the box with our grid system at every breakpoint, with plugins for our spacing units and typography that matched existing CSS implementations, so all you had to do was declare spaces, css color var names, etc. There's clarification to be done, and custom work in many cases, but for generic grid stuff like this? If you're repeatedly doing the same pixel snipping labor, your dev/design teams are dropping the ball on both comms and tooling. It's possible to have shared language/understanding here without designers needing to code. > If no design thinking there is no design system and code, project, budget, people gets bloated. This is tough to parse. I think it can be rewritten as "If there is no design thinking, there is no design system, without which the size of code/project/budget/headcount balloon." I think it's silly to pin that solely on non-technical designers and a lack of "design thinking". As engineers used to thinking about DRY/reuse/abstraction, part of our role is educating upstream teams about the principles from our domain that would make collaboration more effective. I find that designers are usually excited to have conversations about anything that makes their work easier, automated, or predictable. 3) "The task" starts with an assumption that I think is a pretty amateur one. It assumes that the object count in the mocks is the object count for the page, and not merely the number that fit in the viewport. He goes on to gripe about inefficient calls that fetch content that is then not displayed, when I strongly suspect that the designer here meant for the page to scroll and failed to communicate that explicitly enough. This is the designer's failing, but it's not reasonable treat one's assumption about ambiguous post count as an explicit requirement. It would take less time to clarify this than to write the post griping about it. There is a codepen. It is not mentioned whether the codepen was run by the designer for clarification. We do this routinely on my team. It irons out miscommunications very effectively. 4) It's not the role of the designer to imagine within the bounds of what's possible with CSS grid. CSS is a ridiculous and archaic language. If there are implementation difficulties, have an adult conversation about it. What are the underlying goals? Can you achieve visual separation another way? Is an element critical enough that templating should be refactored? There is no default right way to prioritize developer experience compared to user experience. If shitty grid code makes an extra $500k in sales, so be it. To be clear, I don't think these lines are that powerful or important, but "if you can't code it easily you aren't allowed to do it" is a limiting mentality IMO. 5) "The designer doesn't knows exceptions are painful and bloat the source code" ... I really stand behind this one, in general. While designers should not necessarily be able to write code, they should absolutely be robust systems thinkers that can design repeatable solutions. But "the ad requires a variation in the CSS grid" is just so freaking trivial. Given only the scope shown... come on. "Moving out of the grid will spare around half of development time and budget." yeah, half of... an hour or two, the poster estimates? This person didn't even get into the problem I expected them to: on fluid layouts, it's common for content to resize when ads can't, which can result in layout problems trickier than anything mentioned in this post, but that's a result of ad sizes being somewhat standardized and having third party constraints on their display. In complaining about the size disparity, the poster is revealing their own ignorance about the forces that govern the content they're working on. Of course the ads are different sizes. Have you _seen_ a website before? What's the desired alternative here? Set the layout units based on your ad dimensions? They mention moving the ad... great. Did your designer need to code to move the ad in response to layout constraints? No. ---- This person drafted an inarticulate tirade with scare-mongering statistics about trivial numbers ("double the time", "500% more") instead of having a clarifying conversation with their coworkers or attempting to build systems that permanently eliminate this class of hangup. They used a colleague's weak work to demean an entire profession instead of reflecting on their own role in a larger system. Further, they approach the whole thing through a lens where work quality is evaluated based on developer happiness without ever addressing business outcomes beyond their own domain. I somewhat regret spending my time to enumerate the ways that this sucks, but if it gets someone who agrees with the post to reconsider, that would be a good thing for everybody.