• GitHub Codespaces Is Too Cumbersome and Expensive to Replace Local Development

    After trying out GitHub Codespaces for work, it’s clear thatβ€”while impressiveβ€”it is not a suitable replacement to developing locally. It’s slow to set up. It’s also very expensive.

    When using Codespaces with a monorepo that uses docker-compose to run services (e.g. a database, frontend app, and API server) you want to have everything running so you can develop as soon as it boots. However, every Codespaces container builds the entire docker-compose each time which takes time for any non-trivial setup.

    If you try to set your .devcontainer to your project’s docker-compose.yml, Codespaces doesn’t expose the running docker services in an accessible way and you are attached to a single container with no way to switch. You can’t see logs (e.g. docker compose logs {service}) or execute code in another container (e.g. docker compose exec {service} {command}). You can’t change which container the Codespace is attached to so running setup or maintenance scripts is difficult.

    You could use the default .devcontainer and call docker from within the Codespace terminal, but then you push the build latency to after the Codespace boots and the user has to remember to call it for the set of services they need.

    GitHub is also working on a feature to pre-build devcontainer images, but who knows how much that will cost in storage.

    Adding up the costs of using Codespaces full time shows that it’s more expensive than buying MacBook Air M1s. At the default 4 core VM at $0.36 you’re looking at roughly $1,000 per engineer per year. Not to mention and you still need to buy and maintain a work laptop.

    There is an argument to be made that you save money on time spent dealing with local configuration issues. This makes sense at larger organizations, but for a small startup, probably not.

    See also:


  • Emacs in the Browser Using Codespaces

    Using codespaces, you can open a web-based VSCode session, open a terminal and install emacs.

    sudo add-apt-repository ppa:kelleyk/emacs && sudo apt install emacs27
    

    Then set the option for using the option key as meta in Settings.

    Install dependencies for vterm:

    sudo apt install cmake libtool libtool-bin
    

    Then clone my .emacs.d:

    git clone https://github.com/alexkehayias/emacs.d && mv emacs.d .emacs.d
    

    Then open emacs (which installs packages with use-package):

    emacs
    

    Now there is a full emacs with my config and a vterm running in the browser using GitHub Codespaces.

    Other tweaks

    • Add your ssh key so you can push/pull to a remote git repository.
    • Fix M-BKSPC not working like it does in macOS
    • Fix magit can’t open the commit dialogue
    • Install other OS dependencies needed for writing (e.g. efm-langserver, aspell)
    • Go full screen CTRL-CMD-P (there’s still no way of removing the top heading, but it’s close to fully full screen)

    Alternatives

    It’s possible to run a Linux container and run it through the browser using Kasm (an easier remote desktop kindof thing). It can be customize to launch emacs directly. I haven’t tried it but seems promising for self-hosting and running privately behind tailscale.


  • There Are Surprisingly Few Product Engineers

    Product engineers solve user problems, but why are there so few of them?

    As recently as 1999, The Inmates are Running the Asylum told the tech industry that engineers were the reason websites and products were bad. Engineers were not trusted with knowing about users and their problems and yet, they are blamed for poor solutions to solving them.

    The way we organize engineering doesn’t help. As companies grow, engineers specialize and are closely managed by project managers and product managers. It’s difficult to build anything significant that requires action across teams and departments.

    Altogether that means we lack the trust in engineers to understand users and the experience pool to cultivate a strong product engineering discipline. Status quo preserving behavior will continue to keep engineering as they are, which doesn’t bode well for users.

    See also: