Hacker News new | ask | show | jobs
by josephg 1839 days ago
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.

9 comments

>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

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.

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
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.