upvote
At a company I work for, they are doing various changes (and control) over the software we install as we transition to a larger company. I believe they are using Microsoft Intune so they can allow/deny what can be installed.

I have not updated my laptop (or got a new one) because I am concerned they will not allow me to install or continue to use Emacs. Honestly, I can vision how that conversation goes:-

[manager]: Hi, so what is Emacs

[me]: Emacs is a text editor I use daily and makes me efficient in my work

[manager]: OK. I would like us to start using Visual Studio Code with the new projects coming up

[me]: Why? The consumption models we are using has no VSCode support, anyway.

[manager]: It would just be good if we are all using the same tools

[me]: It should not matter what we use as long as we work with git and deployment. If someone else is great with a different text editor why force them to use something else?

[manager]: (Looks up emacs)

[manager]: I think its best we stopped using it because it is not supported by Microsoft and we need to be careful with the dangers of open source.

[me]: OK. Should we contact other IT departments to replace any open source tools they use?

[manager]: Its just emacs is not verified software for the business. I think you are complicating things a little (tries to belittle me)

[me]: Emacs is my daily driver! If it goes, I will hand in my resignation!

* Manager is not there to understand or reason.. he is just following orders from other IT departments. *

reply
I worked briefly in public administration at one point in my career. I asked the admins the same thing, could I get Emacs installed on my machine. I got a bit concerned when the admin staff asked back: "What is Emacs?"
reply
I was a bit surprised when about ten years ago I noticed that there were now really only two reactions to my Emacs use:

"Emacs? What's that? Oh, sorry, I like things with an actual UI."

Or:

"Emacs? I remember that from my DEC days. I'm surprised it's still around!"

reply
I scheduled my intune upgrade when I needed a week off for doing house moving stuff. I was told Emacs would work, didn't. Took them about a week before I could use it again.
reply
Back in the day when i had a windows laptop for work you could just download the windows binary distribution of emacs and run that, has something changed?
reply
This is what I do when I use Windows. However, in recent years, I tend to use Emacs via WSL.

However, I believe Microsoft Intune is used within the Business to control what software can and cannot be installed. So my guess is Windows won't allow you to install via a typical .exe

I am not suggesting the above is 100% valid. I just don't want to get a new laptop and find out. Maybe I can still use Emacs via WSL... bypassing Intune????

At the end of the day, I understand Security is getting much more serious in recent years - and we even have a dedicated department - but controlling the software to install is crazy, especially for a development team.

reply
Does Intune stop you from running any unapproved .exe's? Because IIRC Emacs can run as a "portable" executable that doesn't need to be installed in Program Files.

(I don't have any experience with Intune so pardon my ignorance.)

reply
[dead]
reply
> Their argument is that all team members should use the same tools, and I guess that is a valid point.

Not really. If they mandated all team members use telnet instead of ssh, would you say their position is valid?

Anyway, the important thing to learn is "You're not supposed to ask if you can use Emacs. Just use it!"

Incidentally, do they have a mandated general text editor? And if they do, will you get in trouble for firing up Notepad?

Do they have a mandated TODO tool (for your own tracking of work, not something like Jira meant for the whole group)? I've yet encountered a place that did.

Basically, find some category that Emacs does that they've not mandated, and then install Emacs and tell people you're using it for that category :-)

reply
Having everyone on a team have different personalities is managerially inefficient. You have to deal with each team member in a different way instead of being able to have a unified emotional approach. So we required frontal lobotomies for everyone on the team.
reply
Emacs users (myself included) would feel less like cramming every aspect of our work into Emacs if more tools embodied the freedom and hackability that comes with using Emacs. It's not that Emacs is better, it's that other tools are more restrictive and not self-documenting.
reply
It's also helpful that you get a certain degree of UI consistency from things like completing-read being used everywhere. And even when some package departs from convention, everything is still a buffer, so anything in it is easy to reuse.
reply
> Their argument is that all team members should use the same tools, and I guess that is a valid point.

Why is that a valid point?

reply
In my case, I am a very senior member of my team so 25-50% of each day is spent helping and/or teaching teammates. In situations like that, it is useful to be deeply familiar with the tools that your teammates are using so you can tell them exactly what to do.

For example, if I'm teaching a new hire to set up their vscode it is not very helpful to tell them "now you need to activate the python venv". It is much more helpful to be able to tell them "Now we're going to activate the python venv. To do that, open your command palette and search for 'select python interpreter'".

In my personal life, I still exclusively use emacs (which I have scripted to auto-detect venvs) but I put up with using vscode at work to be a greater utility to my team.

reply
When I've been in that position, I've just trusted junior folks to figure out the tooling-specific way to do things like that, and it's worked out perfectly well. If anything, it leaves people happier and learning more.

And, instead, I can focus on the fuzzier, higher-level things that involve non-trivial tacit knowledge rather than things somebody can resolve with a Google search (or just ask Claude).

reply
Idunno. I think you end up teaching them nothing and just doing it for them. I mentor plenty folks without learning more than basics of vscode/cursor, and the most important lesson for them is always how to figure out how to do stuff (which has never been easier than today).
reply
Yeah, I kinda feel like when you're mentoring people, you should let them drive. If you're going to do it for them, you might as well just record a training video.
reply
I can somewhat sympathize - I guess the debatable aspect is to what extent should you teach?

If someone knows no development tools, then yes, it is good if someone in the team knows Visual Studio Code and can guide them. In my previous job, another senior person knew it and helped out (VSCode was not mandated, and they were free to use some other tool).

I tend to focus on training people on the concepts (code navigation, debugging, version control, etc), and tell them that they're free to use whatever tool they like, but it's on them to learn how to use those tools to apply those concepts. I usually recommend VSCode and tell them there are plenty of videos/sites that explain them.

Then if I see them doing something very inefficiently, I do a quick Google search to see if the more efficient approach is supported in their tool and send them a link.

It's important to hire people who can learn on their own (with guidance on what to learn).

> For example, if I'm teaching a new hire to set up their vscode it is not very helpful to tell them "now you need to activate the python venv". It is much more helpful to be able to tell them "Now we're going to activate the python venv. To do that, open your command palette and search for 'select python interpreter'".

Inspired by a submission some years ago on HN, I came up with a different approach in my last job.

Everything the team did (including onboarding), had to be done via a just[1] recipe. No longer did we rely on outdated docs. just recipes, by definition, cannot be outdated because then we wouldn't be able to do our work.

For onboarding, we had recipes that automated as much of the configuration as possible. For things that required manual work, the recipe would print instructions, and prompt the user to press Enter when they had completed the task.

Sure, onboarding stuff can go stale as people don't onboard often, but we had a policy that if any senior team member had to help a newbie because the recipe was broken, then the senior member needed to fix the recipe and check it in.

I left the job, but I still talk to some of the folks there. They still love the recipes.

[1] https://github.com/casey/just

reply
At some point, shouldn't installing a venv be a pre-requisite to actually be hired as a dev?
reply
That was just an example.

The point of the parent is that in an ideal situation, where everything works without flaw, theoretically it makes no difference which tools everyone uses. In real life, you having a homogeneous setup across a team makes the sysadmin's job a lot easier.

reply
deleted
reply
What about the job is so good as to make you tolerate this?
reply
Taken a look at the job market lately? Unless you’re like the top 1% (which most people aren’t), it’s extremely bleak.
reply
> Their argument is that all team members should use the same tools, and I guess that is a valid point

No. That's only a valid point if something about the tool must be shared between users, rather than just the output. Emacs is a text editor. It reads, modifies, and produces text. The correct tool for each team member to use is the one they're most productive with, full stop.

Jesus fucking Shiva while Odin watches, but I hate corporate management "thinking". It's just become more and more brain-dead over the decades.

reply
... how would they tell?
reply
By looking at my screen? But also, why would you disobey a direct instruction from you super?
reply
> why would you disobey a direct instruction from you super?

Because the instruction was stupid, based on marketing instead of utility, or otherwise given without any thought to how it impacts the actual day-to-day work of their subordinates.

Why WOULDN'T you disobey a stupid instruction? What's the difference between "stop using this tool you're productive in and switch to this one that you're demonstrably LESS productive in for no reason other than I heard it was a good idea", and "Go strap some rocks onto your ankles and swim the English channel. I heard that was a good idea."?

reply
[dead]
reply
> But also, why would you disobey a direct instruction from you super?

Because they disobey their superior (and if they don't, recurse).

But yeah, if I were new to the job, I would wait until I'm fairly competent before playing those games.

reply
deleted
reply
> Their argument is that all team members should use the same tools, and I guess that is a valid point.

Why?! It is a text editor for crying out loud. If you are more productive using the tools you want, don't cost anything to the company and doesn't force your colleagues to adopt your workflow, you could be working with notepad for all I care.

reply