Hacker News Reader

Comment by ahuth | Hacker News Reader

As a software engineer, I've always been fascinated by the amount of critique that designers go through with their designs. While we do have code review, I'm not sure our architecture/design choices go through the same level of scrutiny. And I wonder if we'd be better of if it did.

Having said that, I'm sure it's a double-edged sword. No one wants to feel like someone is tearing apart their code.

View on HN

The last couple times I've made big architectural decisions that would be expensive/impossible to change, I've bounced it off of a small number of trusted folks first. This is almost nothing like a formal critique like you see in the arts, and I do think formalizing it a bit more could be useful.

But yes, one of my first reactions to a lot of bone-headed choices I see is usually, "nobody noticed that X would happen?"

Some places have 'engineering design documents' which are written early, shared widely and invite comments. It's much cheaper to spot issues at this stage than once a lot of code has been written.

I always write a design document first for anything larger than a few days' work. A few pages of prose is enough, written in Google Doc or Quip or whatever is the comfortable sharing+commenting standard within the org.

Even if nobody else ends up attentively reading the document, it's valuable for myself as a point of reference after the work is done. It can be humbling to go back and read my own assumptions.

Usually some of the text can be transplanted into more permanent engineering documentation (Wiki or whatever), so it's also a good habit for documenting beyond just inline comments.

Tech companies tend to have software designs go through a lot of review and scrutiny, with the bigger ones requiring presentations detailing costs, tradeoffs, risks, etc. It's definitely a double-edged sword, and helps to have thick skin.

I used to feel that way. Now I invite criticism, it's great for learning/perspective-shift and saves you from fielding bugs. Detached humility is best when you're doing iterative/evolutionary work, which software development inevitably is. As long as it's constructive, have at it.

I feel the same way -- in fact, now when I'm writing code for my own projects, when I have to make a risky or unclear design decision but I don't get feedback, I feel almost naked. There's something very reassuring about having people go over your code with a fine-toothed comb.

There's even a machine intelligence agent that will critique your logo online ;)

https://brandmark.io/logo-rank/

Some of my favorite posts online are of the sub-genre: company rebrands all design elements, and a well-respected design professional offers genuine critique. I also love reading about process at elite design firms like Pentagram, and how much thought (or emotion) goes into work.

I think a trusted online channel where you could solicit critique for UI / UX experiments online, perhaps through synchronous live video, would be cool. It would probably be invite-only, heavily moderated, etc. But the benefit is input from use cases you yourself would never dream of. Naturally, double edged sword.

Us designers actually do use a system like that to get UX feedback. But for the most part, we pay users to do it over a platform usertesting.com. There are a few reasons we pay participants:

* We want to recruit certain demographics, which most would not overlap with people hanging out i developer channels online.

* Recruiting participants and filtering them is very time consuming - we can run way more tests by just paying participants

* We don't always work on 'cool' systems - not many people are interested in testing a checkout flow or employee intranet.

* Testing flows and providing feedback can be time consuming and tedious, which leads to dropouts. Paying users generally ensures they actually try to finish the tasks and provide feedback.

Live video (generally moderated testing, with follow up questions from the interviewer) is done sometimes, but logistically it's quite hard and often more expensive. Generally speaking it's easier to set up unmoderated tests, that are kind of like an interactive survey overlaid on the application being tested. With this method you can still do screen capture and an an audio/visual track of the participant giving their thoughts.

A bunch of companies have a design doc or RFC process for major changes that they send to the rest of the relevant engineering organization. It's partly a feedback mechanism, partly a notification mechanism.

> No one wants to feel like someone is tearing apart their code.

From my perspective, not everyone is able to conduct a code-review, even if the knowledge is there. As a reviewer, you should be able to communicate in a way the person being reviewed doesn't feel "bad". It's not easy, and you definitely need to know the person who's code you are reviewing.

Do you not do design docs? This seems pretty common across the industry. Write a doc, send it out to the team, have everyone comment and review, schedule a meeting.

Three people fix some typos. Two will start bikeshed to death of some side detail to show they participate. One will have remarks that amount to "look at how smart I am" that are tangential to document.

And maybe one will read and review it as much as it is possible.

Reply on news.ycombinator.com