Hacker News Reader

Comment by harel | Hacker News Reader

I worked on Quartz for a while as a contractor. Hated every second of it. Python version was old (2.4 if I remember correctly when 3.x was already the popular version). But that wasn't it. It was the proprietary version of everything in the stack that got me. Proprietary ide, source control, libs etc. I noted that none of the others who have been there for years have any transferable skills that can cary them out of banking and into a startup for example. All were good devs but only knew quartz. I can say they were great quartz devs. The pay was great, but the work was soul crushing.

View on HN

> Proprietary ide, source control, libs etc

The reason this was a problem was that it meant investment was needed for each of these things, and as such fell behind.

The IDE fell behind most modern IDEs, presumably because it didn't get the budget for it. The source control/ libs where usually modified versions of existing libs, but now needing to be maintained internally to remain compatible with the mainstream versions (which, again, they did not, and so fell out of compatibility).

> any transferable skills

It puts you in a position of arguing that you are familiar with <some-lib>, just a modified proprietary version of it.. Makes those conversations a bit more difficult..

> All were good devs but only knew quartz

To be fair - this is their own fault. It's difficult providing proof in terms of "what you worked on in your last job"; but there's no reason a professional python dev couldn't become familiar with the popular versions of things on their own, given they are fairly close in functionality. Many of the quartz devs I knew already had backgrounds in Python, attended pycons etc; so knew more than Quartz.

Yes, it is their fault, but the organisation didn't even attempt to nurture professional development. Stagnation was a feature, not a bug. Arguably, these guys were paid very well so they would have taken a pay cut anywhere else anyway.

It's not just the "knowing some lib". It's a way of working that is not compatible with the outside world. I had every single character i type having to get director approval. I sopped counting broken things that required human intervention (on rota). The style of programming is... well.. . bankish? I would have had to take a big gamble hiring most of these guys.

I think this would have depended on the teams/individuals you worked with. I recall some devs being completely clueless about environments - my code (that depends on dozens of other files) in uat is producing different outputs compared to my code in dev, why? Some didn't know how to debug. Many went on to FAANG as senior engineers (including Uber when it was the next big thing), hedge funds (citadel, 2s), startups (twilio, is twitter still a startup?). And as far as python knowledge is concerned - I recall attending a number of python talks given by my former colleagues at Python conferences, various PEP discussions around whether a given PEP would help or be detrimental to qz. As a matter of fact one of the qz core engineers is now also a PSF core engineer. Quartz was polarizing, but there was/is plenty of talent among the engineers. P.S.: fwiw, when I left baml, the migration to 3.6 was nearing completion, and the migration to 3.7 was in progress. I guess at some point we realized python and qz were not going away, we must to migrate, so infra was built out to make future migrations easier.

I have no doubt the people who BUILT Quartz are top notch. Users of it... Mileage varies i suppose.

The builders/maintainers (AKA the "Quartz Core Team") seemed to have a poor view of the users (AKA the "Line of Business" development teams). Of course you wouldn't catch them saying that openly, but it was sometimes implied during interactions. I will admit, that view was not completely unwarranted.

I second your opinion (interned @ Athena, not Quartz) - compared to my current BigN experience everything was worse by a magnitude: the IDE, the source control, the review mechanism, the job scheduler and so on.

I'd expect with so many devs working on this the DevX will be ironed out

I wonder how did they make the IDE? Must be an interesting job for whoever got to write it, and hell for whoever is maintaining it and using it, lol.

Some questions are best left unanswered... :)

Reply on news.ycombinator.com