Thread by @LukasRosenstock

Even though I haven't been a big fan of Twitter threads so far, a lot of people I know have made 100-tweet threads for @threadapalooza so I thought I'll give it a try as well. I will start with #APIs and hopefully end up connecting them with the #FutureOfWork. Let's go ...

🧵⬇️

First of all, when I talk about #APIs, I mean HTTP-based interfaces connecting apps and backend servers as well as different services with each other. For now, the technical details, such as whether they use REST, GraphQL, gRPC etc., shall not matter. (1/100)

When humans interact with computers they require a user interface (UI), and when machines interact with each other they need application programming interfaces (APIs). At the end of the day, however, these have to be implemented by humans. Good #APIDesign considers both. (2/100)

The API must be capable of transferring data in a fast and efficient manner required by the use case, while at the same time be understandable by the human developers on both sides. That's the interesting challenge of #APIDesign. (3/100)

Do we always need humans in the loop? Can't machines figure out a way to communicate, or can at least one side provide a contract that a machine on the the other side can interpret? There are concepts like #Hypermedia and interesting work (e.g. by @superfaceai). (4/100)

Still, I believe there's no magic solution and some human work will be necessary in many cases. More generally speaking, there's so much potential in #ArtificalIntelligence and #MachineLearning but that doesn't mean these technologies replace programmers in the near term. (5/100)

Talking about programmers, I believe that we need more of them, not less. I don't necessarily mean traditional full-time engineers but a variety of people adding coding to their skillset and toolbox. And by coding I mean mostly algorithmic thinking and modelling. (6/100)

Algorithmic thinking and modelling and #API integration can happen in #LowCode or #NoCode environments like @zapier as well. The primary skill is understanding that computers are extremely great at following orders but these orders must be accurate and unambiguous. (7/100)

I am sure we'll see an increasing amount of non-developers - which we'll call #CitizenDevelopers - using #APIs and #NoCode tools to build solutions that would otherwise have required a dedicated developer or even whole team to implement. So what about programmers? (8/100)

In the same way that #MachineLearning won't take jobs away from developers but may redefine them it will do the same for the #NoCode space. Someone needs to build and maintain the #NoCode tools after all and these people need a vision to empower more people. (9/100)

The idea of empowering more people to use #APIs - even in a #NoCode environment - puts some emphasis on two additional fields and skills - #DeveloperExperience (#DX) design and #APIDocumention. We must not just create APIs but make them accessible to the masses. (10/100)

Let's start with #APIDocumentation. A reference documentation of all endpoints, parameters and schemas is a good start and absolutely necessary, but by no means sufficient to enable people to use an #API. You need a lot of material to teach and guide developers. (11/100)

I don't remember who said this (probably someone I met through @APItheDocs), but "every API is someone's first API". And, as I've mentioned, the people for whom it's their first may come with totally different prerequisites. As an API provider, you need to consider this. (12/100)

The very least you need on top of reference documentation is a "Getting started" guide that takes your users to their API call - the "Hello world" example. Don't forget sample code in different programming languages. (13/100)

When it comes to developer tutorials, the more the merrier. Some developers prefer prose, some prefer complete sample applications, some developers prefer video tutorials. Make sure you address their needs. (14/100)

As this thread has now become a pitch for API providers to improve their #APIDocumentation, grant me a commercial break and let me announce that you can hire me as a consultant to improve your docs. Reply or DM. Alright, back to the previous program. (15/100)

Let's quickly touch #DeveloperExperience (#DX). Your #APIDesign and #APIDocumentation are the two major parts of it, but there's others such as developer portal design (my friends at @pronovix know a thing or two about that) and onboarding experience. (16/100)

Again, keep in mind that you're targeting different personas. The seasoned software engineer, the student learning to code, the maker trying to build something with #NoCode. If you want to stand out, serve them accordingly. (17/100)

Switching gears from the "How?" back to the "Why?" of #APIs. Of course, an API provider may have intrinsic profit motives for empowering more people to use APIs, but how does the larger world benefit from it? (18/100)

I'm a big fan of #startups, small businesses and solopreneurs or indie makers. It's amazing to see a single person or a small team bring a product to market without the backdrop of a larger organization. #APIs are one of the drivers that make their journeys possible. (19/100)

