Hacker News new | ask | show | jobs
by fivea 1539 days ago
> When you have engineers working into the wee hours of the morning because you don’t want a cursor to blink on a text field, (...)

You're grossly misrepresenting the problems being faced and what forces engineers to work into the wee hours of the morning.

Just because stuff seems done to you or you notice no change, that does not mean nothing is being worked on.

Let's take basic A/B testing. To you, it's a blinking cursor. For the company, it's a bunch of business metrics being reported from N different components feeding into a data lake, with different versions of the same feature being deployed simultaneously to specific subsets of all customers based on their profile. But the cursor blinks differently depending on the market, and needs to comply with accessibility guidelines, on all X supported browsers regardless of their quirks. Some markets might not even have a cursor at all. Perhaps your cursor is only expected to show in a specific geographical location.

But you see a blinking cursor, and as you are oblivious to everything then you think it's just a tag somewhere. To you that's just a line of HTML, right? How hard could that be?

3 comments

Imagining boatloads of complexity involved with the blinking cursors according to markets, profiles and geographic locations and whatever else really doesn't make it sound any better at all.
> Imagining boatloads of complexity involved with the blinking cursors according to markets, profiles and geographic locations and whatever else really doesn't make it sound any better at all.

These basic everyday requirements are oblivious to those who have zero first-hand contact or experience with professional user-facing problems imposed by business requirements.

However, just because you're oblivious or unfamiliar to these requirements, they don't mean they aren't requirements.

Think about it for a second. If it's necessary to target a service to specific geographical markets to comply with legal and/or business requirents, and given it's considerably more profitable to target a shop to a customer based on their personal interests, why would you ignore that and naively presume that the hypothetical "blinking cursor" is straight-forward to implement? And I'm not even touching hard technical probs which most developers aren't experienced or competent in, such as security and reliability.

There is a widespread problem in software development which is this this tendency to be very opinionated over all problems in spite of being totally ignorant and oblivious to the underlying problem domain. Everyone is an idiot except themselves, who always hold the answer in spite of not even knowingwhat the problem is, let alone understanding it.

>These basic everyday requirements are oblivious to those who have zero first-hand contact or experience with professional user-facing problems imposed by business requirements.

Could you paint me a realistic scenario for such multifaceted complexity revolving around this blinking cursor in a particular field? I can see how this might depend on a language/writing system but kind of get lost beyond that.

I do have experience with such "professional user-facing problems imposed by business requirements" btw but they tend to be more related to desktop and factory software each used by hundreds which is probably a few zeroes less than what we're talking about here.

>And I'm not even touching hard technical probs which most developers aren't experienced or competent in, such as security and reliability.

I know more than most that software can behave in weird ways but don't you think if there's a reasonable worry that altering this blinking cursor affects security that something is off?

If you have the infrastructure to manage multiple versions and collect and analyse related information, adding/removing a blinking cursor or any other UI change and analysing the results should be trivial, because most of the process should be automated. Even in multiple territories and/or different user demos.

Unless you're reinventing the wheel for each modification.

> If you have the infrastructure to manage multiple versions and collect and analyse related information, adding/removing a blinking cursor or any other UI change and analysing the results should be trivial (...)

What leads you to believe in that? I mean, you have zero insight or understanding how things work or were designed. You have zero idea of where that blinking cursor comes from, let alone who owns that particular bit of code.

Let's think things through for a moment. Let's imagine you're talking about a blinking cursor in a random page from Google or Amazon. These are organizations where you have teams owning small widgets that show off only in specific pages, and that the page that you see in your browser come from a lengthy page engine pipeline that has all sorts of tests and failsafes, not to mention regional and localized deployments managed by whatever deployment policy.

This doesn't even take into account the whole workflow from product managers, who often demand data on the impact of touching a button.

You don't just edit a HTML file and hit save, don't you?

It wasn't my intention to dismiss the engineering challenges, I'm aware of how difficult something like this can be at a scale like Airbnb. I was more venting about the fact that all the engineering effort is directed at such a seemingly minor thing to begin with.
Then why has the site become more annoying and less usable over time?

This isn't just a personal opinion. I've heard it spontaneously from various friends and acquaintances.

Granted we're mostly a similar demographic in a single market.

But even so.

> Then why has the site become more annoying and less usable over time?

I can't and won't speak on behalf of AirBnB, but you should keep in mind that in general:

a) all software grows by accretion until a breaking point,

b) paying off technical debt without solving any concrete problem or adding any tangible benefit is not considered a worthwhile investment,

c) a site did not changed for the worse if the data shows its conversion rate increased.

> c) a site did not changed for the worse if the data shows its conversion rate increased.

It's a business whose product transcends the site it's presented on, and exists in spite of the quality of its site.