I had a similar experience, but I made the mistake of taking the job. I spent several months in denial about how smart people who act so... not smart. At one point, I asked the CTO for guidance on how to work with the team architect whose feelings I kept hurting. For example, I wrote a constructor for a class, and the architect asked me what "def initialize" was for, and got upset when I asked if they knew how OOP in the language worked. Another time they asked me for help on a weekend to figure a null pointer error on a machine that wasn't running the software they were trying to debug, and got upset when I pointed that out. I brought up both examples to the CTO. The CTO pointed out that the Architect had 10 more years of experience than I did, and while I might be right, I probably wasn't. Then the CTO said (direct quote) "you have delusions of grandeur about your technical abilities" to my face. I started looking for a new job immediately after that conversation. After I left, I heard the project got canceled, the architect got promoted, and they were hiring devs straight out of bootcamps because they couldn't attract anyone with experience.
I used to work closely with Quicken Loans and other FoCs and can attest that this behavior is commonplace. There is this strange culture within the Family of Companies where non-tech leaders think that tenured Quicken engineers and tech people are these sort of super-geniuses. Many years back I was a part of a company in the Quicken led start-up space. We were often "encouraged" to meet with Quicken or FatHead senior engineers for advice. One time I reluctantly agreed and met with "the best programmer in Michigan" who's first piece of advice was:
"Delete your app and start over. Ruby on Rails is trash. Real programmers use C#. With C# you can create libraries that you can reuse across all your apps."
While I don't agree with the way he spoke, was C# one of the de facto or explicit in-house languages of the company, and Ruby was not? If so, he may have been referring to the fact that the company already had many libraries in C# that you could use. Plus, if C# was one of their areas of expertise, it's typically best to use that as opposed to a new, unfamiliar language unless you're explicitly testing out a new approach.
Also, in general, for programming in the large, many experienced programmers, having worked on multiple large-scale software projects, tend to prefer statically-typed languages. We've found by experience that in such large-scale systems, major refactorings are much, much smoother and feasible in statically-typed languages (although unit and integration tests are certainly still needed). And a whole class of errors are eliminated.
I don't think RoR is trash, but if you were starting a large program that would be used across multiple departments whose in-house language was C#, it was probably the right call to suggest switching to C#.
Please note: I'm not a C# programmer, and have never done any work in C# (although I've worked many dynamically-typed and statically-typed languages, and have a clear preference for the latter for large-scale software projects). So this isn't something I have any personal investment in.
Finally, I do get it, working for these types of companies is misery for most programmers. I've worked in such companies. But in this case, the senior may have had a good point.
>While I don't agree with the way he spoke, was C# one of the de facto or explicit in-house languages of the company, and Ruby was not? If so, he may have been referring to the fact that the company already had many libraries in C# that you could use. Plus, if C# was one of their areas of expertise, it's typically best to use that as opposed to a new, unfamiliar language unless you're explicitly testing out a new approach.
[...]
>I don't think RoR is trash, but if you were starting a large program that would be used across multiple departments whose in-house language was C#, it was probably the right call to suggest switching to C#.
According to the parent comment, he was working at a startup that was in the "Quicken led start-up space". My interpretation is that Quicken was acting like an incubator, and he isn't working in quicken, and so the engineering teams are separate. Therefore I don't think organizational inertia applies here.
This is correct. Our company was under the Quicken "Family of Companies" umbrella, but we were a 5 person start-up building a web app unrelated to Quicken.
Yikes. I worked on a team whose de facto tech lead (it wasn’t explicit because we were “flat”) had no idea what SQL parameter binding was (I had to explain why interpolating strings in SQL queries is dangerous). And we apparently went to the same university and got the same degree, and he had at least ten years of “industry experience”.
I’ve also had to explain why logging is a good idea and how to use SSH. What frustrates me isn’t that people don’t know these basics (nobody is born an expert), but that people get hired to do a job for which they lack core competencies. If your job is to fix engines and you don’t know what a spark plug does, you probably shouldn’t be fixing engines. This was at least an issue for me. I know people at Quicken proper who have told me even more ridiculous stories.
It’s a shame. Detroit’s got a lot going for it, but I think most of the tech companies there have some connection to Gilbert and Quicken, and no amount of coneys will get that taste out of my mouth.
I dodged a bullet indeed. Out of the dozen other devs there, there was exactly one person I'd care to work with again. They got pushed out a month or two later, and post-shenanigans felt infinitely better.
My advice is to do what you gotta do to pay the bills, but don't delude yourself into thinking that a crazy sauce employer will change its ways because you try extra hard to change them when they resist your attempts to do so.
