2,180 karma · joined May 11, 2015
I'd accept a 10-20% salary hit to skip my 20m commute 3 days a week, but so far the only options have been for 40%+ lower salaries or work that I am less interested in. For me that tradeoff is not worth it.
Nonprofit org websites, event posters, flyers, t-shirts, illustrations, small utility apps, WordPress themes, unsolicited redesigns of well-known applications on Dribble, etc.
I spend my days convincing developers to make UI changes. Spending my nights and weekends doing the same thing but with even less authority does not sound like fun.
I think you've captured the crux of the issue and the same applies to designers too.
Say I just spent the last eight hours trying to convince a stubborn front-end developer that the reason customers complain about our UI and the product keeps failing usability tests is that it needs a UI overhaul and that telling people to "just RTFM" will not win us any new contracts.
Getting home and having a similar debate with a FOSS dev team where I have even less sway does not sound like a rewarding way to spend my free time.
As a professional UX designer/researcher I've found that option C is pretty common. I'll file tickets for egregious usability issues with trivial fixes, but if an interface needs to be rethought from the ground up it's not worth getting involved.
The best career decision I ever made was to prioritize working with Good People and one of my few regrets was putting up with smart jerks for so long.
But this approach is extremely difficult in some domains. If companies in a particular domain routinely make what you consider to be obvious mistakes there are a couple possibilities. It could certainly be herd mentality and they just need someone to remind them to do more QA and to fix bugs before adding features. But it could also be incentives that resulted in the companies that cut corners outcompeting companies that did things "the right way".
Early in my career I was a minor participant in discussions like this (albeit not in the video game space) and no one was in denial about the massive reputational cost of prematurely releasing buggy software, they were just balancing it against the increasing probability of bankruptcy.
Established companies with deep pockets and startups with shoestring development teams and patient investors might be able to weather a delay of six months or more, but most companies don't have that kind of runway and must constantly weigh the bottomless desire for more time to polish and the need for cashflow to make payroll.
(Thankfully the last couple companies I've worked for have had deep pockets and a strong desire to protect their reputations, but I appreciate that this is a privileged position.)
It reminds me of the "Blue eyes/Brown eyes" exercise (https://en.wikipedia.org/wiki/Jane_Elliott) so let's say this was a real psychology experiment. Middle-schoolers and high-schoolers are encouraged to communicate via a chat application with rich multimedia functionality. But any conversation that includes even a single individual who belongs to an arbitrarily-defined "out-group" has its functionality degraded and the application highlights who the out-group member(s) are. After a year you compare the mental, social, physical, and academic well-being of both groups. Would your university's IRB approve such an experiment?
I initially gave Apple the benefit of the doubt that this was simply a technical limitation. And of course kids will always bully each other about something. But at this point it does indeed seem like a billion-dollar company is intentionally amplifying and leveraging this sort of bullying to drive marketshare. If you don't find this immoral then I'm not sure what to say.
Like others, I am having trouble putting my finger on the reason, the best I can do is to say that in Calc my attention was often on the software itself rather than the data. To use Heideggerian terminology, Calc often feels "present-at-hand" whereas with some experience other spreadsheet tools feel "ready-to-hand".
I initially assumed I simply had more experience with Excel and would find Calc just as easy if I spent more time with it. But then I tried Google Sheets and to a lesser extent Apple Numbers and was able to quickly transition from thinking about the tool (present-at-hand) to thinking about my content and tasks (ready-to-hand).
I still have to drop out of my task flow when using an unfamiliar feature in Excel, Sheets, or Numbers but these feel like momentary digressions with the majority of my time spent thinking about the content. With Calc the ratio felt reversed, with the most of my time spent thinking about the tool. (Though I'll admit I have not tried it in several years -- perhaps it has improved since then.)
I wish I could provide more actionable feedback, but I suspect that the best way to pay down some of their design debt would be for Libre Office to conduct usability tests.
Over short distances (up to about 800m) a cheetah's sprint speed of nearly 100kph dominates, true. However, because they only maintain that for up to 30s, an augmented human moving at 75kph would be less than 10s behind at that point and might be able to catch up over slightly longer distances. I'm unsure the exact distance as I don't know offhand what running speeds a cheetah can maintain for longer than 30s and I'd also assume that cheetahs have better dodging agility than a human with giant springs strapped to their legs (and as per above hopefully some safety gear).
But I stand by my assertion that I want to imagine such a scenario.
As much as I want to imagine people chasing down cheetahs, without empirical testing I have to admit I am skeptical of their claims.
We could shift cultural expectations so that distro maintainers become the first tier of support for all app issues in their distro, and escalate issues to app developers if and only if they've confirmed that the issue is distro-agnostic. That would be sustainable for app developers but could be a heavy burden for small distro teams.
> This is a HARD problem, but that isn't an excuse to not face it.
Agreed, I just don't think it's the responsibility of app developers to solve.
From what I've seen from colleagues in the consumer space they've predominantly switched to A/B testing and statistical clickstream/log analyses, though large companies sometimes still do run lab studies for important decisions and to rationalize the giant one-way mirror they installed.
Second, even policies that provide some benefit to companies may backfire for society if they increase mental health problems, lower social cohesion, prevent family formation, and/or cause their best-and-brightest to leave. At some level the best way to "compete better with China" may be to focus on maintaining sensible policies focused on maximizing an individual's "life, liberty, and the pursuit of happiness" alongside overall national productivity and let short-sighted competitors burn themselves out. (Similar to the strategy adopted during the Cold War.)
However, quantitative metrics like telemetry are used to answer different kinds of questions.
> How big peoples projects are on average doesn’t matter.
To give concrete examples, at my current company we do not collect telemetry and have regularly encountered problems where some assumption about customer usage (the number of items in the largest project, the size of the largest document, the smallest browser window, the oldest browser version, the usage of a deprecated feature) turns out to be incorrect, sometimes wildly so, and we only find out after a customer finally complains that they've been struggling with something for months.
If we had telemetry we could have known about these issues well ahead of time and in many cases avoided the problem in the first place. We still choose not to have telemetry for many of the reasons presented in other comments, but we should at least be honest that it can provide immense value to the product team.
Also in my experience, the companies that were the most cost sensitive with regard to paying for dev tooling were also the ones with the weakest IT/devops support so you either end up with two good options or two bad options.
I thought you might be exaggerating, but if the wikipedia entry is to believed it seems like a pretty obvious case of laundering bribes:
"In 2003, Buyer created The Frontier Foundation, whose stated purpose is educational funding for college students ... Buyer's daughter Colleen was the president ... His son Ryan, in 2009, was director ... the foundation shared an office with Buyer's campaign office ... annual fundraising golf outings had raised more than $880,000 for the foundation. Almost all the contributions were from 20 companies and trade organizations that had interests before the House Energy and Commerce Committee, of which Buyer is a member ... In 2018, the Frontier Foundation was closed by Buyer, the only listed officer, without ever having funded a scholarship."
Excerpts from: https://en.wikipedia.org/wiki/Steve_Buyer#Frontier_Foundatio...
If a suspected mob boss is recorded telling members of their organization stop using words like "murder", "assassinate", and "intimidate" that would not be proof of a crime, maybe they are an upstanding business owner who simply wants their employees to stop using violent metaphors.
But it would be suspicious and seems reasonable for a prosecutor to bring up in court.
I have no specific insight into decision-making in open source organizations, but given that the resources they're working with are several orders of magnitude less it's not surprising to me that they sometimes end up having to choose between stability and new functionality. (While I personally prefer projects towards one end of that spectrum, I'm happy that different projects have different values for other people.)
I've worked on projects where dozens of different stakeholders needed to sign off on the icon library resulting in thousands of person-hours of design review meetings alone. If I could save millions of dollars by picking an existing icon library and adding only what is needed that seems like a smart move to me.
In extreme cases of very large products whose owners want them to look exceedingly modern it can be like painting the Golden Gate Bridge: by the time they finish implementing the last components and icons, the ones that were implemented at the beginning of the project are already due for an update.
The job security simply isn't worth the maddening repetition.
My impression has been that, along with 3D printing, the mechanical keyboard obsession has has spurred a renaissance of keyboard innovation in the last decade or so.
You can now buy keyboards or kits with ortholinear/columnar keys, split hands, built-in displays, modes/layers, non-QWERTY layouts, Hall effect keys, non-uniform resistance, and more.
I haven't seen this degree of keyboard innovation in a long time. The best part is that they're an order of magnitude cheaper than the wacky keyboards of the 1980s and 1990s, many of which cost thousands of dollars. These days you can try something innovative out for just a few hundred bucks and even less if you're willing to solder it yourself.
Another is to find organizations that have individual contributor (IC) promotion tracks that are at least as lucrative as the management track. (Of the highest-paid, most respected people at my company, most of them are not in management and are simply really good at what they do.)
Precisely. In some domains most customers will always choose the cheaper option. In those cases web apps resulted in a race to the bottom. Companies in those domains simply could not afford to cling to native software if they wanted to remain competitive.
But of course you still find lots of native software in domains where a critical mass of customers are willing to pay more (or sacrifice functionality) for qualities like performance, security, reliability, etc. For example: games, fintech, military, virtual reality, video production, realtime controllers. I've worked in a couple of those domains and in those cases I am confident that web apps are a very long way away from displacing native applications.
> everyone involved in it should be ashamed of the product they're turning out
Before judging people for their decisions it's worth understanding why they make them.
I know many developers who take pride in writing extremely performant software. All of them have either shifted to work for companies that are willing to pay them to do that or they've swallowed their pride to feed their kids and they scratch that itch by tinkering with open source or game dev on the weekends.
> Now we certainly have more options but like, what good is more options that suck?
I am not arguing that this situation makes your life better. It doesn't. I sympathize with your frustration and I also like using (and making) performant software.
What I am trying to do is explain how we got here because I think it could help us find a way out. We either have to make performant software significantly cheaper to build or we have to convince customers to pay significantly more for it.
I understand why someone would think that, but in my experience the economics for product owners aren't significantly different between scrappy underdogs and massive firms.
First, most new products start as a web app. If the product is profitable (or convinces someone with money that it will be profitable) the product owner is granted additional headcount to allocate.
In my experience, adding more user-requested functionality almost always has a higher expected return on investment than making fully native versions of the product for iOS, Android, or Windows. (I have no experience making software for Mac.) As much as I like using native apps myself, there are plenty of cases where I couldn't make a case that creating native versions would have a positive return on investment at all.
In summary, the number of products that are profitable enough to afford native development teams is small, and the number of those products where the native development team would pay for itself in increased profits is smaller still.
There are plenty of exceptions like games, legacy software, realtime systems, libre software, low-level utilities, Mac-only dev shops etc. But otherwise the economics don't seem to work out.
(I do not know where this story originated, but ever since hearing about this from one of my design professors I've noticed how many buildings put mirrors next to their elevators.)
I found the same thing moving from a very large company to a smallish company. Both had good tooling, the latter just had significantly less and there were gaps in coverage. Whenever I encountered one of those areas I often found myself wishing I had access to some niche tool I had gotten used to at my prior company.