Pretty early on I realized that what interested me was to observe how people work and help them work more efficiently. I studied General Engineering which is everything from mechanic to electronic but without much focus on computer science. That gave me a background to understand what most people are doing, be able to recognize bottlenecks in various workflows and devise what tool could help. On the side, by myself, I learned some programming languages so that I could implement those tools.
I’m fortunate to be able to work remotely. I take advantage of that and travel a bit around the world. That also means that I do not have a proper desk, and just work from coffee/Airbnb. So here are a few pictures from the latest places I worked from.
Moving a lot, I only have a 13” MacBook Pro, no external monitor or anything else. I tend to use apps in full-screen mode, hiding the top bar and the dock, that helps with fitting more on the screen and staying focused.
I use VS-Code with the One Monokai theme, and Xcode when working with Swift.
My entire setup is bootstrapped using dotfiles that you can find here if you want more information. They can also be used to bootstrap a small instance Linux server which I ssh into to work on the go with an iPad Pro (using the app Blink).
Depends on the mood, but Serverless (Node.js on AWS Lambda) + React sprinkled with some TypeScript is always a safe bet.
According to GitHub, the 5 repos I visit the most are:
All of them are repos I work on/contribute to.
I’m quite interested in seeing if Solid, the new project from Tim Berners-Lee aiming to bring “true data ownership” to the web, can get somewhere. I’m trying to keep on eye on the different repos: https://github.com/solid.
Quantum Computing is also something very promising even though I’m still having a hard time getting my head around it.
I’m currently working on developer tools for Sketch plugins, so this is actually a topic I spend a lot of time thinking about.
Sketch plugins are a pretty niche field, and I obviously have a significant advantage compared to developer tools for the web: I can freely make changes to the platform to accommodate for the tools I’m building. But it still represents a flow that I really enjoy.
So here is how it works:
- You first install
skpm(Sketch Plugin Manager)
- You can then run
skpm create my-plugin-name. That will create a new folder containing everything you need to develop a plugin. Everything is working out of the box: it turns on some flags to enable the developer mode for -----Sketch, it creates a webpack and babel configuration, it adds the plugin to the plugins menu in Sketch, etc.. It even creates a Sketch file for the assets you might need (like the plugin icon, the social card that you can add to a GitHub repo, etc.)
- Update the plugin code, and skpm will automatically compiled it, and optionally run it in Sketch with the logs showing up in the terminal
- Once your plugin is ready, you can run
skpm publishto publish it.
- That’s it!
I’ve been in South America for a while now so I’m trying to learn Spanish.
More tech related, I’m trying to patch up my Computer Science knowledge given I didn’t study it at school. I’m following the “Programming Languages“ course on Coursera. I really recommend it!
And as mentioned before, I’m trying to get my head around Quantum Computing. https://quantum.country/qcvc is an excellent introduction to it.
I try to stay away from learning new programming languages/frameworks in a vacuum and instead pick a new framework when I’m starting a new side project. Because I don’t have any time constraints there, I can make some detours to learn the framework/language as I work on the project.
As mentioned before, skpm is a project dear to me. I started it as an open source side project before joining Sketch when I was playing with Sketch plugins. The developer experience of building a Sketch plugin was terrible. The environment in which plugins are running is really different from a browser or Node.js.
So I set out to create a tool to smooth out those differences. I started to re-implement the Node.js APIs, provide polyfills for global variables that didn’t exist (like
At the same time, Jon Gold was working on
react-sketchapp. In the beginning, the project was using a custom webpack configuration to generate a script to be used as a Sketch plugin which would render the React components in Sketch. It was a bit cumbersome.
So I sent a PR to make it use skpm to create the plugin and hide all the complexity. All of a sudden, a ton of people started using skpm via react-sketchapp! It was a bit scary because there were a lot of bugs to fix and features to implement, but it was inspiring.
Eventually, skpm got me a job in the Sketch team and is now the official tool to create Sketch plugin.
How to dive into an existing codebase. 90% of the projects you do when learning to code are greenfield projects, but 90% of the projects you will work on are going to be brownfield projects.
One thing I’m advising people I mentor is to pick an open source project on GitHub that have some interesting “Help wanted” issues and try to fix it. Sometimes it’s a bit scary to open a PR on a big repo, so I often tell them to first open a PR on their own repo and ping me so that I review it before opening the PR on the upstream.
It’s also beneficiall to learn a proper git workflow, which is not often taught before joining a team: how to write commits, how to rebase a PR, how to squash commits, how to write a good PR description, etc..
If that’s something that could be helpful to you, feel free to ping me in a PR, I’d be happy to spend some time reviewing it!
My team is working on providing a public API for the plugins. Obviously, we want it to be super stable so that plugins can continue to work across Sketch releases. Of course, you always want your code to be future proof but that often only means a code well documented and tested so that it’s easier to refactor when a new feature comes.
Here it’s about anticipating new features so that the changes will only ever be additive. That way the API won’t have any breaking change. It’s tough to do and demand a lot of thoughts about edge cases and sitting down to understand what potential upcoming features are going to impact which areas of the API.
It’s a lot of behind-the-scenes work so that it can stay invisible for plugin developers.