Hacker News Reader

Comment by gruseom | Hacker News Reader

Wow, this is a superb article that resonates with me as much as anything I've ever read on the subject. It practices what it preaches, too. Reading it made me feel the very things it's talking about.

I sense, though, that the author's tactics for working with teams that don't share his values are half-measures. It reminds me of the large and sad literature on "organizational change" in software development, wherein people trade stories about how to cajole managers into letting them do fragments of good engineering. None of that works very well. The satisfying solution is to be part of an organization that values good engineering in the first place.

Similarly, a designer like the author would be better served by working with–I'm tempted to say better engineers, but that's my bias–engineers who feel the same way that he does about product. These exist; I'd consider myself blessed to collaborate like that.

View on HN

...engineers who feel the same way that he does about product. These exist...

Unless my personal experience has been wildly unrepresentative, software developers tend as a group to be almost obsessive about getting fine details right. We’re the guys who worry about whether our design will be as easy as possible to maintain in the face of arbitrary future requirements or whether using some clever data structure would have given 0.07% better performance. We know, rationally, that sometimes our work is good enough and that we need to move on to other useful things, yet still there is a little voice in the back of our heads telling us we should have done better.

If I were to pick one other group who tend to exhibit the same trait, it would be designers. There ought to be a natural camaraderie here that makes it easy for little details to get done right. If that’s not the default outcome, and probably something that people in management and sales regularly have to balance with pressure to ship, the first question should be why.

To the developer, every decision is a trade off, a tension between the demands of the now (features and time) and the demands of the future (elegance, maintainability).

Designers are not in a good position to appreciate the trade offs. It's very easy for a designer to think 'this infelicity decreases delight, and fixing it involves just moving this thing to there'. This is probably an excellent spot of a real design issue, but that isn't the only thing that determines whether the work should get done or not.

I have no solutions, but problems like this are generally because of an insufficient appreciation of the other professions challenges, and if you're working in an environment with skilled practitioners of both disciplines, more communication is likely to fix it.

Here are some suggestions that might help designers talk to developers: Never use the word 'just' when talking to developers, frequently apparently simple things have huge ramifications and just as a designers specialty is understanding how the little things create a full experience, a developers specialty is understanding how little changes affect other things in the full system. Talk to them about the effect you're aiming for, rather than just the change itself - if the change is trivial, the worry is that you're not respecting their time, but if you convey that the trivial change will have a large specific effect then they will understand and may be able to do other things proactively to help you achieve your effect. Show that you care about more abstract values such as 'maintainability'; the ability to add features quickly in the future and having a low bug count are both massively beneficial to the user experience. Where you can, show that your fixes are not merely matters of opinion but are based on empirical evidence, good developers respect evidence. Get involved early in the process and talk regularly to the people implementing the design - show that you care about their opinion, but educate them in seeing things from another viewpoint too.

As a developer, you are probably used to having a discussion with the person who reported a bug for technical issues. Do the same for design issues - even if it's just 'move this button three pixels', talk to them about it, find out why it's important, find out if they really mean that it needs to align with some other element. If you have a legitimate reason to not want to do it, explain the problem - you might be able to work out a better solution together.

Never use the word 'just' when talking to developers, frequently apparently simple things have huge ramifications

Sometimes that is true, and that is so whether you’re talking about changing a design or changing the underlying implementation, and whether you are talking about web design/development or software development more generally.

Having said that, if a designer can’t request and a developer can’t implement trivial changes that really are as simple as shifting something by 3px, most of the times that means at least one of the following is true:

1. The person who implemented the previous version wasn’t very good.

2. The person who implemented the previous version was pressured to take short cuts in order to hit time/money targets and produced work that wasn’t very good.

3. There is some more general problem with the development process that means a designer requesting a trivial change and a developer then making it are expensive when they shouldn’t be.

Obviously there could be exceptions where that 3px change has much wider implications for the overall layout, but I don’t think those cases are really what any of us are talking about here.

The point is that if you use the word 'just' you're saying that you already know that the change is trivial. Perhaps it is, perhaps it isn't. Show respect to the person who will implement it by letting them say whether its trivial or not.

It's absolutely true that moving a button 3px should be trivial, but it's also true that things are often not as they should be.

I agree with your fundamental point that making the assumptions about what colleagues will have to do can be dangerous, though I would still challenge your earlier suggestion that apparently simple things “frequently” have huge ramifications. It’s sensible and polite to acknowledge the possibility, but if trivial-seeming changes are getting push back more than occasionally, IME that probably indicates a more serious underlying problem with how the project is being built.

Reply on news.ycombinator.com