Hacker News new | past | comments | ask | show | jobs | submit login
Don't create for an imaginary group of people (sarvasvkulpati.com)
240 points by sarvasvkulpati 11 days ago | hide | past | favorite | 70 comments





There's great power in scratching your own itch and building the tools and software you want for the real problem you have right now.

But on the flip side, a lot of the software regular people use for their jobs is awful. As software engineers we've built lovely tools for ourselves (development environments, version control, etc). We've scratched our own itch. But we collectively don't feel a lot of empathy for folks in other industries. So they end up with bad, missing or massively overpriced software as a result.

The answer is to go outside, and make friends with people who aren't software engineers. Pick up a hobby or a craft. The best software is always made out of necessity.


>But we collectively don't feel a lot of empathy for folks in other industries.

People work for free on things they enjoy and not what others want. This is no shocker.

I don't have builders building me a house for free just for the fun of it. In general in the world, if you want someone to do something that you want and not what they want, you have to compensate them for this work. And this works fantastically for areas where people are willing to pay. The consumer hardware we have today is mind blowingly good and the software to go with it is outstanding.


I'm not sure anyone is disagreeing with you. That is why they said to get another hobby or craft—so that you might want to write software in neglected areas. And of course financial compensation is good for this too, but I wonder if passion projects are of higher quality.

It is true that "empathy" probably won't help much, though.


>I wonder if passion projects are of higher quality

Based on my personal experience, any software that requires a large team to build and maintain seems to be better when it's commercial (and usually proprietary). This is not the case for one-man software projects.


SQLite, NodeJS, the linux kernel, the rust compiler, postgres and others would like a word.

NodeJS tried to move to an industry governance board model around the release of 0.12, where commercial interests took part in running the project. It nearly killed nodejs entirely.


People definitely get paid for work on more than half of those projects.

So? None of them are commercial or proprietary projects - which was the contention. There’s nothing inherent about opensource that precludes having people paid to work on it. It’s just harder.

> The consumer hardware we have today is mind blowingly good and the software to go with it is outstanding.

It would all be even better if 1) knowledge was de-commoditized (since thanks to digital tech knowledge is now already a non-rivalrous good as it has a zero marginal cost of reproduction) and 2) we used transparent p2p supply chains (http://valueflo.ws + http://holochain.org).

I think today's world is a black box hellworld. I don't think hardware and software are high quality at all. Proprietary tech is a straightjacket. I believe we can definitely escape this hellworld though. Some even say overcoming it is is essential if we want to make it out of global warming:

"The current political economy is based on a false idea of “immaterial scarcity.”

It believes that an exaggerated set of intellectual property monopolies – for copyrights, trademarks and patents – should restrain the sharing of scientific, social and economic innovations. Hence the system discourages human cooperation, excludes many people from benefiting from innovation and slows the collective learning of humanity.

In an age of grave global challenges, the political economy keeps many practical alternatives sequestered behind private firewalls or unfunded if they cannot generate adequate profits."


They never said anything about working for free.

If you are paying for developers than no "empathy" is needed. Shitty industry software is due to the business clinging on to legacy systems and refusing to invest in new ones. And often they are right, using the legacy software has better business outcomes than spending the money required to make something better. We see that when the investment is made, we get great software. The camera software we have is remarkable compared to what we had 10 years ago.

> If you are paying for developers than no "empathy" is needed.

I don't agree. I think its impossible to make good software without deeply understanding the perspective and needs of your users. Money can be used to hire empathetic designers, but its hard to beat software designed and made and maintained by its users directly.

I worked with a designer years ago who organized a series of user study sessions with our prospective clients. She insisted on each engineer on the team going to at least one of those sessions with her. I thought it was a bit silly - but I went to a couple of meetings and I was shocked. It was hugely eye opening for me - I learned so much. It made our product better, too. Down the track I added some small features to our product that nobody asked for, but which were easy to implement and which our clients loved. It wouldn't have occurred to me to add any of that stuff if I didn't first sit in those meetings and hear things from their perspective.


> due to the business clinging on to legacy systems and refusing to invest in new ones

This is a massive generalisation and one that I don't think is as clear cut as you make it sound. Most businesses in my experience would happily replace a horrible hard-to-maintain legacy system if...

* It could be done for a reasonable cost * It wouldn't take ages to do or at least they know how long * They knew how to find the right product amongst thousands of sales people telling them to use theirs * They could find a reliable way to migrate to the new system * They weren't heavily regulated and knew they were on the hook for millions in compensation if they get something wrong

I think a bigger reason is that the software engineering industry is only just starting to form a formal trade where quality is assured by agreed processes and you are more likely to get consistency across suppliers closer to medicine and law. At the moment, there are no agreed worldwide regulations for software, there are no requirements for software engineers regarding experience/qualification and many other reasons.

If we can solve some of those, or at least get close, then we help derisk businesses who want to stay competitive but are currently too scared to!


There are three separate groups involved in modern software markets; the user, the author, and the middlemen who connect the two. I think the reason software for non-developers is awful is because the middlemen are incentivised to connect users to the most profitable software for the middleman, not the best for the user.

For example, there's no easy way to search the app store or Google play for free software with no ads, in any sense of the word free, because free software without ads isn't profitable. All the top ranking app review sites are listicles for ad-supported or paid apps, because those apps have marketing budgets. It is easier to find a FOSS app's github repo and navigate to the play store from there than it is to find FOSS apps on the actual store.

In general there's less profit to be made from showing someone high quality free products than low quality paid products who'll give you a cut of the take.


> So they end up with bad, missing or massively overpriced software as a result.

Immediately, SAP NetWeaver comes to mind. The whole architecture, concept and experience is violating every possible UX guideline of any operating system - and has never been updated since the 80s.

Every single person I've talked to hates SAP for various reasons. Nobody understands why there's no alternative, and nobody understands why SAP exists in the first place. And everybody hates that SAP created the optimum lock-in scenario; where they fictionally created the maximum amount of cost for companies trying to switch to another, more modern, system.


This is a bit offtopic but, can anyone explain what SAP is and why its used? I've heard people mention SAP for well over a decade and I've never gotten a clear story on what it actually does for the companies which use it.

SAP is a large-scale system for resource planning. It nails down to managing development/engineering/human resources in a waterfall-managed company, and usually the workforce have to maintain their own "digital stamping" like enter/leave the company and/or on what projects they've been working on, so the workers use SAP in order to do their own accounting.

The advantage SAP has from an enterprise's point of view is "automated" accounting that theoretically can be integrated into third-party software, like the software that sends out bills via mail to customers.

Usually SAP is too bloated for everyone, in Germany we would say "mit Kanonen auf Spatzen schiessen" because it's too much overhead for maintaining/licensing the system vs. just using a simpler alternative that likely even is open source and can be modified quickly to your needs.

From a selling point of view, SAP is always sold as "it can do anything out of the box" without any development resources necessary. While that's far away from the actual truth, most CEOs believe that kind of stuff and just buy the service; which is contracted in a way that it has a minimum lifetime of years (usually 10 years+) until you're allowed to change to an alternative.

Legal requirement to archive all bills 10 years does the rest, et voila, you have a working Dip nobody can exit out of.


FYI, "mit Kanonen auf Spatzen schiessen" seems to be widely translated as the English idiom "cracking a nut with a sledgehammer". Also, rarely seen but IMO much more amusing in the imagery it evokes, "breaking a butterfly on a [torture] wheel".

I think the magic ingredient of SAP is: The accounting works cross-country because it supports all the different tax laws. It makes certain things easier for multinational corps.

Today, SAP exists so that SAP sales managers and, more importantly, SAP integration engineers, can earn lots of money. Oh, and the people who authorize the purchase of SAP, too: kickbacks and all that jazz, you know. Perhaps there were some other motivations, but today, that's mostly it.

I think the problem with the author's POV is posing the problem as a choice between making for yourself or making for no-one (by trying to please other people).

Trying to please other people is how a market economy functions. You do not produce the things that you would ideally want to produce but the things that other people need.

I think the issues you raise are totally correct, and don't just apply to entrepreneurs. Most developers will, if given the choice, build complexity into products. They will develop things that are fun to develop, not fun to use. And when people want to build a new business, they will usually try to build things that are fun to build...not many people want to build things for water treatment plants or waste disposal operators, that isn't fun or cool.

So I think there is a way in the middle. You should be guided by your own want (but that want should be the product, not building the product) but business is about serving customers. The puzzle over market fit is strange to me...if you aren't building something that other people need, that isn't a business. You have to respond to the market, other people as much as be guided by your own beliefs.

Side-note: you see this in almost every walk of life. Craftsmen prefer old techniques that are fun but result in lower quality. You see it in medicine. Investing is an interesting one too...you only get paid if the world comes round to your view but some people will actively shut out the opinions of other people...that ends badly 100% of the time because you are shutting out the only information that will stop you from making a bad decision (eventually).


The problem with other people is that a) You really don't know what they want b) They want different things.

But if you build for yourself you a) know what you want b) There is only one you


