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.
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.
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.
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.
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.
> Have you ever met somebody who was always against exploring suggested changes to their code in a pull request? Perhaps they got upset if somebody else went in and refactored some code they worked on in the past?
There are at least three dynamics going in here that overlap and get conflated frequently.
1. Ego, inability to accept criticism. Obviously this is just something the engineer needs to grow past.
2. Sometimes another engineer not familiar with the codebase will do a drive by commit. They need to make a specific change and find the code around that change to be confusing, so they refactor it to be easier to understand in isolation. However they don't understand the idioms and patterns of the codebase as a whole, and the net effect is that the system as a whole becomes less coherent and maintainable. This creates both-sides-are-right arguments, like, "Yes you did give that variable a clearer name, except we use the other name consistently everywhere else, so if you rename it here you should rename it everywhere, and it's not really worth doing a such a big refactor and invalidating everyone's familiarity, is it?"
3. Familiarity. When you work in the same system for a long time, you develop a mental map of how everything works. That map can be a source of great productivity. Sometimes it's actually not worth making an improvement because it will necessitate the long term maintainers having to relearn how things work, and they have other things to do more important than this improvement.
[+] [-] ahuth|6 years ago|reply
Having said that, I'm sure it's a double-edged sword. No one wants to feel like someone is tearing apart their code.
[+] [-] __jal|6 years ago|reply
But yes, one of my first reactions to a lot of bone-headed choices I see is usually, "nobody noticed that X would happen?"
[+] [-] rahimnathwani|6 years ago|reply
[+] [-] zeroxfe|6 years ago|reply
[+] [-] aswanson|6 years ago|reply
[+] [-] ArtWomb|6 years ago|reply
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.
[+] [-] novok|6 years ago|reply
[+] [-] MrGilbert|6 years ago|reply
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.
[+] [-] jorblumesea|6 years ago|reply
[+] [-] bluesnowmonkey|6 years ago|reply
There are at least three dynamics going in here that overlap and get conflated frequently.
1. Ego, inability to accept criticism. Obviously this is just something the engineer needs to grow past.
2. Sometimes another engineer not familiar with the codebase will do a drive by commit. They need to make a specific change and find the code around that change to be confusing, so they refactor it to be easier to understand in isolation. However they don't understand the idioms and patterns of the codebase as a whole, and the net effect is that the system as a whole becomes less coherent and maintainable. This creates both-sides-are-right arguments, like, "Yes you did give that variable a clearer name, except we use the other name consistently everywhere else, so if you rename it here you should rename it everywhere, and it's not really worth doing a such a big refactor and invalidating everyone's familiarity, is it?"
3. Familiarity. When you work in the same system for a long time, you develop a mental map of how everything works. That map can be a source of great productivity. Sometimes it's actually not worth making an improvement because it will necessitate the long term maintainers having to relearn how things work, and they have other things to do more important than this improvement.
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] collyw|6 years ago|reply
[+] [-] hellothree23|6 years ago|reply