[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.

[capitainenemo]

Which is still the case. They use the hidden phase to avoid that. You can use hg absorb (also awesome) locally of course to simplify matters.

What censor is for is the case where something absolutely has to be removed from the repo, for legal or security. It allows you to do it in a clean standard way, even replacing it with, say, a key signed statement, without forcing regeneration of the whole repository or altering the tree in any way.

Just remove the contents while keeping the hash.

https://wiki.mercurial-scm.org/CensorPlan

[capitainenemo]

... and gotta say. mercurial will let you do hard deletes. They just discourage it and try to offer tooling that allows you to do what you want without destroying history / changing hashes / generally complicating life for those using the repo.

They also do have the tools to completely rewrite history if you really really want to.

So, "principled fanatic" is not quite accurate I feel. They just have a lot more options than git (which also applies to their commandline tooling I feel, although of course there's a lot of 3rd party stuff out there for git to mimic much of what mercurial has out of the box these days).

[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.

[addaon]

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

This seems like a pretty major lack of a specific piece of knowledge on the senior developers part, yes, but it seems like a much more unforgivable miss on the part of the code reviewers. Was the team stuck in a rut where only a single person (with coincidentally the same blind spot) was reviewing his code, or did multiple reviewers somehow miss this?

[llmblockchain]

Code review? There was no code review. We did get our own offices though!

[Waterluvian]

No rank means much. Not even degrees like a PhD. In fact I swear there’s negative correlation.

[epolanski]

I've worked with a consultancy that prouded itself by exclusively hiring top engineers from top universities and I swear, I can put my hand in boiling hot oil and tell you, they were some of the worst coders I've ever seen, I have no doubts I've met way more brilliant people coming from boot camps.

The fact that people study for exams has absolutely no correlation with how much they will remember or care for what they studied, none.

[malux85]

Yeah it reminds me of that old saying “Some developers have 20 years experience and some have 1 year experience 20 times” haha

[bubblebeard]

Titles really mean very little. The company I work at recently hired a DevOps specialist to help configure Docker services and assist with development. He was a decent developer but had no idea how to securely configure server side services. Still stuck with his mess two years later :)

[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”.