>As software engineers we've built lovely tools for ourselves (development environments, VERSION CONTROL, etc).

Hmm, can't say I agree with your second point. The industry standard version control is notoriously messy and hard to work with.


Steep learning curve sure, but it's an extremely sharp tool that allows one to work magic once you're comfortable with it. After 1 year of git experience I could trivially do things that I never would have even attempted after a decade of CVS and SVN.

> Steep learning curve sure, but it's an extremely sharp tool that allows one to work magic once you're comfortable with it.

One of these years I'll be comfortable with git. Maybe next decade.


This helped me learn git visually.

https://learngitbranching.js.org/

You can probably complete that in less than a day


Make yourself your own git cheatsheet of what you need, and maintain it with examples from usage. It'll click in place and be useful.

have my own cheat sheet. it still hasn't clicked.

I Just copy blindly off the cheat sheet.

hopefully something better will come along.


But you get your job done? Git's just another tool. My guess is you've got bigger fish to fry.

Exactly. Anyone is free to continue using subversion but collectively we have decided the learning curve of got is worth the flexibility.

AFAIK git was initially built to be a source control engine for other tools to build on top of, but most people have just used the underlying engine since it was easier. But I've really started to grok git after using a program called lazygit [0]. Basically a terminal UI on top of git where I don't have to remember the messy language of the engine, I just need to remember a couple of keystrokes.

[0] https://github.com/jesseduffield/lazygit


Reminds me of how Lisp’s syntax was meant to be an intermediate format, but everyone found it intuitive enough that they didn’t bother writing the planned non-sexpr language.

perhaps you have heard of BANCStar: https://esolangs.org/wiki/BANCStar

There are loads of UI layers over git. But largely the git cli is just better and more logical. Other than some minor weirdness, its a pretty good tool.

The GUIs never expose the full power or standard error messages that the CLI will. Had a case where gitlab was blocking a push because the master branch was protected. The git gui gave the wrong error message about why the push was rejected.


Yep. I don't feel the advice in this piece is very useful if you want to create an actual mature product. When you create for just yourself or "one specific person", surely you scratch some specific needs, but how do you ensure that your product won't be a market failure? I'm totally for creating tools to your own heart's content, but this sounds like bad advice when you actually create a for-profit product as a full-time job. A lot of parts of this article also ring really hollow and sound like the cliched "follow your own passion" talk without much substance, which is not that surprising I guess seeing that the author is a uni freshman.

