Live data from Hacker News

How to Design Software Good

haiku-os.org

141–150 of 191 posts

Re: How to Design Software Good

#141
post #58

Earlier quoted context omitted.

> You're right, we should update it, though. No, you really shouldn't, it's not a real problem. The only people who keep tallies of gender pronouns in documents are internet trolls; don't indulge the trolls. Anyway, switching up pronouns every other time breaks continuity and makes documents harder and painful to read.

No need to keep a tally; in 2018, any document that exclusively uses masculine pronouns for genderless subjects reads as outdated. When writing on technical topics, the chief concern is to be clear, accurate, and straightforward. Anything that might distract your reader is undesirable. By referring to “the user” as “he”, you’re already distracting roughly 50% of your potential readership (if you’re writing the docume…

> any document that exclusively uses masculine pronouns for genderless subjects reads as outdated.

Correct English is never out of style.

Different languages do different things, and that's okay. Some languages apply grammatical gender to more than just sex, e.g. tools, or fruit. That's okay. English uses grammatical gender to distinguish between male, female & neuter objects, and defaults to male when referring to unknown males-or-females. That's okay too. It's all part of the rich panoply of life.

> By referring to “the user” as “he”, you’re already distracting roughly 50% of your potential readership

I really doubt every woman is distracted by proper grammar. And of course by not using correct English, you distract people who use & prefer it.

Re: How to Design Software Good

#142

> Writing good software can be hard, but it is worth the time and effort. Is it? I want this to be true because I want to write good software. But I've worked with some very senior developers who would disregard all software engineering and user experience concerns and just spew large quantities of low-quality code that made the managers just as happy, especially since it got done quickly. And the end-users in many n…

Very senior developers know things that are not intuitive, but very true. So I'll let you in on a few secrets. "Good enough is always good enough". You probably want to do more than good enough. Those developers you talked about, probably knew the amount of quality that was actually needed, no more, no less. Clean code doesn't mean "no bugs" and "good software": - I've seen very cool, popular, money making games that…

Agree with all points. Here's another - depending on the size of the shop and the population of users it will be delivered to, there are trade-offs that must be made as you go towards zero on both of those axes. For example, if you have two developers delivering in-house apps to 250 end-users in a SMB company, then the answer is never, "That will take two years and $2M." It is, "We can have that for you in a month," and then you deal later with things that necessarily got skipped. Sometimes it means refactoring and bug fixing, if the pain points to the business are large enough. Sometimes that may mean reaching into a database to fix data that is caused by a complex bug that only manifests itself once a year and isn't worth fixing outright (because there are other things you're working on now). That outlook is probably way to "Realpolitik" for the purists, but it is reality in small shops (which still do exist).

Re: How to Design Software Good

#143
post #107

Earlier quoted context omitted.

> Clean code doesn't mean "no bugs" and "good software" This gets missed too often: clean interfaces are important, whether it's a UI or an API. Clean code? It depends. I once interviewed a dev who had all the right answers when it came to software development practices, TDD, etc, but when we looked at the product he was working on, the UX was a stuttering mess. I don't care what your code looks like if you did not a…

> the UX was a stuttering mess. Is that a good metric to judge a developer, though? Good UX requires either formal training in the field, or a very gifted individual. In my opinion it has very little to do with the quality of either the code or the developer.

It is a very good metric.

To have baseline UX awareness is crucial for every developer on any team that sets out to build a great product, just like any effective designer has to be aware of physical limitations of his design space (for example speed of light, bandwidth)

If your UX designers job is to point out that responsive UI is indeed important for your product, he is not actually doing UX design and you are likely in deep trouble.

Re: How to Design Software Good

#144
post #134
post #126

Earlier quoted context omitted.

> don't care what your code looks like if you did not achieve a good end-product. I do care if your code is a mess if other engineers have to maintain it.

I'm not saying clean code is not desirable. Code which is easy to maintain and modify is absolutely better than messy code. My point is that "good code" should be prioritized behind a good product. The purpose of code is to deliver a product, not to be well-factored or to embody certain principals. If your product is bad, your code is already categorically bad, no matter how beautiful it is.

But it's really difficult to make a good product and good product experience on a messy code base. Quality code leads to better product IMHO. (of course good quality code base can still suffer from badly designed UX)

Re: How to Design Software Good

#145
post #90

> Writing good software can be hard, but it is worth the time and effort. Is it? I want this to be true because I want to write good software. But I've worked with some very senior developers who would disregard all software engineering and user experience concerns and just spew large quantities of low-quality code that made the managers just as happy, especially since it got done quickly. And the end-users in many n…

Disclosure: small-ish company (~100 employees) in France You know, I kind of went through the same questioning: at my current company we have an employee that has his niche/historical role on one of the key infrastructure of our product. The guys works from his home and whatever hours, commits 300+ lines per commit (90% of which is unrelated to the commit name, just commenting things or uncommenting others). The code…

I bet the cost/benefit for the company is positive, and as long the clients are happy and paying, how this guy works is irrelevant. he was rewriting a huffman compression algorithm by himself because he's bored and he wants to learn and experiment. I bet is not a good life he's living. There's a great disorder in working from your home at odd hours, it's not healthy. He would be happier working normal, fixed hours, and with a manager to guide him.

Re: How to Design Software Good

#146
post #90

> Writing good software can be hard, but it is worth the time and effort. Is it? I want this to be true because I want to write good software. But I've worked with some very senior developers who would disregard all software engineering and user experience concerns and just spew large quantities of low-quality code that made the managers just as happy, especially since it got done quickly. And the end-users in many n…

Disclosure: small-ish company (~100 employees) in France You know, I kind of went through the same questioning: at my current company we have an employee that has his niche/historical role on one of the key infrastructure of our product. The guys works from his home and whatever hours, commits 300+ lines per commit (90% of which is unrelated to the commit name, just commenting things or uncommenting others). The code…

Beautiful!

I would pay for a book with more anectotes of kafkaesque, nightmarish visions of horrendous programs.

Re: How to Design Software Good

#147
post #128

Earlier quoted context omitted.

Maybe its meant to be tongue-in-cheek.

I thought it was a vague zoolander reference.

This is also what I assumed, and I'm fairly sure it is.

Especially since the grammar in the article is relatively OK, whereas that title would be really terrible if it were not a pop-culture reference.

Re: How to Design Software Good

#149

Given: > Good Software Uses Everyday Language I'm curious why keyboard shortcuts are called accelerators. Overall looks like a pretty good set of things to think about as a UX designer.

That's what keyboard shortcuts were called in some systems like BeOS, early Windows and probably others. I would guess it's because they provide faster access to a feature or function than going through menus.

Re: How to Design Software Good

#150
post #48

I saw a quick flash of unstyled content (in Firefox) where all the text was jammed into one paragraph with no breaks. And then the page rendered normally. So I glanced at the source code, and it surprised me to see that it was not a typical HTML document, but instead an XML document with a stylesheet. It is very rare to see a non-HTML page on the web, whether it is the XHTML serialization of HTML, or fully custom XML…

Thanks for reporting this problem! I filed a Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1506038 This bug is actually a regression in Firefox 58 from the fix for a use-after-free bug (CVE-2018-5097): https://bugzilla.mozilla.org/show_bug.cgi?id=1387427

I thought it was intentional and not a bug - thanks for reporting! It's true that I don't see flash-of-unstyled-content on HTML and XHTML pages, unless the CSS file is delayed by many seconds. I noticed another bug though - the Firefox inspector tool doesn't show style rules for the XML document.
Post reply on HN