1. 9
  1.  

  2. 7

    This post is really short, and yet, not quite short or long enough, IMO.

    tl;dr: Learn how to how solve hard problems, rather than just farming out all the work to closed APIs.

    To be fair, it is a good insight to gather. I’d be interested to see what you end up doing in your rage against APIs, but I’d also be interested in how you came to this conclusion. Sometimes the journey is as insightful as the conclusion

    1. 2

      Thanks for the thoughtful feedback! I agree and will definitely think about that going forward :)

    2. 6

      I thought it was the perfect length. Rage against overwrought blog posts!

      1. 6

        make phone calls, view weather data

        These two examples are not very good. You generally do want to use an API for these.

        Weather data is data. You’re not going to set up your own weather stations across the world :D

        Phone calls/SMS is an interaction with a complex external system. Back in the day at work we had a GSM modem attached via some thing to a computer to send internal alerts. It was… not the most reliable thing :) And I have no idea how you would do that at scale — business agreement with a phone carrier? who… would… give you… an API?

        1. 3

          Definitely a good point!

          Just for the sake of argument, wouldn’t it be interesting to set up weather stations around the world — or be part of a company that does?

          As for phone calls, I was initially thinking of Twilio, one of the classic hackathon APIs in my experience. Definitely not saying that they aren’t super useful if that’s what you want to do, just that people might get more out of focusing on building a telephone system prototype rather than hooking together API calls.

          I think in general I’m approaching this from a personal growth sort of viewpoint, if you’re trying to make the coolest product by all means use APIs!

          1. 2

            Just for the sake of argument, wouldn’t it be interesting to set up weather stations around the world — or be part of a company that does?

            Interesting in terms of finding problems to solve, sure. Not so interesting in terms of finding new problems to solve, in that weather stations already exist, systems which aggregate the data they collect already exist, and, in general, all of this work has been done.

            As for phone calls, I was initially thinking of Twilio, one of the classic hackathon APIs in my experience. Definitely not saying that they aren’t super useful if that’s what you want to do, just that people might get more out of focusing on building a telephone system prototype rather than hooking together API calls.

            You should be careful about disambiguating between interoperating with other systems to use resources which are by definition external (such as the public phone system) and interoperating with other systems to do work you could just as easily do internally. I agree that relying on external systems to run a PBX, which is by definition internal, is bad, but there’s literally no way to place an external call without… placing an external call, which necessarily involves an API you use to talk to some phone company.

        2. 4

          An API is no substitute for open source, but open source still needs apis.

          1. 2

            APIs are useful even when you have full access to the underlying source code!

            But being able to read existing code is actually a more valuable skill than being able to write greenfield code. Incredibly, this is not what engineers get tested for during interviews.