no_good_names_avail

joined 1 year ago
[–] no_good_names_avail@alien.top 1 points 11 months ago

Product. To be fair to project managers it's even more nebulous than our role. I have only worked with one project manager who was invaluable for my day to day. Sadly didn't get to work with her for long but would jump to do so again.

[–] no_good_names_avail@alien.top 1 points 11 months ago

I'd agree but it goes a bit beyond. Each file has pointers to the source code that is locally checked out. Sure it's not dynamic (e.g. my comments and understanding of what's going on don't sync with the codebase as it changes), but it still allows me to keep a mental map of what's going on and where each piece of the pipeline resides.

It's a mixture of roam, literate programming and an IDE for me. E.g. I can easily spin up a vterm, ssh into a spark node and test some of the code if I don't understand what it's doing thoroughly or to check if something isn't doing what is intended.

In my use case, collaboration is not required. I'm doing it for me so there's no real cost to the documentation and understanding getting out of date. I find emacs an invaluable tool to deepen my understanding and test things in the codebase. An IDE just doesn't fit the bill in that regard.

[–] no_good_names_avail@alien.top 2 points 11 months ago

Haha, why is that? To be clear that's not an expectation of the job. It's a self imposed process so that I understand wtf is going on. I enjoy it personally and feel it makes me better at what I do. Why do you think it's bullshit?

[–] no_good_names_avail@alien.top 1 points 11 months ago (12 children)

First I wouldn't concern myself too much with trying to explain what differentiates Emacs from an IDE. Life is too short to get into such debates. I can't really summarize why anyone should care about Emacs vs their IDE of choice.

For me what separates Emacs from vscode for instance is not the IDE aspects but the integration with the broader ecosystem. I'm a PM that works with technical and data heavy products. The details matter. I frequently walk through the pipelines and code of my product to understand how it is implemented by the team(s).

For example you can break my underlying product down into 3-4 large blocks of pipelines. Each pieline has 6-7 stages that mix Spark and other Python jobs. For each pipeline and stage I have my own little literate org file that points to code, has small samples of inputs and outputs, and generally speaking allows a non data engineering professional such as myself keep up with people that are far better and keeping this all in their head.

I write down questions as I do this to browse and/or raise with the team. I can, when questioned by our senior leadership, truly explain what it is our team did and the impact it had.

I can't do that with an IDE. I can't see an easy way to do that with any of the other note taking tools. I can't jump between code browsing, executing and writing as seamlessly anywhere else.

I started with Spacemacs. Switched to Doom. Switched to my own vanilla emacs for a year or two then went back to Doom.

I find Doom's defaults well thought out. It just works (insofar as Emacs just works). It has sane default bindings and I can just use emacs to get my job done. There's nothing inherently noble about rolling your own config or choosing a particular kit. Just try them out and see which you enjoy.