Lessons from Design School for Software Engineers

https://stackoverflow.blog/2019/10/09/lessons-from-design-school-for-software-engineers/

by ingve • 7 years ago

136 16 7 years ago

lesson #6. quit design school and buy $100 worth of course work on Udemy.

ahuth• 7 years ago

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.

__jal• 7 years ago

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?"

rahimnathwani• 7 years ago

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.

pavlov• 7 years ago

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.

aswanson• 7 years ago

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.

gwd• 7 years ago

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.

zeroxfe• 7 years ago

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.

ArtWomb• 7 years ago

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.

superhuzza• 7 years ago

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.

novok• 7 years ago

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.

jorblumesea• 7 years ago

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.

watwut• 7 years ago

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.

MrGilbert• 7 years ago

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.

collyw• 7 years ago

Any advice for dealing with co-workers that are too attached to their code?

bluesnowmonkey• 7 years ago

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.

Lessons from Design School for Software Engineers

Related Stories