MTA is an Alaskan ISP serving the southwest area of the state. The software team consists of 7 devs who support a relatively complex business enterprise environment. We're looking to add another Software Engineer and a dedicated Systems Engineer (DevOps) to our team.
As the hiring manager I want to be clear about a few things:
- This is a 70 year old enterprise telecom, not a high speed startup
- This job may interest you if you want great benefits and long-term job stability
- We have an existing environment running onsite on VMWare; the Systems role is designed to support, improve, and make adjustments to our tech stack over time
- Our core backend language is F# these days (replacing Haskell after 5+ years in production), frontend is React
- Our DevOps tooling is built around Terraform, Chef, Nomad, Vault, Concourse CI, Sensu, Prometheus, etc
- Must be authorized to work in the US
Software Engineer: https://mta.csod.com/ux/ats/careersite/4/home/requisition/59...
Systems Engineer: https://mta.csod.com/ux/ats/careersite/4/home/requisition/60...
If the team had been full of diligent Haskellers they'd have stuck with it, but they aren't really the type to align with a language/paradigm, and so a slow pivot into F# was decided ~2 years ago via a well documented RFC process.
I'm personally still a Haskell fan, but my hand isn't on the keyboard anymore. Not my place to make the tooling choice for them.
No one above me cares about this type of choice since we're a small backend department to internal customers. As long as the team is delivering results by the deadlines we commit to we get a lot of freedom to use whatever tooling we think makes sense.
I think those are the things we really wanted to hear from you about!
I'm actively working on improving the Haskell ecosystem. I'm aware of a lot of "typical ecosystem problems" that cause challenges for onboarding of new Haskell users but I'm not actually aware of many problems for users who are onboarding and generally successfully using Haskell. I suppose general tool cruftiness might be one of those but I think it's a much bigger problem for new users than experienced users.
If you could mention the problems you ran up against I would appreciate it.
- Poor ecosystem fit for an enterprise environment. We weren't willing to write libraries for some of the things we needed to support: DB2 access, SOAP, etc. Ended up writing C# wrapper services for a lot of that early on
- Poor library ecosystem in some cases. What felt like a good choice would be unsupported a year later
- Perhaps our own fault for committing to using Reflex for a heavyweight frontend. The team did an amazing job, but supporting GHCJS, the tooling around it, and trying to get faster dev iterations became a huge drag on the team
- Indirectly had to support it due to Reflex, but Nix. It's another rabbit hole that requires collective interest and a willingness to peel back the layers to make things work. Was another drag on the team
At the end of the day I'd say the biggest problem was cultural. I firmly believe that in order to have a successful Haskell environment, you need devs committed to the language and would label themselves "Haskellers". My team learned it and became expert engineers, but they are by no means Haskell language pros who thoroughly understand the inside outs of the language and its myriad of extensions. It's just a tool to them and they only used as much as they needed to.