1,706 karma · joined September 18, 2014
We use this process to make some of the harder more nebulous decisions that require a bit of research and investigation from the entire team. While it does suffer a little from "decision by committee" we haven't ran into it as a problem in practice.
It's a great way to give people a chance to try and introduce new technology, processes, or paradigms. If they're committed they'll get the entire team excited and involved. If the team isn't interested it doesn't make it to the end of the process - and that's ok!
- 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.
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.
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...
I assume you are pointing out that split-teams is the insane part, in which case I agree. The philosophy was supposed to define the blurred line between developers and operations, using tooling to help facilitate the shared responsibilities where sensible and make hand-off a breeze.
As you pointed out, the division existed 20 years ago, and it still exists now at many places. That lack of integration doesn't offer much improvement in relation to the past.
[1] https://blog.unity.com/news/plan-pricing-and-packaging-updat...
This is the route I've taken and my mental health is much better for it. I still wonder what I'm missing out on had I stayed on the treadmill, even now, but I keep telling myself the life balance far outweighs the work balance.
A good chunk of our world is Microsoft .NET, so we have legacy C# applications lying around. Several years ago we wrote some new systems in Haskell and really enjoyed the FP experience but not the ecosystem. F# moves us closer to the business world while maintaining the FP experience we enjoy.
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
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...
Can confirm. Worked for two Japanese mobile game companies that drove themselves out of business as they strove for headcount over production value.
Why not? Seems like the start of the path to post-scarcity civilization. Once nothing has value and everyone has everything I'd say that's a win.
I'm going through a huge pile of resumes for a role I have open this week and these are getting thrown out immediately. I have no interest in reading through 6 pages of bullet points with keywords bolded. It's tacky, too information dense, and doesn't call out what you are actually good at nor how you've applied it.
MTA is a rural Alaskan coop ISP. The software team consists of 8 devs who support a relatively complex business enterprise environment. This role pertains to the platform/delivery portion of the workload, including the configuration and support of Chef, Terraform, Nomad, Concourse, Consul, Vault, Sensu, and Traefik.
As the hiring manager I'll be perfectly clear about a few things:
- This is a 70 year old enterprise telecom, not a high speed startup
- Our salary range can't compete with pure software startups; I am not allowed to disclose it here unfortunately
- This job may interest you if you want great benefits and long-term stability
- We have an existing environment; the role is designed to support, improve, and make adjustments to it over time
https://mta.csod.com/ux/ats/careersite/4/home/requisition/56...
Time and money spent working with cybersecurity professionals writing SOG/SOPs which map the business practices to the standard. Money spent buying and setting up some of the necessary equipment to handle CUI properly. Time (indirectly money) spent redoing decades old business processes to map to the new paradigm. Time (indirectly money) as the business spent time training their staff up on the components relevant to their business units.
I agree that building a culture is at the root of it, however, that culture alone isn't going to move the needle unless everything else is in place as well. Worse, you have to walk the company through the 5 phases of grief because in general people don't entirely understand what is actually going on and why it's important. "So you can get government prime contracts" is an easy answer, but doesn't erase the confusion behind all of the hand-wavy procedural work required to execute them.
f x = reverse (sort x)
Becomes: f = reverse . sort
The compiler reaches the same conclusion either way.Perhaps you are thinking of RULES pragmas? Which honestly you wouldn't usually reach for unless you really need to force the compiler to optimize in a particular way that is non-trivial.
Look at the big tech layoffs earlier this year - they were letting both the cruft and top tier talent go. Is it easy to say you are truly safe where you are at?
No one will remember or care about your title, your salary, or the effort you put into wherever you work. Your next employer will have no insight into any of that at all outside of your interviews; they'll measure your worth on the job unless you are a world class snowflake.
I'm not saying don't continue to learn and excel! But there's more to life than your day job. Spoken as someone who discovered way too late a proper life/work balance.