Today, we're talking with Jesse Duffield, a Melbourne-based software engineer. Known for his popular open-source projects like Lazygit and Lazydocker, Jesse transforms the complexities Git and Docker into user-friendly Terminal User Interfaces (TUIs). Let's dive in and learn more about the man who's helping us code a little more effortlessly.
Q: Can you give us a brief introduction about yourself and your background?
A: I’m a software engineer based in Melbourne
Which open source projects do you currently maintain?
Oh boy, there are a few. The main ones are Lazygit and Lazydocker but I have a few others under my belt: Lazynpm, horcrux, the OK? Language, and some other smaller ones. I don’t do a very good job keeping abreast of them all: Lazygit is my main focus.
What inspired you to create Lazygit and Lazydocker?
Lazygit came first: I was frustrated by the git CLI and wanted a project for the sake of learning Go. The incumbent git TUI was tig and although it was good for read operations (e.g. viewing the git log) it wasn’t as good at write operations (e.g. staging files) so I focused on that.
Lazydocker came after: Lazygit enjoyed huge success very quickly and I wondered: what other annoying CLI interface could I turn into a TUI?
Can you walk us through the process of designing the TUIs? I imagine you had to experiment with various aspects like navigation keys, box dimensions, and other design elements.
Surprisingly, the basic design hasn’t really changed since day one. I wanted to show as much context on the screen as possible and that naturally led to having the side windows for files, branches, etc, and the main window for viewing the currently selected item.
Navigation keys are an interesting bit of trivia: the library I originally used for handling keybindings was termbox, and that didn’t support shift+tab, so instead of using tab/shift+tab to navigate up and down side windows, I used left/right arrows instead. It’s a pretty bizarre scheme when you think about it but it’s stuck.
I’ll be honest: I did very little experimentation. I optimized for speed of development and that meant just picking something that seemed sensible and then releasing it. It’s experimental in a way given that I can then iterate based on user feedback, but there are some cases where more forethought would have spared me some pain!
Git can be hard to navigate for lots of developers. There are so many commands and options to choose from. Was there a particular Git command or option that was difficult to implement in Lazygit?
The hardest thing has been the ‘rebase magic’ stuff. So for example selecting a patch from an old commit and then splitting that out into its own commit or moving it to a later commit. It just involves many pieces: selecting the patch, starting a rebase, applying it in reverse, then applying it forward later on, and dealing with the different edge cases in between.
What projects or features are you most excited about implementing next in Lazygit and Lazydocker?
I’m excited for a few things in Lazygit. First of all: bulk actions, so e.g. selecting a group of files and then staging them all at once, or selecting a group of commits and moving them all down in an interactive rebase. I’m also looking forward to a better diffing UX and a mechanism for toggling arbitrary flags before running a git command.
Horcrux is another cool project of yours. What's the backstory behind that project?
I enjoy writing (as you may have noticed from my blog) and some of my writing is just personal stuff whose intended audience is just me. I want to be able to read it all back when I’m older but I don’t trust cloud platforms to safeguard it and I don’t trust myself to remember a password 40 years down the line, nor do I trust that I can put this stuff on a USB without somebody else stumbling across it. So that’s how I thought of horcrux: what if I just split up the file into encrypted fragments and if I have enough fragments I can put it together again. Of course, what are the odds that in 40 years time I’ll still have all the fragments? So it’s a bit of a silly idea but I thought it was cool enough to build anyway.
During the development of your projects, did you encounter any lesser-known libraries or tools that notably solved a difficult problem or accelerated your development?
That’s a good question. An implementation of Samir’s Secret Sharing Scheme by Hashicorp was critical to horcrux: it’s what allows you to reconstitute an original key only using a subset of the original fragments.
Were you surprised by the positive reception of your projects?
Very much so. In fact I posted Lazygit online a couple times to zero interest before eventually striking gold on Hacker News. And although I currently think Lazygit is pretty good, I’m amazed at how much traction it got in the first few weeks given that it really was a buggy, sluggish, broken piece of software haha.
What's the primary programming language or framework you use in your projects?
Go.
Have you had any particularly memorable interactions with community members? This could be related to a specific pull request, an especially helpful contributor, or even a challenging interaction.
I’ll take this opportunity to shout out Stefan Haller who became a contributor in the last year and who has become deeply invested in the project. Stefan is very intelligent and often wins arguments against me. It’s great to have somebody like that on the project.
How do you prioritize and manage your time between work, maintaining open source projects, and personal life?
The truth is that I don’t balance it! I’m yet to find a way to make it all work: there are times where I give my friends more time and times where I become a recluse and just focus on Lazygit. One day I’ll hopefully strike a balance.
Has the notion of doing open source full-time ever appealed to you? If there was a sustainable way to support yourself financially, would you consider it?
God yes. If it was financially sustainable, I’d do it in a heartbeat. I probably have more sponsors than average and even then it’s not enough to live on.
What are some of the most significant challenges you face in maintaining your projects?
I’m an introvert so when I’m programming I’m in my happy place. But maintaining a project means interacting with lots of people and that can drain my energy. So trying to remain responsive and keep on top of issues/PRs is probably my biggest challenge.
What advice would you give to someone looking to start their open-source project or become a maintainer?
Fix a problem that you personally have because then you are guaranteed to have at least one happy user. It’s much easier to solve your own problems than to solve somebody else’s.
How can the community best support you and your projects?
Please consider making a one-time or recurring donation at https://github.com/sponsors/jesseduffield. It really does make a difference!
Jesse’s Links: