caminmccluskey

It's still possible, and I suspect likely, that many more problems will require new creative advances. Creative advances that may have arisen in the regular course of attempting to solve these problems that were nevertheless amenable (often in a very alien brute-force way) to combination of existing techniques

Thanks so much for trying it out, and for your feedback. You're right, that is a bit wonky - we should change the UX for inputs when the maximum of the range is massive, will get on that asap.

UXWizz looks great! Unfortunately we don't yet list self-hosted tools simply because our audience generally does not have the technical expertise to set these up. If that changes in the future (and I could see that happening) we'll definitely look into evaluating your platform for inclusion.

Hi HN! I'm Camin, co-founder of Stackfix. We've built a B2B SaaS comparison platform to solve problems we experienced when buying software.

Evaluating SaaS tools today typically requires piecing together information from marketing pages, user reviews, and sales calls just to understand features and pricing. Existing comparison sites unfortunately don't solve this because their business models depend on incentivized reviews for vendors [1].

Our approach is different:

- We have in-house human experts who test every product using consistent, category-specific rubrics.

- For pricing, we combine vendor information, mystery shopping, and customer data to build models that reflect detailed costs, based on your usage.

We'd love feedback on two core features in particular:

- Pricing calculator: https://stackfix.com/pricing-calculator - Get estimates without talking to sales

- Side-by-side comparison: https://stackfix.com/compare - See true feature parity

We're starting with comprehensive coverage of major categories (CRM, ATS, Product Analytics etc). We're focused on depth over breadth for now. Thanks for taking a look :)

Visual demo: https://www.youtube.com/watch?v=cBOGySb6zvc

[1] https://news.ycombinator.com/item?id=41620432

I really like the Twain quote.

With reference to OP; you'll notice on this site and elsewhere on the web, the best posts are very frequently of the form - "I just figured out this thing and I'm writing this blog post to share my experience while it's fresh in my mind". We could speculate on why that is but I imagine it's because they tend to be much more relatable and actually more helpful to anyone searching out how to do something for the first time. Since you'll likely directly address the questions an expert will have forgotten they ever had.

I definitely share your view that the content there is lack lustre (was it ever great?) and it's certainly a high noise-to-signal platform for job searching.

My experience is that it is still an excellent place to reach prospective buyers and to do a semi-authentic style of marketing. The number of impressions a good post gets far exceeds other platforms (X, Medium etc) and, if you're pretty diligent about your connections, those impressions are generally high-quality in the sense they are in your target market.

I've seen a few post from others more successful that me, on this topic. Including Gagan Byiani (Udemy cofounder)[1]

[1]: https://www.linkedin.com/posts/gaganbiyani_ive-had-over-1m-i...

Stand out from a crowded job market by writing technical blog posts. This is super valuable advice I wish I'd known much earlier. Now I'm in a position to make hiring decisions, developers which can prove their mastery and passion through their writing stand head-and-shoulders above other candidates. Perhaps most importantly, through writing, they demonstrate a clarity of thought and give an insight into their personality which allows them to effectively shortcut a major part of (at least my) interview process.

A reassuring take on the history of automation as a labour substitute. While I'd like to believe the fundamental message here still holds from 2015, recent advances make me a little less confident that the following continues to be true - "many of the middle-skill jobs that persist in the future will combine routine technical tasks with the set of nonroutine tasks in which workers hold comparative advantage: interpersonal interaction, flexibility, adaptability, and problem solving."

(for any put off by the length, the paper is very comprehensively referenced. The actual content is 25ish pages)

I had no idea you could do this. Very helpful for theming where the colour of elements needs to be determined at runtime by the user

Appreciated but what we need is the oral history of Jack Dorsey in this time period to understand if this was the only problem he was considering working on. As I say, even if that were true, the problem != the idea. The problem is a starting point for potentially many ideas.

> "I want to start a company, what should it do?"

That's not what the article is saying, although I appreciate the sentiment exists. The core idea was that, if you are someone that likes to solve problems, and you've noticed some in the world, how do you figure out a) which of them is a good idea to work on and b) if you find out your initial ideas are flawed, how should you improve them?

I don't mean to single your comment out but I see a common idea I disagree with throughout this comment section namely:

"You should only work on the 1 problem you have a burning desire to solve"

I get why people feel like this. There is a culture of people that just want to start companies because it seems cool. To that I say, so what? If they solve a problem for people, and are successful, it doesn't matter what their initial motivation was and if they fail they fail. Secondly, a problem is not an idea. A problem is a starting point for many ideas - what I think could be better understood is how to ideate from a problem as a starting point. Thirdly, curious people exist in the world and it would be a good thing if they were solving problems and maybe starting companies as a vehicle to distribute their solution. Curious people don't have a single thing they're curious about, they may have many problems they'd like to work on, Elon Musk had a list of at least 2 (humans aren't multi-planetary and we're running out of fossil fuels) but slotted in online ads & payments first because it was a better problem to solve for him at the time.

Agreed the primary objective is solutions to problems. I tend to think the best solutions will very often come from entrepreneurs and startups but that need not always be the case.

However, on the margin, you should choose to solve the biggest problems for the most number of people. If you succeed in doing that you may be able to build a venture scale company (and arguably you should). Furthermore, it's hard to build a company either way, so you might as well try to solve the most ambitious problems you can.

On the Square point - I don't know Jack Dorsey but I would find it hard to believe that he chose the "street vendor" problem as it was the first thing worthy problem he saw after Twitter. Furthermore just the problem statement is not enough, making X easier is not an idea. *Ideation is was happens after you've noticed that initial problem.* A nuance that seems to be lost when people talk about startup ideas.

Should have made a problem generator first :)

