4 ms·
I am keen to crowdsource a study of emacs workflow practices, where we can collect, compare and analyse different development practices among emacs users. This
by petr_tik 7y ago
I am keen to crowdsource a study of emacs workflow practices, where we can collect, compare and analyse different development practices among emacs users. This should help other emacs users to borrow modes/keybindings/specific techniques/tricks.
* Motivation
This is inspired by an ongoing conversation about emacs with a friend and a debugging interview that I really enjoyed.
* Exchanging emacs tips with a friend
A friend of mine is pretty proficient in emacs: org-mode all the things, written >500 LoC of elisp, tried several distributions. We still regularly teach each other about existing emacs functionality and exchange messages along the lines of:
- I just found that there is a function foo, which I have made a keybinding foo and can now search open a tab with a SO search with text from the clipboard
- whaaat? That's super useful!
- I know, right?
He works with a couple of greybeards, who also seem to be constantly finding emacs functionality that makes their lives easier, which suggests it would be beneficial for all of us to watch others in emacs.
* Interview
I was given a real git repo that I needed to load into my environment (spacemacs on Linux) to debug and fix failing tests. They sat me down during the onsite (the days when we would go to interview in person), told me to download the repo from the URL, told me how to run the tests (after activating the python venv) and watched me debug and fix failing tests - only 5 were failing from about 100. The interviewers were not proficient in emacs, but I felt that they could follow my thought process and workflow. I had only recently set up python dap-mode and felt clunky navigating in pdb through dap, so ended up print debugging.
It made me think how interesting it would be to watch other people with different backgrounds and experiences debug the same problem and how often I would learn new tricks or debugging techniques. Having a good understanding of the problem and the code allows you to focus on the activity of programming and watch out for new ways of tackling the same problem.
* What will we investigate
Furthermore, it might be interesting to see what debugging practices are statistically more succesful in tracking down the bug faster (and control them for overall years of programming experience and emacs proficiency).
If our sample is big enough we can answer questions like:
Correlation between overall years of programming experience and debugging time?
Who is faster at debugging: printf or gdb debugger people?
Which keybindings and modes are most frequent across users?
Is there a correlation between having custom elisp functions and debugging time?
* Format
I will prepare a representative repo in the most popular language (I am most comfortable in Python, happy to consider other languages, if people prefer), bury some bugs in it (that will be easy), administer the study and summarise the findings in a spreadsheet/write-up.
Following the debugging session outlined above. Every participant:
starts recording their screen
Starts a fresh emacs instance with their config and loads a emacs lisp script that we provide for printing keypresses and recording keypresses + function calls to a log file.
download the prepared repo
run tests
investigate failing tests
fix them
commit their changes
The participant ends the screen recording session before sending me
- the video to me or youtube/dailymotion URL
- plaintext keylog history
- <optional> link to their elisp config
I appreciate logging keypresses/function calls might feel intrusive, so if you are uncomfortable doing that - don't! At the same time, if we want to share good debugging practices and general emacs tricks - I see this as the most impactful way to share techniques and elisp snippets.
I watch it, sumarise the findings and present a write-up.
Who is interested?
- AnonC 7y agoOP here, so I’m completely useless for this. It sounds wonderful. Whenever you get this done, please do a Show HN or Tell HN on this.
- petr_tik 7y agohey, it will be interesting to see how you would tackle the problem as well to compare emacs novices to proficient users.
- klibertp 7y agoI would be. You're not making it very easy to contact you - I don't have a Twitter account, and I couldn't find your email either here or on github, or on your page/blog. If you happen to see this comment (I'll add another with some thoughts on the matter), please shoot me an email (in my profile).
- klibertp 7y agoIn general, I avoid coding contests, especially if they focus on speed. This idea, however, caught my attention as something I'd like to both participate in, and obviously, to see the results. I'm a reasonably proficient Emacs user, and my config is (just checked) just shy of 5k loc mark. I would love to see if all the hours I put into writing that code make any difference. I'll have more comments later, but the first two, slightly related to each other, would be: 1. Are you sure using just one language for the code is a good idea? It's going to instantly turn off large segments of people who would otherwise like to contribute - no matter which language you choose. Further, "the most popular language" may not even be appropriate: there's probably less Java, C#, and C++ programmers who use Emacs compared to the general population. I think the first step here should be a poll to see which languages are actually popular among Emacsers. Once we have the list, we can prepare a couple of codebases using the top 5 entries (for example.) I think I can contribute here - I don't think there'll be a language I'm unfamiliar with on the list. I'm also reasonably confident that, in case the improbable happened, I'll be able to learn that language in a few days. (Assuming there are docs available and so on, the usual disclaimers :)) 2. Another consideration: how much time would participants have to prepare? I believe this is crucial. In my case, I have a bunch of "first-class" lang configurations, for the ones I spent the most time with, and "the rest," with configs just barely above bare-bones. If you give me a month, I guarantee I'll have all the possible tools you could use with the lang prepared, and I'll have quite a few hours of practicing their usage. If I had to go for it right now, and the implementation language happened to be outside of ~10-15 languages I use regularly or used extensively in the past - I don't think I'd be up for it. > Starts a fresh emacs instance Why a fresh one? Do you want to measure startup time (and later, performance in general)? But then people on the latest and greatest would have an advantage over someone working on a netbook. > a emacs lisp script I wonder if this wouldn't be better handled by an external tool. I don't know which, but it might be worth considering. > logging keypresses/function calls might feel intrusive You don't need keypresses - commands and functions would be quite enough. To be honest, I'd prefer a short chat with a participant afterward, maybe coupled viewing the replay at 10x the speed. What is valuable, I think, is the thought process behind the chains of commands, and "decompiling" those out of the "assembler" (key presses) of people's minds might prove quite hard. That's it for now, I'll be happy to talk more about the idea, though I think we should take the conversation off the HN. My email is in my profile :)