Noel De Martin

Software Ideals in the Age of AI

2026-02-03T17:02:00+00:00

In the last few weeks, there has been a lot of talk about the end of software development. We're entering a period where software is easier to make than ever before, and many are proclaiming that soon we won't need to look at code anymore.

I'm also very excited by the idea that anyone can make their own software, but there is a problem. The design choices that come baked-in with most of these tools are not great. If you ask an LLM to vibe-code an app, it's going to inherit all the faults of the previous generation.

In the age of AI, we need better defaults.

My Software Ideals

A few months ago, I gave a short presentation talking about my side-projects, and one of the slides included a list of my software ideals. But, what are software ideals?

Basically, they are the guiding principles that shape the architecture and design of the software I build. As well as the one I'd want to use. Calling them "features" would be a disservice, because they are a lot more than that. They convey my platonic ideal for what software should be.

This concept had been simmering in my mind for years, but this was the first time I actually wrote them down. After some deliberation, I came up with the following 3.

Universality

There are many ways to interpret this idea. Crucially, it's one of the core tenets of the Web. But to me, it means that I should be able to use my software anywhere. In any device, at any location.

The first point seems easy enough. If the software is built using web technologies, it most likely can run everywhere. And yet, I routinely find vendors perverting this idea. Just last month I was told that I wouldn't be able to access my savings account without installing an app in my phone.

But the second concept is more tricky. So much of our software relies on having an internet connection, that without it we're left with a rather useless device. The pinnacle of human invention and ingenuity, the "bicycle for the mind", turns into a beautiful brick.

It is, of course, possible to work around it (if you prepare in advance). But most of the industry is moving in this direction, and the solution doesn't come for free. Software has to be designed explicitly with that goal in mind. However, it's not as difficult as it may seem. Software makers just need to care.

But this isn't only important when we're offline, given that it's not as common these days. Requiring an internet connection often means that we depend on someone else's computer (aka servers, or "the cloud"). And that, is a problem.

Sovereignity

A while ago, I only chose software based on the user experience. And it resulted in a lot of heartbreak. Despite my technological inclinations, I'm not someone who changes software very often (I'm still using Firefox!). But during the first decade of my computer life, some of my favorite apps disappeared. Wunderlist, Sunrise Calendar, Google Reader, Evernote Food, and many more.

The funny thing is that I never wanted new features. In fact, those were often unwelcome. If these apps hadn't vanished, I'd probably still be using them today. But somehow, we've accepted that software can be taken away. Unlike everything else in the real world.

But sovereignity is not limited to keeping software forever. It also means having real ownership of your data. There are many reasons for that. Certainly, I started this journey thinking on privacy. But there are also practical reasons. I often want to share data between apps. And, in the rare case when I do change software, migrating is always a pain (often impossible).

If you can't access the raw data, it's not really yours.

Interoperability

If you've been following my content for a while, you may be thinking that I sound like a broken record. But yes, I think interoperability is that important.

I believe that this is the software property people would value the most, if only they thought it was possible. If you could travel to a parallel dimenson where everything was interoperable, I can assure you that coming back here would be like going back to the stone age. But most people don't even question the status quo, because they think this doesn't happen for technical limitations. However, as I've written at length before, it has nothing to do with that.

Actually, I did travel to a parallel dimension. In 2024, I spent a couple of weeks in China, and got to experience the WeChat ecosystem. They call it "the everything app" for a reason. I could even use it to operate a washing machine in my hotel, and get a push notification when the laundry was done. Of course, it wasn't ideal that I didn't own any of my data, and everything was run on a centralized system. But in terms of user experience, it was great.

Wouldn't it be nice if all the applications you build with AI could share the same underlying data?

The Age of AI

I have been thinking about these ideals for a while, and now they're more important than ever. People are starting to delegate their decisions to an AI, and that's only going to become more common. Unfortunately, most of the solutions LLMs come up with are very much against these ideals. The only one that works (sometimes) is Universality, as in "run it anywhere". Everything else, is often ignored.

Sure, there will always be software makers who care. And I don't think AI can replace a developer completely (yet?). But I also share the excitement about anyone being able to make their own software. In the next few years, I hope we get a lot of Barefoot Developers.

However, if we're going to democratize software making, shouldn't people build apps that are aligned with their ideals? I could understand vendors making selfish decisions before (even if I don't agree with them). But if people are going to make their own software, they shouldn't be shooting themselves in the foot.

My toolbox

Since I started making my own apps in 2019, I have been seeking for an architecture that allows me to live up to these ideals. I can't say I'm 100% there, and I've certainly had to build a lot of my own tooling. But I have learned about some technologies that, combined, give you pretty much everything I've talked about out of the box:

PWAs (Progressive Web Apps): I'm sure many of you are already familiar with PWAs, they are pretty widespread (although not as much as I would like). Essentially, a PWA is a web app that can be installed like a native application. There is still some debate about the merits of PWAs vs native apps. But for me, there is no contest: PWAs all the way!
CRDTs (Conflict-Free Replicated Datatypes): If you want to make your application local-first, you most certainly will end up using a CRDT. It sounds complicated, and if you search online you may get overwhelmed by the technicalities. But they can also be pretty simple. If you know nothing about CRDTs, I'd recommend that you start by watching this talk: CRDTs for Mortals.
RDF (Resource Definition Framework): Ah, RDF. If this isn't your first time hearing about it, you either love it or hate it (most likely the latter). RDF is a data modeling framework that attempts to formalize knowledge so that machines can understand it (almost the opposite of LLMs, actually). Basically, it allows different programs to collaborate on the same data. It's been around for ages, and it's used a lot in some fields (it's the format that powers wikidata, for example). But as I said, it has a bad rap. Once again, I think it's because it's often overcomplicated. I gave a talk about this, so if you're interested to learn more, check it out: Thoughts on Solid Developer Experience.
Autonomous Data: This one is more of an idea than an actual technology, but it is important to mention because you can use all the tools in this list and fall short of these ideals. Autonomous Data is an application architecture I described in 2018, before I knew about the Solid Protocol. If you're curious, you should read the site because it's not too long. The short version is that data should be decoupled from apps, and users should have true data ownership (in practice, and not just in theory).

Putting AI to the test

Having read thus far you may be thinking that this has an easy solution: just ask your AIs to use these technologies. Unfortunately, reality is not so simple.

First of all, most people don't even know that these exist, so they aren't going to include them in their prompts. But even if they did, do you think it would work? I was curious about this myself, so I decided to give it a try. I asked various popular vibe-coding tools to create the most simple of applications: a Todo app.

Here's the prompt I used:

Create a Todo application that is architected as a local-first Progressive Web App. The core philosophy of this app is that it must be fully usable upon visiting, requiring no internet connection and no user account to create and manage tasks. To achieve this, the underlying state management should rely on Conflict-free Replicated Data Types (CRDTs), ensuring that all data is persisted locally in the browser first.

Crucially, I want the internal data model to be structured using RDF standards. Instead of storing simple JSON objects, the application should maintain a semantic knowledge graph of the user's tasks.

For the synchronization strategy, design the system so that users remain anonymous by default. However, provide a way for users to log in where they can input a URL of a self-hosted backend or sync engine. Once this URL is provided, the local CRDT state should synchronize with that server, allowing the user to back up their data and share their task graph across multiple devices.

Other than this configuration, the user interface should only support two actions: adding a new task and toggling its completion status with a checkbox.

And these are the results (source code in Github):

Google's AI Studio
Bolt.new
Lovable.dev
Vercel's v0 (Cannot be hosted on Github Pages because it uses Next.js 💀)

How do they fare?

Universality ✅: Most of the apps are PWAs that work offline. The only exception is Vercel's, which uses Next.js and cannot be served with static assets. I haven't even bothered checking if it actually works as a PWA, because given the requirements, it makes no sense to make an app with server-side code. But of course, it would be very easy to host in Vercel 😉.
Sovereignity 🤷: This one is arguable. Google's and Lovable's synchronize with a Yjs websocket, and Bolt's uses Supabase. Both of those are open source, and as far as I know you can self-host them. But they make the classic mistake of relying on implementations, rather than protocols. If Supabase or Yjs go bust tomorrow, I don't think you'll keep using this for long. You'll have to go through a painful migration, not unlike the classic "export your data in a zip" that many vendors provide as an illusion that you own your data. What are some examples of good data formats? Plain text (or markdown), JSON, or indeed, RDF.
Interoperability 💀: Not surprisingly, this is where all of them fail miserably. It's funny because looking under the hood, they are structuring the data as RDF triples. But then, they go ahead and serialize it in different formats, which misses the entire point of using RDF. In my interoperability scale, all these apps fall at the very bottom: Obfuscated interoperability.

So yeah, as it happens with AI, the initial result seems impressive. But as soon as you start digging into the details, you realize it's full of holes. Furthermore, this experiment has also confirmed what I already suspected: each platform has their own technology preferences, and they'll shove them down your throat even if they aren't appropriate for your use-case.

If you're curious to see a Todo app that actually follows these ideals, check out my task manager: Focus.

Skill issues

Now, I know what a lot of people reading this post are going to say: "You're doing it wrong!".

I am aware that my prompt could have been better, that it's not reasonable to expect this to work in a single shot, and that these may not be the best tools to build "real software".

But here's the thing, most people aren't going to do any of that either. As I mentioned, they won't even know that these technologies exist, or how to judge the result. So I think this was a pretty reasonable example of how things would turn out in most cases.

Outro

If you made it here, thanks for reading!

You may agree or disagree with my ideals, and I'm sure you have your own. But AIs also have theirs, and I doubt they are aligned with you either (even if you tell them!).

Even though we can now chunk out code faster than ever, our jobs as engineers are far from being over. Software Development is dead, long live Software Engineering.

The Problems With Modals, and How to Solve Them

2025-08-04T15:28:00+00:00

I have been building UIs on the web for 10+ years, and most of the time I've been using a component framework like Vue. There have definitely been some ups and downs in the frontend space, but overall I'm quite happy with the current state of the art (I did start on the jQuery era, after all!).

However, there is something that always bothered me: Modals.

Classic modals

If you've used virtually any component framework, this is probably how you've been taught to open a modal:

<button @click="show = true">Open Modal</button>

<MyModal :open="show" />

Basically, you're supposed to declare the modal component inline, and use a boolean to control whether it is open or not.

This approach is used in shadcn, PrimeVue, Vuetify, Tailwind Plus, and is even featured in the official Vue docs.

The problem is... I don't think about modals that way!

Instead, the native JavaScript approach feels a lot more intuitive to me:

alert('Hello!');

For starters, I don't write all my code inside of components. What if I want to open a modal from a JavaScript file? And what if that code is reused in multiple screens?

The answer is that you must do some component gymnastics to make sure that some component, somewhere, is actually declaring the modal. And then, have some roundabout mechanism to make sure that a signal is passed around to control the modal's visibility.

But it gets even worse. What happens if you need to get a response from the modal? You'll probably need to complicate things further with events and listeners, or give up altogether and write the logic within a component.

In plain JavaScript, once again, things are a lot simpler:

const answer = prompt('How many golf balls fit into a Boeing 747?');

You just call a function, and get a response.

What if I told you that you can also do this with Vue? This is how I've been using modals for years, and in today's blog post I'll share how you can do it too:

import MyModal from './MyModal.vue';

const answer = await showModal(MyModal);

Better modals

The first thing we're going to need, ironically, is somewhere to render our modals 😅.

But! We only need to do this once. We can choose a single place to render all of them, and move on with our lives. To encapsulate this behaviour, let's create a component called ModalsPortal:

ModalsPortal.vue<template>
	<component
        v-for="modal of modals"
        :key="modal.id"
        :is="modal.component"
    />
</template>

<script setup>
import { modals } from './modals';
</setup>

This is not too different from using Vue's <Teleport> component, so you could say we're just adding some syntactic sugar here.

Once you've done that, you can define all the plumbing we'll need to make this work in a plain old JavaScript file:

modals.jsimport { shallowRef } from 'vue';

export const modals = shallowRef([]);

export function showModal(modal) {
    modals.value = modals.value.concat([
        {
            id: Math.random(),
            component: modal,
        },
    ]);
}

Now, all you need to do is place a <ModalsPortal> somewhere in your app, and use the showModal() function to dynamically render modals from anywhere.

Congratulations, you're already using better modals 🥳.

Passing and receiving data

So far, we've managed to render modals without declaring them in any template. We can already reproduce a DX similar to JavaScript's alerts:

// JavaScript
alert('Hello!');

// Vue
import HelloModal from './HelloModal.vue';

showModal(HelloModal);

However, for any real application this is going to become limiting very quickly. We're also going to need to pass some arguments, and get a response once the modals are closed.

Sending arguments is straightforward, we can simply use Vue props:

modals.jsexport function showModal(modal, args) {
    modals.value = modals.value.concat([
        {
            id: Math.random(),
            component: modal,
            props: args,
        },
    ]);
}

ModalsPortal.vue<component
    v-for="modal of modals"
    :key="modal.id"
    :is="modal.component"
    v-bind="modal.props"
/>

But getting a response is a bit more involved. We'll need to manage the asynchronous nature of the operation, and remove the modal when it is closed.

We can do it by wrapping everything in a promise, and listen to events on the component:

modals.jsexport async function showModal(modal, args) {
    const id = Math.random();

    return new Promise((resolve) => {
        modals.value = modals.value.concat([
            {
                id,
                component: modal,
                props: args,
                close(response) {
                    modals.value = modals.value.filter(
                        (modal) => modal.id !== id,
                    );

                    resolve(response);
                },
            },
        ]);
    });
}

ModalsPortal.vue<component
    v-for="modal of modals"
    :key="modal.id"
    :is="modal.component"
    v-bind="modal.props"
    @close="modal.close($event)"
/>

MyModal.vue<template>
    <button @click="$emit('close', 'The Answer')">Close Modal</button>
</template>

And that's about it!

Now, you can even lazy load modals with a plain old dynamic import:

const { default: MyModal } = await import('./MyModal.vue');

const answer = await showModal(MyModal, {
    question: 'How many golf balls fit into a Boeing 747?',
});

Of course, if you want to use this in a real application you'll also need to take care of styling and whatnot. But this covers all the missing pieces to start using modals the right way. You can take a look at the complete example in this Vue Playground.

TypeScript

But we aren't done yet. If you're like me, you're probably taking advantage of Vue's TypeScript features, which have been improving a lot recently (we even have Component Generics now 😍).

However, this whole modal shenanigans throws it all out of the window. We're not setting the props in the template, and the modal response doesn't take advantage of typed emits. But don't fret, this is nothing that some TypeScript wizardry can't fix 🧙.

First of all, we'll need to type the props for the modal component. This can be achieved using Vue's Component type, combined with some generic magic:

modals.tsimport { Component } from 'vue';

export type GetComponentProps<T extends Component> = T extends {
    new (): { $props: infer TProps };
}
    ? TProps
    : never;

export async function showModal<T extends Component>(
    modal: T,
    args: GetComponentProps<T>,
) {
    // ...
}

The second part, typing the response, is once again a bit more involved. Maybe you're thinking that we could follow a similar approach, and infer the type from the $emit property:

modals.tstype GetComponentResponse<T extends Component> = T extends {
    new (): { $emit: (event: 'close', args: infer TResponse) => void };
}
    ? TResponse
    : never;

export async function showModal<T extends Component>(
    modal: T,
): Promise<GetComponentResponse<T>> {
    // ...
}

Whilst this technically works, you'll find that it's also limiting in more realistic use-cases. The examples I've shared so far don't use any auxiliary components, but the more common scenario is that you'll have a generic <Modal> that you'll re-use across modals. And usually, it'll have a close button. So now we have more than one component emitting events: the generic <Modal>, and our custom <MyModal>.

Things can become complicated very quickly, but the easiest way to solve it is by introducing the concept of "modal dismissal". If the modal is closed from anywhere outside of our custom component, we can assume it's been dismissed. If we do that, we only need to add something like a dismissed boolean to our promise, and we're done:

modals.tsexport async function showModal<T extends Component>(
    modal: T,
): Promise<GetComponentResponse<T> | { dismissed: true }> {
    // ...

    close(response?: GetComponentResponse<T>) {
        if (response === undefined) {
            resolve({ dismissed: true });

            return;
        }

        resolve(response);
    },

    // ...
}

Putting it all together

TLDR, after following this guide, you'll be able to use Vue modals like this:

MyModal.vue<template>
    <Modal title="My Awesome Modal">
        <button @click="$emit('close', { answer: `Hello, ${name}!` })">
            Close
        </button>
    </Modal>
</template>

<script setup lang="ts">
    defineProps<{ name: string }>();
    defineEmits<{ close: [{ answer: string }] }>();
</script>

import MyModal from './MyModal.vue';
import { showModal } from './modals';

const { answer } = await showModal(MyModal, { name: 'Guest' });

Isn't that beautiful!

You can of course start doing this yourself, as I've been doing in multiple projects over the years.

But I got tired of rewriting this time and again, so I also started working on a package to make this easier. If you want to start doing this in your apps, or dive deeper into the code, check it out in GitHub: github.com/NoelDeMartin/vue-modals.

Going further

That's it for the guide, but here's some parting thoughts:

Did I say modals? This whole article I've been talking about modals, but the truth is that these ideas apply just as well to other types of overlays: snackbars, toasts, etc.
Did I say Vue? And yes, this also applies to React, Svelte, and many other frontend frameworks.
What about accessibility? I am very aware that I have simplified a lot here. If you want to handcraft modals in your apps, you'll need to take care of focus trapping, keyboard interactions, and a million other things.

I chose not to get into that rabbit hole because that's something that component libraries are doing right, so you don't need to worry about it. If you're curious about doing this with existing libraries, I have documented some integrations in my project.
What about the native <dialog>? A couple of years ago, we got baseline support for the native <dialog> element; and it seemed like it would solve all of our problems. Unfortunately, that's not completely true. And to make matters worse, the DX deviates from how native overlays usually work, and you have to declare modals inline.

The Soul-Crushing Reality of Job Seeking

2025-03-12T15:06:00+00:00

I've found myself looking for a job a couple of times in my career, and it has always been a grueling experience. This time, it doesn't seem like it's getting any better.

The NLNet fiasco

If you read my blog 7 months ago, when I quit my job to explore new opportunities, you may be wondering what I've been doing ever since.

The first few months, I did exactly what I was planning: I took a break. But it wasn't long before I started moving some pieces for my next projects. On October 1st, I submitted 3 proposals for an NLNet grant. The plan was to get a response by the end of 2024, and see where to go from there. You can read my original submissions here:

Given that you're reading this, things didn't quite work out. Long story short, on March 6th (5 months later), I was notified that I wasn't getting the grant. Needless to say, I was bummed out. But not for the reasons you may imagine. Sure, it sucks being rejected; but the worst aspects of the process were the agonizing wait and the lack of feedback throughout.

In case you weren't familiar with NLNet, I decided to apply because many people working in the Solid ecosystem have been funded by them. And from conversations with previous grantees, I learned they usually replied within a few weeks. But I was extremely unlucky with my timing, because they've had noticeable delays in the most recent calls due to an increase in applicants.

However, something worse than waiting was the lack of feedback. For months, I only got generic emails about delays and the status of the review. Including one at the end of January revealing that I had been selected for the second round, but also without any specifics about my project. Then, on March 3rd, I finally got some questions about my submission. I replied immediately, and 3 days later my project was rejected. I wonder if my answers to that email were really that bad!

To their credit, I got some feedback after following up. And I can't say I disagree with their reasons, though I also realized that we aren't aligned in some aspects. But it would have been nice to find out sooner.

In short, it wasn't a great experience. But the thing is, I cannot blame them. The increase in applicants was just bad luck, but I had no reason to believe that I would get any feedback. I didn't realize it at the time, but effectively I was entering a process very similar to applying for a job. And as I've learned the hard way, it's very rare to get any feedback or meaningful takeaways from these rejections.

And there is one very particular reason why this happens: the power imbalance.

The power imbalance

Here's the thing. There is an inherent asymmetry in most hiring processes. First of all, people hiring have almost nothing to gain from rejected applicants. But also, the ratio of applicants to reviewers is usually in the hundreds if not thousands. That is, for each reviewer there are probably hundreds of people applying.

This situation results in a process than can be very demoralizing for applicants, because it's not feasible to give personalized feedback and attention to everyone. It doesn't matter that you, as an applicant, have spent hours or even days crafting the perfect cover letter and work history. It could all end in 5 minutes, because unless they are convinced that you're worth looking into, they'll move on to the next candidate. There are different ways to deal with these rejections, and I certainly believe ghosting is the worst one, but going through a process that treats all candidates fairly is the exception rather than the rule. And don't even get me started on unpaid interview assignments, salary negotiations, and many other hurdles that make it unfair.

However, there is a cheat code: networking. If you have some connection inside the company, your chances of landing the job increase tremendously. It doesn't mean they'll hire you on the spot, but it does mean they'll at least look at your candidacy more closely. You may even get to skip some parts of the selection process altogether.

I was already aware of this, but I realized it's more relevant than I thought when Adam Wathan, the creator of TailwindCSS, shared their hiring experience. They posted 2 offers, and out of 1600 applicants, exactly 0 were hired. Instead, the two who ended up getting the job came through networking and didn't even apply. It seems like effort didn't play such a big part after all.

This gets even worse when you consider that many offers don't even make it to a job board, or don't exist at all! It's not uncommon for companies to be heads down on their work, not looking for anyone new. But they will be more than happy to hire the right person if they happen to cross their paths.

Unfortunately, this isn't getting any better in the AI-era. This imbalance is growing ever greater, with applicants flooding job postings with AI applications, tech workers going through massive layoffs, and the uncertainty of whether AI will take our jobs (I don't think so). Today, the human connection is more important than ever.

This realization has led me to believe that skills are not as important as I thought for getting a job. Of course, they must be important for keeping a job. But for job hunting, soft skills like marketing and networking may be more impactful than actual skills related to your job (unless, of course, you're working in marketing or sales).

Also, when I say networking, it doesn't necessarily mean that you have to literally know someone on the inside. But it does mean they have to know you. For example, if you're working in the open and they are familiar with your work, they'll certainly consider your application more carefully. It also doesn't hurt if you're already working at a popular company.

So, where does that leave me? I'm not great at networking, and even though I work in the open, my audience is almost non-existent.

You could say this is only an excuse I'm telling myself, and I'm actually lousy at my job as well (besides sucking at networking). But I'm pretty sure the people I've worked with have been happy with my contributions. And the worst part of The Job Seeking Experience is that most of the time I don't even make it to the interview or technical test. The most common response I get is also the more frustrating: silence.

But it is also possible that I'm not applying to the right positions. The truth is that I've been very selective with my shots, and I've only applied for 2 positions since I quit working at Moodle: Laravel and Mastodon. Indeed, weeks later, I'm still waiting to hear from them.

The clear answer is that I shouldn't be so picky. But before we get there, let me backtrack a little. When did I become selective in the first place?

The passion lie

Once upon a time, I was a bright-eyed computer programmer who had just finished their studies, and I had no idea of what the software industry had to offer. That's when I moved to Taiwan for a few months, and started my professional career. At the time, I didn't have many aspirations, and I was just happy to get paid for writing with code.

However, as time went on, I started to learn more about the industry, and I started working on my own side-projects. That's when I realized that I really loved programming, and I was spending more and more of my spare time coding as well. I also developed a taste for the type of code I wanted to write, and I started to think that maybe, I could enjoy my work as much as I enjoyed my side-projects.

I'm sure you've seen this before. Maybe you had a co-worker who also coded in their spare time, or maybe you've done it yourself. And even though that wasn't the reason why I was doing it, I bought the idea that being passionate would bring me better opportunities. Some people even say that caring about quality code and craftsmanship is the key to avoid getting replaced by AI.

But now, I think that's a lie. Or rather, it's more nuanced than just "being passionate".

When I look back at my career, I can't think of a single time when caring about my craft has opened any doors. And you could argue that it's impossible for potential employers to know about it unless they've worked with me. But that's when working in the open and publishing your work comes in.

In the last 6 years, I've been very public about my work with Solid. And it seemed to have paid off. I've made contacts with most people in the ecosystem, I'm often highlighted as one of the main app developers in the community, and two of my apps were featured in Tim Berners-Lee's keynote at the WeAreDevelopers World Congress.

And yet... I've failed miserably to find an opportunity to work with Solid full-time. The problem is not that I wasn't passionate enough. The crude reality is, put simply, that there is not enough going on with Solid.

The nuance to being passionate is that it really matters what you're passionate about. For example, if you look at classical musicians, there can only be 2 French Horn soloists in the world making a living at any given time. It doesn't matter that you're a great surfer, you can't surf without a wave. If you simply follow your passion, you may end up at a dead end.

And I know, this is kind of obvious when you think about it. But without my realizing, I had been reinforcing this belief with my media diet.

The Instagram effect

Well, I don't even have an Instagram account, so I guess I should call it "The RSS effect" because I get most of my information from podcasts and blogs. And that's definitely distorting my vision of reality. I spend my days listening to how great everyone else's life is, and how their passion lead them to a successful career. But that's only the tip of the iceberg.

I have been listening to too many Steve Jobs quotes:

For the past 33 years, I have looked in the mirror every morning and asked myself: "If today were the last day of my life, would I want to do what I am about to do today?". And whenever the answer has been "no" for too many days in a row, I know I need to change something.

― Steve Jobs' Stanford Commencement Speech

When I should have been listening to Mark Manson's:

All of this "every person can be extraordinary and achieve greatness" stuff is basically just jerking off your ego. It's a message that tastes good going down, but in reality is nothing more than empty calories that make you emotionally fat and bloated, the proverbial Big Mac for your heart and your brain. The ticket to emotional health, like that to physical health, comes from eating your veggies—that is, accepting the bland and mundane truths of life.

― Mark Manson's The Subtle Art of Not Giving a Fuck

One bland and mundane truth of life is that not everyone can be Aaron Francis.

The problem with living in such environment is that, subconsciously, I've been lead to believe that I'll only be happy if I get to work at one of these companies I admire. Or create my own. But the truth is that my job doesn't need to align completely with my passion.

I have to accept that I might not make it.

Managing expectations

Shooting for the stars is not inherently wrong, but you shouldn't set unrealistic expectations either. It would be nice if every passionate developer could make a living with their open-source project that is trying to make a better Web. Instead, we live in a world with billionaires making more money in their sleep than you'll make in your entire life.

I realize this article hasn't been the most uplifting thing you've read this week. But to be honest, it reflects my current state of mind as I'm trying to recalibrate my expectations. Which is, turns out, the real key to happiness because You Can't Always Get What You Want.

The truth is that I probably won't get to pursue my passion, at least not fulltime. And that's ok. I had been melding my love of programming with my professional career, but there's nothing wrong with keeping them apart. It's just weird that they are so close together!

I should also be more grateful of how extremely lucky I have already been. I'm aware of my privileged position, and I shouldn't take it for granted.

What now?

Indeed, what now?

For one, my involvement with Solid will probably decrease. I don't think I'll stop altogether, because I still believe in its vision and enjoy working on my apps (that's why I started in the first place). But it's definitely going back to being a side-project. Though I may still experiment with some businessy ideas, because I really think I should improve my marketing skills.

Something else I'm changing is my job hunting approach. I already mentioned that I've been too selective, and I had this stupid rule to avoid being in too many selection processes in parallel. Mostly because I would hate to get a better offer when I already committed elsewhere. But seeing how things are going, that's very unlikely to happen.

And finally, I'm recalibrating how I'll evaluate new opportunities. Last time I was on the market, I wrote a blog post outlining what I was looking for. Astute readers will notice that I didn't even mention compensation, because I've always been frugal and I don't have big expenses. But if I'm going to be working at a job I'm not particularly passionate about, I may as well make the most of it.

The ideal solution would be to find great companies that are not as notorious as the Laravels of the world. I'd be thrilled to work at a small, little known company that is doing quality work. The problem is that, by definition, it's very difficult to find them!

On that note, if you know of any opportunities that could work for me, please let me know. I'm all ears.

The End of The Chapter

2024-08-01T13:00:00+00:00

Yesterday was my last day working at Moodle, an Open Source LMS that is used all around the world.

I joined more than 4 years ago, and for the most part it has been a great place to work. But recently I decided it was time to move on, and today I want to share why and what's coming next.

Farewell, Moodle HQ

My last personal update on this blog was 3 years ago, and I mentioned that I had finally found a company sharing my values. It's not uncommon for companies to have empty mission statements, and I really believe that Moodle is having a positive impact in the world.

On top of that, my working conditions were great. I've been working 4 days a week, which has allowed me to spend time doing side-projects. And I've had a real flexible schedule (with very few meetings!).

With all that, you may wonder why I decided to quit my job. The answer can be found in a blog post I wrote 6 years ago, titled Finding Opportunities that Fit Your Values. In that post, I talk about 4 things that are important to me: Vision, Work, Company Size, and Remote. Moodle has been great in Vision and Remote, but Work and Company Size have been drifting from my ideal.

Company Size

When I joined, Moodle had ~60 employees. Today, there are more than 200. This happened, in part, because of some acquisitions. But the other teams have also been growing. For some people, this may still be considered a "small company". But as I've mentioned before, I consider Dunbar's number (150 people) an inflection point.

This is the first time I've worked at a company of this scale. The working conditions and environment were still great, but I can't say I've had a big influence on the company or the product. I did feel like a cog in the wheel, and I'd rather be a linchpin.

Now, does this mean that I'll never work at a company of this size? Or that it isn't possible to make an impact at this scale? No, it doesn't. But so far, my suspicions where true.

Work

The second reason for my decision, and probably the most important, was the work itself. I feel like most of my work was maintenance. That doesn't mean I didn't do anything interesting, I even gave one talk about some of the things I worked on. But most of my contributions where at a code level. Barely ever affecting the UI, the Product Roadmap, or the Company Culture.

And that was only half the problem. I suppose I wouldn't mind having no impact in a "perfect" codebase (I know those don't exist), or in an environment where I'm still learning. After all, I've said multiple times that I enjoy programming in and of itself. But Moodle didn't have an environment where I could thrive. Anyone familiar with Moodle's codebase will know what I'm talking about; but for those who don't, I'll just say that Tech Debt is a real issue not to be taken lightly. My experience working at Moodle, if anything, has reinforced my opinion that high quality software is worth the cost.

However, it wouldn't be fair to say that I haven't learned anything. When I joined, I had very little experience building accessible websites. I also didn't have much experience with Dark Mode and RTL interfaces. Now, I'm confident that I can build UIs that are usable by everyone. Working on an application used by millions around the world has been an enlightening experience.

It was also my first time working with a UX writer. I already knew that designers were my favourite partners in crime, but this is a breed of designer I hadn't met before. Given how much I like writing and naming, it shouldn't come as a surprise that I also enjoyed working with them; and I look forward to meet more in the future.

Looking back

Thinking about these years, I realize that towards the end of my tenure I was still very happy with my life, but I wasn't happy in my life. That's what ultimately lead me to make this decision.

I cherish the time I spent working at Moodle, and I'll look back on it fondly. I also won't shy from saying that it's been the best company I've worked at, and I'm really envious of anyone who'll join them in the future. But all good things come to an end, and my time was up.

What's next?

Now that I've come to this crossroads, I'm pondering what to do next. An obvious answer is to go into Solid full-time, since I've been doing it on the side for years. But is that a good idea?

The business of Solid

I recently talked about why I'm choosing Solid in my side-projects, but I didn't talk about choosing it for a business. Overall, I'd say there are two groups of people working on Solid full-time.

The first one is people working on projects to improve the ecosystem. I'm talking about teams like Ponder Source, o.team, and ActivityPods. As far as I know, most of their funding — if not all — comes from grants. In particular, it seems like NLNet is supporting most people in the ecosystem. Which is a great way to get started, and I'm glad that something like NLNet exists. But I strongly believe that eventually projects should be sustainable on their own. And I don't see many plans to make that happen around Solid, hypothetical or in practice.

The second group is people focusing on the B2B market. Some companies that come to mind are Graphmetrix, Digita, and Inrupt. In this case, I have absolutelty no idea how they are doing financially. But the truth is that I'm not super interested either, because as I mentioned in my previous post, I'm more interested in B2C (even though that is playing in Hard Mode).

Outside of Solid, there are many businesses I admire: Laravel, Vue, Mastodon, 37Signals, etc. All of them have different business models, but there's also one thing they have in common: critical mass. Of course, none of them started with millions of users; but I've heard their founder backstories, and none struggled for adoption either.

Which takes us back to the issue that Solid is not getting any traction. It's not that I need a thriving ecosystem to guarantee my success; but in the current ecosystem, I'm not sure it's possible to make a living as an indie developer. And I haven't seen many job opportunities that pique my interest.

Here we go again

If your conclusion reading the previous section was that I shouldn't go into Solid full-time, you'd probably be right. But I'm doing it anyways 😅.

The thing is, I can't really help myself. The work I've been doing with Solid these last few years has been some of the most fulfilling of my career. And for all its flaws, I still think Solid is the best thing that could happen to the Web (and maybe software in general). Even if there's only a slight chance that it works out, I'd regret not trying.

Furthermore, I've spoken of my entrepreneursip before; and for years I've been itching to get back into it. The problem, like always, is money. I've never been good at making money, and even though I've learned a lot since, I still haven't done it in practice. This will be the perfect opportunity to do so.

However, there is one thing I'll do differently this time. The only thing I regret from my last attempt, Geemba, is that the project died with the company (and we had happy paying customers, though not enough to make a living). If this time doesn't work either, I want to make sure that the project outlives my failure. Open Source will probably be part of it, but hopefully not the only one.

The Plan

Ok, so that's nice and all, but what am I actually going to do? I have a few ideas.

A framework to make Solid Apps. This would be the most straight-forward, because I have already started working on it. It also builds on top of everything I've been doing, and since I'm using local-first I can market it to a larger audience. But I also see some problems.

If we're talking about audience, my decision to use Vue over React is probably bad (but it's unlikely to change). I usually wouldn't care too much about it; but I can't see a project like this becoming sustainable without a large audience.

Still, many people both in the Solid and local-first communities often mentions the lack of an easy solution to get started. This could be my attempt at making the Ruby on Rails of Solid/local-first.
A B2C Solid POD. If I really want to help the ecosystem, this is what I should do. I'd love to make a POD provider that acts as a proxy for different cloud providers (Google Drive, Dropbox, Nextcloud, etc.) using custom domains. That way, it'd be possible to migrate to a "real POD" later on. Also, the familiarity of these providers would remove the barriers to entry for many people, and help them understand how Solid works. I'd certainly focus on the UX, which is the biggest problem most PODs have nowadays. And because it'd be a proxy, I wouldn't be storing anyone's sensitive data (besides their credentials). Finally, this seems the easiest idea to monetize.

There is just one slight problem... I would be starting from scratch 😅. Yes, I've been working with Solid for a while, but it's always been as an app developer. If anything, I've made a point to ignore the server-side stuff leaving it to "the protocol".

But it also means that I'd finally get back to work with Laravel, so it's not completely off the table.
More and better apps. I could just continue doing what I've been doing, but kicking it up a notch. So far, everything I've released has been a byproduct of working in the open. The real audience has always been myself, and I'm fortunate that it seems to have resonated with others (although I don't know how many people is really using my apps). But this time, I would focus on solving others' problems with Solid.

For example, I've been asked multiple times about adding social features. And I think it would be really cool to take advantage of Activity Pub to achieve it. Also, I haven't done any user research. I could definitely do a better job at learning what people wants.

However, I should also say that this sounds like a recipe for disaster. I'm not saying it cannot work, but I've struggled to achieve this in the past. If we're adding Solid to the mix, and the fact that I'm not sure how I'd monetize any of this, it sounds even more shaky.
A paid course. This is the most far-fetched idea, but I'll mention it anyways. Starting with info products has worked for others before, and one of the recurrent issues that come up in Solid is the lack of resources to get started. But I see many problems with this one.

If the audience was a problem for my first idea, it is damning for this one. And not just Solid's audience, but my own as well. I still feel like I have no audience, certainly not enough to make a living with a paid course. But maybe I have enough people to make some of the other ideas work.

Additionally, to have even a slight chance to make this work, it would need to be framework agnostic. No Aerogel, no Vue, and certainly no Soukai.

Nobody knows what'll happen in the future, but for now; the prospects for this one don't look good. If you're curious to know what this would cover, you can watch a spiritual preview in my FOSDEM talk: From Zero to Hero with Solid.

Whichever of these I choose to pursue, it's very unlikely that they become sustainable in the short term. To start with some runway, I'll probably apply for an NLNet grant. If I don't get it, the timeline will be a lot shorter and I may have to relegate my Solid work to side-projects again.

Time for a break

Having said all that, I'm not starting right away. My savings won't last forever, but I'm in a good situation with very few attachments. So I've decided that I'll spent the next few months taking a sabbatical.

I'll use this time to ponder where to go next with my career, and possibly start moving some of the pieces. If you've got any thoughts about what I could do next, I'd love to hear them. If all goes well, I should be back to work in January 2025.

The point of the sabbatical, though, is that I won't have any goals. This could mean that I end up working on side-projects more than ever, or I could go afk for months on end. If you're interested to see how that's going, check out my journal in /now.

2025 Update: I've written a follow up to this post, check it out: The Soul-Crushing Reality of Job Seeking (TLDR: the plan didn't work 😅).

Why Solid?

2024-06-24T13:00:00+00:00

For five years, I've dedicated most of my side-project time to making apps and tools using the Solid Protocol. Many share its vision, but it's also common to hear criticisms. I'm often asked why I'm still working on Solid, or told about another project that is doing a better job at solving similar problems.

Today, I'll go through some of the criticisms, share my own concerns, and answer why after all these years I'm still choosing Solid.

What is Solid trying to solve?

This may, in itself, be the first problem. Solid's vision is so broad and all-encompassing, that it doesn't have the same meaning to everyone. So I'll start by clarifying what it means to me, because that will be the lens through which I address the rest of the post.

Privacy and Data Ownership

One of the fundamental pillars of Solid are Solid PODs, personal datastores. The idea is that everyone can have their own POD (or PODs), and thus control their data. This is not limited to individuals, though. Organizations can also have their own PODs and WebIds. The point is that each actor owns their data, and decides who they share it with and under which terms.

This is the angle that got me into Solid to begin with. I was working on a similar project, called Autonomous Data, when I discovered Solid. The vision was so similar that I decided to drop what I was doing and contribute to Solid instead.

But this is not what I'm the most excited about anymore. I still believe it is extremely important, but I'm convinced that most people don't care about privacy. Maybe most people reading this post do, but if people really cared about privacy they wouldn't be using Facebook, Google, or the cool Big Tech product of the day (I guess that's TikTok nowadays? Or is it ChatGPT?).

Application Interoperability

Something else that Solid is trying to solve is Application Interoperability. That is the idea that you can use two applications at the same time, with the same data.

This is for example how things like podcast players and email clients work. Users can choose their favorite applications, and they will work regardless of what the podcast publisher or the person they are communicating with are using.

Unfortunately, this is a vestige of the past and that's not how most apps work anymore.

Walled Gardens, by David Simonds

If people don't care about privacy, talking about silos and vendor lock-in is a different story. Most non-technical people won't understand what those words mean, but once you explain it — and they learn that it's a technical choice and not a limitation — you've got their attention.

Everyone has a horror story of an application they loved that disappeared, or degraded so much that it no longer resembles what they fell in love with. I myself have a handful: Wunderlist, Tviso, Evernote Food, Google Reader, Sunrise Calendar, etc.

Fortunately, to have real interoperability we also need true data ownership. So these two goals compliment each other pretty well.

Untangle Network Effects

Finally, a nice consequence from this is that service providers no longer need to take care of managing servers. Since the data is now hosted by users (or whoever they choose to entrust it to), it is decoupled from apps. And software builders can focus on what they care about: Making awesome apps.

Furthermore, today's situation often results in winner-takes-all markets. Because of network effects, many applications don't even get a chance. This ends up crippling innovation and hurting both developers and end users.

With Solid, even the tiniest of independent developers can build something that makes an impact. Applications don't have to compete with each other, they can be complementary experiences that are tailored to each individual.

Criticisms

Now that we've got that out of the way, let's dive into the most common criticisms.

The UX sucks

If you gave Solid a try, I'm sure this is one of the first things you noticed.

The UI of the POD provider that is recommended to most people, solidcommunity.net, is not very intuitive and certainly could use some polishing. And Solid Apps are not great either; most of the apps you will come across are experimental, unmaintained, or straight up don't work.

Although I agree with all of that, the reality is that if you don't like any of my apps there is only one person you can blame: myself.

Yes, there are some things in Solid that can make your life more difficult, like the login process and some limitations in the spec. But Solid at its core is a data exchange protocol. It doesn't enforce anything at the UI layer, and you could build any app with Solid. In fact, I strongly believe the UX ceiling for Solid Apps is a lot higher than for any traditional app, because you can create unique experiences that are not possible elsewhere.

The DX sucks

Developer Experience, and the lack of tooling or developer documentation, is another common concern. I recently gave a talk about my Thoughts on Solid Developer Experience, make sure to check that if you want my full thoughts on the topic.

In short, I actually believe you can learn the basic concepts of Solid in less than an hour. I'd even say that most people who already know how to build websites will be able to understand Solid in the first 10 minutes of this presentation (a talk I gave at FOSDEM in 2023).

I think one of the reasons why most people trip up is RDF, the data model used in Solid applications. It can get confusing, specially when you start looking at all the edge-cases and serialization formats. But if you learn the abstract concepts of RDF, it's not that different from OOP (Object Oriented Programming). And with patterns like Active Record, you don't even need to know RDF to make Solid Apps (much like most developers don't need to know SQL).

The lack of tooling and documentation is real though, we're still a long way from other ecosystems. The good news is that we have people working on it, myself included.

This smells like the Semantic Web

Maybe this is a variation of the previous point, but it seems like many developers who had high hopes with the Semantic Web have been burned in the past.

I cannot talk much to this, because Solid was my first encounter with RDF and the Semantic Web. All I can say is that if you're worried about that, you're probably right 😅.

And it couldn't be any other way, because Solid is precisely that: the next step for the Semantic Web. You can see a glimpse of what Solid would become in 15 year old presentations. Even in his 1999 book Weaving The Web, Tim Berners-Lee talks about many things that sound like Solid.

Websites were supposed to be read-write since the beginning. And the decentralized nature of the Web empowered individuals to host their own documents from the start (remember personal blogs anyone? Oh wait, that's where you're reading this :D).

It's not getting any traction

Of course, if you compare anything with the Web, you're going to be disappointed. What happened with the Web was a miracle, and I don't know if that's going to happen ever again. Still, it is true that Solid has been around for a while now, and it doesn't seem to be going mainstream anytime soon.

There has been a lot of talk about what is going to be the "Killer App" for Solid, but in the last couple of years I've changed my mind. I no longer think there can be a single app that showcases the power of Solid, what we need is an ecosystem of apps working together.

But that leaves us with a Chicken and Egg problem. Developers are not motivated to make Solid Apps because there are no users, and users don't want to use Solid because there are no apps.

However, I also want to raise the point that this all depends on your definition of success. If your only definition of success is complete and utter dominance, then yes, maybe Solid is doomed to fail. But if you believe that being useful to some people is enough, we're getting there.

The spec isn't evolving

This is an issue I often raise myself. In 4 years, we've only had 3 versions of the core specification; with most changes in those versions being superfluous. And we're still lacking essential features for any developer used to traditional databases like modification timestamps, pagination, or search.

If you look outside of the core specification, it doesn't get any better. Most have been a draft for years, like Type Indexes, the WebId profile, or Solid Application Interoperability. And the authorization story is a bit in the air with two competing standards, WAC and ACP.

I've tried to understand why this is happening, and I even had a short stint trying to contribute. Is it a case of design by committee? Is it a lack of contributors? Is it a tension between server implementers and app developers? Between organizations and individuals? Or maybe it's normal that these things take time?

Honestly, I don't know and it's probably all of the above. The only positive thing I can say about this is that what we already have is plenty. The nice thing about Solid is that applications are often interfacing with a single user's data, and you can get away with many things that wouldn't work querying a database for millions of users. In my case, I've also found a perfect pairing with local-first, and the specification is no longer a limiting factor.

Some people have also asked me what I think of use-cases I haven't tackled yet, like adding social aspects to my apps. My answer is that, indeed, Solid in its current form would struggle to work at scale. But there is a very similar protocol we can look at: ActivityPub.

ActivityPub is the protocol powering Mastodon and the fediverse. If I ever want to implement social features, I'll probably use ActivityPub rather than Solid. And the good news is that the protocols are very similar in spirit. Both use RDF, and both are under the W3C umbrella. In fact, there are already projects trying to bridge the gap, like ActivityPods. So I can see a future where both of them converge.

Lack of POD providers in B2C

This is, to me, the single most important issue holding Solid back.

I can control the experience in my apps, and I can work around the limitations of the spec. However, as soon as I ask people to "log in with Solid", they will find an insurmountable wall that draws them away. This problem is not unique to Solid, it also happens in the fediverse. But for most newcomers, you can recommend mastodon.social and get them going.

In Solid, the only viable option is to become a POD provider yourself. But that's a catch-22, because you either restrict it to your own apps (in which case what's even the point of using Solid), or you're now responsible for people's sensitive data (which is what you wanted to avoid in the first place).

In my case, I am saved again by local-first. My apps can be useful without a Solid account, and people can dip their toes before committing. Only when they want to use them across devices, or save their data in the cloud, is Solid a requirement. But that obviously removes many of the advantages, and any app that isn't local-first is out of luck.

So yeah, this is certainly a bummer. And I'd say what's going on in the B2C market for Solid is lackluster overall. Which takes us to the last criticism I wanted to tackle...

Inrupt

Inrupt is the company that Tim Berners-Lee cofounded back in 2018. They were supposed to be the ones leading the charge in making Solid the next step of the Web, but it hasn't quite panned out.

At the beginning, they were a key member of the community, and released many public libraries. They are still an important part of the ecosystem, with their authentication library being the only viable solution for authenticating Solid Apps. But more recently they've been slowly moving their focus towards the B2B market.

To their credit I'll mention that I'm not sure they actually said they would be focusing on B2C and empowering the community. But that's what I and many others understood, so it's been a contentious topic and it's often raised as an argument to why Solid isn't working out.

There are two things I have to say about this.

I still believe they fulfill a crucial role for the future. Bringing Solid to organizations and governments is also necessary, and that isn't going to come from independent developers like me. The only caveat I have to add is that this only holds true if they do it respecting Solid's vision and values, and not just as an implementation detail.

But the second, more important thing, is that it shouldn't matter. Solid, like the Web, is permissionless. Regardless of what Inrupt does, a grassroots movement can emerge to push the community forward. That is what I'm more interested about, and rather than blaming Inrupt for whatever Solid is lacking nowadays, I'd rather look myself in the mirror.

Advantages

At this point, you may still be wondering why I continue supporting Solid.

First, most of the problems I talked about can be solved and aren't inherent to Solid's vision. Second, it's not like the alternatives don't suffer from many of the same problems. But also, there are some things unique to Solid that I haven't found anywhere else. Or at least, not in combination.

Tim Berners-Lee

Interestingly, some people have raised this as a concern. Not that they don't like Tim, the creator of the Web. But it isn't uncommon to hear things like "if it weren't for Tim, nobody would care about Solid".

I certainly agree that Tim's success with the Web has brought a lot of visibility to Solid. But if we've got to be honest, why would free publicity be bad? As I've been hammering throughout the post, Solid is the Web. It doesn't make sense to think about it in a vacuum.

Even leaving its popularity aside, the Web is one of the greatest technologies ever created. Not just in technological prowess, but its unique combination of serving the people and Universality are nowhere else to be found.

The fact that Solid is built on top of the same ideals is an advantage that very few alternatives can claim.

Interoperable Serendipity

I wrote about this in a previous post, but TLDR I believe the real power of interoperability will be unleashed when it happens through applications that don't know about each other. And I don't mean only on a technical level, but made by developers who haven't spoken among themselves.

When you make a website, you don't have to talk with browser vendors to make sure that your website works. When you write an email client, you don't have to talk with email providers to see which formats they are using. You code against the specs, and everything works.

My dream is to live in a world where this happens with every application, and Solid is the only project that has a slight chance at making this happen nowadays. And we already have people actively working on that.

It isn't Web3

It is Web 3.0.

I don't think everything in Web3 is bad (though sometimes it looks like that), but I do think it's good at solving some very specific problems. And it's not the kind of problems I'm working on.

Where Web3 and Solid are similar, and why people may associate them, is that both create decentralized apps. However, there is a very important distinction. In Web3, decentralized means that data is everywhere. Whereas in Solid, decentralized means that data is anywhere.

If we're talking about my private data, I'd very much prefer the second approach (with "anywhere" meaning wherever I choose). And I don't care how secure blockchains are; certainly I don't trust that whatever encryption we have today won't be trivial to breach 10 years from now.

Even when we're talking about public data, I think something like IPFS is much more appealing. And there are already projects trying to bring those ideas to the Semantic Web, like IPLD.

It really is a protocol

As you can see by looking at the variety of server implementations, there is a lot of different people working on Solid: Node Solid Server (JavaScript), Community Solid Server (TypeScript), PHP Solid Server, Solid Nextcloud, Manas (Rust), etc. And that's just including Open Source PODs!

This may be one of the most distinguishing aspects of Solid. Even though other projects look nice on the surface, after further inspection you quickly realize the only implementations out there have been created by the people defining the specs. Not to mention the lack of apps or any real piece of software that isn't just for demo purposes.

This is the same reason why I'm so excited about ActivityPub and the fediverse. It's true that Mastodon has most of the user share, but there are plenty of other apps that are already working together: Pleroma, Pixelfed, MissKey, etc. That's the kind of ecosystem I like to see.

Conclusion

Like everything, Solid has positives and negatives. But overall, I still believe it's the best thing we have to improve our relationship with software and data.

I should mention, I also like many of the alternatives too. It's not that I dislike anything that isn't Solid, and there are many interesting projects out there. I'm happy to see that we have many people working on this. But every time I hear about an "alternative to Solid", I can't help but think of this:

Standards, by xkcd

This comes up so often that it's trite at this point. But it doesn't make it any less true.

It's still early days for this space, and I hope that all the variety serves to stimulate the ecosystem and cross-polinate ideas. Eventually, we should start converging on common solutions. And if that isn't Solid, that's fine, I'm prone to ignore Sunk Costs anyways.

For now, though, I'm staying with Solid.

What do you think, did I miss something? Let's talk about it, you can join the conversation in the Solid Forum.

Skeuomorphic Software

2023-11-28T06:00:00+00:00

Can you imagine a world where software lives unencumbered from the artificial limits we've created? One where applications work seamlesly with one another, and silos become a thing of the past.

I can, and this is what it looks like.

Skeu-what?

The word "skeuomorphic" comes from the greek words skeûos (implement, tool, vessel) and morphḗ (form). It can mean "resembling a tool" or "with the form of a tool".

You may already be familiar with skeuomorphic design, or skeuomorphism. In software, it has been used to describe graphical elements that resemble objects from the physical world: a floppy disk used to save files, a trash can that holds deleted files, etc.

Libreoffice's taskbar is a good example of skeuomorphic design

For a long time, we used it to transition from the physical world to the digital world. Today, we're moving on. Digital is already part of most people's life, and the bridge is no longer necessary.

However, when it comes to the way software works (not the way it looks), this bridge was never there. We've come to accept some limitations that don't exist in the physical world.

I have already written about these artificial limitations, and today I want to talk about what things could be like if we manage to break free.

The Platform Split

Maybe the most important limitation keeping us from the future I envision is the lack of interoperability.

In the physical world, we take it for granted. If you've got a tea kettle, you can use it to brew any brand of tea. You can serve it in any brand of cup. And you can combine it with any brand of pastries.

In software, things aren't so simple. If you download an audiobook from Audible, good luck playing it in your favourite media player. Or if you want to share someone's message in another social network, it won't look pretty.

Some of these may improve with regulation, such as the Digital Markets Act. But that's still a far cry from the ideal, and I'm not so naive to believe that any of this would be easy. Although I also believe that if we made the effort, we would be in a much better position than we are right now.

There is actually one piece of technology that embraces this philosophy: The Web. It's called the universal platform for a reason, and that is by design. Not only that, but going against it is frowned upon.

However, when talking about private data, not even The Web lives up to this ideal. As soon as we create an account, we've abandoned any hopes of making it compatible with other services. In a perfect world, you wouldn't even think about this. It would happen by pure serendipity.

But interoperability is only one part of the puzzle. Skeuomorphic software is much more than that.

Personal Software

Something else that happens outside of software is that people is more willing to learn and do things on their own. And so, experiences become more personal.

I'm sure that anyone reading this has at some point considered working on a DIY home project. The most ambitious may have built their own furniture or done some electrical wiring. But things as simple as gardening, making tableware, or even mounting furniture from IKEA show a willingness to learn and understand your environment.

When it comes to software, most people are helpless. Unless they have experience programming or administering software, they see technology as an impregnable black box they will never understand.

But it doesn't have to be that way. Programming is not as difficult as you'd think. Sure, you're not going to make an app from scratch without any prior experience. In the same way that you wouldn't remodel your kitchen without some professional help. However, when the sink is clogged, your first instinct is not to call the plumber.

It gets even worse. Not only don't people do software on their own, they don't even consider hiring a professional to do it for them. Sure, there is some work formatting computers and whatnot, but when was the last time you saw Personal Software? That is, a piece of software that has been built for someone's specific workflow and is not intended to be used by anyone else.

The closer we've got to this is spreadsheets. I'm always surprised to meet people who've mastered the most obscure of Excel's formulas, but are dumbfounded when you show them the simplest of JavaScript code.

On the other hand, everyone has an account on the Social Media platform of the day. Very few people have a place of their own in the Internet, and that's how we end up with a Big Tech ecosystem instead of a person-first indie web. I'd much rather have an ecosystem where software artisans take part in making everyone's experiences better, at an individual or community level.

Small and Open

In this ideal world, my favourite kind of software could thrive: Small and Open.

I strongly believe that great software is born from small teams. There are some exceptions, but software created by big organisations is often bland and complex. Smaller teams, on the other hand, can produce whimsical software that sparks joy.

When I say small, I also mean small in scope. Too large a team often results in a handshake overhead that stiffles innovation. And the attention to detail necessary to craft a great experience can only be achieved with a small surface area.

Small doesn't mean tiny, though. I think a good heuristic for what is "too big" would be Dunbar's number (150 people). Which is already a huge number, if you ask me. But I still believe a company of 150 people or less can make great software.

Now, go ahead and look at the software you use on a daily basis. I'm pretty sure most of it comes from Big Tech. But if you think about the software you love the most, I'm also pretty sure it'll come from a small team.

The other side of the coin is Openness. Not just Open Source, but also open formats and non adversarial practices.

One drawback of "small tech" is that it'll often have some rough edges. And a small scope could mean that it doesn't fit your particular use-case. But if the software is Open, there is room for you or someone else to fill that gap.

Something I would like to see is developers hired to implement Personal Software. In part, that's how I saw the spirit of Github's "Fork me" feature. It's something that didn't catch on, but it happens all the time in the physical world.

Going back to the example of kitchen remodeling, imagine that you hire someone to help you face the task. And right off the bat, they tell you that you can only choose from a catalog of premade designs. I'm sure that would go against most people's expectations. But nobody bats an eye about the lack of personality in Social Media platforms.

This idea may seem dystopian in today's ecosystem that prizes market dominance above all else. But it wouldn't be so if sustainability and versatility were taken more seriously, and we didn't think that small independent software is doomed to fail.

The Long Road

We're still very far from this ideal, and there are many challenges to overcome like standard fragmentation, maintenance burden, sustainability, data ownership, self-hosting, and many more. Though I wonder how many of these are real problems, or they are issues we created ourselves.

I also cannot say that my work lives up to this ideal. But at the very least, I'd like to see that we're moving in this direction. I'd certainly be happy to see people forking my apps!

If history has taught me anything, it is that it goes in cycles. I'm not sure in which part of the cycle we are at the moment, but ultimately progress prevails. And I can't conceive of a world with the same limitations 1000 years from now, if we're still around.

Onwards!

Interoperable Serendipity

2021-10-12T06:00:00+00:00

{{ partial:components/callout title="Check out the video!"
content="Interoperable Serendipity @ Solid World"
url="https://noeldemartin.com/solid-world-2025"
image="/img/talks/interoperable-serendipity.png"
icon="icons/play"
target="_blank"
/}}

If you had asked my thoughts on interoperability some years ago, I wouldn't have had much to say. Nowadays, it has become one of my most revered ideals. And today, I want to take you along for a journey towards its summum: Interoperable Serendipity.

Preface

Before we begin, let me lay down some context.

As you may know, I've been working with Solid for a while now. I started down this path 3 years ago, when I started working on what I called Autonomous Data. Soon thereafter, I found about Solid and decided to switch my focus there.

Recently, I came across Zero Data Apps, which is very much aligned with my initial idea for Autonomous Data, and it encompasses other projects beyond Solid. The main Zero Data protocols right now are Solid, remoteStorage and Fission.

One thing all of these have in common is that they make a great emphasis on the importance of interoperability. And this has been a common topic of discussion in the community.

In this post, I will give my take on the topic. I am going to use Solid in my examples because that's what I have experience working with, but my ideas should be universal.

A taxonomy of interoperability

The first time I heard about interoperability being classified was listening to an episode of Seth Godin's podcast called Adversarial Interoperability, which I recommend listening to.

In this episode, he introduces Cory Doctorow's classification; which is:

Indifferent interoperability: I don't care if you plug your thing into my product.
Cooperative interoperability: Please plug your thing into my product.
Adversarial interoperability: Dang it, stop plugging your thing into my product!

What we really want for our apps is indifferent interoperability, but I think that's very difficult to achieve in practice (more on this later). What we have with Zero Data protocols is cooperative interoperability. And what's more common in the rest of the industry is adversarial interoperability.

This classification is useful to understand the overall ecosystem, but I want to drill down on what cooperative interoperability looks like in practice.

Obfuscated interoperability

When you are writing a Solid app, you have a set of tools at your disposal to make it interoperable with other apps. But these tools can be neglected or misused.

One example is the type index, which is a way to declare where your data is stored so that other apps can find it. However, it's perfectly possible to make a Solid app that doesn't declare its data in the type index. This means that other apps have to know the exact location where the data resides, or they won't interoperate properly.

Another example is data types. In Solid, your app relies on Semantic Data, which means that each piece of data is self-describing (more on this in the next section). However, there is nothing keeping your from misusing that representation. For example, you could use a description field (which is supposed to be human readable) to store a json object.

Both of these examples are not uncommon in the wild, and there are multiple reasons for this to happen (ill intent not being a common one). To be honest, I have done a fair share of this myself, and probably still do.

When this happens, interoperability in Solid is not too far from adversarial interoperability. You have to go out of your way to make your app interoperable, and you have to rely on implementation details that are prone to change.

Intentional interoperability

If you use all the tools properly, things are much easier.

As I mentioned before, Semantic Data is self-describing. Let's illustrate what that means with an example. Imagine that you are making a task manager. In a traditional non-Solid app, this is what a Task could look like:

{
    "id": 1,
    "description": "Go shopping",
    "done": false
}

If you look at this data, you can probably guess what it means. But that's all you are doing; you're guessing. As the app becomes more complicated, that will be more difficult.

In Solid, this is what a Task could look like:

{
    "@context": "https://vocab.example.com/",
    "@id": "https://data.example.com/tasks/1",
    "@type": "Task",
    "description": "Go shopping",
    "done": false
}

On the surface, you may think it doesn't look that different, but let's dig a little deeper.

The @context property indicates the vocabulary, and this can be used to expand on the meaning of all the other properties. For example, if you visited https://vocab.example.com/description you would see some documentation on what the description property actually means.

The @type property is also important, it tells you what this object is. If you visit https://vocab.example.com/Task, you would see what properties this object can have and what it represents.

This is a lot better, and much closer to what Cory Doctorow means when he talks about cooperative interoperability. For a developer who wants to make an app interoperable with another, seeing this type of data and reading the vocabulary definition is not unlike reading the API documentation for a traditional app.

But there is an important difference here. In Solid, each application doesn't use its own data structure. Developers are encouraged to reuse existing vocabularies that can be found in websites such as schema.org and lov.linkeddata.es. This way, apps that are working on a common set of data will be interoperable out of the box.

But this doesn't work as well in practice as it does in theory. When it comes down to making an app, it's rare to find an existing vocabulary that fits perfectly with your use-case. So you resort to either mixing vocabularies or defining your own. The end result is that applications still need to be intentional about being interoperable.

Lens-based interoperability

With the concepts I've introduced so far, it's relatively easy (or at least possible) to make an app interoperable with another. You just have to look at the vocabulary it is using, and use the same one in your app. But soon, this can go awry if you want to be interoperable with two apps that use different vocabularies.

Up until recently, I didn't have an answer for that. But some weeks ago, looking at the notes for a Zero Data Swap, I came across a new project called Cambria.

Imagine that you want to be interoperable with two applications that generate the following data:

{
    "@context": "https://vocab.example.com/",
    "@id": "https://data.example.com/tasks/1",
    "@type": "Task",
    "description": "Go shopping",
    "done": false
}

{
    "@context": "https://vocab.acme.com/",
    "@id": "https://data.acme.com/todos/1",
    "@type": "ToDo",
    "name": "Go shopping",
    "completed": false
}

They use different vocabularies, so making your app compatible with both won't be easy. But looking at the data, you can tell they are actually doing the same thing. What if you could tell your app how to map from one vocabulary to another? And what if you could do it using your own vocabulary, making this translation transparent to your codebase?

That is exactly what Cambria proposes. It's not focused on Solid, but Solid has a concept of shapes and I think this approach would be a perfect match. They call these translations "lenses", hence my referring to this as lens-based interoperability.

But of course, this doesn't come without some caveats, such as what happens when two shapes are not perfectly translatable. To learn more about this, I'd recommend reading their thoughts on the topic. But one problem I see in practice is that developers, or someone, still needs to define the lenses. It's still not completetly effortless — it's not indifferent interoperability.

Interoperable serendipity

With lens-based interoperability, we can go very far. But there is still a use-case it doesn't solve. What are the chances of two indie developers, who don't know about each other, making apps that are interoperable out of the box?

Even with lenses, I'd say the chances are very low — you still have to know about the other app in order to define the translations. But that's the world I want to see. When I think about the potential of Zero Data Apps, what gets me excited the most is thinking in a world with hundreds or thousands of apps, that work with each other by pure serendipity.

I have some ideas of how this could happen, but none of them is perfect.

One possibility would be to rely on crowd-sourced repositories of translations. Even if a developer doesn't know about another app, the community could do the job of defining the translations. But this could potentially ruin the decentralized nature of Zero Data Apps.

Another solution would be to actually ask users how to translate the data. But this is a huge challenge in and of itself. Making this intuitive for non-technical users wouldn't be easy. Not to mention that this would add even more barriers to entry.

So yeah, I don't have a perfect solution. But I think it's important to strive nonetheless, and I'm looking forward to see how this evolves in the upcoming years.

The way forward

I have mentioned many ideas here, but interoperability is still lacking in practice. Not to mention interoperability between protocols, which I haven't even tackled.

But that shouldn't be discouraging, on the contrary. The fact that this is even a topic of discussion is a silver lining. In the world of centralization and Big Tech, this isn't even a possibility. So we must keep asking these questions, and working towards an ecosystem where these ideas are a reality.

For my part, I will continue working in the open and sharing what I learn along the way. The Zero Data ecosystem is still in its infancy, but I am hopeful that eventually it will blossom.

Onwards!

10 Years as a Software Developer

2021-07-13T15:00:00+00:00

In July of 2011, I finished my degree in computer science and got my first job. That was 10 years ago.

Today, I want to look back and share some of the lessons I've learned.

A Brief History of Me

Before I start talking about what I learned, I will review the journey that got me here. If you don't care about any of this, feel free to skip to the next part.

Before the beginning

Before I knew anything about programming, I wanted to be a graphic designer. My programming experience going into university was completely non-existent. I knew so little, in fact, that I didn't even know what I was getting myself into.

What I knew was that I liked mathematics and computers more than I liked the subjects I saw on the curriculum for an art degree. So I figured (wrongly) that if I studied computer science, I would learn Photoshop in some of the subjects.

I realize how stupid that sounds, but to my 18 year old self this made perfect sense. In high school, all the subjects I had taken related with computers had been all about teaching us how to use programs like Microsoft Word or AutoCAD. So in my mind, doing a career about it would just mean learning how to use more programs.

In the end, however, it turned out for the better because I love programming!

2011: Getting started

It was 2011, and I was 21. I had completed my bachelor's degree in 3 years, so my academic experience was rather short. I could have done a couple more years to get a full degree, but this time I understood the curriculum and I decided that I wanted to do something else. I had fallen in love with algorithms, but I was still very much interested in graphics. So I found the perfect follow-up, I started a masters degree in Artificial Intelligence and Computer Vision.

But there was something else nagging at me. I was enjoying the student life and working on my assignments, but I craved real-life experience. I had heard about entrepreneurship, and the concept was extremely appealing to me (even though, like with the CS degree, I knew nothing about it). As these things go, turns out that a friend of mine was starting an entrepreneurial endeavor and offered me to join them part-time. That's how I got my first job at Ilurus. Later on we started working on a different project called Veziko.

It was at this time that I started to follow others' work online. Probably the first developer I ever followed (and still do!) was Jeffrey Way, who taught me about CodeIgniter. This also meant I started learning about The Web, which I had seen close to nothing in university.

I also started listening to podcasts, and the first one was Entrepreneur on Fire. I don't listen to this one anymore, and my idea of entrepreneurship has changed a lot since (at the time, I saw entrepreneurship as a synonym with Silicon Valley and the VC unicorn madness). But this period definitely set the pillars for my ideals today, and I started to understand what this entrepreneurship thing was about.

But then, 2012 happened.

2012: Seizing the opportunity

In the summer of 2012, another friend reached out to me with an opportunity to work at an international company called Toro. It was a french-founded asian company, headquartered in Taiwan, with plans to open a new office in Barcelona the following year. They were hiring 10 developers to participate in a 5 months training program in Taiwan, who would then come back to inaugurate the Barcelona office in January 2013.

On the one hand, I still enjoyed learning about the entrepreneurship scene, and to this day I still look back at my days at Veziko as one of my dearest professional experiences. But I thought things were moving too slow, so I still craved that real-life experience. Now I understand that things take time, but I was young and ignorant then. And as much as I was enjoying the master degree, it was still purely academical.

On the other hand, Toro was already in business, I would gain international experience, and they were working with mobile technologies — which I knew were going to become the future (I knew because a teacher told me, I wasn't that insightful).

So it wasn't an easy decision to make, but in the end I decided to seize the opportunity (this was my first blog post ever, and yes, I also cringe reading it).

After the 5 months adventure in Taiwan, things were relatively stable. In January 2013 we opened the Barcelona office. As destiny would have it, I managed to continue pursuing my interests in graphics and UI. Most of my work at this company revolved around creating a UI engine for J2ME-like applications. I say J2ME-like because applications were written using J2ME, but they run on top of a cross-platform virtual machine. One of the challenges, then, was to replicate native components as much as possible. This seemed crazy at the time, but today we have Flutter which is kind of doing the same, so maybe it wasn't so crazy after all. Other than UI, I also got some experience working with assembler code and virtual machines. To this day, this has been my most technically intensive role. I even tutored a thesis on true-type font rendering, believe it or not.

I worked at Toro for two years, and I learned a lot given that this was my first "real job". But I still hadn't been cured of the bug of entrepreneurship, so in the summer of 2014 I decided to quit.

2014: Entrepreneurship

If Veziko had been pure entrepreneurship, Toro was my first experience working in a corporate environment. It still had a startup vibe, but there was definitely a lot more bureaucracy. So I still yearned to do things my own way, and I wanted to experience working in the full stack. Not "full stack" as in development stack, but the full product stack. I wanted to take an idea from inception to reality and experience all that goes with it.

Years before, I told myself that even though I was getting a job, my primary goal was still to learn. And it would be until I was 25 years old. I was 24 when I quit Toro, and I had some savings. That's why I decided this would be my best chance to do entrepreneurship. Even if it didn't pan out, I would learn a lot.

Now, the problem was that I wanted to do "something", but I didn't know what! Yes, that's the text book definition of a wantrepreneur. Struggling with this is how I came up with posts like In the search of value.

But that situation wasn't so bad, because it gave me the chance to experiment and follow my curiosity. In this period, I planted the seeds for some of the things that I value the most today. For example, I created this website. It was also during this time that I really started getting into web development, and fell in love with Laravel.

I decided to release my products under a brand. That's how I came up with Lincoln's Chilli, which I called my "entrepreneurial sandbox". Most of the projects I started are discontinued now, but one of them survives: Quick Pick. This was actually the first product I ever made, and it embodies that notion of doing everything myself. It's 100% hand-crafted. I got some help from my girlfriend who sketched the characters in paper, which I then digitized and colored for the game. Even the music you hear is actually me playing the guitar! (don't get too excited though, it's a silly tune).

In parallel with doing my own thing, I also collaborated with a friend for something more ambitious. Actually, if I have to be honest, it was too ambitious. We created an online turn-based card game for mobile phones. You can think about it like a mix between Magic the Gathering and Chess. And we weren't shy on features. I implemented from scratch: a leveling system, a backend to manage the library of cards, a custom protocol to synchronize (and replay) actions across devices, bots with different difficulties, an interactive tutorial, etc.

I would agree if you say that it was a bit overengineered. However, working on this project was extremely fun and insightful. We also collaborated with illustrators and sound designers, so it wasn't just about programming. The game is no longer available, but you can find some screenshots – and an APK to play offline – in the projects page.

So, for two years, I had been working on my own projects full-time. But let's talk numbers. Do you know how much money I made? 0€. Yes, that's not a typo: 0, zero, nothing. And it wasn't because I didn't monetize my products; the card game launched with in-app purchases, and my latest product wasn't free to use. I even had ads on my second product, but it made almost nothing so I didn't bother cashing out.

The critical mistake I made was always the same: launching to crickets. I learned, the hard-way, that it doesn't matter how good your product is. If you are not solving a real problem, it will not work. And marketing is also very important, something I did almost none of. Not to mention time, there is no such thing as an overnight success, and most of my projects were finished at launch. I'm not saying that my products were great either, but I learned this because it didn't matter how much effort I put into a project, the response was always the same: crickets.

So I won't try to sugar coat it, let's call it what it was: failure.

But if I'm honest, I don't regret a minute of it. I mentioned how my main goal was to learn, and I had definitely done that. There is a valley of difference between doing something as an employee and doing it for yourself.

And just when I was about to start looking for a job and leave aside this entrepreneurial pipe dream... I co-founded a startup.

2016: Startup life

After spending a couple of years trying to push my ideas into the market, which doesn't work, I was ready to go back to a stable job. But before I even applied anywhere, I got a new opportunity. Yet another friend had rented an office in a scientific park in my home town. And the person renting the office next door had just launched their idea and was looking for a technical co-founder.

The vision was to give people access to sport facilities without paying subscription nor registration, just paying for their use in minutes. There was a gym across the street, and they had already run a pilot with good results. The name of the project was Geemba.

The prospects were really good: the location was great, there was a technical challenge, and the business idea resonated with me. But not everything was sunshine and roses. My savings were running out, and taking this kind of position wouldn't guarantee a stable income for a while. What's worse, I had to invest money in order to found the company. And I was 26! So the learning excuse was out.

But I really wanted to do it, so I decided to join with a couple of conditions. We opted for a government-backed loan called Enisa. If that was granted, together with our own money, we had a financial runway of about a year without relying on external investment. I had to ask for a personal loan to cover my part, but I would get it back with a (very low) salary and doing some freelancing on the side.

So that's how I managed to kick it up a notch and became the "CTO" of a startup. I put that in quotes because it's ridiculous to call anyone CTO for a two-person company. But that's how things go in the entrepreneurship scene.

The next year and a half was great. It was bittersweet having to freelance to get out of debt, but I wouldn't have changed it for the world. We ended up hiring some part-time employees, and because we were located next to a university we also had a couple of students doing internships. I even did some presentations in the university and joined as part of the jury for a couple of master theses.

On the product side, I was very happy with the solution we came up with. Customers would download the mobile app, introduce payment details, and request access before arriving at the gym. Once they got there, the receptionist would accept the request from their private dashboard and let them in. At that point, the timer started counting. When they left, the receptionist ended their session and we charged them for the exact amount of minutes they had spent inside the facilities.

On the technical side, I also learned a lot. I started using Vue, another one of my core technologies today. As you can imagine, building all the moving pieces was not trivial (the app, the backend, the receptionist's dashboard, etc.). To top it off, everything had to work in real time and payments were involved! Thank God that Stripe already existed. Fortunately, we never had any serious technical issues.

But if you're reading this, you know it didn't end well. Customers loved the idea, but finding gyms willing to do it was a different story. Many of them actually thought this was a threat to their business model, because they depended so much on customers paying subscriptions (even if they didn't attend the facilities, does that ring a bell?).

We started with this idea of "gym by hours", but we slowly began catering more to the gym's needs: we built a CRM for all their customers (not just the ones using our app), we created an editor to make personal training plans, etc. Eventually, we started to run out of money and our only option was to seek external investment. I'm happy to say we didn't even try, we didn't waste a single minute on that.

A year and a half before, we set out to validate the idea. After having given it our all, we decided that this was it for us. Could it have worked if we kept grinding? Sure. Could we have done it better? Absolutely. Do I regret quitting or even trying? Nope.

If you're curious, you can also learn more about Geemba in the projects page.

So after almost 4 years working on my own projects full-time, I went back to the workforce.

2018: The wrong bus

If you've paid attention, you may have noticed that this was my first time looking for a job. So my job hunting skills were virtually non-existent. To make things worse, I didn't even know what to look for. Should I look for a management position? Technical lead? CTO at a startup? Fullstack developer? Frontend developer? Mobile developer?

Ultimately, I decided that I wanted to spend most of my time programming, so I looked for developer offers. But narrowing them down was still tougher than expected. I had my development stack of choice, but I didn't care about it as much as I cared about the values and mission of the organization I would join. Turns out that's not something you can filter by in job boards. In the end, after spending too much time searching and applying almost nowhere, I ended up joining a startup called MusicList.

Initially, I was looking forward to it, because I was the first employee and I thought I could have an active role in shaping the values of the company. But soon I realized that wasn't going to happen. The values of the founders were too different from mine. And I didn't notice before joining because their values were not that different from mine 4 years before. In the 4 years of walking my own entrepreneurial journey, I had changed.

I'm not saying their values were necessarily bad, or that they were trying to do something unethical. But they were on the Venture Capital Startup hamster wheel, and I was done with that. By this time, I was more interested in privacy and sustainability than growth. I also started reading Seth Godin's blog, which gave me a new perspective on how to do things. Right about that time, he published a post called The wrong bus that had a big impact on me. I was on this bus headed to startup land, and I didn't like it. I'm sure it helps that I read it while riding a bus, on my 1-hour commute, in the middle of August, whilst most of my friends were enjoying their summer holidays.

So, shortly after joining, I was back on the job hunt. But this time, I was in no rush. I finally had a stable salary and no debts, and I had just moved out of my parents house (yes, at 28 years old!). The work itself wasn't bad either, I was using Laravel and learning about React, which completed my curriculum with professional experience with "the big 3" frontend frameworks (React, Vue and Angular). But all that time, I wasn't completely happy because I knew I didn't like were I was going.

The following year and a half I transitioned from accepting the situation to almost quitting. From the start, I was completely honest with my colleagues and I even published a public blog post announcing that I was looking for work. I also asked others for advice. It was during this time that I learned that job boards can be some of the worst places to find a job (at least the kind of job I was looking for).

Other than job seeking, I still had the entrepreneurial bug in me (I guess it's never going away). So I joined Seth Godin's The Bootstrapper's Workshop, which pushed me to start working in the open. This is also when I learned about Cypress, TailwindCSS, and Solid; the three technologies that completed my current stack.

Even though doing that on the side was great, I became ever more uncomfortable with my day job. Eventually, I decided to quit for good. But I didn't want to go into entrepreneurship again, so I would be quitting into unemployment. Talking with someone in an event, I had a crazy idea. I had heard about the mythical 4-day workweek, and I thought that dedicating an entire day a week to my side-projects would satiate my hunger for purpose (at least for the time being). So I went ahead and asked for it. If my request was denied, I would quit altogether.

I really saw this as an excuse to tell myself in order to justify quitting without a plan, I totally expected it to be denied. But to my surprise, they accepted. And this is how I started experiencing a 4-day workweek, and haven't looked back since. It's funny how two of the best decisions in my career came out of a period when I felt the most out of place: working in the open and the 4-day workweek.

A couple of months after that, it seems like my job seeking efforts finally started paying off, because I got an offer I was excited for. I was offered a Mobile Developer position at Moodle.

2020: The right bus?

In November 2019, I joined Moodle. I hadn't been unemployed for long, but I had been looking for work most of the time since January of 2018.

In all that time, you must think I sent hundreds of applications, right? Well, I only sent 21. That's like 1 per month. Of those 21, I was rejected from 9, didn't hear back from 7, didn't get clear answers from 3, and was accepted in 2 (MusicList and Moodle). And 3 out of those 21 were Moodle. The first time I applied was for MoodleNet Technical Architect (this happened before joining MusicList) — I was rejected. The second one was for PHP developer — I didn't hear back. And the last one was for Mobile Developer — I was accepted.

All of this is to say that job seeking is hard. At least it was for me with the parameters I set for myself. But I did it! I am finally working at a company with values I share.

So, am I on the right bus now?

I guess there's no way to know, but I would say that I am. I'm not a "startup guy" anymore, although I still call myself an entrepreneur. I cringe a bit at the term, but I haven't found a better word for describing what I do. I could just say that I am a developer (and sometimes I do), but I enjoy working on other parts of the product besides code. I could also call myself a maker or something else, but I don't feel identified by any of those terms. So I'm sticking with entrepreneur for the time being. Even though I don't care about earning money with my projects, so I guess that's not very entrepreneurial. Regardless of what I call myself, I think I'm in the right path.

I've also found a good balance between being an employee and working on my own projects. I never went into entrepreneurship for the riches, I just wanted to do work I cared about. So I'm fine being an employee if I'm contributing to a worthy goal. But there are still things I want to do that will never happen as an employee, so having a 4-day workweek makes my side-projects sustainable. Even if my salary has nothing to do with them.

2021 and beyond

So, what are my plans for the future?

The truth is that I have none, other than continue doing what I'm already doing. That doesn't mean that I'll work at Moodle for the rest of my life, but I have no plans of leaving in the foreseeable future. And I'm still very excited about my side-projects, so I'm not running out of ideas anytime soon.

Things have changed a lot in 10 years, so there's no way of knowing what will happen in the next 10. If anything, I have to say that I'm extremely lucky to be where I am, because even though I have my gripes with the current state of the software industry, I love it.

Lessons Learned

Now that we've got that out of the way, let me start with the part that could actually be helpful to you.

Here's 10 lessons I learned in 10 years.

1. Values > UX > DX

If you expected this post to be only about development, I'm sorry to disappoint. Yes, I am a developer, and these are the lessons I've learned as a software engineer. But it's impossible for me to see my career as "only tech". I think we — as engineers and human beings — are responsible for what our work contributes to.

This wasn't obvious when I embarked on this journey. But now, it's one of my core tenets. In the work I do, be it as an employee or not, the most important question I ask is what is it for?. If I'm contributing to something that is not aligned with my values, I don't care how nice it looks or how fun it is to code — I won't do it.

As a consequence of that, and given my interest in design, I also place a great importance on UX (User Experience). I like to think about it in terms of Kano model, focusing on what actually has a real impact on people.

But I'm no designer, so I also care about DX (Developer Experience). I've talked about how much I like Laravel and Vue, and that's how I want all my development experience to be. I want to spend my time solving real problems, instead of battling accidental complexity or fighting against my tools.

These three — Values, UX, and DX — build on each other, and it is possible to tend to all of them. That comes at a cost, you will be slower in the short term. But I believe it pays off in the long term. That's why most of the time I'll choose to cut the scope instead of degrading quality.

2. Write good code

Every developer loves good code. But there is something subjective in determining whether some code is "good" or "bad". You could measure how well it solves a problem, how often it crashes, or how easy it is to extend. But if we're honest with ourselves, the only valid measurement of code quality is WTFs/minute. So, good code is simple code.

However, that's easier said than done. According to Rich Hickey, simplicity is objective. But I think that's an oversimplification. Sure, you could write the simplest code ever, but as soon as it needs to interact with other code, it won't be as useful. The opposite of that is overengineering. If you write your code so flexible that it can do anything, it'll become a complex mess. So the challenge is in balancing both. I try to resolve this tension with conceptual compressions. Simple enough to be understood from the outside, yet powerful enough to be useful.

There are many concepts that have influenced my idea of what makes "good code": the SOLID principles, YAGNI, First principles, doing code katas, etc. But there is something beyond that. There isn't a specific way to measure good code, but I can recognize it when I see it. Some people call this "taste", I often call it "elegance". Regardless of how you call it, there is something I'm convinced of. Programming is not just science, programming is an art. And that's why I love it so much.

Write good code, make good art.

3. Be opinionated

One of the earliest ideas that is taught to developers is to "use the right tool for the job". While I agree on the overall idea, I have to say that most of the time it doesn't matter.

This is particularly irrelevant when it comes down to framework comparisons. There are tons of articles talking about Vue vs React vs Angular vs [insert new JS framework here]. The truth is that you'll be able to do the same thing with all of them. And I'm not saying that these comparisons are useless. But the chances that they actually matter for your project are slim. In the end, I chose the one that I enjoy working with the most.

React is all the rage today, but for the life of me I don't see how anyone likes it more than Vue. Now, before you jump down my throat maybe wait until you finish reading the blog post. I never felt comfortable writing React (who ever thought that throwing a Promise makes sense!?), whilst using Vue is effortless. I'll even go further and say that Vue helps me become a better developer. And that's something I'd say for all my favorite tools: Laravel, Vue, TailwindCSS and Cypress. I don't think it's coincidence that all of them also have great documentation.

I'm aware that I'm often misunderstood when I raise this point, so let me clarify. I am talking about personal preference here. When I join a team, there are more important things I care about. So I'm more than happy to work with the tools that are already in place. Even if I were in a position to make the choice, maybe I wouldn't chose my favorite tools for a team project anyways.

This also doesn't mean that I never ever want to learn anything new, quite the opposite. I don't find technology worthy of taking this position every day. But when I do, they convert struggle into bliss. One common occurrence is that I'll start using patterns I learned in these tools elsewhere. For example, I'm always porting Laravel facades to other languages.

And I'll finish by saying that frameworks and libraries are not the only tools I'm referring to here. Your programming environment also matters, and I have to credit Caleb's awesome course for showing me that.

4. Never stop learning

If I think about it, I learned about my favorite technologies on my own. And if I had to say what made me grow the most as a developer, I'm not sure if I would credit my work on "real projects".

I mentioned it before, but it bears repeating. There is a valley of difference between doing something as an employee and doing it for yourself. I've also learned a lot from watching conference talks and reading books and blogs, but nothing beats doing something from scratch on your own. That's why I think it's important to be deliberate about improving yourself, instead of expecting it to happen as a side-effect of doing your job.

I know there are a lot of developers who don't want to dedicate any time outside their working hours to coding. And that is totally fine, I don't think that should be a requirement. The problem comes when companies don't allocate resources to self-improvement. And even when they do, most of the time it is only for technologies that are relevant to the company. I'm sure there are times when you come across a new technology or paradigm that gets you excited, but you don't do anything about it because it's not relevant to the project you're working on (and there are deadlines). However, following that curiosity is what will make you a better developer in the long run.

To be clear, I don't think this is inherently wrong from the company's point of view. After all, in our capitalist society, employment is an exchange of labor for money. Which can be done as humanly and fairly as possible, but that's what it is. And you could choose to live outside of capitalism, but good luck with that (I'm not being snarky, I'm trying to do some of that myself).

But there is a loophole. We, developers, are in an extremely privileged position. There is certainly no shortage of jobs, salaries are among the highest in many professions, and remote work opens many doors. If you use this to your advantage, you can navigate this capitalist system to keep improving while having great work-life balance.

I'm taking advantage of this situation with a 4-day workweek. I don't see it as a 4-day workweek at all, I see it as a 4-day main project and 1-day side-project workweek. If you think this is crazy, maybe it's because you haven't tried it yet (I certainly did before giving it a shot). But it's not the only way. You can also take sabbaticals or switch to freelancing for a while.

Now, I know what you're thinking, and I don't want to get into financial independence, cost of living, and all that jazz. But I'll say that if you don't have that kind of buffer (in your lifetime, not at any given point), you've got bigger problems to worry about. We are privileged enough to not have to worry about this. If you want to learn more about these topics, I recommend checking out the blogs of JLCollins and Mr. Money Mustache.

5. Think long term

Code is read more than it is written. You'll only write it once, but there is no limit to how many times it can be read. Whenever I look at code I wrote years ago, I'm often glad that I cared about readability and following best practices (although be careful with so-called "best practices", there's no silver bullet). If this made a difference for me, you can only imagine how important it is for other people reading your code.

At the beginning of my career, I wasn't sure if agonizing over details was worth it (and it seems like I wasn't alone). I would spend too much time thinking about things like variable names or code. I did it because I couldn't help myself (and to be honest, I enjoy it). But I had the impression that it wasn't the best use of my time. Over the years, I've found that eventually it pays off. Sure, there is code that nobody will read. There is code that doesn't even make it to a commit. But the point is that the way you do anything is the way you do everything. There is a fine line between things that matter and nitpicking though, so I try to be practical about it.

Looking at the broader picture, it is essential to separate the urgent from the important. There are things that are urgent and important, so you'll naturally do those first. However, the trouble begins when you start prioritizing the urgent things that are not important over the important things that are not urgent. We always want to get things done as soon as possible. But things take time, and there's no shortcut that can change that. So give them the time they deserve. When I get stuck on a problem, the most effective solution is always to give it time. I leave it for the next day, or I go work on something else. When I come back, it always gets easier.

And you have to apply this mindset to your mental bandwidth as well. If you're mindlessly checking tasks off a TODO list, you're only being reactive and you'll never get anywhere. You need to be proactive, you need time to ponder and to follow your curiosity. That's how you'll make your best breakthroughs. It can feel like this is slowing you down in the short term, but these are the types of actions that will compound into your best results in the long term.

Zooming out even more, you can also apply this to your career. It's fine if you're lost for a while, if you keep working on it eventually you will get what you deserve. In the short term, luck is a big factor. If you don't succeed passing an interview, or if your project doesn't get the response you expected, that doesn't mean that you did anything wrong. By the same token, if you succeed that doesn't mean you did everything well. But in the long term, luck is diluted.

However, there is something crucial to keep in mind. The "long term" can be longer than you'll be on this path. Longer than you'll be alive, for that matter. So you should be comfortable with not getting what you want. Don't put yourself in a bad position with the hopes that it will eventually pay off. I've had my ups and downs, but I've never been done something I didn't want to do. Plan for tomorrow, live for today.

6. Use systems and processes

Regardless of how much experience you have, you're still human, you will make errors. Not only that, our brains are not wired for long-term thinking, so if we only follow our gut, we'll be all over the place. This can be improved with discipline and deliberate practice, but we will never become perfect beings. That's why I think it's important to have systems in place.

Peer reviews, schedules, workflows, linting rules, etc. All of them help us reduce human error and become more consistent. But you should also be careful that your systems don't get in your way. There's a reason why most people hate bureaucracy. Even though it's inevitable to a certain extreme, it should be minimized.

And systems are not something set in stone. You should create your own processes, see how they are working (or how they aren't) and improve them accordingly. And that, in itself, is an ongoing process. I'm always trying new things and reflecting on how my systems are doing.

I have written about this before, so if you are interested you should check out
Rigid-Flexible Planning and Order vs Chaos.

7. Remember nothing

Some years ago, I talked about the power of ignorance, and it is still one of my most controversial ideas. But 5 years after writing that post, I still agree with most of it.

In programming in particular, it may seem counter-intuitive to say that, because there is so much jargon you "have to know". But actually, when I say "remember nothing" I really mean "remember nothing on purpose". When you are learning about a new technology, a new design pattern, or a new paradigm, the name of the thing is the least important. It's not the same to know the name of something than knowing something. If you really understand something, you'll learn its name without trying. So you should strive to understand, not to remember. The names will come naturally, and they will serve to compress ideas. Instead of explaining a design pattern every time, you'll just use the name as a shorthand for the entire concept.

At the beginning of my career, I used to take courses and read about the basics. Things I should already know, and I mostly did, but I still enjoyed drilling the basics. I did that until it got boring. And I think that's really important in order to interiorize the principles.

Another way of looking at this is the way you tackle problems. Whenever I am working on a project and something doesn't pan out, I will often spin up a hello world application and try to reproduce the problem in isolation. This is helpful to remove the existing baggage on the project, and helps giving me a fresh view on the problem. I also make a conscious effort not to remember the rationale behind some of my decisions (that's why I don't write comments too often). If later on I am reading some code and I don't understand it, or I'm calling a method that doesn't work as I expected, that's a great way to see it like a newcomer would. If it's not obvious, it's probably not right.

8. TDD is the way

Like most people, I wasn't too keen to get into TDD at first (Test Driven Development). But after having seen the other side, I can't go back anymore.

Let me be clear in saying that I don't believe in TDD as a dogmatic approach to coding. For example, I don't look at code coverage at all, because I think it's a perfect example of Goodhart's law. But now that I've gotten used to writing tests very often, I feel crippled when I can't do it. So let's call it TDDish.

The main reason why I think testing is great is that we all do it. When you are developing a new feature, you're probably running some code to see that it actually works: calling a script, opening the browser, etc. So you are effectively doing TDD already. The only step you're missing to follow the "TDD way" is to automate those tests. At first, this will slow you down and that's why many developers dread testing, as I did. But if you persist, you'll eventually reach a point where writing a test becomes as natural as calling a script or opening the browser. Once you get over that hump, testing will become an essential tool in your toolbox.

In the short term, this will give you a faster feedback loop when you're writing new code. I use Cypress very often instead of a normal browser, because it's so easy to automate what I would do by hand and I can time-travel between steps.

In the long term, it will let you sleep at night. And more importantly, it will allow you to refactor without fear of breaking existing functionality. And refactoring is crucial, I probably spend more time refactoring than I do writing new code. Without tests, you're often afraid of breaking things so you think twice before refactoring. And that leads down a dark path.

Testing is also great for maintenance. When you find a bug, you can just fix it and move on. But if you write a test reproducing the bug, you've fixed it forever. It's only fixed if there's a test.

I don't follow the doctrine of the testing pyramid, which dictates that you should have more unit tests than integration tests. I just write the tests I find useful, and those vary depending on what I'm working on. For example, when I'm writing a library I usually write a lot more unit tests, because it's more likely that those units end up being used in isolation. But when I'm writing apps, I rely almost exclusively on integration tests.

There are a couple of heuristics I use to gauge how my tests are doing. The first one is how often the software breaks. You'll always find bugs in your software, specially in edge cases. But if you're finding too many obvious problems that your tests weren't picking up, that's a bad sign. And the other heuristic I use is how often I need to change my tests when I'm refactoring. It is one thing if the refactor involves some change in functionality, but if every time you change something your entire test suite goes nuts, you're probably doing something wrong. Your tests should not replicate the structure of your code.

9. Be a team player

In this blog and my online persona I talk mostly about the work I do as an independent developer. However, that's not what I'm doing most of the time. And if given the choice, I'm not sure if I'd want to.

It doesn't matter how good you (think) you are, you won't get anywhere by yourself. Success and quality wise. There is a saying that goes "you are the average of the 5 people you spend the most time with". It can seem shallow to think this way, like you don't have a personality of your own. But whether I like it or not, it's true to a certain extent. And I'm not sure if that's because you seek people like yourself or because your environment shapes your personality. I guess it's a bit of both.

These 5 can be people who don't even know that you exist. If I had to list mine, I'm sure more than one would come up — because I spend a lot of time listening to podcasts, reading blogs and watching presentations. More often than not, however, you'll be surrounded by the people you work with. Naval Ravikant said "if you can't see yourself working with someone for life, don't work with them for a day". The first time I heard it, I disregarded it as idealistic. But the older the advice gets, the truer it sounds.

In most occasions, you won't be able to pick your peers. But you can pick the company you work for. If you're starting at a company with strong values, chances are that the people around you will share these values. Even better, because you didn't pick them, they'll bring diversity to your points of view and you will get out of your filter bubble.

But there is something you need to understand when you're joining an organization. It is extremely difficult to change the culture, in the same way that it is extremely difficult to change people. And to be honest, even though it can be frustrating at times, it's probably for the better. I often think about the four stages of competence, which explain how a person can know so little about a topic that they don't see the complexity and think it's easier than it seems. You are that person in more areas than you think. Most of the time, there's a reason why things are like they are.

But that doesn't mean you shouldn't strive to influence the culture anyways. I think the most important thing for a project to succeed is communication and awareness. It isn't following good practices, nor having a great technical solution, nor even having money (although these are important). The most important thing is communication. That's also one of the reasons why I prefer working at small companies, because I think it's easier to talk with the right person and understand what's going on. So, even though they can feel like chores, I think doing 1:1 meetings, managing expectations, and having regular updates is really important. Overcommunicating is way better than undercommunicating.

10. Know Thyself

If you've read this far (thanks!), chances are that you disagreed with something I said. And that is totally fine, I don't think what I say applies to everyone. Certainly not everything applied to me 10 years ago, and it may not apply to me 10 years from now. But there's something that is important for everyone: You should know yourself.

When I started working, I had this idea about what my career would be. I would start working as a "junior developer", then I would be a "senior developer", and eventually I would graduate to become a "manager". Now that couldn't be further from the truth. I have dabbled in managerial positions, and I enjoyed them to a certain extent. But programming has always been at the forefront of my job. And I would hate stepping away from the keyboard (or the whiteboard). Not everyone is like this, some people actually enjoy managing other people. Or — as good managers say — enabling others to do their best work. And I'm glad they exist, but I'm not one of them.

Later on, I started to have some doubts whether I wanted to work for someone else or I'd rather work for myself. I think the jury's still out on that one, but I know for sure I could be happy with either one. It depends more on what I'm doing — and who I'm doing it with — than how I'm doing it. Some people only care about the technology they use, or how much money they make. I'm not sure if I'm glad they exist, but I'm not one of them.

Since the beginning, I've been inclined to "do things right". Maybe too inclined, even, because I have been an architecture astronaut at times. And I worry that my experience is often a crutch more than it is an advantage. But I'm aware of that; of the good parts and the bad parts. And it's something I try to control with the systems I've put in place.

One great way to know yourself, is to work in the open. I have said it before, but for me working in the open is valuable in and of itself, even if no one is looking. And if you don't even know what working in the open means for you, just write. If you're not writing, you are not thinking.

You'll never finish this journey of introspection, but you must walk it. All along the way, you will change. We're all chameleons, so our colors won't be the same tomorrow as they were yesterday. And experience colors our vision of the world. If you think the way you do, it's because of what you've lived through. There's no other way to learn, and with new experiences there will come new lessons.

Onward

So, that's a good chunk of my thoughts right there! I hope it was useful to you, and I'm grateful for what my journey has been thus far.

I will continue working in the open, so if you want to keep up and see what I learn in real time, you're welcome to follow along!

2024 Update: I'm not working at Moodle anymore, you can learn more about why and what I'm doing next in The End of The Chapter.

What Technology Wants

2021-04-21T17:00:00+00:00

...is nothing.

You do, and I do. But technology doesn't.

Everything you love about technology, and everything you hate, is not its own doing. Technology is only a multiplier.

Use it for good, and it will flourish. Use it for evil, and it will corrupt everything in its path.

My Vision

For a long time now, I've had this abstract idea of how I think technology should be. Today, I want to share some of that vision and reflect on what I'm working towards.

It will be extremely idealistic. I don't think it will materialize tomorrow (or maybe ever). It'll also be focused on software. I know other types of technology are important, and there's plenty of problems in society that cannot be solved with technology alone. But this is a vision seen through my eyes, and it serves as an ideal to strive for in my work.

When I think about technology, I am excited about the limitless possibilities. It has radically changed the way we view the world. If you had a time machine, drove 100 years into the past, and explained people from that era the information you can get in less than a second; they'd take you for a lunatic. And that's not limited to things you can do online, you are carrying in your pocket a device more powerful than anything they could ever imagine. We take it for granted, but if you could send a mobile device back in time it would change everything.

But it doesn't always work this way. Some technology builders are closing their gates, and limiting the possibilities for their own gain. This is detrimental to society because it only benefits the individual (even if that "individual" is an organization). But technology is not a zero-sum game, so we're shooting ourselves in the foot. Imagine if the mobile phone you sent to the past required in-app payments or internet connection to work. It would be no more useful than paper weight. That is the reality we're living in today, and most people just accept it. But it could be better.

Taking a closer look

One of my major frustrations are streaming services. Technology would allow us to consume any piece of media, anywhere in the world, anytime. And yet what we have today is a mishmash of platforms, each with their own walled garden, and with catalogs that lose content on a regular basis.

If there's a movie you want to watch, your first step is to start fishing for platforms that have it available. If the ones you happen to be subscribed to don't have it, you're out of luck. You may still be able to rent it in some other platform - if it's available in your country. By this point, you can consider yourself lucky if you've spent 20 minutes searching, filling up forms and accepting terms and conditions you didn't read. If you're not lucky, you just wasted 20 minutes of your life.

And I know what some of you are thinking, this doesn't happen to you. Sure, if you are going to watch last week's hollywood blockbuster this won't be your experience. But try to watch an obscure japanese movie from the 80s and let me know how that goes.

That's why most people don't do that. Most people don't keep a list of movies they want to watch. Instead, they log into their walled garden of choice and start browsing. Or watch movies recommended by other people. Movies those people found on the same walled garden, of course.

In this situation, human behaviour is driven by the algorithm. Technology is using you. It should be the other way around, you should be using technology.

Not to mention how preposterous it is that these platforms are called "streaming services" to begin with. Why is it so hard to download media for offline consumption in an open format? You know the answer is not some technical limitation.

What's even more preposterous, why don't these platforms have all the movies from public domain available within their catalogs? You know the answer is not some technical limitation either.

With all this non-sense going around, sometimes we end up with some pretty ridiculous situations. From technology's point of view, this is inexcusable. But if you look beyond technology, there are some pretty good explanations.

There is another world out there, though. The so-called world of Piracy. I'm saying so-called because there is nothing illegal about the technology powering the sites that are deemed so.

In that world, the gates are wide open. The problems I've mentioned are replaced with a different set of problems, none of which arise from technology itself. But this paradigm has been threatened an ostracized for a long time, so it's becoming ever more obscure.

And yet, their catalog is unrivaled. You can only imagine how life would be if technology were completely freed from its shackles.

I know what you're thinking though, so let's talk about the elephant in this post.

On Business Models

The main reason why any of these limitations exist is money. Don't get me wrong, I know that creators should be paid for their work. And I'm well aware of the disease of "free" products (spoiler: nothing is free). But I think the way we are monetizing isn't great, and business models shape the world.

Let's go over the most common ones.

Free products Ads

There are no free products, those companies are usually selling ads. Or straight up selling customer data... or selling the users themselves (more commonly referred to as "making an exit").

I won't even get into why I don't like these business models, because I could write an entire blog post about it and I don't even know where to start.

I'll just leave you with this: If something is free, you are the product.

Subscriptions

Next up are subscriptions. This business model has become more pervasive over the years, and I don't have any issues with the model itself. Some subscription services make perfect sense, and I'm happy to pay for those. The problems start when this gets out of hand. It comes down to this: when you are paying a subscription, what are you paying for?

I suspect a lot of people would say that you are covering server costs. After all, these subscription shenanigans started when syncing data to the cloud became more prevalent. But I don't think that warrants a subscription. The current ecosystem works under the assumption that managing your data is the service provider's responsibility. Instead of having your own cloud, your data is stored in somebody else's cloud. And this is an assumption I'm very much against, as surfaced by movements like Solid, Unhosted and Local-first software.

So, server costs are not an excuse.

Another common reason is to support ongoing development. However, when you buy into a product, it doesn't mean that you'll automatically like every new feature that comes out (sometimes it's the opposite). Sure, you can always cancel your subscription if you're unhappy with new versions. But at that point, you've already funded its development. And because you don't own your data, you probably can't abandon the service without paying the switching costs of vendor lock-in.

I'm also not a fan of the short lifecycle of apps nowadays. I'll talk more about this in a moment, but suffice to say that software should strive to live until the end of the internet.

So, supporting the ongoing development is not a valid reason either.

Which takes me to the only argument I will concede for subscriptions: Maintenance. Things like answering support emails, fixing bugs, and the like. But this one comes with a lot of caveats. It's a well known fact that no software is perfect and no software is finished. But there is also plenty of software out there that has done great with minimum maintenance costs. Especially when the gates are open for the community to help each other.

So, if the only real cost is maintenance, why are subscriptions so popular nowadays?

The real answer, that no company will ever confess, is that some of them are just milking their customers. It is people farming.

Sponsorship

Now we're getting somewhere. I like sponsorships, because they are basically voluntary subscriptions. If you want to support the ongoing development, why not do it explicitly instead of being strong armed into it?

But there is such a thing as the tragedy of the commons, so it's not realistic to think that this will work for everyone. That's why sometimes, sponsorships end up being subscriptions in disguise (when the perks are too sweet).

There is something in between that I like: Sponsorware. The idea is that a product will be private until it reaches a certain level of funding, at which point it becomes a public good. Unfortunately, I haven't seen many people following this model. But I hope it becomes more widespread, because I think it fits really well in the intersection between making your work sustainable and not limiting the technology.

Buying

Buying, instead of renting, is the purest form of value exchange. If you own something, you can do whatever you want with it. And this business model should remove any incentives to limit the technology. But there is such a thing as planned obsolescence, and sometimes you don't even own what you buy.

Do you remember that time when you bought a DVD and you knew you'd be able to watch that movie ten years later? Those days are gone. Sure, you can still buy DVDs. But do you?

There are good reasons for DVDs to go out of fashion though. But why don't we have the online equivalent? It would be great if you could buy the license for a movie, and that license stayed with you forever. In that world, when you want to watch a movie you can choose your favorite streaming service (who competes on UX, not catalog) and pay them according to your consumption. That's it, no subscriptions.

Most subscriptions should be pay-per-use services instead. I don't want to stop paying for a service when I realize I haven't used it in the last 3 months.

Ultimately, I believe the way a business makes money should be aligned with their value proposition. If it isn't, customer interests will eventually clash against financial incentives. And you know who will lose in that situation.

Ads or "free products" are completely misaligned, that's why they are the ones I like the least.

Subscriptions can be aligned, but they are often used to milk customers. That incentivizes making a product that people use on a regular basis, even if the problem at hand could be solved in one instance. Or locking away customer data, even if the product itself does not add any value.

Buying can have the best alignment, but it can also be abused because increasing lifetime value is often disincentivized.

In this post I am arguing from the point of view of building technology with the end goal of being useful to people. But the reason why this is idealistic is that it's often used as a vehicle for personal gain. This is especially obvious with some companies' relentless pursuit of growth.

So, there is no silver bullet. But there is definitely room for improvement, and hopefully we can learn from the current situation and make things better.

What can you do about this? Vote with your dollars, and put your money where your mouth is. Nothing will make a greater impact on the ecosystem than customers rejecting business models that are against their interests.

On Open Source

Now that we've got that out of the way, let's go back to talk about technology.

Why isn't all software Open Source? Or even better, free (as in freedom)? You may think it's because of security, but it isn't.

In my rant against subscriptions I mentioned that customers end up funding the development of new features. HEY is an example of that.

I am a big fan of Basecamp, but they pride themselves on going against the grain. Most of the time that's good, because that's how innovation happens. And if they were to implement every feature requested, things would get ugly fast. But an unfortunate consequence is that they'll often focus their efforts in features I don't want, instead of making the ones I yearn for (converting "The Feed" to a real RSS feed, better classification rules, etc.).

There is a solution to this conundrum: Open Source. If HEY were Open Source, I could implement these features myself. Or somebody else would have done it already.

But of course, there is a caveat to this solution. If HEY were Open Source, how would Basecamp keep people from using HEY without paying? They wouldn't be able to do it, not without limiting the technology. And that's the tradeoff we live in today.

I chose this example precisely because I like Basecamp, as you can tell if you've been clicking through the links in this post. They are awesome, and I'm happy to be a paying customer because I love their work beyond HEY (and HEY is nice, even if overpriced for my use-case). But this shows how endemic the problem is, if we are in an ecosystem where the best of the companies is limiting their technology.

The Bright Side of Technology

So far I've focused on the negative, or rather limiting, uses of technology. But there are also great examples of technology empowering people. So I'll end the post by focusing on the positive.

There is one technology I love above all others, and that is The Web. The Web is free (as in freedom), The Web is open, and The Web is here to stay.

There are also other technologies that are great, for example Email and RSS. And there are some up and comers that I'm cheering for, like Solid and Activity Pub.

Can you notice anything in common? These are all protocols, not implementations. And those often thrive on interoperability. If a technology is interoperable, it means that anyone can adapt it to their own needs.

If you are a solo developer and want to focus on your own projects, you can.

If you want to build a community that contributes to humanity as a whole, you can.

Unfortunately, if you want to build a multi billion dollar empire that is a closed silo, you also can.

But those aren't technology's fault, so it's on us to make it better.

Afterword

Hey, you're still here? Consider the post finished, but here's some things I wanted to mention before you take off.

I am aware that the title of this post is the same as Kevin Kelly's book. However, it has nothing to do with it and I haven't read the book. But I like the way it sounds :).

I am also aware that money is a story, and most companies would not agree with the way I characterized subscriptions. But I don't like this story, and I can't help but feel that subscription models are hurting more than they are helping.

Finally, you may see this post as a modest critique of Capitalism, not very well articulated. If you're interested in that, you should read DHH's take on the topic: The enclosure of internet commons.

If you enjoyed this, I wrote a spiritual follow-up: Skeuomorphic Software

Working in the Open When No One Is Looking

2020-10-23T11:15:00+00:00

It's been more than a year since I started working in the open. Here's an update.

Is no one really looking?

What do I mean when I say "no one is looking"? Isn't working in the open the opposite of that, "everyone is looking"?

Well, the thing is that I have no tracking on the site. I have no idea if there is one person reading this post or a hundred. It feels like nobody is looking. But someone surely must. Right?

There are some metrics I can look at to see how popular my content is. I can look at the server load to have an idea if a lot of people is visiting my site. But I am using the smallest DigitalOcean droplet, and I use it to host multiple sites. I can also look at social media interactions, and I don't usually get any reactions to my publications.

So yeah, it really feels like nobody is looking.

But the truth is that I don't mind. I don't do tracking because it's against my values, but I could use a privacy-respecting analytics provider. I prefer not knowing because I can focus on what I care about the most. With analytics, the numbers game could become a distraction.

What is it for?

So then, what is it that I care about?

I care about writing eloquent code. I care about having clarity of thought in my blog posts. I care about designing elegant software. I care about making usable interfaces. I care about creating enjoyable experiences.

In short, I care about my craft.

When it comes to judging quality, there is always a tension between my opinion and that of others. Quality is subjective. In my craft, my opinion is paramount. Which is not to say that I don't care about external opinions, my palate is certainly influenced by others. But my opinion is the ultimate measure of satisfaction.

In the last couple of years, my side-projects have consisted of scratching my own itch. I used to strive in making products for others, and fail because only crickets showed up. I still strive to make products usable by an audience broader than myself, but it is no longer my definition of success.

This change in strategy started when I realized that being successful at making products for others takes a lot more than working on the product. I also started thinking about a different way to build applications, using an architecture I called Autonomous Data. Which created a lot of itches to scratch. Shortly afterward, I learned about the Solid protocol and decided to embrace it because it is strongly aligned with my vision. I believe this the best way to build applications, and I want to see more of them. So I embarked on a journey to rebuild my online experience with tools that work in accordance with my values.

Now, what I do is valuable in and of itself.

On building an audience

When I wrote the first post about working in the open I mentioned the importance of building an audience. I still think it's important, but given my recent experience and change of mindset it has become secondary.

Having an audience would give greater meaning and impact to my work. I also think feedback is very important and it helps me improve. However, building an audience doesn't come for free.

One of the significant aspects to build an audience is being constant. And I'm very irregular with the content I put out. The most regular outlet I have is my journal, and sometimes I don't update it for weeks. It's also very unstructured and I don't think anyone but the more hard-core followers would be interested. But that gives me the freedom to work at my own pace, unrushed and undirected. A luxury I don't have in other parts of my life.

Another important aspect is creating value. This is something I've been thinking about for a long time, and I still struggle to define it. I'd say the gist of it is that people are interested in what you do and it's useful to them. In my case, what I do is too niche and I switch topics frequently. Maybe at some point my apps will be good enough for people outside of the Solid community to use, but I don't think that'll happen anytime soon. And it's not like I am 100% focused in Solid either, I dabble in other things.

To build an audience it's also important to make your work visible. Right now, the only way to keep up with my work is to subscribe to one of two RSS feeds: my blog feed or my journal feed. I could create a newsletter or be more active in Social Media, but I'm not willing to dedicate the time to do it right. I'd much rather spend the time practicing my craft.

Is it possible to build an audience without any of this? Could these be a bunch of excuses to avoid realizing that my work sucks? Sure, it could be. Maybe you know someone who built an audience just by virtue of working in the open. But I don't think that is going to happen to me anytime soon. And that's ok.

It's worth mentioning that the work I'm talking about here is my personal projects. At the moment, I am working 4 days a week at Moodle and doing side-projects the rest of the time. My work at Moodle covers a lot of the advantages I mentioned about having an audience. It certainly has greater impact and meaning, and I interact with team mates and members of the community. That allows me to focus in my craft on the side.

The reason to work in the open

If you've read thus far, you may be wondering why do I even bother working in the open. I certainly could do everything I've mentioned in private. I do it for a couple of reasons.

First, openness is one of my core values. I wish there was more open-source software and more people working in the open. So I'm doing my part in making the world I'd like to live in. And that isn't limited to code, documenting the journey and sharing lessons learned is part of that. I want people to benefit from my experience as I have from others.

Documenting the journey forces me to take the time to reflect on what I do. And that is valuable by itself. It's easy to get lost in the trenches, and I still do it often. But it's important to look from above on a regular basis, and working in the open is nudges me into that direction. It also helps me see it from an external point of view.

Another reason is personal branding and building a body of work. I've had this website for 6 years, and I've been writing software for 9 years. However, I didn't have anything to show until I started working openly. For some people, programming is just a job, and that's ok. For me, it is a mix between job, hobby and vocation. I strongly believe in Small Tech and the Indie Web. Individuals should have a place of their own, instead of being just an account on Github, Twitter, or any Big Tech platform. Working in the open is making my corner of the Internet more interesting.

Open Productivity continued

On that note, I think there is something missing from my current set up. As I mentioned before, there isn't many people who react to my content when it's published. However, what I have seen is some people reacting to content I published months ago.

This made me realize there is a use-case I am neglecting: catering for people who don't follow my work but want to know more about it. Currently, the way I am communicating what I do is through updates in my journal, but that isn't useful unless someone is really interested and wants to dig deep. And the only content for first time visitors is the introduction in the home page.

For that reason, I added a new section at noeldemartin.com/projects. In this page, I'll keep a list of the projects I'm working on and their current status. I hope this will be useful to passersby who are visiting my site.

Say hello!

Another reason why I don't use analytics is because I figured a better way to learn about my audience would be to talk with people. But I never asked for feedback... until now!

The best way to contact me is to send an email. You can also reach me in Mastodon and Twitter.

If you've been following my work, I'd really like to hear about you. Maybe I already know you, or maybe I don't. Or maybe no one is really looking!

You Can't Always Get What You Want

2020-08-01T10:22:00+00:00

The Stones knew it.

Maybe you want to get a successful business by making a great product, but you need Marketing.

Maybe you want to get your dream job by honing your skills, but you need Networking.

Maybe you want to get lean and eat cake, but you need a healthy diet.

Sometimes, what you want is not what you get.

Pick your battles

We are wired to believe that life is fair. In our minds, we know it isn't. But in our hearts, we feel it must be. And so, we get surprised and outraged when we meet unfairness. Specially when we are the ones getting the short end of the stick.

This is not a good strategy.

A better approach is to decide what you care about and ignore the rest. It comes down to efficiency. You can improve anything, but you can't improve everything. You may as well focus on the things you care about the most.

Spheres of Control

If you care a lot about something, there isn't much you can do about it if it's outside your sphere of control. If it is only in your sphere of influence, that's all you can do: have influence over it.

Mental bandwidth is one of the most important assets at your disposal, you shouldn't waste it worrying on what you can't control. Actually, you should never worry about anything. If you've got a problem and you can do something about it, do it. If you can't, accept it and move on.

The illusion of control

If you think you know what's in your control, take a look at the tragedy of the commons.

The tragedy of the commons is a situation in a shared-resource system where individual users, acting independently according to their own self-interest, behave contrary to the common good of all users by depleting or spoiling the shared resource through their collective action.

Wikipedia

In these situations, by definition, the actions of a single individual can't decide the outcome. Collective behaviour does. You can only have influence over the results.

The prime examples are environmental issues like global warming. But these principles can be applied to many situations in life. They explain the uneven distribution of wealth, why scientific innovation stagnates, and in general why life is not fair. Once you start thinking about it, you'll see that the tragedy of the commons applies everywhere. It's the essence of human struggle.

Garrett Hardin wrote one of the first pieces on this topic. In that article, he explains why it is up to the system's rules and not individuals to affect the results. He also reveals that individuals acting in good faith can be harmful to the commons without realizing. And that tells us a lot about the nature of the problem, it proves that there isn't always a secret evil plan going on. It's just how things are.

Maybe you are thinking of a person with a lot of control over others. Whoever that is, it isn't real control. It's an illusion of control held by social contracts. Money? It's a social contract. Laws and governments? Social contracts. Love? Yes, a social contract. Society is bent on maintaining the status quo, that's why the illusion of control is so strong.

Ultimately, the only thing you can control is yourself.

Embracing the unexpected

Anything of which you are entitled the owner is in your possession but is not your own; for there is no strength in that which is weak, nor anything lasting.

Seneca, On the Fickleness of Fortune

If there is a philosophy that embraces this idea, that is Stoicism. One of the tenets of Stoicism is to accept things as they come, with no expectations and no lamenting. The Stoics see Ataraxia as the ultimate state of mind, similar to how Buddhists see Nirvana. However, this is not something Stoics aim for, but a consequence of living with equanimity.

In a way, understanding the inherent lack of control in life is the essence of Stoicism. One advice you will find reading Stoic philosophy is to surrender to your fate. This can seem counterproductive, because we often associate the word "surrender" with defeat. But in this context, it's interpreted as an aptitude of acceptance.

Stop struggling.

There are many stoic exercises you can do to practice this. Negative visualization will help you appreciate how privileged you are. And practicing hardships like fasting or retreat will improve your endurance.

My idea of the modern Stoic sage is someone who transforms fear into prudence, pain into information, mistakes into initiation, and desire into undertaking.

Nassim Nicholas Taleb, Antifragile

One step beyond accepting the unexpected is to gain from it. Antifragility, a concept developed by Nassim Nicholas Taleb, describes the property of systems which improve with shock instead of deteriorating.

Since we have asserted that life is full of things we can't control, leading an antifragile life is guaranteed to make you better. You can use obstacles to your advantage.

Imagine that you are suddenly fired because your employer goes out of business. This is usually seen as a bad thing. However, if you have enough savings to avoid depending on your salary in the short term, you can use this opportunity to grow. It can be reframed as a good thing because it kicked you out of your comfort zone. Like the quote attributed to Taleb says, "the three most harmful addictions are heroin, carbohydrates, and a monthly salary".

There are other parts of your life where you can apply the same principles to be antifragile. Rent instead of buying, diversify your skillset, avoid ruin.

Ditch goals and expectations, embrace compasses and maps

Goals are only good insofar as they help you move in the right direction. Expectations only lead to disappointment.

Instead, use heuristics like maps and compasses. But the map is not the territory and there is no perfect compass. Always expect the unexpected, the only constant is change.

And remember. You can't always get what you want. But if you try sometimes, you just might find you get what you need.

Testing Laravel Applications Using Cypress

2019-11-18T10:24:00+00:00

You won't usually see technical posts in this blog, but this time I decided to shake things up. I've been working with Laravel for many years now, and one of the main advantages is its easy of use and eloquence. In those areas, I don't find libraries that rival Laravel often.

But some months ago I found Cypress and it does. These two technologies don't seem like a good fit out of the box, but in this post I'll tell you what I've done to mix their magic.

What we are going to achieve

Before getting down to the nitty-gritty, let me show you what we're going to achieve:

describe('Welcome', () => {
    it('Shows "Laravel"', () => {
        cy.visit('/');

        cy.contains('Laravel');
    });
});

describe('Authentication', () => {
    it('Logs in users', () => {
        cy.create('User').then((user) => {
            cy.visit('/login');

            cy.get('input[name="email"]').type(user.email);
            cy.get('input[name="password"]').type('password');
            cy.get('button[type="submit"]').click();

            cy.contains(user.name);
            cy.contains('You are logged in!');
        });
    });

    it('Maintains sessions for logged in users', () => {
        cy.login();

        cy.visit('/');

        cy.contains('You are logged in!');
    });
});

Does that look simple and easy to understand? I'm happy it does, that's the point.

If you're familiar with Cypress, there are a couple of things that may have jumped at you. Cypress knows how to interact with the browser, but what's going on with cy.create('User') and cy.login()?

Those are actually calling Laravel's factories and authentication services under the hood. That's the magic we're going to build now.

For the remainder of this post, I will assume you are familiar with Laravel and Cypress. If you aren't, I encourage you to check out this introduction to Laravel and this introduction to Cypress.

Preparing Cypress tests, no magic yet

Cypress is often associated with Javascript applications because it's a frontend testing tool. But it's just interacting with a browser to test your application. So any application that is running in a browser is testable with Cypress. That includes Ruby on Rails, Django and of course Laravel.

That's why in order to write our first test, we don't need to do anything special. If you launch your Laravel application and prepare your Cypress configuration with the baseUrl pointing to your Laravel app, you're ready to go.

Your first test can be something like this:

it('Shows "Laravel"', () => {
    cy.visit('/');

    cy.contains('Laravel');
});

Unfortunately, that's as far as we can go without making some customizations. Laravel tests will typically populate the database and interact with other services. Let's do it.

Adding backend communication

If you look around the Cypress documentation, you will find that they mention test environment specific routes. This is a good approach to establish communication between our tests and our backend.

You can add this to your Laravel routes file:

if (App::environment('testing')) {
    Route::get('/_testing/login', function () {
        Auth::login(factory(\App\User::class)->create());
    });
}

This will allow us to write a test like this:

it('Maintains sessions for logged in users', () => {
    cy.request('/_testing/login');

    cy.visit('/');

    cy.contains('You are logged in!');
});

Remember to be running your app in testing environment.

That gets the job done, but let's not stop here. In a way this kills the readability we love so much. It's still "readable", but if we continue down this path you'll notice how it becomes more and more cumbersome.

Making it readable

One way to encapsulate this behaviour is by defining a custom Cypress command.

All we need to do is adding the following to the cypress/support/commands.js file:

Cypress.Commands.add('login', () => cy.request('/_testing/login'));

And now our test will be that much readable:

it('Maintains sessions for logged in users', () => {
    cy.login();

    cy.visit('/');

    cy.contains('You are logged in!');
});

You may be surprised if I tell you that this is actually all you need to know in order to test your Laravel applications with Cypress!

Anything else you need can be added following the same pattern. Define a Laravel route, and then define a custom Cypress command that encapsulates the request.

For the sake of clarity, let's do another example.

Hooking up model factories

As I mentioned earlier, another common operation in Laravel tests is populating the database. This is normally done using factories, so let's create a new command for that.

Add the following to your routes file:

if (App::environment('testing')) {
    Route::get('/_testing/create', function () {
        $modelClass = 'App\\' . request('model');

        return factory($modelClass)->create();
    });
}

And then define the following command:

Cypress.Commands.add('create', (model) => {
    return cy.request('/_testing/create?model=' + model).its('body');
});

Now we can write this test:

it('Logs in users', () => {
    cy.create('User').then((user) => {
        cy.visit('/login');

        cy.get('input[name="email"]').type(user.email);
        cy.get('input[name="password"]').type('password');
        cy.get('button[type="submit"]').click();

        cy.contains(user.name);
        cy.contains('You are logged in!');
    });
});

Going further

This is as far as we'll go in this post, but you'll find a couple of things that can be improved if you want to use this approach. Things such as moving the testing routes to controllers, implementing tests setup and teardown, adding other arguments to the create command, etc.

In order to get you started, I've released a Cypress plugin and a Laravel package that add this functionality. Check out cypress-laravel and laravel-cypress.

Another meaningful aspect of testing applications is running them automatically with every code change. It's also important to run tests in an environment that is not dependant on your local machine. For this purpose, I've also created a sandbox repository configured with Github Actions for CI. Use it to get started with your own projects, or just to tinker around. Check it out at laravel-cypress-sandbox.

I hope this was useful, let me know what you think and don't hesitate in asking anything!

Real-time vs Asynchronous Communication

2019-05-27T16:10:18+00:00

Communication is an essential part of our lives. And there are two ways of communicating: in real-time and asynchronously.

Are you using both effectively?

How do you communicate?

Most people are not aware of how they are communicating.

If you are having an in-person conversation, you expect to get a reply as soon as you finish your sentence. If you send an email, you are aware that it may take hours or even days to get a response. Those are clear examples of real-time and asynchronous communication.

But what about everything else? If you are having an online conversation, do you expect the other person to reply instantly? If you call someone with your phone, do you expect them to drop whatever they are doing and attend to your request?

I'm sure everyone has experienced at some point being fully immersed in an online conversation just to have the other person take minutes to reply.

Conversely, everyone has also experienced being immersed in any activity just to be interrupted by a phone call.

We've come to accept these situations as the way things are, but there is a better way.

In this post I will introduce many ideas that are applicable both to professional and personal contexts. But this piece will be focused on how to improve communication at work.

Real-time communication

In the workplace, real-time is the defacto standard of communicating. The only thing that is not expected to be real-time are emails, but even those are expected to be attended ASAP sometimes.

I get why people think this always-on aptitude is good for collaboration. But, like the guys at Basecamp say, interruption is not collaboration.

It's true that the fastest way to solve a question is to ask someone who already knows the answer. But maybe it's not the best way. Sometimes, the question shouldn't have been asked in the first place.

Whenever we encounter a problem, our tendency is to ask for help right away. There are two reasons why this isn't optimal.

First, we don't work through the problem ourselves, and just getting the answer doesn't teach us as much as digging into it.

And second, we're probably interrupting someone else's work. Barring the fact that interrupting a co-worker is rude and annoying, context switching is expensive. What I prefer to do instead is send an asynchronous message they'll be able to answer at their discretion. Many times they'll reply instantly anyway, but at least it's them who manage their focus and I am not imposing my urgency upon them.

Doing this will also give our more knowledgeable co-workers an opportunity to share their experience with us. Instead of giving a quick answer and get back to work, they can elaborate on how they see the problem and teach us a thing or two. Which brings me to my next point.

Asynchronous communication

One of the most important things that asynchronous communication allows is the ability to think things through. Most of the time, saying the first thing that comes to mind is not a great idea. I love this piece from Derek Sivers where he talks about this: I'm a very slow thinker.

Another often overlooked aspect of asynchronous communication is that most of the time it leaves a record. Meaning that it's easy for anyone to re-read in order to better understand it. And that person can be your future self. A lot of information is lost over verbal communication, which makes for redundant conversations and wasted time.

And finally, the key factor that asynchronous communication enables is focus. It will depend on your type of work, but you most likely benefit from entering a flow state (most commonly called being in the zone).

One common excuse to resort to real-time communication and interrupting others is being blocked. I like a term I learned from the guys at X-Team called being unblockable. If you really need someone else's involvement to keep working, there are probably worse organizational problems to be worried about.

Balancing both

It may seem like I'm bashing real-time communication a lot. But that's because it's usually what comes out naturally, and we need to make an effort to compensate for that tendency. Of course, there are also benefits to real-time communication; emotions and human connection are best created with real-time conversation. So the art is in using both.

Real-time communication is great when it's necessary to exchange information with a rapid feedback loop. Asynchronous communication is better for deep work and to transmit information clearly.

In order to get more specific, here's some things I've found that can be used to improve your communication:

Implement office hours

Instead of being always on, you can achieve the same results by having office hours. These are hours when you're available to have real-time conversations. Outside of these hours, your peers should expect asynchronous communication unless there's some urgency (which rarely happens, if ever).

This doesn't mean in those hours you're just waiting for someone to talk with; you're working all the same. But you're open to interruptions and that's why you'll schedule your tasks around that. For most people, these "office hours" are actually all working hours, and that's a mistake.

These hours are also ideal to schedule real-time communication, for example meetings.

Write down decisions and rationale

I already hinted at this before, but many times we fall into the habit of communicating decisions verbally and without any rationale. Which is prone to generate doubts, questions and more communication overhead.

I'd argue for the opposite instead, make an effort every time you communicate a decision to explain how you got to that conclusion. You'll save repeating the same thing 10 times and having it lost over verbal communication.

It doesn't mean the decision has to be final, but at least everyone's got all the background and will be on the same page.

Ping

I was hesitant on adding this one because of how much I dread the term, but the core idea is good. A ping is a message that lets you know when someone needs your help ASAP.

Doing this, interruptions are not really interruptions, as they allow the other person to finish whatever they are doing. If we combine this idea with office hours, it's a great way to start a real-time conversation.

Still, be careful not to abuse this because it can easily become obnoxious and counterproductive.

Wrapping Up

In the end, everyone is different and each person will have a different tendency on what they're more comfortable with.

I prefer a combination in a forum-like platform mixed with real-time conversations from time to time, preferably in person or video-call. Emails are cool, but they can become messy over time and not everyone can refer back to them (only the recipients). And chats are ok, but they can often get out of hand without proper organization and discipline.

I hope this served you to think more about the way we communicate. And I'd suggest that you continue by reading this other piece by Derek Sivers: Considerate communication.

Lessons Learned: Musashi by Eiji Yoshikawa

2018-12-13T22:53:31+00:00

Musashi is an outstanding novel that I'd recommend to anyone. I recently finished reading it, and after reviewing the notes I took and mulling over them, I've decided to publish them here.

This isn't a book summary, it's a Lessons Learned summary. Don't be afraid to keep reading if you plan to read the book, this will be spoiler-free. I will include quotes from the book, and I hope they serve as motivation for you to actually read it. If you already have, I invite you to let me know what you learned and how that compares with my takeaways.

About The Book

*Depiction of [Miyamoto Musashi](https://en.wikipedia.org/wiki/Miyamoto_Musashi)*

Musashi is a japanese novel written in 1953 by Eiji Yoshikawa. It relates the journey of Miyamoto Musashi, a real-life samurai from the 1600s who decided to follow the Way of the Sword. It's an interesting novel because some of the events related in the book are documented to have happened in real life. I'm not sure how much of the book is real or fiction, but I don't think it matters. Some works remain written by the real Miyamoto Musashi, the most famous of which is The Book of Five Rings.

In essence, this book relates the journey of a man who dedicates his life to self-improvement and self-discipline, and how he reaches enlightenment.

I know, "enlightenment", that's one of those words that can have thousands of connotations. What it means to me is reaching a state of mental clarity and calmness. Nothing less, nothing more. I think of this as an ideal to strive for, and not as something that can be grasped.

Without further ado, let's get into what I learned reading Musashi.

The Path and The Way

One of the most prominent ideas mentioned throughout the book is the Path and the Way. We are all walking our own path, and it is our actions that lead us to the place we want to reach. Continuous learning and self-discipline will get us where we want, only if we follow the Path.

This can feel like an abstract concept to understand, but after reading the book I get what it means. It makes a lot of sense for how I see the world and my life. This quote from the book encompasses its meaning:

He well knew that to live was more than merely to survive. The problem was how to imbue his life with meaning.

For Musashi, meaning comes from being a samurai. Early in the book he decides to follow the Way of the Sword:

To Musashi's way of thinking, there was one way of life for ordinary people, another for the warrior. It was vitally important for him to live like a samurai and to die like one.

Don't be discouraged if you don't know what's your path. I'm not sure I'd be able to put mine in words, but I know I'm on it. I know because I make progress every day and I am satisfied with my life. There is always room for improvement, but that's ok. It's part of the Path to never reach its end.

You shouldn't evaluate whether you're on the Path or not by looking at your current situation. And your circumstances don't matter either. Being on the Path means walking on the right direction, doing what you know you need to do. And it's a long journey. Temporal digressions don't make a difference as long as the overall direction is correct.

This passage comes from another important character in the book, Takuan. He explains how different paths are in reality the same:

People talk about combining the Way of Learning with the Way of the Samurai, but when properly combined, they aren't two—they're one. Only one Way.

You should be looking for your own path and what brings meaning to your life.

And it doesn't have to stay the same. Musashi's opinion of his path evolves throughout his journey:

He had come to see the Way of the Sword in a new light. [...] To cut people down, to triumph over them, to display the limits of one's strength, seemed increasingly vain. He wanted to conquer himself, to make life itself submit to him, to cause people to live rather than die.

The Limits We Set for Ourselves

In Musashi's time, status and position were very important. Part of which came from family bloodline. That's why it's surprising that him, who's got no prominent relatives, becomes increasingly uninterested with the idea of obtaining status.

Here's a description of what a rōnin (a samurai without a master) should be:

A true rōnin did not seek fame or profit, did not curry favor with the powerful, did not attempt to use political power for his own ends, did not exempt himself from moral judgments. Rather he was as broad-minded as floating clouds, as quick to act as the rain and quite content in the midst of poverty. He never set himself any targets and never harbored any grudges.

Society imposes judgement and limitations upon us. Some are unintended, and some are self-imposed. It's important to understand those and define our own standards.

We must reassess our perspective frequently and not make any assumptions. Musashi is well aware of his shortcomings, and he's constantly evaluating his knowledge and how far he's from reaching his goals:

I'm afraid I'm still immature, imprudent—far from being truly enlightened. The more I travel, the longer the road becomes. I have the feeling I'm climbing an endless mountain path.

And this also needs to be applied when things are going our way. Don't sit complacent when you get someone else's seal of approval. One of the things I admire the most about Musashi is his humbleness and how he responds to undeserved praise:

Don't embarrass me. I'm still an amateur. But the world's full of people who don't seem to be as good as I am.

That's why the Path is a journey of constant learning. To me, learning is one of the fundamentals of life.

Another fundamental is the Self.

The Self and Looking Within

We get wrapped up in external stimuli, and we end up with a skewed view of reality.

We mustn't forget that we are the center of our life, and I don't mean it in a selfish way. Helping others is one of the best things you can do for yourself.

Here's another gem uttered by Takuan:

One's self is the basis of everything. Every action is a manifestation of the self. A person who doesn't know himself can do nothing for others.

Something that can lead us astray from looking within is envy or aspiring to be like someone else. It's always good to have someone to look up to, having goals and ideals is what helps you make progress. But don't lie to yourself thinking that anyone is perfect. At the end, we're all going through the same struggles:

Whether people were great or not, there was not much variety in their inner life experience. Any difference lay merely in how they dealt with common human weaknesses.

Which ties neatly into this other quote:

It is easy to crush an enemy outside oneself but impossible to defeat an enemy within.

What it comes down to is being comfortable in your own skin. Musashi spends a good deal of time alone. And it's in those moments of introspection where he feels the most alive.

Counting his footsteps, listening to the silent voice of the heavens above, he could forget everything and rejoice in his own being. When he was surrounded by crowds of busy people, his spirit often seemed sad and isolated, but now he felt alive and buoyant.

The Value of Experience

This has been introspective and abstract so far. But this book relates a samurai's journey, so there is a good deal of action.

It's good to reflect and ponder, but it's also necessary to put thoughts into practice.

The truth of the scholar, alone in his study, does not always accord with what the world at large considers to be true.

Growing consists of a cycle of thinking and doing. And none can be fully effective without the other.

The knowledge that comes from books is of no use to the warrior, if a man worries too much about what others think or do, he's apt to be slow to act.

This is not only for the sake of our physical existence. The world of ideas is intangible, and our minds need to be fed with experiences to thrive. A feedback loop between our experiences and our thoughts is necessary for growth.

Only those who had actually grown their own grain and vegetables really understood how sacred and valuable they were. Those who hadn't were like priests who did not practice what they preached or swordsmen who learned combat techniques but knew nothing of the Way.

This leads us to reevaluate our view on obstacles and adversity.

A Different Look on Hardships

This is one prayer that Musashi makes in a temple on his journey:

Please test the lowly Musashi with hardship. Let him become the greatest swordsman in the land, or let him die.

Quite extreme, but gets the point across. The fact is that going through difficult situations is essential to reevaluating our assumptions and getting outside our comfort zone. You should not necessarily see them as bad or something to avert.

If something scares you, analyze objectively if it's worth doing. And most of the times, it will. Fear often comes from inexperience and lack of knowledge. By facing our fears we can expand our self where we need it the most.

The path that Musashi chose tested him constantly on this regard:

Any person who followed the Way of the Sword was constantly in danger of being killed. [...] Danger was the grindstone on which the swordsman whetted his spirit. Enemies were teachers in disguise.

In those situations, it's difficult to remain calm and absorb all the lessons. But we need to take control and get a handle on our emotions. We need to learn how to detach and make objective judgement.

The ability of detaching from a situation doesn't come naturally, specially from high-pressure situations. It may even be contrary to our nature. But it isn't something that cannot be tamed:

While custom was bred by daily experience, being on the boundary between life and death was something that occurred only a few times during a lifetime. Yet the ultimate aim of the Way of the Sword was to be able to stand on the brink of death at any time: facing death squarely, unflinchingly, should be as familiar as all other daily experiences. And the process had to be a conscious one, though movement should be as free as if it were purely reflexive.

Granted, we don't have to be as extreme as him. But that's because we're not on the Way of the Sword. So find the equivalent for your Way, and do it. By exposing yourself to those environments you'll absorb all the stimuli and improve drastically.

But don't limit your experiences only to what you consider your Way.

Fighting isn't all there is to the Art of War. [...] A serious student is much more concerned with training his mind and disciplining his spirit than with developing martial skills. [...] He wants, essentially, to go everywhere he can and learn everything he can.

Go everywhere you can and learn everything you can.

Being One With The Universe

I have talked about the importance of both mind and body. And this is something that's expressed throughout the book as being one with the universe. It encompasses everything: our inner experiences, our outter experiences and everything around us.

I've also spent some time traveling about the country side, learning from the mountains and the rivers. I regard them, too, as teachers.

Be in contact with your environment and become a spectator to your life. Looking at the true essence of the world will allow you to move freely. But don't try to bend it to your will.

Do not attempt to oppose the way of the universe. But first make sure you know the way of the universe.

Things are what they are, there's no point in complaining about things we can't control. The sooner we realize that, the sooner we'll start walking the Path.

I feel like I've only scratched the surface and there are many ideas I didn't get into. If you found this useful, I commend you to read the book for yourself. It'll be a journey you won't regret.

And don't let all of this get to your head. At its core, life is simple:

The Buddha's Law is simple: Eat your rice, drink your tea, wear your clothes.

Open Productivity

2018-11-12T21:54:32+00:00

I've been a proponent of transparency and working openly for a while, but I struggled to translate this into something actionable myself. So I came up with this new methodology: Open Productivity.

The Human Factor

I recently joined Seth Godin's The Bootstrapper's Workshop, and one of the concepts introduced is that of finding the Smallest Viable Audience. This is related to something I learned from Chase Jarvis, he calls it building a community. It's also similar to something Derek Sivers suggests: focus on who you want to help instead of the product you're building.

These concepts are not the same, but they are closely related. And they mean that you need a human factor for success. I used to think that it was possible to focus only on the product, but every day I'm more convinced that's not true for the kind of work that I want to do.

That's why it's necessary to expose your work, create human connections and know your audience. Communicating your work is as important as the quality of your work.

I have been aware of this for some time, but I haven't been great at doing something about it. My initial reaction was "Ok, I'll interact more with others. I'll join communities that resonate with me and I'll start giving more feedback to creators that I follow". And this has been positive so far, but it isn't nearly enough.

Right now I don't really expose my work, so I don't think anyone actually knows what I do other than myself. It's time to change that.

Over the last years, I've actively reduced my exposure to social channels. I don't use Facebook, I'm not subscribed to any news outlets, I try to suppress as many notifications as I can, I turn my phone off every day when I go to sleep and I don't turn it on until I've completed my morning routine the following day.

The only social networks that I use are Twitter and Mastodon, and I don't even check them that often.

I'm all about productivity, and I've written about it multiple times. That's why my time is allocated to planned activities. And I consume content mostly from sources that I trust.

In summary, for me productivity is related to isolation. I reduce the noise around me and work from first principles, studying and learning on my own accord.

But this clashes with the idea of building human connections. And I'm also aware that I have a lot to learn from interacting with others. I tried to allocate some tasks to "interact" but it felt forced and unnatural. What's helped me is changing my mindset about consumption, interacting more with the content that I already consume.

Thinking how to align these two is how I came up with this new approach.

Enter Open Productivity

I thought I was already "working in the open" because I started publishing my code on GitHub, but if no one is watching it's like it isn't there. There is also a lot of context and reasoning that's missing from the code. So I could do a better job at that.

Some months ago I came across Doug Belshaw, and I've been following his work ever since. I think he's a great example of what working in the open means, and he's inspired me to take action.

I've come to the conclusion that a great way to do it for me is merging the productivity system I already have with my communication channels. And that's what I call practicing Open Productivity. Here's a diagram trying to convey what I mean:

With this, I'll begin to document my journey and it'll be easier for anyone who finds me to learn what I do. I also expect to increase my interactions, so ping me when you have anything to say!

Starting today, you'll be able to follow my progress in my "now" page at noeldemartin.com/now.

I plan to mix it up with my communication channels, so you should also see a difference if you're following me on Twitter, Mastodon or my blog.

2020 Update: I've written a follow up to this post after applying these ideas for a while, check it out: Working in the Open When No One Is Looking

Finding Opportunities that Fit Your Values

2018-10-01T02:00:00+00:00

For the better part of this year, I have been looking for a new job and struggling to find a good match.

The problem is not the "skills". My background is on web and mobile development, so I am looking for a fullstack, frontend or backend development position. There are thousand of jobs matching those skills. But how do you optimize to search for a job matching your values?

I have to confess that I didn't even know what I wanted. So I put my head down and tried to define what are the criteria for the job I am seeking. This is what came out.

Vision

I want to work somewhere with a vision that motivates me and shares my values. Putting this in less abstract terms, I want to help solving a problem I care about and I don’t think is already solved or has a market saturated with solutions.

Examples of suitable visions: privacy, education, open source.
Examples of unsuitable visions: yet another task manager, consulting, analytics/marketing, blockchain.

Of course none of those is a deal breaker nor a sure bet, it depends a lot on the specifics. But overall those are good approximations.

Work

I want to surround myself with talented and motivated individuals, because I want to continue learning and share my passion. I also want to nurture and teach others, but “If you’re the best in the room, you’re in the wrong room”.

I am also looking for a place where they share my work philosophy, which is greatly influenced by Basecamp. Quality > quantity. I don’t care that much about growth, I care about serving customers well and creating value. For obvious reasons I do care about profitability, but I don’t think it correlates with growth as most companies seem to be obsessed with.

Company Size

I believe the environment where I can thrive is a small to medium organization. Reasons for this are based more in theory than in practice, but I think I won’t be able to make an impact in a big company if I am only a cog in the wheel.

My experience is also better suited, since my abilities span multiple areas and I enjoy interacting with other departments.

Remote

This is as much a restriction as it is a criterion. I live in Barcelona and I’m not willing to relocate permanently (I would for a training period). Focusing my efforts only in opportunities located in Barcelona would limit my options even more. That’s why I am looking for a remote opportunity.

After reading this, there is a variety of reactions you may have. One I hear often is thinking that my standards are too high. Maybe it's true, but hear me out.

We spend 8+ hours a day working. Considering 8 hours of sleep and other activities necessary for survival, working is the biggest chunk of time we spend in life. And time is without a doubt the most important thing you will spend. So I would argue it's one of the most important things to get right.

The plan

I am a big proponent of Stoicism, so I am not restless about my situation. I'll just continue striving to be the best I can be while enjoying what life's given me.

However, there is one thing I need to improve and that is networking. That sounds like a catch-all concept, but what I mean in particular is how I communicate my work and where I choose to spend my efforts. I have been contributing to Open Source for a while, but it's been mostly on my own projects. I will be more intentional with my work, and I'll expose myself to other communities and get outside of my bubble.

I hope my views on job seeking can inspire others. And of course, if you know of a company or an opportunity that can fit my values, let me know!

Blockchains: Innovation or Sham?

2018-08-20T02:00:00+00:00

With so much happening with blockchains, there is an ongoing discussion on the impact they have. In order to form my own opinion, I have studied three and I will give my take of them and the ecosystem. If you are not familiar with blockchain technology, make sure to read my previous article where I introduce the foundations and explain what makes it different from other technologies.

Bitcoin

This is probably the most famous blockchain, and it is sometimes confused with blockchain technology overall.

Its main purpose is to process payments, and that's why it's called a cryptocurrency. The original intention was to provide secure and cheap online transactions, without the hurdles of trusting third parties to mediate. However, it has since evolved in different directions. Although the technology is the same, people have been using it for other purposes. Some of them are:

Replacing physical currencies: Most ambitious proponents of Bitcoin argue that it's the future and it will eventually replace physical currencies.
Speculation: One of the main trends is to buy Bitcoin with the expectation of making a profit. Or manipulating public opinion in order to benefit from price fluctuations.
Anonymous transactions: Since there is no real ownership in Bitcoin other than holding a private key, transactions can be anonymous. And this makes it a real benefit for some.
Smart contracts: The fact that the system is secure and immutable has prompted some actors to use it as witness that an agreement was made.
Others: Using transaction metadata, other applications have been built on top of the Bitcoin network for multiple purposes.

Most of those are not unique to Bitcoin and can be seen in other cryptocurrencies as well.

My opinion of the current state of Bitcoin is not great. The key problem I see is precisely what makes it special: it has no regulations. Some people are of the opinion that that's good. But I believe having bad regulations is generally better than no regulations. I'm not saying that today's laws are perfect, but hundreds of years ago things like slavery were common-place. And I'm sure that having no regulations brings the worst in humanity. I don't think that people is inherently bad, on the contrary, I believe most people wants to do good. But without rules, a few bad actors can have a huge impact and influence the entire ecosystem.

The reality is that today most successful use cases for Bitcoin are speculation and illegal activity. Unfortunately, the use cases that I find more beneficial are less viable every day or don't compensate for all the problems that are created in exchange (volatility, scalability, environmental impact, etc.). And without regulations, I don't see how this will ever change.

An alternative blockchain called Bitcoin Cash was created to fix some of those issues, but I am sceptic for what I just mentioned. In any case, I haven't looked much into it, so I cannot have a definite opinion.

Ethereum

I mentioned that Bitcoin has been used to develop other applications on top of the network. But it has some limitations because it wasn't designed with that purpose in mind. That's where Ethereum comes in. It supports a programming language that is run using their built-in cryptocurrency.

Since it has been built with a broader scope, it covers more use cases than Bitcoin, and multiple blockchains have been built entirely on top of the Ethereum blockchain. However, since I don't know much about its use in the wild I will refrain from talking about this. What I do know is how it works after reading the white paper and digging a couple of concepts. And my initial opinion is not great.

Applications built with Ethereum are executed in every node of the network, which results in a lot of wasted computation. I can understand how this is necessary for security reasons, but I'm not sure that many applications justify this trade-off.

In order to run code on the blockchain it's necessary to spend Ether, their built-in cryptocurrency. The problem is that the price of Ether is not stable. For someone who is not part of the network, operations may be too expensive and unreliable.

All in all, I think the approach is better than Bitcoin, but in the end it suffers from the same core problems. And I struggle to find a use case that could not be solved with other technologies.

Steem

The last blockchain I want to talk about is Steem. This one does a couple of things differently and its main purpose is to provide a distributed content and blogging platform.

Everything works around a cryptocurrency called Steem. This currency can be earned by using the platform, for example writing posts, comments or upvoting. And it has two derivations: Steem Power (SP) and Steem Dollars (SBD). Steem Power is used to potentiate your activity. The more SP you have, the more impact your activity will have and more Steem you'll get. Steem Dollars, on the other hand, are used as a way to have stability within the system. One SBD can be exchanged for the equivalent of one USD in Steem at the current evaluation.

The founders of this blockchain also created a platform called Steemit, where it's easy for anyone to create an account and start interacting with the blockchain in a seamless way. In fact, you won't notice that you're using blockchain technology, since it behaves like any other media platform. The one thing that will stand out is that posts and comments have an amount of dollars next to them. This amount is how much Steem has been generated for the author of the content, represented in Steem Dollars.

I have to say that Steem is the first blockchain I like. The main thing that got me interested is providing a viable alternative to fund content creators. In contrast with the advertisement model, which I am heavily against. If you want to learn more about this from a content creator's point of view, read this post by David Kadavy which covers the basics: A writer’s guide to making money on the STEEM blockchain – for beginners.

Having used the platform for a while has been a good experience so far. I am worried about a couple of things like bot activity, but nothing dramatic yet. The fact that Steemit is a layer on top of the blockchain can help fixing some of these issues. It may seem counter intuitive to say that, given the main point of blockchains to be distributed. But if Steemit goes sideways, the underlying blockchain with all the information is still open. And it's possible for anyone to create alternative platforms.

Some alternatives to Steemit already exist, like Busy.org. And a decentralized alternative to YouTube called D.tube has been built on top of the Steem blockchain. But keep in mind that videos are stored on IPFS, not the blockchain, so the same rules won't apply.

Final veredict: awesome or awful?

With all this said, what is my final opinion on blockchains?

First let me point out that technology is a multiplier. If you want to do good, technology will help you. But it will also potentiate bad intentions. That's why I believe the real question here is how are blockchains being used today.

Unfortunately, I don't like the current state they are at. I've found a lot of arguments for and against, and the ones with more impact are the ones against. Seems like most prominent scenarios are speculating and introducing ill-informed hype. And the solutions to existing problems are mostly based on hope and hypothesis, but the current situation does not seem to be changing.

It is also possible that Bitcoin and sketchy blockchains take much of the spotlight, and smaller blockchains are not taken into account. But as I said, the important part about technology is how it's being used, so it isn't inherently wrong to judge based on that.

I agree with most of the principles, but not the execution. I believe it's possible to fix the problems. In particular I think the keys are improving efficiency and introducing self-regulation mechanisms. This is already happening with some blockchains, but it will not happen for the entire ecosystem in the short term.

That's why I think it is important for us to be aware of what kind of blockchain we are supporting. Next time you see a new fancy blockchain being announced, make an effort to learn what's actually going on under the hood.

Blockchains: How do they work?

2018-08-13T02:00:00+00:00

The word is out about blockchains and how awesome they are. Or how awful, depending who you ask. I have been spectating the discussion for years, but I recently decided to give it a real look.

In this article I will introduce the foundations on how does blockchain technology work.

Sources

In order to cover a good amount of diversity, I chose three blockchains to look into: Bitcoin, Ethereum and Steem. I think those are representative enough to get started, but if you think I missed any game changer, let me know!

With so much controversy it is difficult to find impartial learning sources. I decided to start by reading the original whitepapers and search specific information based on that. They can be found on the following links:

The key concept to understand is that blockchains are made to store information, that’s why sometimes you see them described as some kind of database. A blockchain is nothing more than a collection of records storing data. These records are called “blocks”. They have an intrinsic chronological order, because they store information about previous blocks. Together they are called "the blockchain".

The easiest way to understand the underlying nature of blockchains is to think of them as Linked Lists.

Other than the basic architecture, there are some key properties which make blockchain technology unique: distribution, encryption and immutability.

Distribution

This is probably the most important property of blockchains and what makes them extremely resilient.

It is possible to clone a blockchain, and such clone will be the same as the original. Computers running those clones are called “nodes”. And it doesn’t matter if the original blockchain is lost, as long as there is at least one active node, the system won’t be disrupted. All nodes together make the “blockchain network”.

Given that there isn't one true blockchain, you may be wondering how is the system protected from malicious nodes. This is solved using a consensus algorithm, where a malicious node would need to control more than 50% of the network to manipulate records. It makes a blockchain more secure the bigger it grows.

Encryption

Since anyone can join the network, it is necessary to validate information without trusting other nodes. And that is achieved with encryption. All the information in the blockchain is cryptographically tied together. In order to modify even one byte in a block, all subsequent blocks would need to be modified as well.

One interesting side-effect of this is how ownership works. In blockchain there aren’t any owners or “users”. Think about a traditional application, where a user is authenticated with a password. Because those applications are controlled by one entity, if the password is lost they can perform recovery operations and create a new password. But in blockchain the only thing that represents a “user” is the possession of the password, in this case a private key. If the password is lost or stolen, it cannot be recovered.

That's why it isn't so much who owns anything, but what you can or cannot decrypt the data.

Immutablity

As a consequence of distribution and encryption, blockchains are immutable. This doesn’t mean that the final application using the blockchain is immutable. Applications built on top of blockchains have a derived state, which can be inferred from traversing the entire chain. What this means is that anything from the derived state can be changed, but the history of modifications will always be recorded.

Having all this into account, it’s important to keep in mind something that isn’t immediately obvious. Operations performed on a blockchain can be really slow and resource-consuming.

The problem is not the operation itself. In order to trust an operation as valid, it should be spread through the network until it is considered secure. For example, in the Bitcoin blockchain it can take as long as one hour to have a confirmed transaction. And Ethereum nodes have to do a lot of extra work just to maintain security. Other blockchains have different timeframes and limitations, but this goes to show how unexpected consequences can arise from not knowing the specifics of a technology.

Blockchain is becoming a buzz word these days, and a lot of scams are disguising themselves with the cloak of this technology. Not to mention the amount of people who have no idea about what they are doing. So be careful and get informed before getting involved in any blockchain endeavor.

Part II: Blockchains: Innovation or Sham?

Order vs Chaos

2018-06-26T02:00:00+00:00

Conventional wisdom says order and planning are the key to achieve great productivity. But I've found the importance of chaos as well. In this post, I will tell you how to embrace both to get better results.

Order

I'm always improving my workflow, and productivity is one of my favorite reading subjects. I also wrote how I approach planning before.

Over the years many techniques have proven to be effective: Timeboxing, Getting Things Done, Flow, etc. I actually enjoy them, so it isn't a drag accommodating my workflow to some rules. I also think work/life balance is tremendously important and has a positive impact on the quality of your results. That's why it's important to follow a schedule.

Jocko Willink emphasizes the importance of order comparing discipline vs motivation: "Motivation is fickle. Motivation comes and goes. Motivation is unreliable and when you’re counting on motivation to get your goals accomplished, you’re likely gonna fall short. So don’t count on motivation, count on discipline. You know what you have to do. Go make yourself do it."

It makes perfect sense, but it isn't until I embraced it that I really understood it. Productivity is a matter of action. It isn't enough just to learn about it, you need to apply it and create your own workflow.

Chaos

Interestingly enough, my most effective approach is the most recent. I am constantly changing tools, and they are always more effective at their earliest stages. They may accomplish the same end goal, but I'll switch on and off techniques such as Pomodoro Timer and I change my task management app frequently.

An important aspect of setting your own workflow is to know that you can change it. It should empower you, not become your shackles. This is dangerous though, because part of having an effective workflow is force of habit and being able to stick with it.

The way I approach this conundrum is by allowing chaos to live within the order. I allow myself to do experimental work and break my routine because I know it will pay off. But I'm always aware of my goals and deadlines, so I know when it's more appropriate to do it at the risk of wasting time.

It's not the same as scheduling chaos, and l get better results like this. After all what is more effective: 10 hours of disciplined work you don't feel like doing or 5 hours when you are in the zone?

The equilibrium of both

There is value in both sides of the coin. The challenge is how to balance them, and the answer depends on your work and your personality.

Order and discipline are more appropriate to get things done. Chaos and motivation are more appropriate for creative work. And both are necessary to achieve great results.

A sustainable workflow is benefited from having a routine and planning. In order to get work done, you need to focus your efforts in solving the task at hand. So reducing decision fatigue is very important to perform better. David Allen says to keep anything potentially meaningful out of your head and parked in some trusted place. This will free up your mental bandwidth and make you better.

On the flip side, it's important to use moments of inspiration. It's true that creativity can be manufactured. The blank canvas syndrome can be mitigated, and creativity is infinite. But using motivation and creativity when they are stronger works better than scheduling.

If we're 100% disciplined, and our working schedule is 9 to 5, we should stop working at 5 sharp. If we're in the zone at that time, we are cutting it short. Breaking the rules and pushing through the schedule can be beneficial at times. Gut feeling is not a reliable tool for sustainable work, but it shouldn't be omitted either.

Programming and Human Languages

2018-04-11T02:00:00+00:00

Have you ever thought how programming languages relate to one another? I recently did, and to my surprise there is a lot of similarities with human languages.

I’m sure you will see programming languages in a different way after reading this. If you don’t know much about programming, this will help you understand them a bit more.

First things first, what is a programming language?

I won’t go into defining what a human language is, because I assume we already have a common understanding. But what is a programming language?

According to wikipedia: “a programming language is a formal language that specifies a set of instructions that can be used to produce various kinds of output.” This is a good formal definition, but there are other aspects I want to consider. The main purpose of a programming language is to “transfer information into a computer”, with the goal of the computer producing a result. And here is where I find the first analogy. What is the main purpose of a human language? Well, I would say it is to “transfer information into a human”. In the same way that the receiving human needs to understand the human language, a computer running code needs to interpret the programming language. Luckily for them, it's easy for them to understand new languages by installing software.

Other than the core purpose of transferring information, there is a clear difference on how they operate. Programming languages are 100% logical (ok, 99% if we consider Heisenbugs). It may seem irrational when bugs appear, but there is always an underlying logical explanation. Everything a program does can be boiled down to 3 concepts: Inputs, State and Outputs. Inputs are the information given to run the program. State is the information existing within the system. And outputs are the information generated from the computation. All programs are structured like this, formed by submodules that interact with each other to create complex systems.

Humans arguably do this as well, if we consider senses inputs, memory state and actions outputs. But it’s not yet clear if we work like this at a fundamental level. I have talked about it before, and it’s an ongoing debate in fields such as philosophy and physics. This is also why I won’t be considering quantum computing in this article (that, and the fact that I don’t have experience with it).

Languages birth

The first thing I want to talk about is how programming languages come into existence. Contrary to human languages that are created naturally, programming languages are created artificially, and there is a design process involving conscious decisions behind their creation. However, there is no programming language that comes out of nowhere. Similar to human languages, programming languages have a genealogy (family tree). Creating a new programming language always involves using existing concepts and ideas. One particularity is that their family tree is actually messier than the human languages’. Because they are often influenced by many others, they have multiple ancestors.

Here you can see an example to compare both genealogies (click to see more details):

If you are curious, the first programming language was Fortran, and it was born in 1954. So the history of programming languages is only about 64 years old.

Languages structure

When looking at programming languages, there is always an underlying structure that is common to all of them. All have variables, methods, loops, conditionals, etc. And the same can be said for human languages; all of them have verbs, adjectives, conjunctions, etc. It also goes beyond simple structural components; in programming we can find design patterns that can be used in any language, and with humans we find concepts like eating or feeling emotions common to everyone.

This bears to conclude that all languages stem from one abstract mother language. For humans, this is the mental model we all share regardless of culture and race. There is an hypothesis considering this which calls it language of thought. For programming it is called pseudocode, which is used to define code regardless of implementation and platform. This idea of having a mother language is further supported by the fact that they can be translated into one another. Human languages are constantly being translated, but programming languages are also translated with a process called compilation. At the end, anything can be implemented or said in any language, but each one is more suitable for a specific context. This explains why Eskimos have so many different words to say “snow”, or why Perl has so much string manipulation functionality.

Sounding native

Thinking about this concept of “sounding native” is what got me started thinking on this topic. Languages have syntax rules indicating what is correct and what isn't. And there are tools that can validate those. For humans we call them spell checkers and for programming they are called linters.

But there are also non-written rules that vary from one context to another and aren't standard. And that’s something remarkable, because the same thing happens with human speech. I could speak in Spanish with a Mexican and we’d understand each other perfectly. But we’d both notice many subtle differences that give away that we are not native from the same context. One stark example in programming is tabulations, some languages tend to use 2 spaces instead of 4 (or, god forbid, tabs). If you ever want to become fluent in a language, keep this in mind. Small subtleties make all the difference.

An extension to this can be found in dialects. When a human language changes too much, we call it a dialect. In some occasions, speaking a language is not enough to understand other dialects. For programming we find this behavior with frameworks. Being written with the same language, the differences can still make it hard for a developer to understand the code.

Languages proliferation

Something definitely different is the pace at which they are created. As I commented before, the first programming language appeared 64 years ago. In only those few years, programming languages' count could be about to surpass human languages'. According to this article, it is possible that we already have more programming than human languages. And according to this other article, Python is apparently the most popular language to be taught in primary schools (including human languages). I have to be skeptic about those, but keep in mind that they were published in 2009 and 2015 respectively. Today this may be an exaggeration. But if they keep this pace, in another 64 years programming languages will have surpassed human languages for sure. I wouldn’t be surprised if 50 years from now people who don’t know to code are like people who don't know how to read today. Programming is definitely the new literacy.

One possible explanation for this phenomenon is how easy it is to learn new languages. We already established how computers can learn new programming languages just by installing software, but for humans it isn’t that difficult either. If I count, I would say I know about 8 programming languages, while I only speak 3 human languages. I have been studying a new human language for more than a year, and I’m barely getting started. But I can learn a new programming language quite thoroughly in less than a month. Learning a new programming language is often easier than people think.

Another possible explanation is how easy it is to create a new programming language. There is even a category of programming languages that are literally created without purpose, called esoteric programming languages. One I find particularly amusing is Taxi; a programming language that consists on a virtual taxi moving “data passengers” from one place to another in order to execute operations.

Languages usage

Tying into this we can talk about how they are used. When choosing a programming language, there is a saying of choosing “the right tool for the job”. This tries to convey that programming languages are not better nor worse, but more appropriate depending on the task at hand. But that statement is only true in theory. In practice, there are other reasons why someone would choose one language over another. I would argue the strongest arguments for picking a language to use are the languages you already know and how many people are using it. Again, we find the same pattern for human languages, and it’s more extreme given the complexity to learn a new language. It’s obvious that a person will prefer to work with others speaking the same language, or learn one that many others speak.

This becomes crystal clear when looking at the current trends of programming languages.

Let’s talk about the king: Javascript

Javascript was originally created for the web, and its main purpose was to make websites (the front-end) more dynamic. But fast-forward to today, and people is writing software using Javascript everywhere: Front-end, Backend (Node.js), Mobile (Ionic), Desktop (Electron), etc. And I have something to confess: I used to hate Javascript.

One of the slides in a talk I gave in 2017.

I’m probably not the only one who did. In university, I learned programming using Java and C++; and going to Javascript after that was not a nice experience (specially back in 2011). Fortunately, things are looking much better today.

But the reason for this to happen is not that Javascript was a great language at the beginning. This happened because it is the most accessible language. Everyone has everything they need to learn and run Javascript code: a browser. The popularity of Javascript is tied in no small measure to the growth of the Web. And the open source movement has made it even more accessible, given that it is the most used language in GitHub repositories.

Conclusion

After this, I’m sure you see programming in a different light, regardless of your previous background with it. At first glance it may seem stiff and boring, but it can be one of the most creative activities that you will find. I certainly think that, and it plays a big part on why I love programming so much. The same program can be implemented in a thousand different ways, and choosing one is part of the craft. This is something Linus Torvalds refers to as having good taste. And let me finish with something you may not realize: naming things is the most difficult thing programmers have to do. Let that sink in.

Let's Agree to Disagree

2018-03-22T03:00:00+00:00

I have always seen myself as a very rational and logical person. I have no problems acknowledging my ignorance when due, but if I have an opinion it’s usually a strong one. However, I have lately been looking at opinions and conversations in a different way.

Conversations using logic

First let me start explaining how I used to approach conversations about opposing opinions. Logical thinking fascinates me, and it’s something I try to base all my reasoning upon. That’s why in many of my conversations I end up saying “you’re not being logical”. I don’t mean to dismiss anyone’s arguments or call them stupid. I mean, literally, that they are not being logical. Logic is not something subjective, it has a formal definition and it’s guided by two simple concepts:

Axioms: Statements taken to be true.
Rules of inference: Rules indicating how to correctly combine axioms to create new ones.

Therefore, a conversation using logic can be reduced to contrasting axioms upon where an opinion is formed. When there is a disagreement, it means somewhere along the train of thought there is an axiom both parties don’t agree with. But once that happens, that axiom can be broken down further into more axioms, and this process keeps repeating.

This can be modeled as a statements Tree. Each node represents a statement, and their children are connected by rules of inference. A conversation driven by logic would consist in navigating the tree in a pre-order traversal. When both parties agree on a node, it’s not visited further and taken as valid.

Since this is a bit too abstract, let me illustrate with an example. Here’s a conversation between person A and person B both in text and in tree form:

A: Cats are better than dogs.
B: What? That's not true!
A: Yes, because cats are more self-sufficient and smarter.
B: They are more self-sufficient, but not smarter.
A: They are, because they learn faster and cannot be taught so easily.
B: They may learn faster, but you can definitely train your cat.
...

I’m not saying that I like cats more than dogs, maybe I’ll leave my opinion on that for a different post.

Conversations with human beings

What I just explained is obviously an idyllic approach. In reality, when I had a conversation, one of the following situations would arise:

Situation 1: A point is reached were one party (or both) agree that some axiom is not sound. After that, the breakdown of axioms is backtracked and opinions are readjusted. Both parties now agree 🎉.
Situation 2: The breakdown of axioms goes on and on, and a dead end is reached. The conversation becomes too abstract for the topic that started it. This is similar to how most pages in wikipedia lead to Philosophy. I have often unwillingly moved the conversation into “how do you know I exist and I’m not a product of your imagination?” territory.
Situation 3: One party does not apply rules of inference correctly. And that’s when I say “you’re not being logical” and the conversation starts deteriorating.

After all, how can an opinion be valid if it can’t be argumented properly? Most of the time, what happened is that statements were argumented with fallacies instead of proper rules of inference. And for me that was the end of it: I was right, they were wrong.

But reality is not that simple. One clear example is experience; if a statement is argumented with experience, that’s technically a fallacy, because the fact that something happened in one instance does not justify generalizing. But in human terms, it’s undeniable that experience can be a valuable argument. And it’s not only that, there’s also efficiency. If a conversation is approached like that, it can be dragged for too long. That’s ok if you like to ramble, but in practical scenarios that’s not the most efficient use of your time.

If you read up to this point, you may be thinking that this structured view of conversations cannot be used by humans and it’s worthless. But there is a middle ground. Other than agreeing on a statement, there is a different way to continue: Heuristics. That is, to let a statement slide even if it’s not 100% valid.

We already do this naturally, or conversations would never end, but there is one heuristic in particular I want to highlight: accepting disagreement.

Why it’s fine to disagree

Let’s face it, nobody is perfect. You can see how I used to think before, but really I wasn’t that logical either. If I were, my opinions would never change, and I’ve certainly changed my opinion in multiple occasions. So the first thing to realize is that there is no absolute opinion, not even yours. If you could talk with yourself a year in the future, you would probably disagree on multiple things. Heck, even talking with yourself a week from now. And that doesn’t mean that you are more right or more wrong, it means that you’ve changed and that’s part of human nature, so let’s embrace it.

There is also what I mentioned about efficiency. I have started treating opinions differently. I never actually thought that I was always right, it’s just that I thought having two opposing opinions meant that one was wrong and one was right. More often than not, both opinions have part of truth so in the end it’s not a question of which one is 100% right, but rather how true is each one. And maybe it’s 50/50. And maybe that changes everyday. At the end, what this means is that sometimes it’s ok to disagree on something and accept that as part of the conversation.

Since I started thinking that, I have to say that I’ve learned more than ever. In fact, I’ll go even further, I’ll say that opposing opinions are necessary. If you are not exposed to different opinions and take them seriously, you risk staying inside of your own small opinion bubble. And I can assure you, regardless of how smart you are or how much you know of a specific topic, different opinions are the secret to growing and learning. It’s now easier for me to accept a different opinion, and contrary to making my opinions less powerful they are enriched by this. As one misquote I find very useful says: “The real voyage of discovery consists not in seeking new lands but in seeing with new eyes”. Another way of interpreting this is thinking about Food for Thought. If I don’t agree with something but it makes me reconsider my assumptions, that’s great. Just be sure to separate actual food for thought from time wasting.

Something I am contemplating as of late is how many of my opinions are really mine. It may seem stupid to ask this for someone who said “I usually have strong opinions” at the beginning. But it really is something worth thinking about. How do you know your opinions aren’t just a mix of what you read, what you see, what you listen to every day? Your environment affects you more than you think, that’s why cultural and environmental differences explain how some similar people have radically different opinions. The more opinions you're open to, the broader your bubble will be and you'll be more you.

Some parting thoughts

At the end of the day, thinking about the statements-tree model in a real conversation is really interesting, because I’m sure an analysis of how the tree is traversed would look like chaos. The way we drive conversations is more art than logic, even for the most logical individuals. And being able to do that is remarkable, that’s why I think machines still have a long way to go to replace humans.

Now don’t go to the other end of the spectrum and be contempt by disagreeing on everything and not using logic anywhere. There isn’t a singular mindframe that’s perfect for everyone, but I’m sure thinking about this and contemplating both extremes will help you be more self-aware and become a better learner.

Rigid-Flexible Planning

2015-09-22T11:32:51+00:00

I have always been a fan of planning everything. Over the years I've come to create a methodology which I call “Rigid-Flexible Planning”. More than a methodology, it's a philosophy with guidelines. So please, take this post as food for thought more than strict rules.

Why plan everything?

When you read “plan everything” you might think I am crazy and my life is dull and predictable. You'd be wrong (maybe not so much about the crazy part). When I say that I plan everything, I mean that I try to be aware of where all my work is headed, which is the goal I am aiming for and which is the estimated effort. Just because the alternative is ignorance.

A plan may fail, it may be delayed, it may be underestimated, etc. But any of those is better than no plan at all, because all of those scenarios provide awareness, lack of planning does not.

And of course, we are humans. So we need mental bandwidth and freedom to perform correctly. Here, the rigurosity or looseness of your planning comes into place. Don't let the plan get in your way, let it be your tool.

When you fail to plan, you plan to fail

― Benjamin Franklin

So now, which are the basic concepts for this? In my opinion, a planning should have two core properties: Rigidity and Flexibility (You think these are contradictory? Keep reading).

Rigidity

The rigidity is essential in anything that must give us trusted and solid information. For something to be congruent, rules have to be applied. And this is what I mean, all the rigidity to always know with certainty what you have in your hands:

Every task must have time estimation. If you think you don't have an estimation for a task, you will at least have a rough approximation, so use that (I'm sure you know if it's in the order of hours, days or even months). Be aware that sub-tasks can span from working on a task.
Every task must have a priority. This can be represented in different formats: priority order, priority weights, chronological precedence, etc.
Every task must have a “before” and an “after” task. This is important, if you think some task can't have it, let the before task be the “beginning of the project” and the after task be the “end of the project”.
Every task must have a status (ongoing, frozen, waiting, etc.). This can be a little tedious, but it depends how the statuses are defined. If ongoing means “working on it right now” it'll be tedious indeed, but if ongoing means “started but not finished”, that's a different story.
Every task must be SMART.

Flexibility

The flexibility is important for not letting the planning get in our way. If we want our planning to really help us, we need to be aware that life gets in the way, and plans are ever-changing.

Anything must be able to be modified at any time. A problem that may arise from this is how changing something affects other parts of the planning. That should be had into account in order to maintain congruency.
Planning will go wrong, so it is important to be aware of this and have a system to introduce unexpected events into your planning. A counter measure to modifying existing tasks may be adding sub-tasks.
The system used for planning must be easy to use and natural. If you find yourself in doubt of how to reflect something in your planning, that means the tool is getting in the way and the rules you've set in place are too strict.
It must be easy to pick the necessary information at any moment. This is important in order to focus on the appropriate thought process. There are lots of representations of a plan (Gantt diagram, list of TODOs, etc), but it is important not to be overwhelmed with information and keep in mind only what's necessary at the moment.

The challenge

The challenge then given this ideas, is to create a workflow which allows for this properties and doesn't make us crazy about it. Complex yet simple.

How would you do it?

In the search of value

2015-05-12T11:42:39+00:00

Value is an interesting concept. Everyone talks about it, and everyone says it's the make it or break it for a business. But... how do you find it?

The secret ingredients

So, according to previous experiences, there are two secret ingredients for a project to be successful: Value and Discovery.

Discovery is easy to understand. You should leverage your marketing budget, your existing connections and your creativity in order to make as big an impact as possible. Not only that, but the product should lend itself to organic growth, and if possible, have built-in sharing and spreading mechanisms. Please note that I am saying it's easy to understand, that doesn't mean it's easy to achieve. In my case, the Google Play Appstore, doesn't seem to be a good platform for discovery:

I wonder how the heck does appstore search work when searching for "Quick Pick" you get Booking as a second result... pic.twitter.com/wE66kzI4xi
— Noel De Martín (@NoelDeMartin) marzo 17, 2015

Basically, almost no users will find your application using Appstore search unless you already have a good user base. So you have to get them elsewhere.

Value, on the other hand, is more tricky. What is value? I like wikipedia's description of the concept:

Value is the difference between a prospective customer's evaluation of the benefits and costs of one product when compared with others

But it still doesn't fully explain it. Value is the single most important property of any product. It is what makes it special and the main reason why users should want it. Put simply, it is what makes a business work.

In the search of value

Personally I have always been aware of this concept of Value. But whenever I really think about it, it's so difficult to achieve.

Here's the situation: you hear about the wonders (and hustles) of entrepreneurship, you believe in that and you believe in yourself, so you decide to finally go for it, and build your thing. You know it won't work soon, you know it will take months or years (or maybe never). But the idea behind that, what keeps you going, is following your believes and working in something to make the world better. If you work hard, it will eventually pay off.

But, once you're sold on the idea and you decide to take the step, reality hits, and you ask yourself “What should I build?”. The answer is something that solves a problem, something that will really help its users, … something of value. And there we go again, what is value?

So far I haven't really faced this important issue, because my first projects with Lincoln's Chilli have been games (Quick Pick and Brain Duels), and the value in games is relatively simple and straightforward: having fun, prevent boredom, socialize, etc. Now I will face this head on, and really try to find something I am proud of building and something which is solving a problem.

And that's what I'd like to present in this post, my way of searching for value: The value pipeline.

The value pipeline

The value pipeline is a process I will follow in order to find something worth building, something of value, and I hope it can help someone who is in a similar situation. It is designed to maximize the real value created without wasting too many resources and going to deep in any particular idea. I've divided this process in 4 stages. Up until now my process had been jumping directly from stage 1 to stage 4 (Idea → MVP). So let's change that.

Stage 1: Value Candidates

This first stage is the starting point in the search for value. There are different ways of looking for something that could potentially be valuable. And it doesn't only include brainstorming and looking for ideas. It also includes investigation and research. The final output in this stage (which will be the input for the next stage) is a ton of “possible projects”, or put more bluntly, ideas. I call these Value Candidates. They should be generated using the following techniques:

Brainstorming: Doing brainstorms at regular intervals. Not only when “it's time to start something new”, but keeping a habit of brainstorming every two weeks or once a month. Too many brainstorms are bad because you start to repeat yourself, but too few and some amazing ideas will be kept burried. For this particular scenario I recommend to do themed brainstorms, trying to find a different source of inspiration for each session. Some that worked for me to start off are Chris Guillebeau's convergence or thinking what you're committed to.
Ideas Backlog: You should already have an ideas backlog. If you don't have it, start right now. An ideas backlog is something very simple. Every time you have an idea for a product, write it in your ideas backlog and forget about it. From time to time, review this backlog and discard whatever you think is not that good or not applicable anymore. Don't worry if this backlog grows big (I have 85 ideas right now!), that's normal and doesn't harm because you'll review this very sparingly.
Problem Research: A good way of finding problems to solve... is to look for problems! There are many places where you can find people trying to have problems solved: Google, Yahoo Answers, etc. Another way is not to solve problems, but to reframe existing problems from a different point of view. And finally, ask people! Ask you friends and family what problems they have which technology could help them solve, you may be surprised.

Stage 2: Value Validation

From the previous stage, we should now have a ton of ideas and problems to solve. Now, this next stage is very important (if not the most important). These should be validated as real problems, and also, our solution should be validated to really solve this problems. Each value candidate should pass at least one of the following filters (if not all of them!).

Experiments: I guess the more traditional term for this is a prototype. But I like to call them experiments for two reasons. First, because that's the name of the section on my website where I will place them (ha!). And second, because they should be completely and 100% experimental. Some times, prototypes can be confused with MVPs, but at this stage that shouldn't even matter. The only goal here is to test if a problem is solved properly as soon as possible (and wasting as little resources as possible), without thinking about viability.
Hackathons: I think hackathons are a great way of testing an idea. Of course, you should go to a hackathon in order to win, but if you also want to test an idea, this way you can win even if you lose, because you would have tested your idea. Hackathons are also great to give you a good focus and work a lot in an idea in a relatively small amount of time (and who knows, you may even start recruiting for the team to build the real thing!).
Existing products: This is so obvious, but yet so many people forget to do it. Search for existing solutions to what you're trying to solve. And this doesn't mean a quick search in Google. Really, spend some time trying to solve the problem with existing tools (maybe some products are not advertised to solve a problem but they do it quite well; don't underestimate spreadsheets!).
Feedback: Also so obvious, but people wait too much for this. Start asking for feedback as soon as possible, don't wait until you have already wasted resources. One of the best ways to validate an idea, is to get real customers before you build anything. If someone is interested in your product, that's the best feedback you can get. As well as simply asking for feedback, try to use some techniques to make sure the idea is explained correctly, like story telling, or have them explain what they understand of the problem, not the solution. And finally, the good old technique to surveying some people.

Stage 3: Value Definition

If some value candidates have gotten to this place, that should mean they are promising enough to start thinking about them as a real product. Here's when we should really start to think where most people start, and not sooner. Make a business case (product lifecycle, customer acquisition plan, monetization, etc.) and define what the real product (not prototype) should be. Start looking for the resources you will need, like the team and costs that will need to be covered, and there you go, start a new project!

Stage 4: MVP

Here's when the “work hard and in months or years it will pay off” begins. Even if something is really valuable, it doesn't mean it will succeed from the start. There are thousand of reasons why it may not work: you lack discovery, the market is not ready, the MVP doesn't reflect the value correctly, etc. But at least you know you are finally working in something of value.

Everything is a Draft

2015-02-25T20:39:26+00:00

Do you think you are capable of doing something perfectly in your first attempt?

Do you think anyone does?

Do you think perfection exists?

My answer to all of those questions is: NO.

My View on Perfection

Before beginning, let me tell you that yes, of course this is about your work. I am not referring to perfection in the overall sense of the word. I am referring to having something 100% finished with no room for improvement. Be it a piece of code, a graphic design, a business model or anything in between.

When I start something from scratch, if it is some area where I have a lot of experience and I am used to (for example, programming), I always have the feeling that the solution is already in my head. I only need to spend the time to actually do it. But many times, I find there is something I was assuming which is not true. Or maybe I believe something is “finished”, but later I take a second look and something obvious is wrong or could be improved. It is easy to think of something as perfect or finished, but it always turns out not to be. That's why I don't think perfection exists. Even in big projects, with thousands of hours spent in development, something (if not everything) can be improved.

That can happen to problems whose optimality is measurable (how fast an algorithm is, how many users clicked on an ad), but most of the time the problem with perfection is that it is something subjective. Usability, context and personal experience come into place.

And that is why I think everything is a draft.

Why it matters

Ok, nothing is perfect or finished, so what? I would like to use this reasoning to reflect on some behavior I have observed in many individuals (myself included). And by doing that I hope to improve it.

Fear of deleting

There is generally an aversion against deleting work done. I guess the main reason is feeling that the time spent doing the work has been wasted. To be frank, sometimes that is the case. But most of the time something has been learned in the process and it may be worth it to delete everything and redo it with the new knowledge and experience.

Some quotes related to this:

Bruce Lee – “One does not accumulate but eliminate. It is not daily increase, but daily decrease. The height of cultivation always runs to simplicity.”
David Heinemeier Hansson (Creator of Ruby on Rails) – “The delete key, my favorite key.”
Paul W. Homer in 97 Things Every Programmer Should Know – "More time gets wasted in trying to salvage bad work than it should."
William Zinsser in On Writing Well - "I especially like to cut: to press the DELETE key and see an unnecessary word or phrase or sentence vanish into the electricity."

Nonacceptance of critiques

This point is more widely accepted: You should accept critique. Still, there is so many people who don't take feedback well. First, I think I made my point clear when I said that nobody does something perfectly in their first attempt (or ever). But sometimes, people think because they are experienced, opinion from less experienced individuals is not worth listening to. There is something dangerous about experience, we take shortcuts instead of using reasoning and common sense, because we use layers of assumptions. Most of the time that is good because you don't have to reason everything you do, but that also means you're less thorough and it can be easy to miss something.

Following that, that's why I give feedback and expect to be criticized on my work. Of course, constructive criticism. I specially like to present a problem I'm working on in a simplified version to someone with no experience on the topic, because the new point of view can be something completely different. Sometimes, it can result in something that makes no sense, but at least give it a thought instead of rejecting it (see Ad Hominem Fallacy).

Simplicity is not King

There is this saying that Simplicity is King, as well as the KISS principle. And I actually agree for the most part. But don't be fooled into thinking that if something is really really simple, it is perfect. “If it cannot be simplified, it cannot be improved” is wrong. Even if a wheel is the embodiment of simplicity, maybe you'd been better of using a lever instead.

Simplicity is King always it goes hand in hand with context.

Mark something as Finished

For practical purposes, we need to mark some things as finished to move on to new tasks. But be aware of that. We live in a Draft, every system, product or service you use is a draft. And that's why everything can be hacked some way or another. Have you ever heard this expression? “90% of the projects are 90% finished”. It is spot on.

Also, the idea that if we had infinite time to work on something it would eventualy be finished is completely wrong. It is similar to Zeno's Paradox of the Tortoise and Achiles; every step you take will take you half of the remaining closer to the goal, but you'll never reach it.

Practical Applications

All of that was food for thought, so I would like to finish this post with some practical applications of these ideas.

First, I think this is the root explanation of why Copy & Paste Programming is so wrong. The whole point of doing something is to learn from it, so if you're going to copy/paste a piece of code, you better understand exactly what you are adding to your project.

From the fact that everything you do is a draft, it can be infered that the probability of doing your best at first is not 100%. That's why it is important, at the start, to think different solutions to a problem. Or said differently, it is important to make different drafts before choosing which one to go on with. One technique that leverages this concept is Brainstorming, and I would recommend to use it quite often.

Every time you want to improve something, maybe you should start by deleting unnecessary parts. If the project is old, it's likely that some things that were important at the time are not relevant anymore. It is then an improvement to remove the unessential. And it helps you to understand the problem better if you have clarity on what is there. For example, every time I start something from a template or boilerplate, my first step is to check everything that has been included and delete whatever I think is not necessary for my project.

And of course, this post is a draft. So let me know if you think that something could be improved!

Call for Mentor / Mastermind

2015-01-30T13:21:19+00:00

Some time has passed since I started working on my own. One of the ideas I value the most is the power of feedback, experience and different points of view.

That's why I am starting a search for a Mentor or starting a Mastermind Group as one of my 2015 New Year Resolutions.

Presenting myself

About me, I introduced some of myself in the first post of this blog. If I had to say which is my main occupation, it would without a doubt be a software developer, which is what I have done all of my professional life. Most of my experience is based on Web development (backend & frontend) and Mobile development (Android). But I really think about myself as platform agnostic, with Artificial Intelligence as an area that passionates me but I haven't got into intensely. All this can be inspected further in my LinkedIn profile.

Technical matters are well inside my comfort zone, but I also enjoy Design and Business topics. Although I have to say in practice I turn to focus too much on the product, that's one of my flaws. I read and follow experts in different roles in order to keep my vision broad. And I enjoy trading ideas and reflect upon subjects.

What am I looking for?

Now, why am I doing this? I have read multiple times about the benefits of having peers to whom I could explain my doubts and intentions in order to get feedback. I think now it would be a good time to start doing this in a more structured way. I am looking for either a Mentor or a Mastermind Group, because any of those fulfill my requirement of having some regular review of my goals and progress, and would bring a greatly appreciated external point of view to all this.

The profile I am most interested in is certainly not technical. It can be, but where I would get more insight is definitely on the personal management and business areas.

In case someone is reading this and wondering what a Mastermind Group is (I assume everybody knows what a Mentor is); as I understand it, a Mastermind is a group of like-minded individuals who have meetings at regular intervals in order to discuss some matters of interest, with the final goal of helping each other and grow together. The perfect scenario is having people with different backgrounds in order to have a significant pool of experience and knowledge to leverage. Of course, in case of a Mastermind I could fulfill a role of strong technical knowledge. A full description of what it is can be read in this post.

My intentions are to meet approximately twice a month (every two weeks). I always prefer to have interactions in person, but I would like to have feedback from someone with a different perspective to mine (and I am not sure this idea of mentorship/mastermind is practiced in Spain). So I am not against having peers from far away, we'd use video chat and/or email.

If you are interested or know anyone who could be, please let me know at {{contact.email}}.

The Power of Ignorance

2015-01-09T19:40:15+00:00

I have something to confess, I am surprisingly ignorant in many topics of general knowledge. I don't know much about economics, literature, sports or world news. And I'm not ashamed nor do I regret it. But before I explain why, let me tell you who's also ignorant this way: Sherlock Holmes.

Dr. Watson: His ignorance was as remarkable as his knowledge. Of contemporary literature, philosophy and politics he appeared to know next to nothing. […]

Sherlock Holmes: You see, I consider that a man's brain originally is like a little empty attic, and you have to stock it with such furniture as you choose. A fool takes in all the lumber of every sort that he comes across, so that the knowledge which might be useful to him gets crowded out, or at best is jumbled up with a lot of other things so that he has a difficulty in laying his hands upon it. Now the skillful workman is very careful indeed as to what he takes into his brain-attic. He will have nothing but the tools which may help him in doing his work, but of these he has a large assortment, and all in the most perfect order. It is a mistake to think that that little room has elastic walls and can distend to any extent. Depend upon it there comes a time when for every addition of knowledge you forget something that you knew before. It is of the highest importance, therefore, not to have useless facts elbowing out the useful ones.

― Sir Arthur Conan Doyle, A Study in Scarlet

Why

I have to say I didn't start this on purpose, but rather I'm naturally not interested in some things. I'm sure the brain has a mechanism to forget things we don't find interesting, and that's why it's so difficult to study or learn something you dislike. You don't enjoy it and your brain is doing you a favor.

But it goes beyond the natural absorption of the brain. There is a cultural tendency to see ignorance as something bad, I know many people will see the title of this post and think I'm stupid. But it's important to see what I mean with this. I am talking about ignorance in something which is not relevant to oneself. If I couldn't locate Taiwan in a map three years ago, maybe it was because It didn't affect my life in the least. You can know about everything and you'll end up being a jack of all trades, but master of none. The point is that in this era, we have access to so much information that we get overwhelmed, and it's completely fine to be ignorant of a ton of stuff, and we should focus on whatever we're interested in.

There is also another side to this. Besides the polluting gaining of information, there are some times when even good information should be stopped. There is this concept of someone working in their “flow”. You work best when you're in your flow. I would say most people's flow is obtained when not being bothered with distractions. And that's not only external distractions, internal distractions as well. If you want to be productive working, focus on one thing at a time, and batch all your information gaining activities (twitter, reading news, etc.).

The power of ignorance is the power to have room left in your brain-attic.

Some similar concepts

The fragment from A Study in Scarlet I quoted at the beginning is not the only reference which brought me to this realization, there are also some similar concepts which bring insight to this topic:

Never memorize what you can look up in books: Albert Einstein, turns out he didn't know the speed of sound. When asked how was that possible he replied: “[I do not] carry such information in my mind since it is readily available in books. ...The value of a college education is not the learning of many facts but the training of the mind to think.”
Pulling your focus away: David Allen, author of Getting Things Done, talks about the importance of writing things down and forgetting about them, so that they stop bothering you and pulling your focus away of the task at hand. Your brain is not a good place to store all your TODOs.
Education is Broken: Ken Robinson, in the most popular TED talk of all time, explains why evaluating intelligence based on the knowledge of some pre-established topics is wrong.
Low Information Diet: Tim Ferris, author of the 4 hour work week, defends that selective ignorance and a low information diet is the way to stop the default mode of working for most people, which is an infinite interruption.

The Three Pillars of Product Success

2014-12-18T15:25:55+00:00

With time, I've come to observe there are three key components necessary for a healthy product to exist: Business, Design and Development. This post is by no means a deep revelation or anything new, but it is an analysis I would like to perform as an exercise to obtain some insights.

The three pillars

This so-called pillars are areas of action which can be taken towards everything regarding a product. Of course there is not a fine line separating the three of them, there is rather a gray boundary of uncertainty. But I'll try to explain how I see them and which matters concern each one.

The first pillar to talk about is Business. “Money” is probably what comes to mind when you read that word, but that's not the only important aspect to think about. In this context, Business is the reason to be of the product, what is called the vision, and how is it going to change the world. This is the most intangible of the three pillars, because it has arguably nothing to do with the product itself. It's important to always keep in line what is being done with what is trying to be achieved. Of course, money is necessary to do a lot of things, and that is why it is a core part of Business. So, basically, Business is everything related to the ultimate goal (vision), how to achieve it (resources) and keeping control of the progress (management).

The second pillar is Design. This includes graphic design, user experience and image. It is about the product seen from an outsider's point of view. Traditionally it is something ignored by developers, and it is often substituted with the bad practice of “prettifying”. Design is something that should be had into account from the start, and goes way beyond graphics or marketing. Some people even talk about design-led organizations.

And finally, Development is the third pillar, the actual building of the product. It has everything to do with the technology. It's the insights of the product, the inner workings and the gears. The importance of this area is in building a product in line with Design and Business. It's easy to drown into technicalities and lose focus, but the real challenge is to build the perfect infrastructure for a product to grow in the correct direction (under-engineering or over-engineering are completely Development mistakes).

To finalize the understanding of this pillars, if we had to do a simile with a human being, Business would be the soul, Development would be the body and Design would be the clothes.

Analysis and practical applications

Now we understand what this three pillars refer to. Let's see why they are the key combination for a successful product.

The Business provides the longevity, resources and reason to be of the project. Everything which is necessary for the project to be sustained, it represents the core and the foundation everything depends upon. The Design is in charge of making a product for the present, how to take an idea into reality and make a viable product. It means being in contact with clients and measuring the actual usage of the product. And finally the Development will make possible all the necessities Design and Business have in the most efficient, flexible way possible.

With this explanation it is clear that none is more important than the others, because there cannot be a product without covering all this necessities. You may be thinking of a scenario where one product reached success totally ignoring one of this aspects: Viral applications like Flappy Birds come to life overseeing the Business; clone showcase HTML5 cross-platform apps driven by marketing ignore and even sub-contract Development; and Geeky applications like command-line games ignore Design. But by successful product I mean an organically created product, born from the Entrepreneur Marathon, which can live for decades. Note that the kind of applications I just mentioned are no more than one hit wonders or temporal gold mines.

With the understanding that all of these aspects are necessary, it's important to give attention to all of them when working on a product. I would defend that any unsuccessful project is due to the mismanagement on any of these parts (if you built a product the market doesn't accept, it's probably because you didn't do the due validation of the idea, that would be because you failed on the Business pillar).

The take away for this analysis is to always balance this three aspects in a project. Ideally, at the start of a project we would have one person in charge of each of the pillars. But in the case any is missing, it is important to cover it with external services (consulting, research, etc.) or have a person take multiple roles. It would be an error to procrastinate it until a later stage of the project.

The Curse of Being A Developer

2014-12-03T19:36:55+00:00

I am a software developer, and many people I speak with tell me how lucky I am of being able of doing everything myself. If I have an idea I can define, prototype and implement the whole thing myself.

There is a problem with that, though. I don't prototype. And chances are, if you're a developer, you don't do either.

I think people have a tendency of working always at their higher level, using their top skills when possible. As it has been said many times, simplifying is difficult, and purposefully downgrading yourself is quite unnatural. That's why I don't prototype, because I have a tendency of thinking something will be “easy”. But inevitably things start getting complicated and something I could have spotted with a simple prototype becomes a problem I am working on (and wasting my time on). I reckon there is a problem there, and my goal in this writing is to analyze the problem and start making an effort to improve my approach.

Let's analyze why this is bad

First, it delays the completion of the first milestone for your project, which should be getting feedback to validate the potential of the idea. That is, unless you know for a fact that your project will be a success, which I doubt you really do. Anything that doesn't work towards the goal of getting feedback must be avoided when possible. The only reason why you would do something now is because you think it will save you some time in the future: “Let's implement this feature so that we can reuse it later”. And I can assure you the feedback you can get from a simple prototype far exceeds any time savings you can get from code reusage. It will not only tell you if the idea is good or not, you will even change entire features which will make your “reusable code” completely useless.

Another excuse is that you simply enjoy building it. That is true to some degree, but do you really want to systematically implement everything and anything just because you enjoy it? That's what I used to do, and it brought me to this realization that I never prototype. It's a bad habit that shouldn't be the default approach. If you really do it for the sake of programming, I recommend other type of activities that are more enjoyable and have a framed time of dedication (which prevents you from over-complicating things from the start).

Finally, there is the fact that your programming skills are a valuable asset of yours. You shouldn't be throwing them away for free. When you start working on something, make sure it'll bring some value at the end. That's something The Joker and Randall Munroe know well.

So then, what is a prototype?

I hope I've convinced you (and myself) that prototyping is the way to go. So, then, what is a prototype? As I understand it, a prototype is an artifact designed to get you feedback about an idea. That's it. The feedback may be different in each scenario: it can be feedback about the correctness of the idea (will it work?), it can be reactions of potential customers to some product (will anyone buy it?), it can be an estimation of the appropriate pricing, a search for the correct public, etc.

In any case, this prototype will probably be something anyone could do, without having any programming skills. It can be some hand drawn wireframe, a market study or even a simple explanatory text (you know, an elevator pitch). And I am also sure there are thousands of applications better for creating prototypes than an IDE.

So, the next time you eagerly open your IDE ready to start your next project, think twice about it.

My AppsWorld 2014 Digest

2014-11-19T12:45:20+00:00

Last week I attended AppsWorld 2014 in London, a conference about mobile applications and the mobile industry overall. As I expected, It was a valuable experience, and I thought it would be a good idea to make a summary of what was said and what I learned. This will serve for myself as a way to process all the content and for anyone who is interested to see what happened.

My Point of View

First, I have to say it was quite a big venue with lots of talks and events. If you take a look at the agenda, you'll see there were many presentations, most of them overlapping. So my summary and my remarks will be based on what I had time to see, which is a combination of what happened in Developer Zone, Droid World and Gaming World.

The events I attended were the following:

Keynote panel: Creating a successful app business
Apps: From inception to expansion (Petter Briffet, Yplan)
Panel: Monetisation, discovery, engagement & retention
The first 48 hours: How to know now if you've got a hit or are DOA and what to do about it (Jon Walsh and Elisabeth Priestman, Fuse Powered Inc)
Panel: Building geo-location into your Android app
Panel: The evolving role of the publisher
Fast Failure - risk management in a mobile gaming studio (Vladimir Funtikov, Creative Mobile)
Mini WIP JAM
Android app marketing: Tips for app publishers (Ruth Barnett, SwiftKey)
Going Mobile: Challenges for indie game developers
Discovering Android design guidelines (Marten Joensson, Google)
Panel: Designing your next beautiful Android App

Core Ideas

There were some core ideas repeated throughout multiple talks, which make them even more important. It's true that some of them are quite “obvious” and I've heard them like a thousand times already, but in my opinion that's a sign that they are so important. And should be definitely had into account.

Product Value & Idea Validation

What's the most important of a product? Of course, it is the value. The added value. This was repeated many times in different ways, but it is so hugely important to understand this, that I'm sure many applications live or die by this concept. The added value of a product is what makes it appealing to a user. It is simple, the user will be giving you money (or time, which is more important), so you have to give something back. Value is not features, so defining an application in terms of its features is mostly wrong, and it is something that us developers do a lot. So I am grateful to have heard the importance of added value 10 times this two days, so that next time I start thinking on an application I really see it from the user's point of view.

When in doubt, there is a simple question that tests the validity of an idea: Which problem does it solve? If you really cannot answer that, there is something wrong there. Users will download the application for that sole purpose, so it is important to really solve something well. In order to validate an idea it is necessary to pitch it to real customers, or run a focus group session. That's how you will really know if a product will work or not. Another way of seeing it is having a use case which defines the context of the application. All this is well expressed in the Lean Startup methodology.

There was something interesting mentioned for games, but I think it can be applied for any application. There are three aspects which need to be defined before starting to build anything: Mechanics, Monetization and Fun Factor (or Added Value).

Advertisement & Discovery

I have something to admit, before listening to some of the talks I had quite a bad idea about application advertisement and discovery. My idea was simple: “spend money in advertisements and create visibility in social networks and users will come”. Now after listening some insights, I realize that a bad application can never succeed only with this (although it really makes you wonder what happened with Yo, but I guess there are always exceptions). But also, a good application cannot succeed without it, you really need to be able of communicating effectively and know your audience. So it really has to be a combination of both to have winner.

A good advice was to find out which is your addictive user base niche before spending money in advertisements. And also, advertisements that are detectable as the company having paid are not that good (I actually know for experience with Facebook advertisements). If we have to talk about good methods for advertisement and discovery of apps, there are three:

Bloggers & Media: If users see the application for the first time from a trusted source, like a blog or the media in general, they are much more open to give it a try. On this note, a good way of achieving this kind of coverage is to put yourself on the media's shoes, and make it easy for them to want to write about your app (it is noteworthy, appealing, there is plenty of information, etc.).
Organic Growth: Friends sharing with friends. If you can make that your application is spreading itself, you're gold. This is how most big applications really grow.
AppStore Optimization (ASO): I'm sure most of you are familiar with the term Search Engine Optimization (SEO). Turns out there is a new trend for applications, which is called ASO. It follows the same reasoning as SEO, optimizing the content, description and marketing of your application in order to appear more easily when users search for apps on their own. But I guess it has a different approach given there are many app stores with different mechanisms (Google Play, iTunes, Windows Phone Store, etc.). In particular, there was someone specialized in this, Nick Duddy and his company Miratrix.

It was also noted the power of having a brand supporting the launch of an application, this can be obtained for indie developers with publishers. And depending on the brand, this can make a huge difference at the beginning.

Metrics

And of course, there was a lot of talking about metrics. Most of these are valuable to me as a baseline, because really I didn't have much of an idea about what determined a good or bad app (besides downloads and rating). I have to say that most of them were particular to game applications, so I am not sure they can be applied for all kind of applications. But as I said, it serves as a baseline (better than knowing nothing).

So these are some of the metrics I found useful:

Returning Users: The percentage of users that open your application for a second time. Turns out a good value is having 40~45% of returning users. 35% is already pretty bad.
Free to Play: In general, having free to play versus paid applications ends up with 10x audience and 3x revenue.
Paying Users: The percentage of paying users (how many people using your application actually spend money) doesn't seem to go up with time. So, you shouldn't expect this to improve much without changing anything. Also, applications with a low percentage of paying users seem to do well with advertisements (if placed properly). A good value for this metric is having 2,5% of paying users.
Player Value > Player Cost: Player value should be how much your paying users spend divided by the amount of total users. Player cost is the amount you spend on acquiring users divided by how many new users you acquire. So as you may guess, in order to do well, your player value should be bigger than your player cost.

Most of this was explained in the talk by Fuse Powered Inc, which can be found as a blog post here: The First 48 Hours: How to know NOW if you’ve got a hit or are DOA.

An interesting concept that was mentioned was having a “magic number”. It means having a metric that makes the difference for your business, for example in Spotify this metric is the time required to stream a song.

Pitching & Networking

There were also some other things to have into account from a personal point of view. In case of searching for investors, when pitching the idea you should know that you're pitching you and your team as well (that can influence a lot if the investor will go in or not). Also, at the beginning of businesses it is important to get into the community, attending meetups and doing networking to strengthen your contacts network and creating collaboration opportunities.

Conclusions

An that is a summary of what I found more interesting about all the presentations and discussions. It is obvious how important it is to get out of the comfort zone as a developer and start thinking about other important topics: Value, Networking and Visibility.

Starting Something New

2014-11-10T09:41:19+00:00

There is a feeling I enjoy a lot. The feeling of Starting Something New.

This is my first blog post, and because of my personality the first thing I did to prepare it was reading the first posts of blogs I follow. It didn't help too much, so I did a list of what I should include here and that's it, I started writing. It wasn't so painful as I thought it'd be.

Who Am I

I don't really know if anyone who doesn't already know me will even read this, but well in case that happens here you have what you can also read in the about section at the moment.

Hi there!

My name is Noel De Martin Fernandez. I am a Problem Solver, Software Architect and Entrepreneur. I created Lincoln's Chilli and I am in the process of exploring the market and creating my own framework to deliver services and products. I enjoy innovation and collaboration, so I am interested in different technologies and projects that open me to different possibilities.

I live in Catalonia (Spain) and you can check me out in Twitter or LinkedIn for more information. If you want to contact me, don't hesitate on sending an email.

Cheers

As of my current situation, I recently quit my job (3 months ago) and I'm now trying to follow my dreams and passions. It's not as easy as it sounds, because for starters I don't even know what those are, but as they say “You don’t have to get it right, you just have to get it going”.

By the way, I already started something, and that's Lincoln's Chilli. Check it out, I call it my “entreprenurial sandbox”, and I want to someday convert it into a profitable company.

What this blog will be about

I have been thinking about writing a blog for a while. I would say as much as 4 years (more or less when I finished university and started reading some blogs). In all this time I have been taking note of ideas I had, but I never actually started a blog (you know, we're all too busy and that kind of excuses). But now there are no more excuses, so here it goes: Noel De Martin's Blog.

They say blogs should be focused in one topic, and I half agree with that. On the one hand, that's how a blog would get readers and create an audience, which gives the blog a reason to be. On the other hand, I don't really know if that'll happen even if I try, and the main focus for now is to write all this ideas I have floating in my head.

Happily for me, there is a way to fulfill both aspects of that. Because of my current situation, my passions and what I'd like to write about, I have realized everything can be summarized in one topic: Developer Entrepreneurship. Being myself a developer who is trying to become an entrepreneur (so I guess right now I am a wantrepreneur), this can be the perfect place to narrate my journey and the ideas I have during this evolution. I am particularly interested in this topic, because I think it is not covered as much as I would like. There is a lot of content about development, and also about entrepreneurship, but I haven't seen as much about the combination of both.

Final Words

So, that's what you can expect from this, kind of. Like always that I start something new, I am very excited about this and I am looking forward to see your opinions on my thoughts.