Then you'll agree it was used correctly, if metaphorically, in the article :)

Yep finding opportunities to take advantage of changes in technology to solve a problem 10x better is part of ideation.

> “want to work on this problem; business seems to be the best way.” This is the right attitude but I would ask - why limit yourself to a single problem?

I think it's very easy to over-index on this point. Indeed I think it's now super fashionable to do so. The whole "ideas are cheap, execution is everything" argument.

Ideas aren't everything but they are important. The crucial distinction is that the initial idea isn't that important, iteration to an idea you can scale (and the execution that follows) is.

Totally agree that a valid approach is looking at what should exist. I also agree that the issue with that is that your conception of what should exist needs to be grounded in reality. Ensuring you're focused on problems is that "contact with reality".

To that end, I would contend the examples you give are absolutely founders that wanted to solve a problem (or realised very acutely that they were solving a problem as they built something new)

Facebook's core problem was figuring out if that person you met at a party was single without being creepy. A problem that Instagram now solves much better (coincidental acquisition? I don't think so).

The 2 Steves initially met and solved the problem of long distance phone charges by building legally questionable "blue boxes" - https://en.wikipedia.org/wiki/Blue_box. They later united on the problem of bringing computers, which they had a passion for and knowledge of, into the homes of everyone.

Amazon is an interesting point - Bezos saw the clear trend of increasing internet usage and realised there needed to be commerce online. He was certainly smart about the type of things that could sell well on the early internet. I would argue it solved a problem - long tail commerce (i.e. bookstores can't stock books about any conceivable topic) - but I'd concede that perhaps wasn't the primary initial motivation.

Looks really slick! Can think of quite a few tedious manual processes that could be eliminated by this.

It's a very tricky book to get a handle on, I must confess I've only made it halfway. I made a sort of "reader's companion" app to try to make sense of some of the esoteric language and references - https://camin.xyz/ulysses-companion/ (not at all mobile friendly)

Full credit goes to John Hunt, The Joyce Project at joyceproject.com for the annotations, I just found that site very tricky to use as I read.

Awesome progress, congrats on that! How did you know blood sugar was out of control, where you actively measuring I guess? Also really feel you on "Record progress as appropriate", it seems like progress is never going to be that quick (and may fluctuate a lot) which demotivates me. How did you decide what was appropriate, in terms of cadence of measurement?

I went back and forth on whether it was a good idea. In the end I wrote one and it was well received by my team. Indeed, most of the team wrote one and we collated them in our documentation space. This was pretty helpful in the first few months of lockdown, when people's work preferences and constraints were quite varied.

I also decided to write up a short piece on the pros and cons + some advice if you are considering writing a User Guide (or README or Personal User Manual) - https://medium.com/better-programming/personal-user-manuals-...

[Edit: Grammar]

I wrote something about this pretty recently - a pitch/anti-pitch to these sorts of guides. I do think the tl:dr is that you need a high level of psychological safety in the team to make it workable. Although I think the act of writing one can be a useful exercise in itself, I certainly hadn't thought deeply about what my preferences are for work. It also gave me some ideas of what I could work on personally.

https://medium.com/better-programming/personal-user-manuals-... <- scroll down for the pitch/anti-pitch :)

We've build an app to help housemates deal with the myriad of problems that come along with sharing a house together.

We're pretty early stage but have an iOS and Android app on the respective stores. I'd love to get your feedback - is this something you'd use? What problems are we overlooking?

Feel free to play around with app, we'd be very grateful for some constructive feedback as we'd like to iterate for a wider launch in a couple of months.

Thanks, inHouse Team :)

shortcut links: iOS: https://apps.apple.com/gb/app/inhouse/id1488409238?mt=8 Android: https://play.google.com/store/apps/details?id=io.inhouseapp....

Thanks for your thoughts, Twitter is a melting pot, and that's a fantastic thing. I would probably agree that fundamental social problems can't be "fixed" by technical solutions. However Twitter (in particular) seems to exacerbate out of group bias

Although with that said, I don’t notice political views seem to enter most discussion regardless of topic

My pleasure, glad it was interesting.

It's a semi-grassroots initiative, there is a steering committee made up of various engineers, some of whom are involved in engineering education. The work is supported by senior engineering leadership.

The other core idea is that these principles are internally open source, and as such are there to be refined by engineers.

Really like this idea, and thanks for the tip!

This is a good question - I found recently that I was following more political accounts and maybe if I used it just to keep up with my industry/hobbies I might have a nicer experience. Does anyone find twitter is a pleasant/supportive place though? (Genuine question)

I had been thinking about a sort of human prompt, like a time window to take back a tweet with a prompt to consider if it’s kind/necessary. Won’t do anything about bots, since I imagine it would just be a tick box or something, or no action means you’re happy for the tweet to send

I really like the Karma system. I think Karma as a way to decide user permissions is interesting (as is the case on hacker news). I also wonder if karma should decide the “reach” of a tweet, that way more respected users get to amplify their ideas and trolls do not. Downvotes is a contentious one, as we want to foster active debate. The issue I see with downvotes is that their ambiguous - you might downvote because you disagree with the statement OR because you don’t like the tweet.

We use them in my current company. I've found them useful and they have great buy in across the engineering org. There does need to be a certain level of commitment to make it worthwhile, feedback needs to be taken onboard and processes and reward need to align to the principles also.

Engineering Principles: https://github.com/Skyscanner/engineering-principles Some background (may be slightly out of date): https://medium.com/@SkyscannerEng/an-update-on-our-engineeri...

In summary - definitely useful, but to avoid the issue you raised around documentation like this becoming a relic you need to commit as an organisation to living by the principles and reviewing them often enough

(*all my opinions - not the necessarily the opinions of my employer)