For me, this is what a free-market economy should look like. A variety of smaller organizations focused on the needs of their consumers and building their value-add while offloading infrastructure and generic work to others through #APIs. (20/100)

For consumers, both individual and businesses, a larger number of suppliers adds some complexity and maybe an overload of choice ("paradox of choice"), but some healthy competition can improve products and provide tailor-made solutions for different target segments. (21/100)

Many people are familiar with @JeffBezos' "two-pizza rule", which says that no team should be so large that you can't feed them with two pizzas (that probably depends on the size of those pizzas too, but I digress ...). I think this rule can be taken a step further. (22/100)

There's a huge amount of software companies - maybe even a majority - that don't have to be larger than a single "two-pizza team" and still provide the massive value of their API-driven supply chain in a highly targeted offering. We're seeing successful solopreneurs. (23/100)

Think about @anthilemoon of @ness_labs or @levelsio of @NomadList - both single founders with a product that relies on community, #APIs and plain software (PHP!). I would love to see more of these and APIs can help us towards that goal. (24/100)

The broader reality is different. The GAFAM - Google, Apple, Facebook, Amazon, Microsoft - take over a huge part of the online world and expand their reach through R&D, M&A (acquisitions) also sheer power through network effects. However, I'm not here to bash the GAFAM. (25/100)

Google, Apple, Amazon and Microsoft are #platform providers with their own #APIs and three of them are also big players in #CloudComputing so they have provided opportunities to the wider ecosystem of smaller players, something that shouldn't be discounted (26/100).

Still, there's no good balance right now and we're being driven into a polarized world of a few giant corporations and an army of self-employed makers (I think @levelsio said this but can't find the statement). I think we need some alternatives in the middle as well. (27/100)

Right now, even though #APIs are often called "open APIs", the API provider has a lot of power. They can build the APIs that benefit them and shut them down when they no longer need them. This has happened a lot, especially with social networks like Facebook and Twitter. (28/100)

On one hand, this highlights the importance of not just designing an #API as a technological interface but also think of it as a product and how it fits into the business. For example, free API access is often incompatible with business models relying on ads. (29/100)

Good #APIGovernance includes a clear and transparent set of rules on what consumers can expect from the #API and what they can't Handling versioning, deprecations and eventual sunsetting of an API is part of that. Offering an API that isn't sustainable doesn't work. (30/100)

Luring consumers with an unsustainable #API business model in the hope of capturing more value than you give away and then alienating your developer community by turning away when you no longer need them is just unethical.(31/100)

I want #APIs to remain with a vision of empowerment and interoperability, a tool to create more value by combining forces. As API practitioners, we should call it out when the spirit of APIs is violated. (32/100)

However, the burden is also on the consumer. Even though I advocate using #APIs, you must be mindful when integrating APIs that you have a third-party dependency outside your control. You must have a fallback strategy in case the API goes down. (33/100)

Going back to the balance between large platform providers and smaller companies, there is an interesting idea from @albertwenger called the "right to an API key". Platform users should be given access to data instead of being locked in to limited user interfaces. (34/100)

An example would be ridesharing companies like @Uber. With the "right to an API key", drivers could use third-party software to improve their experience and potentially optimize for multiple marketplaces instead of having to rely on Uber's driver app. (35/100)

A very small glimpse in this direction is the "right to data portability" set out in the #GDPR which gives individual consumers the right to obtain a machine-readable copy of the data that a company has on them. Far from realtime #API access, but it's a start. (36/100)

(I'm taking a break now as I've reached the limits of @typefullyapp and also don't have more time right now, but this thread will eventually be continued.) (37/100)

OK, I'm returning to where I left off and talk about power dynamics in platforms. Some people believe that centralized for-profit platforms are always unfair and exploitative because they put shareholder interests before stakeholder (employees, customers) interests. (38/100)

Whether or not that narrative is true, it's interesting to explore alternatives. One of those is platform #cooperatives - transfer ownership to the stakeholders. In his book "The zero marginal cost society", Jeremy Rifkin claims that coops will play an increasing role. (39/100)

Traditional coops, like the "Genossenschaft" in Gemany, are based on the idea that shares are owned by members who benefit from the coop's services. In a Genossenschaft, every member gets a vote, no matter how many shares they own. (40/100)

Apart from the traditional model, there are more modern approaches, like DAOs - distributed autonomous organizations - who are held together not by people but by smart contracts on blockchains. I don't know enough about that space to go into detail, though. (41/100)

Instead of aligning the incentives of a single #API provider or platform with its consumers, we can also look into decentralization. The first approach is to design universal APIs, or protocols. It's not a new idea, we all use these every day. (42/100)

The reason why you can (mostly) access every website in every browser is because #HTTP and #HTML are standardized and everyone can build a HTTP server, HTTP client, HTML generator, and HTML parser. The same goes for email where you have, e.g., #SMTP. (43/100)

There are more protocols, like #RSS feeds, built on top of #HTTP. There are also things like #ActivityPub, #Matrix, #XMPP etc.. Building protocols is hard, though, because they're not driven by a single organization's #APIGovernance but multiple stakeholders. (44/100)

Smaller players in a market like open protocols because it gives them equal footing while larger organizations play a winner-takes-all game and either ignore the standards, follow an embrace-extend-estinguish strategy, or drive them into prohibitive complexity. (45/100)

Another problem is that there's not just one open standard or protocol for a specific use case, there are often different standards to choose from - see XKCD. (46/100)

xkcd.com/927/

An interesting element common in many open standards is the idea of #federation. Users have accounts on one server but can exchange messages or data with accounts on other servers. Think about email: You can send it to any email address, no matter who the provider is. (47/100)

With #federation, there is no vendor lock-in, as all servers still form a network. There's typically a client-to-server #API and a server-to-server API that makes this happen. As witnessed with emails, the downside of open, federated networks is SPAM. (48/100)

Also, even though #federation connects different networks, users still have to choose one server as their "homebase", and if they want to move between servers their user ID changes. There are other approaches to #decentralization that deal with that. (49/100)

The concept of self-sovereign #identity or decentralized identifiers (#DID), full peer-to-peer #P2P networks using blockchains and distributed hash tables (#DHT). These technologies are still in their infancy, though. (50/100)

When the original Internet mostly relied on protocols with #federation such as email, with the "Web 2.0" era we became used to walled gardens like Facebook and Twitter as means of communication. Some of them have grown too big to fail but nobody knows if the tide turns. (51/100)

I spent more time on #decentralization in this thread than I intended, because it's something I'm really curious about, but also frustrated because many of the newer protocols are still "toys for nerds" and don't reach the masses. (52/100)

One approach and community I like is the #IndieWeb (I have attended @indiewebcamp before) because they seem to be pragmatic about it. They believe everybody should have a domain and their own website as a #blog or #digitalgarden. (53/100)

Besides that, the #IndieWeb focuses on lightweight #APIs like #webmention to connect their websites and #syndication (#PESOS/#POSSE) to bridge the divide towards the walled gardens of the "Web 2.0" era. (54/100)

I also want to give a shoutout to @joinmastodon, a federated Twitter-like social network based on the #ActivityPub protocol. You can join any instance and follow me on that network, too, where I'm on an #IndieWeb branded server. (55/100)

indieweb.social/@lukas

Unlike others in the #decentralization community, I do not believe that decentralizing our tools and social networks solves all their problems and that we necessarily have to decentralize everything. I believe in hybrid approaches that bridge different worlds /protocols. (56/100)

Also, #decentralization is not a business model! We cannot rely on infrastructure run by hobbyists. There is space for both for-profit companies and not-for-profit players like communities and cooperatives. (57/100)

Due to the fact that #decentralization can be messy and complicated, I see enormous potential for small and medium companies to bridge the #APIs of various centralized and decentralized players and add some additional value that's worth charging for. (58/100)

Alright ... I wanted to eventually move from #APIs to the #FutureOfWork in this thread, so let's switch gears again. When we talk about the future of work, we need to consider individuals, organizations, and society at large. (59/100)

Talking about individuals, I already mentioned that coding skills, or at least algorithmic thinking that can be applied in a #NoCode environment, becomes more important. #CitizenDevelopers should also be able to access the potential of #APIs and a "programmable world". (60/100)

What is a "programmable world"? It's one where everything is designed with #automation in mind; i.e., every thing has an #API so it can be a part of workflows that can run without human intervention and observation. (61/100)

To enable #automation, we need to think different about the capabilities that a thing enables beyond user interfaces. This is a change for #UI/#UX designers, who have to understand a system not just in terms of pixels on a screen but also a broader set of interactions. (62/100)

An #APIMindset - thinking of every product as a programmable entity - changes not just the work of #UI/#UX designers but every non-technical role involved in product development and management needs to have an understanding of #APIs and their implications. (63/100)

Apart from ignorance about the potential of #APIs, power plays that rely on market dominance or business models that require control over user experience, we may fear #automation as a job killer. Better, more automated workflows thanks to APIs mean less human work. (64/100)

Regardless of whether technology just changes jobs, creates new ones, or kills of others, we have to be ready. The #FutureOfWork will bring a much more flexible and dynamic job market. The stable, career-long 9-to-5, becomes less prevalent. (65/100)

Not only will requirements for salaried employees change, making #LifelongLearning a necessity, there will be more contract- and project-based freelance arrangements to bring specialized experts into a team for a limited amount of time. (66/100)

As more people go the freelance route, they will form groups in which they pool their knowledge and can act like a company without being one. As I say this, @yak_collective and @TheaFreelancers comes to my mind. Also marketplaces like @Upwork are destined to grow. (67/100)

If the #GigEconomy becomes a larger part of the economy, and the job market, our state-run social security systems need to adapt. While it may take some time to be fully implemented, I think the universal #BasicIncome #UBI is eventually inevitable. (68/100)

I can't foresee all the new job descriptions that will exist in the future, but in the segment that I'm in, I believe #DeveloperExperience, #DeveloperRelations/#DevRel and #TechnicalWriters are roles for which demand is growing as we make #APIs accessible to more people. (69/100)

Software developers will continue to be in demand at both large and medium-sized organizations but also as freelance experts. The latter have to think of themselves less as coders but more as consultants and what @daedtech calls "efficiencers". (70/100)

Even as #APIs and #NoCode tools grow and become more accessible, not everybody can keep up with them while working at an unrelated job role. That's where the consultant comes in to analyze their business problems and how technology can help them. (71/100)

The efficiencer uses the least amount of code needed to integrate #APIs and implement workflows between #SaaS tools that the client already uses. Not everybody can afford to hire custom development, but a few hours time from an efficiencer can go a long way. (72/100)

There's another aspect of the #FutureOfWork, and that is #RemoteWork. This year, due to the pandemic, it has grown a lot, and while it will not stick for everyone, some people will enjoy getting rid of the commute for good. (73/100)

As travel becomes possible again, we may see more people leveraging their new-found freedom in #RemoteWork by becoming #DigitalNomads. For the sake of the planet, I hope that they will look into it as a method of #SlowTravel rather than hopping planes. (74/100)

Something I only realized through an article that I read this year is how much #RemoteWork and the #GigEconomy a.k.a. the rise of freelancers and solopreneurs are connected. Each of these trends supports the other. (75/100)

The short version: #RemoteWork decreases cohesion inside a company and allows broader communities (like freelance collectives) to become a replacement. The longer version is in my blog where I linked to the original article, too. (76/100)

lukasrosenstock.net/2020/08/12/one…

In a sense, #RemoteWork is a similar form of #decentralization in the real world as federated or #P2P protocols are on the Internet. Activities move away from centers of action (like #SiliconValley) and spread throughout the planet. (77/100)

With #RemoteWork, developers and other knowledge workers compete for jobs globally. If education and skills develop faster in a country than living costs and salaries do, this is good news for places like Nigeria and slightly less good news for Europe and North America. (78/100)

A more equal world where possibilites are evenly distributed is better for humankind. However, the person who just got laid off because their job went to a cheaper country, probably disagrees. This brings me back to another topic. (79/100)

Where more flexible work arrangements, less human work, and global competition come together, the argument for #BasicIncome as a safety net grows even stronger. But keeping a majority of the population out of the job market doesn't sound too good either. (80/100)

I think we have to redefine the meaning of jobs. A lot of our society is based on the idea of #workism and that a well-paid job is good per se, both for the individual as well as the society which benefits through income taxes, and full-time work is default. (81/100)

If we can simplify and automate work and that causes a loss of jobs, isn't that a reason to celebrate? Less work means more free time to pursue hobbies, creative and intellectual pursuits, care about family, or volunteer for people in need. (82/100)

One part of our society engaged in traditional paid works and the other just volunteering and collecting #BasicIncome may not be the best setup either. It would be good if everybody had the option to do both. (83/100)

An interesting concept is #NewWork by Dr. Frithjof Bergmann @FrithjofNewWork. In this scenario, every individual can spend roughly one third of his time in one of three areas: traditional paid work, self-reliance/DIY and self-actualization. (84/100)

Traditional paid work is reduced to a third of the time that it takes right now. Today part-time work is considered a temporary exception. Even freelancers with good hourly rates who have the privilege of reducing their paid hours rarely do this. (85/100)

The second area motivates people to produce their own goods, e.g., through small-scale farming and #3DPrinting or engage in local networks to buy less and share more, reducing reliance on the market and #capitalism, ideally being more #ecofriendly as well. (86/100)

The third area finally is about helping people find out what they "really really want" in their life. Very few people have the privilege and the opportunity to do this today. In Bergmann's vision, "centers of #NewWork" help people find their goals. (87/100)

I don't think that the #FutureOfWork like look exactly like Dr. Bergmann describes but I find his vision inspiring because, similar to Jeremy Rifkin whose "The zero marginal cost society" I quoted earlier, he thinks beyond #capitalism without resorting to #socialism. (88/100)

I am very confident that with the challenges from #ClimateChange and the technologies that enable #DigitalTransformation our future economy and society will be much different from today. Talking about #capitalism vs. #socialism is so 20th century! (89/100)

Out of all the tech that is part of #DigitalTransformation, #APIs are not often the first that comes to mind. Things like #ArtificialIntelligence, #Blockchain and #QuantumComputing seem more exciting, APIs are quite a boring and comparatively old idea. (90/100)

On the other hand, #APIs are the glue that connects everything together. They are what make other technologies accessible. Think of massive compute clusters with #MachineLearning models exposed through APIs that enable developers to tap into them. (91/100)

However, to fulfill this potential, #APIDocumentation and #DeveloperExperience is really important. I said this earlier in this thread already but it deserves being repeated after the other things I've mentioned. (92/100)

As we get closer to the end of this thread, I want to talk once more about #ClimateChange, which may be the defining challenge of our time. Technology contributes to carbon emissions but it also provides us with tools to optimize efficiency. (93/100)

We must, however, be vary of rebound effects! If something is more efficient, it doesn't mean we should do more of it. The future may not be about doing/producing more, but about doing/producing the same with less input. (94/100)

Technology and the #DigitalTransformation can save much resources thanks to #dematerialization, for example by replacing paper with digital process, but we need to embrace this and implement technology with this purpose in mind. (95/100)

Most people either believe in a techno utopia with emission-free flying cars or in going back to a simpler life with less consumption. I think we have to look beyond ideologies and implement pragmatic solutions and the future may look like a mix of the two. (96/100)

The future I'm looking for is cleaner and greener and it will have drastically rethought the ideas of work and employment. It will be full of people empowered to use technology to live a better live while consuming less material goods. (97/100)

Some technology will be provided by the GAFAM while other will come from a vast group of smaller #SaaS companies and independent #API providers, many organized in forms that transcend the for-profit model, with federated and decentralized networks in the background. (98/100)

And in the same way that I don't want all technology to come from the GAFAM, I similarly don't want it from SMBs all run by white dudes. We need #diversity - women and non-binaries, different ethnicities, orientations, locations, social background etc.. (99/100)

I've reached the last tweet mandated by @threadapalooza and will end here. Writing this thread took much longer than expected but it was a good opportunity to bring my thoughts on my main areas of interest together. I will see how I can explore them in the future. (100/100)