Hacker News new | past | comments | ask | show | jobs | submit | caminmccluskey's comments login

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.

"This is super valuable advice I wish I'd known much earlier."

Thanks! That's why I have been talking about technical writing and its power since I started with it in 2019. Many engineers disregard it as "ah, it's just blog posts", but it's more than that. It can have a huge impact on your career.


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)


From page 26 to page 96! 1266 in all.

TL:DR;

The bogeyman of automation consumes worrying capacity that should be saved for real problems . . .” A half century on, I believe the evidence favors Simon’s view.


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


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.



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.


Should have made a problem generator first :)


The rest of us (humanity) are working hard at that.


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?


Well I have worked on lots of problems over the decades (acceptance of open source in business, guess that one worked :-), internet servce (before there were ISPs), drugs in the water supply, remote loally-maintainable solar... and a business is not always the optimal approach.

Saying "I want to start a company, what should it do?" seems like putting the cart before the horse. I guess it matters if your primary goal is actually "I want to make a lot of money", but that's kind of lame for a primary goal IMHO.


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


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.


> iteration to an idea

I do 100% agree on this, but... I've never seen any discussion of the importance of ideas that wasn't exclusively referring to initial ideas.

So I don't think there's really any risk of overindexing; people who discuss this from a pure ideation perspective aren't talking about iteration - at least not in a way that's realistic. The op talks about "linear ideation" and "restarting flywheels" as what seems like esoteric metaphors for iteration but they're entirely focused on pre-build/pre-execution ideation.


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.


Thanks a lot - any specific use cases you'd be interested in trying just let me know and can look into it for you!


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

Search: