rn-109: add interview with Linus Arver

Author: sivaraam

rev_news/drafts/edition-109.md

@@ -29,9 +29,225 @@ This edition covers what happened during the months of February 2024 and March 2
 ### Support
 -->
 
-<!---
-## Developer Spotlight:
--->
+## Developer Spotlight: Linus Arver
+
+* Who are you and what do you do?
+
+  I'm one of those so-called "self-taught" developers. My educational
+  background is in English and tax law (I know, boring right?). Over a
+  decade ago I thought I would be a corporate attorney, but in law
+  school I discovered programming and fell completely in love with the
+  craft, and never looked back! In hindsight it was the second-best
+  decision I've made in life (the first being getting married to my
+  lovely wife four years ago).
+
+  I said that I fell into programming during law school. But actually my
+  original journey started in 7th grade when I tried to pick up C++. I
+  remember learning control flow, structs and pointers in the first few
+  chapters of the book I was using, but when it came to the chapter on
+  OOP and classes, I could not understand why OOP was necessary.
+  The book I was using just explained why OOP was great, and not
+  why it would ever be bad.
+
+  Of course, years later I realized that OOP is one of several
+  paradigms, so perhaps my instinct to question OOP as a panacea was
+  onto something.  In high school and university I remember tinkering
+  with HTML and websites before smartphones became popular. What a
+  simpler time it was, back then!
+
+  Fast forward to law school, where I had the idea of writing class
+  notes using plaintext. Soon after I had the idea of converting these
+  plaintext notes to prettified outlines, so I needed a way to convert
+  them to HTML. For better or worse, all this happened before I
+  discovered Emacs and Orgmode (or even Markdown).
+
+  Anyway I first wrote a plaintext-to-HTML converter in Ruby. Then I
+  rewrote it in C just for fun. Then again in Haskell (using a minimal
+  subset of Orgmode syntax). As you can see I sort of got carried away,
+  haha.
+
+  I would go on to write dozens of pet projects (rudimentary chess
+  engine, game modding tools, etc) where I got to write tons of code.
+  I've had the "ugh, did I really write this?" moment too many times to
+  count. I like to believe that I did the tech industry a favor by not
+  entering it until I was well versed in fundamental programming and
+  architectural concepts. 😉
+
+  Since those law school days I've taken an interest in learning more
+  languages/ecosystems (e.g., Elixir and Rust). Recently, I've taken a
+  renewed interest in Literate Programming. I'm toying with the idea of
+  using it in a somewhat large scale in a future project. It takes a ton
+  of work to do LP right, but in many ways it's the best possible way to
+  document code (case in point, the absolutely stellar documentation
+  standards of the TeX community, such as the glorious TikZ user
+  manual).
+
+  And I believe that readability is the most important attribute when it
+  comes to code --- even before correctness! Because at least if the
+  intent of the author is clear, we can have a fairly (easy) way to fix
+  things to make it correct. The other way around (correct, but
+  unreadable code) suffers from stagnation because people become afraid
+  of touching it, because it's hard to understand. It becomes harder to
+  extend and grow, which is required of any software worth maintaining
+  (we call it _soft_ ware for a reason).
+
+  Going back to the question (sorry for rambling a bit there), in my
+  $DAYJOB I work on microservices, APIs, and backend systems.
+  Professionally I've always been a backend/infra engineer. In my spare
+  time I contribute to this wonderful community!
+
+* What would you name your most important contribution to Git?
+
+  I would say my contributions to the documentation come out on top.
+  At the end of the day, Git is meant for human consumption.
+  So getting a bit more polish here and there for user-facing docs is
+  well worth the trouble, and I am most proud of my work in this area so
+  far.
+
+  If I had more time I would overhaul the documentation to make things
+  easier to understand. Truly, Git has a very simple conceptual model
+  (thanks to the brilliance of its original author). You just have to
+  understand that commits come from one or more other commits (sort of
+  like family trees). That's it! But sadly we have a reputation of
+  having absolutely terrible user-facing docs, so much so that it pushed
+  people away to Mercurial and other more friendly VCSs. We need to fix
+  that.
+
+* What are you doing on the Git project these days, and why?
+
+  Last year I started trying to add unit tests to the (perhaps obscure)
+  `git interpret-trailers` command, but this effort has morphed into
+  "let's also overhaul the entire subsystem around how trailers are
+  handled, with the aim of creating a reusable C library around it".
+
+  I'm afraid I've bitten off more than I can chew, but I do have a
+  backlog of about 60 patches that I need to get sent up for review. Not
+  all at once, of course haha. Hopefully I can get these sent up and
+  merged over the coming months. The review process can be lengthy you
+  see, but for good reason --- we take time to try to make sure things
+  are right the first time.
+
+* If you could get a team of expert developers to work full time on
+  something in Git for a full year, what would it be?
+
+  At the risk of being unoriginal, it would be libification (see
+  [Calvin Wan's interview](https://git.github.io/rev_news/2023/08/31/edition-102/#developer-spotlight-calvin-wan)
+  from edition 102). But to be more precise, it would be the complete
+  banning of "shelling out" which we do in many places (where Git
+  spawns another Git process to do something). Instead we could
+  (and should) be using libraries internally inside Git's own codebase.
+  I believe that once we can get Git to start treating itself
+  as a library, that external library consumption will soon follow.
+
+  There are many others interested in this area as Git has a massive
+  footprint in our industry. I hope that the many large companies that
+  benefit from Git can grow their roster of Git contributors.
+
+* If you could remove something from Git without worrying about
+  backwards compatibility, what would it be?
+
+  `git checkout`. I believe `git switch` and `git restore` replaced the
+  need to have `git checkout`. I believe in the "there should be only
+  one way to do the right thing" camp when it comes to the CLI, so I don't
+  like how we have multiple commands with a lot of overlap.
+
+  I say this even though personally I've been using Git for over 15
+  years and have always used `git checkout` (even after the introduction
+  of `git {switch,restore}`). Simplicity matters!
+
+* What is your favorite Git-related tool/library, outside of
+  Git itself?
+
+  [tig](https://jonas.github.io/tig/). I use it all the time, every
+  suday. It's so good that I basically never use `git log`, unless I'm
+  piping it through to search it.
+
+  Every time I see someone proudly showing off their latest "git-log"
+  incantation (with all its bells and whistles), I think to myself "I
+  guess they've never heard of tig".
+
+  Being an Emacs user, I tried to get into [Magit](https://magit.vc/)
+  but could not get used to the keybindings that conflicted with my
+  Vim-styled bindings. (Yes, I use Evil mode if you're into that sort
+  of thing.) OTOH I get so much done with the basic git-* commands and
+  tig that I'm rather happy with my workflow.
+
+* Do you happen to have any memorable experience w.r.t contributing to
+  the Git project? If yes, could you share it with us?
+
+  Nine years ago, I contributed my first patch series. I was so proud of
+  this work that I wrote [a blog post](https://funloop.org/post/2014-09-09-my-first-contribution-to-git.html)
+  about it.
+
+  The TL;DR of that post is that anyone can contribute to Git, and
+  really we are a welcoming community. Junio goes out of his way to
+  accommodate new contributors (I admire his patience), so please, feel
+  free to join us!
+
+* What is your toolbox for interacting with the mailing list and for
+  development of Git?
+
+  So my first contribution 9 years ago was via (the traditional)
+  `git send-email` command. These days there is this very neat service
+  called [GitGitGadget](https://gitgitgadget.github.io/) that allows
+  you to create pull requests on GitHub and does all the housekeeping
+  work of keeping mailing list discussions in sync (you'll get comments
+  on your PR which come from mailing list responses). Plus you can get
+  previews of your patch series (exactly how they'll look like on the
+  list) before you submit it, which is always nice.
+
+  For local Git development, honestly I don't do anything special or
+  unusual. One window for Emacs, one window for (re)compiling Git and
+  running tests, and maybe one more for tig. From Emacs I use [notmuch](https://wiki.archlinux.org/title/Notmuch)
+  to browse the mailing list emails (which I sync to Gmail with
+  [lieer](https://github.com/gauteh/lieer).
+
+  I use Orgmode in Emacs heavily for organizing code snippets and ideas.
+
+  Lastly but not least, I use tmux to organize terminal windows and
+  nagivate quickly across them, even if I'm not using SSH.
+
+* What is your advice for people who want to start Git development?
+  Where and how should they start?
+
+  The hard part is figuring out which area you want to work on. Git has
+  a large codebase, so I recommend starting out with documentation
+  changes to familiarize yourself with the current state of things.
+  There's always a typo or grammofix hiding in there!
+
+  Many of our manpages read like dictionaries, when they should read
+  more like user guides. Some manpages have helpful "EXAMPLES" sections
+  to show you how to actually use various options and commands, so if
+  you can think of additional examples, that would be most welcome.
+  Getting familiar with how things work with user-facing docs should
+  help you understand the intent behind the large C codebase we have.
+
+  Try to make your contributions as small as possible, but make an
+  effort to write good commit messages. Copy the style of veterans like
+  Junio, Peff (Jeff King), Christian Couder, and others I am forgetting
+  (sorry!) who've been doing this for a long time.
+
+  Once your change is submitted, nag people weekly to get things moving
+  (yes, we need prodding occasionally). But also don't get offended if
+  there are a lot of review comments for seemingly small things ---
+  we're just trying to maintain a certain level of quality. Git is used
+  by almost everyone in the software industry, so it's important for us
+  to keep a high bar for quality, that's all.
+
+* If there's one tip you would like to share with other Git
+  developers, what would it be?
+
+  Junio has been our maintainer for over a decade. It's a tough job and
+  somehow he's kept going at it all this time. Still, let's do our best
+  to help make his job easier, because honestly we are truly lucky to
+  have someone of his caliber lead our project.
+
+  More concretely, this means helping out with code reviews. If you're
+  not sure which ones to review, see the "What's Cooking" emails that
+  Junio sends out regularly to look for patches that need help from
+  reviewers. They are commented as "Needs review" or "Comments?", so
+  they're easy enough to spot.
+
 
 ## Other News