[llmblockchain]

I've been that person a few times.

1. The only developer on the team with Github and put forward the idea of the company not hosting their own source code with TFS.

2. The only developer using branches with git when the co-founder asked (demanded) everyone to only use master.

The list goes on!

[capitainenemo]

Given the various accidental leaks dues to people not realising deletion still has a history with git when publishing (not to mention git has no equivalent to mercurial's "censor" operation), or people confusing public and private repos on their github accounts, or even the story just last week here on HN with counterintuitive behaviour of forking in terms of privacy (https://news.ycombinator.com/item?id=41060102), I can totally understand a company being opposed to being on github.

Perhaps you should have proposed anything-but-TFS (git/mercurial/even svn - no need for distributed in a small company... https://www.bitquabit.com/post/unorthodocs-abandon-your-dvcs...) but internal.

Might be a relatively easy sell if you just setup a local migration of their data to repository with a decent web gui for viewing the commits and associating with tickets, given my experiences with TFS in terms of slowness, and crashes/data corruption.

[vintermann]

> not to mention git has no equivalent to mercurial's "censor" operation

Haven't followed that for a while, but it used to be the case that it was Mercurial who was principled/fanatic about never rewriting history, ever, while git happily let you mess up with hard deletes.

[malux85]

Here’s a few of my horror stories where I was a consultant at various companies:

1. Previous consultants left no documentation or anything, and a running Hadoop cluster handling (live!) 300 credit card transactions a second. Management hired 8 junior sysadmins - who were all windows sysadmins, had never used Linux before, and were expected to take over running this Linux cluster immediately. They all looked at me white as ghosts when I brought up SSH prompt, that’s the point where I learned they were all windows sysadmins.

2. Another company: all Java and MySQL developers who were trying to use Spark on Hadoop, refusing to learn anything new they ended up coding a Java app that sat on a single node, with a mysql database on the same node, that “shelled out” to a single trivial hello-world type function running in spark, then did the rest of the computation in Java on the single node, management celebrated a huge success of their team now using “modern cluster computing” even though the 20 node cluster did basically nothing and was 99.99% idle. (And burning huge $ a month)

3. Another company: setup a cluster then was so desperate to use the cluster for everything installed monitoring on the cluster, so when the cluster went down, monitoring and all observability went down too

4. A Cassandra cluster run by junior sys-admins and queried by junior data scientists had this funny arms race where the data scientists did what was effectively “select * from *” for every query and the sysadmins noticing the cluster was slow, kept adding more nodes, rather than talk to each other things just oscillated back and forwards with costs spiralling out of control as more and more nodes were deployed

Any many more!

This might sound like I’m ragging on juniors a bit but that’s definitely not the case - most of these problems were caused by bad management being cheap and throwing these poor kids into the deep end with no guidance. I did my best to upskill them rapidly and I’m still friends with many of them today, even though it’s nearly 10 years later now,

Good times!

[llmblockchain]

"Senior" holds no weight with me. I've had plenty dumb founding conversations with "seniors".

My favorite was at the company that was self hosting their code. The senior team lead wanted me to help him find a memory leak that plagued the product for months. Customers were told to restart the application every few weeks (this was a C++ application).

I sat down with the senior and looked at the code. I spotted the error.

I was like, "You know when you do new[] you need to use delete[]?" as all of his deletions were without [].

The look on his face was the best.

[baq]

> 2. The only developer using branches with git when the co-founder asked (demanded) everyone to only use master.

I’d argue everything else becomes expensive quickly.

…but it is also imperative to remember any modification on checked out code is a branch, technically, regardless of the version control system used. This becomes important if your testing is expensive.

[rblatz]

There are advantages to trunk based development, not exactly only using master, but close enough that you could probably spin it to comply.

[chris_wot]

What would stop someone creating a local fork in git, then do a merge fast-forward to the trunk and then push their commits and not the fork?

[MBCook]

A friend’s company was still doing it (in SVN) as of late last year. Quite possibly still are. It’s “what they’ve always done”.