Hacker News Reader

Comment by dublinben | Hacker News Reader

The writer sounds like a crippling perfectionist. The world isn't perfect, and neither is any real program. It's an important step in your personal development to recognize and deal with that.

Perhaps they would be happier as a designer, where they can make everything fit into perfectly neat boxes.

View on HN

> Perhaps they would be happier as a designer, where they can make everything fit into perfectly neat boxes.

Typically I'd just downvote, but was that condescending comment really needed? This is the sort of toxicity that turns people away from our community.

It is a fair comment. In design you at least have a chance at clean work safe from messy reality.

It's a condescending comment because there are many designers who have to design for the real world. It's no less condescending than saying someone should go into programming where they just have to type out code all day and not face the real world.

That's exactly why software engineering is more attractive than hardware engineering though?

A condescending comment would be something like: "Maybe you should stick to your pretty R graphs for 'journalism' and leave discussion of software engineering to the professionals who actually get paid to build systems and who haven't, as a profession, fucked up on every metric in the last decade even without including the most recent election."

That would be a condescending comment--the one you are remarking on can be interpreted as "hey, designers get to make pretty things unfettered by layers of shaky abstractions and stupid imposed by business and deadlines".

Please don't rush to aid the theoretically aggrieved; especially when there are folks in this same subthread going "yep, as a designer, that's the truth".

If a designer doesn't confront reality while creating a design, then I would say they have failed miserably. Perhaps you are right, and few designers are successful in this regard.

I'm not sure about that - designers have to build a UX that works in the real world, and sometimes there are really complicated processes that need to be exposed in a nice way. I imagine this has similar tradeoffs as programming (i.e. difficulty in implementation, balancing power/intuitiveness)

As a designer, one can live exclusively in "photoshop", ignoring the complexity of the process and the reality of usage. It's not like you can "test" a drawing with a real user.

As a programmer, you gotta get all the little details right or the application is not possible to use. There is no way around it, whatever is forgotten will just hit you right in your face.

And last but not least. Drawing is dead easy. A programmer could design a UI in a drag&drop devtool maybe as fast as a designer. The challenge when creating an application is not the drawing of the UI but the handling of the user interactions and the data.

Thank you for illustrating my (apparently unpopular) point.

This is such a massive simplification of what a designer does it's actually amazing. You're first and last paragraphs are simply wrong.

First of all a designer doesn't get to live exclusively in photoshop or some other tool. They don't get to ignore the "reality of usage". In order to be a competent designer they have to not only completely understand the problem domain, but also the given software solution and how a user can use the software to achieve the desired goal in the most concise manner. They have to worry about how to signal to users how to perform any given interaction and the overall complexity any activity has. Also they absolutely do test designs with real users. There is like a whole field of study in design around exactly this.

As to your last point, drawing != designing. Designing is actually really hard. This is a problem I see with programmers all the time. The oversimplification of others contributions. Yes you can put together a UI with drag and drop tools. You can build a website with drag and drop tools too and you'll probably get the same quality as the drag and drop UI. A drag and drop design will probably have most of the various pieces. But will it be obvious what actions a user can take from any given screen? Will it properly optimize screen space, and be color correct? There are a 1001 questions that a designer has to ask that most programmers wouldn't even think to ask. There are many challenges when writing an app, and good design has proven over and over again to matter just as much to the success of a business as solid code.

We both agree that there is a difference between a "drawer" and a designer, just like there is a difference between a "code monkey" and a developer.

First paragraph. I could say all the exact same thing about a developer.

Second paragraph. Yes to all your questions. I should clarify that the drag&drop tools I had in mind were for desktop applications, not web, that's a different world.

Design <ought> be perfect, because you actually have a chance to do so. Design is declarative. You are defining what <ought> be. People who are studying someone's design specification shouldn't have to wonder whether your circle is <really> a circle. A designer declares a perfect circle even if when zoomed in you find bumpy pixels.

Also, design in the context of a team especially ought be perfect, because your perfection will be degraded in a game of telephone.

By perfect, I don't mean that your design fits the user with maximum optimality. I mean that when you draw a box, you actually mean a perfect box. When a mathematician draws a square, they are describing a perfect square. It would be a little socially blind to pick up a magnifying glass and accuse the mathematician or the designer's square to be imperfect because you find the bumpy ugliness of a 1080p monitor or a sheet of paper.

Design is often a victim of mutually excluding constraints, i'm not so sure it's easier to achieve perfection. In fact, I'm pretty sure it isn't.

That comment about being a designer is <not> an obvious aggression -- notwithstanding whether aggression is net useful. However, saying that someone's speech is characterized by condescension and toxicity is <obviously> aggressive -- notwithstanding whether aggression is net useful.

Given that you do not possess the prerogative to control the costs of your potential mistakes, ought not calls of toxicity be restrained toward obvious cases? Also, how toxic are mistaken accusations of toxicity?

This thread is full of obvious cases of toxicity.

Or perhaps she'd be happier in an industry such as aerospace, defense, or emergency services.

6-7 years ago, I interviewed at EFJohnson. The position involved maintaining code for systems used by emergency services (might've been related to E911, but I'm not sure). I distinctly remember one of my interviewers telling me, "if we screw up, people die". I'm fairly sure my lack of self-confidence was why I didn't get the job; he could easily see the nervousness on my face when he said that. However, it sounds like that kind of job would be perfect for the author.

It's interesting because I suffer from perfectionism as well, severely so. Probably for worse, I've also been able to achieve it in a lot of aspects of life. This reinforces my desire for perfection.

The interesting part is that programming is the one place where perfection escapes me, as in I haven't desired for it. I realize there are bugs and caveats to written code. My flip side here is that I strive for perfection of the user's experience. I do get disheartened when a user experiences something negative in the code based I work on.

The key for me has been focusing on the perfection to a user and not perfection of code. There may be a dark edge that they never see, and it's fine.

When there is a careless bug, I still struggle balancing empathy and drive to fix it. That's fine, however, as I'm aware and work to not do it. I could see where someone who strives for perfection would easily get disheartened and feel misalignment in values.

Or maybe they'd just rather do computer science than software development.

There are lots of branches of technology work that prize understanding over shipping.

Shipping without understand is no virtue, and as far as I can tell, there's no hard conflict between the two.

The entire official story of "lean" is "build, measure, learn", which is fundamentally about developing a process for shipping while deepening an understanding.

The hermeneutic circle (https://en.m.wikipedia.org/wiki/Hermeneutic_circle) cited by Dave Herman of Mozilla Research and Brendan Eich (about JavaScript) is a process of iteration that prizes a deepening understanding interleaved with lessons learned from shipping.

I didn't interpret the OP to be saying that she wanted to gain a perfect understanding before shipping, but rather that she preferred a style that focused more than the tech community average on deepening understanding.

And I don't think she needs to go to a different branch of technology to get that. Maybe app development needs more of it.

Steve Jobs famously talked about the interplay between understanding and building: https://wycats.svbtle.com/theres-a-tremendous-amount-of-craf....

I think we could do worse than to think about this topic more.

Belongs in an enterprise environment IMO. That mentality works really well with unlimited budget where projects can live forever.

Enterprise projects have sprawling budgets and indefinite timelines, but nobody who has worked on line-of-business software would suggest that the outcomes are anywhere close to perfect.

Not implying that. Just that her way of thinking is a much better fit in that environment.

Could you explain? Because she sounds like the opposite of an LoB enterprise programmer to me.

In the enterprise environments that I've been in, there has always been a big push for over engineering. The idea of iterating and improving is generally frowned on and the waterfall mentality tends to shine. Waterfall planning revolves around trying to understand the entire problem, plan every step of the way and then methodically deliver a solution that's prematurely optimized. Once the project is over it's handed off to a production support team with the goal of living virtually forever.

Her mindset of wanting to fully understand the problem, why it's a problem, etc seems like it would fit be in an environment where you had lots of time and a lot of people that you could meet with to gather information, plan, etc.

Having spent significant time at a true enterprise (in the top 100 of the fortune 500), the push is not for over engineering, but for over bureaucracy. I would represent that the frustrations are more likely to increase, as not only is there an absence of understanding things deeply, but also no impulse to ship.

Reply on news.ycombinator.com