Comment by jmclnx
3 years ago
When it comes to business (corporate), you hear "do it right". But in reality that means "do it fast even if wrong". If mistakes are made, what happens depends upon management.
In most cases, I have seen people who do a project 100% correct, sometimes slightly slower get ignored.
Other people who get it done fast, even with many blaring mistakes, get rewarded. Usually the people who worked on it end up working 24/7 to get it fixed. That is looked upon by most managers as very good work.
If your projects go live without issues, it is usually forgotten, people who fix their own issues by putting in fixes after go-live by working 24 hours, get noticed and rewarded.
graphic designers sometimes ship their draft deliverables with 1 or 2 obvious bugs, and allow the customer to recommend these 'changes' on their own for final delivery. and if they don't, they're just fixed for final delivery anyway.
i read about it before i had this done to me for the first time, and i played along with it. it's a neat trick because it's plausibly deniable for everyone involved and the outcome is good while minimizing the bullshit work in favor of a sacrificial final word.
I've done this in hardware design, presented a design for review with a problem that had already been discovered and had a fix in progress. It was a red herring that gave the customer something to latch onto and feel like they were contributing to the success of the project. Somewhat dishonest, yes, but very effective in getting customers to work with you rather than be adversarial.
There is a concept of a sacrificial feature to prevent customers from becoming fixated on other aspects of the design that would actually create problems if changed. I prefer to avoid that sort of dark pattern though because it erodes trust.
"The Queen's duck"
https://bwiggs.com/notebook/queens-duck/
I’ve also done this, with both visual design and software.
It’s a deliberate canary - if the client didn’t comment on the obvious mistake/bug, I know they didn’t actually look at it.
Yes, but more importantly, it solves the problem of ritualistic feedback, which is very common. People think it’s their job to produce suggestions no matter if they have any or not. This gives people license to provide harmless feedback while adhering to the religious framework.
Code reviews is a great example of this, of course. You’re supposed to comment something, otherwise how will people know that you are smart and did your job? Famously, the most straightforward code changes always gets some comment to change something stylistic or menial.
This was known as adding a 'duck'. It is unfortunately very helpful when your client stakeholder doesn't value your expertise as much as they should. It works for web design too, but you must be careful that your duck doesn't become a feature!
This is a weird thing to tie to graphic designers. Just because you noticed a graphic designer doing that doesn't mean it's a thing that's more commonly practiced among graphic designers than any other trade.
It is.
The reason is most people can tell red from green and big from small, and most people use graphic designs daily, so will have an opinion on whether a design element should be bigger or redder.
Other professionals with a similar plight could be copywriters, and devs when selling a PR.
Compare to plumbers or lawyers.
1 reply →
We've all read the duck story, but it was probably bullshit, and nobody does that
I do that, and it (usually) works.
1 reply →
The fact of the matter is unless your company is very mature, getting 3 big features to prod in a month even if that means bringing down some system for awhile is generally much more valuable than getting a single feature out with zero downtime.
As the company and number of devs grow, the probability of a dev doing something stupid increases substantially, so those early mistakes can actually be quite valuable in showing where your infrastructure has gaps.
Let the imperfect code happen early, it often leads to free chaos-testing and more stable infrastructure.
How can you distinguish between "project is not important/forgotten and due to that, no issues are discovered" and "there are no issues, so it is forgotten"?
I encountered this in a previous job. I told them during design phase the implementation was failing basic computer science knowledge and would cost the company a lot of excess computing costs (due to redundant work).
a quarter after launch it was a crisis because $5k a month customers were costing $50k a month in compute. The original designer put in some patches that got it down to $25k, and then $3k and was a "hero". By my estimates the limit of the actual work being done should have been < $500. But we didn't have time to implement that due to a quarterly insistence and folks all nodding their heads at eachother to get promoted.
In the end he got promoted and i got a negative review for not being a "team player" (ie being disagreeable about a design I knew had undesirable properties)
> told them it was failing basic computer science knowledge
> i got a negative review for not being a "team player"
Effective communication is good for your career. People don't want to work with someone who slings distracting insults.
You can say "This will cost $50K, but we can't afford more than $5K, and I think we can do it $500", or "a 10x customer will cost 100x to serve, but a different design can bring that down to 10x".
SaaS without the sass.
2 replies →
Unpopular opinion: I find with long projects that development speed later on depends a lot on whether we made good decisions early on. Stopping to figure out an architectural thing can make things easily changeable later. Keeps your speed up, even a couple of years into a project.
"Do it fast" feels really, really good. It's motivating, and you feel like you're pushing forward. But it can really slow you down in the long run. Eventually, everything's so coupled that it takes weeks or months to add new features or fix bugs because you can't touch anything without breaking five other things.
As a mentor-of-sorts once told me, you end up feeling like the street sweeper after the parade
Of course, this is only rational if you know what you're building ahead of time, and that you'll need the things you're preparing to build
Agreed. In the same vein I have seen this approach work well too: "make the issue a big deal, then be the hero that fixes it"
If you just fix it business as usual.. or prevent the issue then noone will care about you.