I think there is tremendous value in life in thinking about how to leverage your abilities to the maximum effect to serve and make an impact on the others, even if it might imply giving up part of what you thought you personally like to do the best. (Cal Newport's idea and his dislike towards the "follow your passion" slogan is somewhat similar to this.) A simple example would be trying to build something in your favorite but esoteric programming language which pretty much nobody else uses, instead of using a boring but mature technology with a lot of community support, which practically all big companies do. Will your pet product reach millions of people? Unlikely. Will you lose some of the "personality" that you tried to cling to, if you either join a big tech company, or grow your own company rapidly using battle-tested technologies? Probably. But in the end most wisdom seems to suggest that being able to serve the others (and by definition millions of others are bound to be "faceless") will be ultimately much more fulfilling and mature than attaching too much self-importance to your own peculiar quirks and beliefs that you just can't let go of.


The problem is often that the whole workflow of a user needs change to leverage things like version control and development environments. For example, when the whole company is doing everything in Microsoft Office, there is not much benefit in introducing git.

> There's great power in scratching your own itch

Yes I build for myself foremost, and if other people get to use my tool, then that's a bonus. However this comes with the caveat of having to build in business logic from the get-go (Unless it's FLOSS in which case it's a free-for-all and I would be working for free).


The hobby angle is so powerful. Software engineers are relatively rare so being able to automate and build for any hobby field is wildly lucrative. That's where I've found my projects' greatest success.

>"You need to create for an audience of one that you understand well.

An audience of one is specific. Whether it’s you or someone you know well, there are clear preferences that you can cater to. They have a manageable number of needs and pieces of feedback. Which means that creating for an audience of one is specific and attainable. You have a goal post that can tell you whether you scored or didn’t, so failure and success are both explicitly defined. Now, you know what to make, but more importantly, you know exactly when you’ve failed making it."

Interesting quote. What was not mentioned is how to find the audience for what you create; whether it's a new thing with a new market to be created or an improvement on an existing thing with an existing market.

An interesting blog on why it's important to find the right audience for your work is https://leveragethoughts.substack.com/p/cracking-the-who-you...


> What was not mentioned is how to find the audience for what you create; whether it's a new thing with a new market to be created or an improvement on an existing thing with an existing market.

This. 100%

I have an imaginary audience that I've curated over the years. I use them to critique my draft poems. These voices are people I've met, both online and in real life, in various poetry forums and workshops. They are people who have given me valuable advice about draft poems - advice that I've internalised over time to the point where I can self-critique my new work as I redraft without needing to constantly badger the real 'them' for feedback. They are the people I want to write poems for - even if they don't know it.

OTOH when I listen to an audience of one - me - for feedback on some non-poetry work[1] then I do it knowing that the work is going to end up as Outsider Art[2]. This state of affairs doesn't particularly bother me, but sometimes I do get sad that I've taken paths that real people are unlikely to be interested in. Maybe in fifty years the Posterians will notice, like they noticed Wilfred Owen back in the 60s.

[1] - I posted links to some of my less mainstream works a couple of days ago in another comment, so no need to repeat myself here.

[2] - https://en.wikipedia.org/wiki/Outsider_art


I'm a fan of Ash Maurya's Running Lean (ISBN-10: 9781449305178) and the Lean Canvas methodology it describes.

The entire premiss of that book is to avoid "faceless audiences" but to talk actual people that you think should or could be your customers.

Once you know it is important to find the right audience, the next step is to actually find them and engage. Which is what this "lean canvas" thing is about.


The worst variation of this is people inventing and subsequently refuting an argument that some group of people allegedly made. It's almost becoming rare for someone to refute a political argument in a direct discussion.


Build a straw man to "represent" a group, then refute its argument to deter the target group from ever joining the discussion.

Do you have a kind of "What has been seen cannot be unseen" feel about this? For me, once I noticed this behavior in people, I now see it constantly, and not just with politics, but with any idea that supports the categorization of humans. And I think it's particularly sneaky, because it seems like people who do it perceive their thinking to be logical, due to it containing logic, which is a similar error.

I wonder if there is a way to fix this problem, kind of like a software patch for the nodes in a cluster. In this case though, the nodes seem to be resistant to patching, even if they might desire it...like there's some sort of other software (or something) preventing it.


That "cannot unsee" feeling you have seems like the best remedy to me. Though it's tricky to bring up, if you're not careful you might be perceived as part of the imaginary group with it's imaginary infuriating argument.

I don't get much remedy from the feeling, mainly curiousity!

It helps enormously to know who you are trying to reach. This doesn't necessarily have to be a single person, but, yes, know your audience is terrific advice.

I think we write or create for some faceless other in part because it's easy to criticize and criticism is rampant and people are happy to dog you, your writing or your creation for any old reason. People start trying to figure out how to defend against that and it's not unreasonable to want to defend against that, but it can end up putting the cart before the horse.

If you are writing or creating from a defensive position first and foremost that will impact the creation. It will tend to be all defensible facade and little real substance behind that.

Get to know your audience, try to make sure your audience is some specific individual or some real group of people to whom you can genuinely relate and then consider tweaking it defensively after the fact.


Apple famously ignores its users because typically users just want cheaper/faster versions of what they already have; faster or cheaper horses rather than bicycles or cars.

Smartphone users already had devices they loved like BlackBerry and Palm Treo, not to mention Nokia, etc., but Apple stupidly introduced an "iPhone" that was very different from what smartphone users expected and were asking for. iPhone was like a shrunken version of the failed Microsoft Tablet PC, but without the nice stylus and Windows compatibility. Nobody besides Apple fanatics wanted one - until they actually saw it in action. All of a sudden a Treo-like Android phone didn't seem viable anymore, and Android had to pivot.

Ironically Apple did eventually end up delivering cheap, fast UNIX machines that run all day on batteries and fit in your pocket or backpack.


It’s great advice to focus on a real user experience. It’s easy to get seduced by intellectual thought experiments about user convenience, that don’t translate into real enjoyment that drive real people’s behavior. I’ve made this mistake often, even when trying to predict my own enjoyment.

The subtle thing here is that experience is emotional, not mechanical. It can be difficult to stay attuned to your emotional intuition while you are analyzing and coding all day.


"Do it for yourself" is great creative advice that I've gradually arrived at on my own. I have been creating something that I have shown to maybe a couple hundred people and none of them connected with it on any meaningful level. To me, it's the best thing ever and I'm obsessed with it, but no one else seems to get it or like it. But somehow I keep the project alive exactly because I really am doing it for myself. Yes, I do hope that others will also grow to love it eventually, but it's not the main motivation. If it were, I would have gone crazy by now.

Could you tell us more about your project?

This went in the opposite direction to what I expected, but I think I agree with it. I expected it to be about getting feedback early and often from real users, but it was about trusting your own feelings about a project. Both are valid approaches and better than fretting about the imagined reactions of people you aren't getting direct feedback from.

> about trusting your own feelings about a project

was also when I started disagreeing. Sure, your gut-feeling is a good guidence. Asking yourself "do i need this polished" or "would I stop using the software if X is removed" is great advice.

I disagree because I think better advice is to make it slightly more scientific: "Most people would jump ship to a competitor if I remove X" is easily proven (just remove it), but also researchable: remove it for a cohort. Ask 10 random customers. Check your event-log or database if X is actually used currently.


This reminds me of this video[0] of a philosophy teacher who argues that we've entered a new era of "identity" where identities are based on curated profiles vs. what it used to be, around so-called "authenticity." One of the aspects of that is our identities are curated now to appeal to the "average online follower" (he calls it the "general peer") which is an abstraction of the "typical" person we cater to to get engagement (likes, follows, etc).

[0] Forgot video: https://www.youtube.com/watch?v=-QMHOsfjHq0

Timestamp when he talks about the general peer https://www.youtube.com/watch?v=-QMHOsfjHq0?t=1228


Seems to be more of a personal problem of the writer: "Many of my high achieving friends had an underlying anxiety and discontentedness."

The more common "creating for an imaginary group of people" problem is creating a product for a too-narrow niche. You see a lot of those if you go to VC presentations. It's classically a problem of writers writing their first bad novel.[1]

[1] https://youtu.be/yYvkICbTZIQ


> creating a product for a too-narrow niche

In my experience, the opposite is more common. Instead of just nailing core feature A, devs start thinking that users will want features B, C and D as well. And this is before even entering beta.


Why is a very narrow niche as a starting point a bad thing?

What an phenomenal band and song... My god.

I was reading this strongly expecting it to be about startups and avoiding creating a product for non-existing users. It was such a pleasant surprise to learn this is about not comparing yourself to others and living a happy life. I think it's more than a coincidence that the right answer in these two vastly different areas overlap so neatly.

Persona development in user-centered design (see https://en.wikipedia.org/wiki/Persona_(user_experience) ) puts a face on the imaginary group by developing a single persona to represent that group.

Of course, there are many possible users, so there may be many personas. Persona development lets you decide which one or two to prioritize.

Cooper use the term "The Elastic User" to describe what this essay describes as "The Faceless Other", and the associated vagueness.

If you are writing software for software developers then you can likely follow the HP approach - "design for the guy at the next bench".

If you write software for non-software developers, it's harder to know if your personal views are a good guide.


I don't know. For example, I'm not even active on Twitter but rabid social media lynch mobs scare the hell out of me. Sometimes an imaginary group of people imagines itself into existence and decides you will be the main character of its crusade.

Am I allowed to use the word "black" to describe a visual aspect of an evil character? Am I allowed to release code with a master branch? What if I misgender or deadname someone accidentally? What if I don't have a code of conduct?

Creating anything right now is fscking terrifying.


This is akin to being afraid of going outside because you might be hit by a car. Yes, innocent pedestrians get hit by cars and well-meaning people get hounded by Twitter mobs. These things are awful and we should strive to eliminate them.

But it's also rare enough that you shouldn't let it stifle your creativity. Don't worry about Twitter coming after you over some misunderstanding. There are far more important things to worry about. I'll tell you my biggest worry: making something no one wants.


Thanks. That's a really helpful perspective.

As someone not on twitter I haven't noticed them. I would leave twitter behind. A twitter crusade doesn't last too long either, the mob is smaller than they appear and can't keep up with attacking everyone at once plus they crave novelty outrage. Yesterday's outrage doesn't cut it and emotions go flat.

I think it extends even further than that. Don’t live for an imaginary group of people you think are watching you. I find myself doing that a lot and it is so silly.

Meanwhile in UX it is all about understanding the Other, the specifically Not Me, and creating products for a researched, understood and empathetically engaged many.

The implication is that if you don't have an audience, it should be you. Instead of Faceless Other, create for yourself.

I just spent the last year doing this and the trap with this is that you may end up building something that you love but nobody else does, or at least not enough that you can reach them easily.

This article didn't go where I was expecting it to, but I liked where it ended up. I thought it would suggest a data driven approach, but it instead said to ignore everyone else and just follow your heart, which is more humanistic and a needed message right now.

What do you suggest we do and what do you except the voters, managements, shareholders, jury, customers and parent will think about it? I don't care what they think, or want to but seems to me that is what most people do all day.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: