rio517
However, I fear they conflate "living wage" with desire for full time work in this metric. It also seem to so closely track the official unemployment rate as to not be useful.
Also, as others states, 26k is a surprisingly low number to be called a living wage. I think that number also varies depending on household make up, but I can see why they skipped that complexity.
I said "maybe think for a while on ideas and then give me a few options?" Opus 5 still just did the thing, while 4.8 gave me options. Same exact prompt and context. Really annoying.
I said "maybe think for a while on ideas and then give me a few options? " and Opus 5 still just did the thing, while 4.8 gave me options. Same exact prompt and context.
Tencent put out this study showing that Elixir seems to reign supreme: https://autocodebench.github.io/
At work, we use C#. I'm shocked at how much worse it is. I've also used a bunch of Python, but I still feel the quality isn't as good as the codebase grows, but I didnt put as much effort trying to improve it.
> Requiring me to churn out 3-5 features a week in the first 6 months is the best way for me to hand my resignation a mere two weeks after starting.
Elixir and Rust is a good mix
LiveSvelte – Render Svelte Directly into Phoenix LiveView with E2E Reactivity
Either way, the avg person productivity bit is rather subjective. I picked phoenix/elixir. It helps me be productive. Good for me. Maybe you'd pick something else that you can be maximally productive in. That's great! We're both productive! ... It isn't a zero-sum game.
Disagree with the advice your responding to, but I really don't agree with the premise of being a sloppy programmer... "Not sloppy" is faster at anything except prototyping. Coming from a different starting point probably has a lot to do with my different conclusions.
Edit: Grammar/Spelling
I eventually decided that the UI was too clunky to move my whole family onto and opted for 1password. Very happy with that choice.
Came to these comments to figure it out. The following important bit should be more obvious.
> In 2024 we will launch the first line from our Paris hub. This will lay the foundation for our ambitious plan to create a network of more than 10 destinations, each between 800 and 1,500 km from Paris.
I don't think he is a good marketer - he is more middle of the road. I think people say that to discredit him. Have you watched any of his full length presentations. He is terrible. What he is good at is having a vision he believes in. He sells that well.
Many of the problems are organizational/infrastructure challenges, not inherent to staging environments/setups. Straightening out dev processes and investing in the infrastructure solves most of the challenges discussed.
Their points:
What's wrong with staging environments?
* "Pre-live environments are never at parity with production" - resolved with proper investment in infrastructure.
* "There’s always a queue [for staging]" - is staging the only place to test pre-production code? If you need a place to test code that isn't in master, consider investing in disposable staging environments or better infrastructure so your team has more confidence for what they merge.
* "Releases are too large" - reduced queues reduces deployment times. Manage releases so they're smaller.
* "Poor ownership of changes" Of course this happens with all that queued code. address earlier challenges and this will be massively mitigated. Once there, good mangers's job is to ensure this doesn't happen.
* "People mistakenly let process replace accountability" - this is a management problem.
Solving some of the above challenges with the right investments creates a virtuous cycle of improvements.
How we ship changes at Squeaky?
* "We only merge code that is ready to go live" - This is quite arbitrary. How do you define/ensure this?
* "We have a flat branching strategy" - Great. It then surprises me that they have so much queued code and such large releases. I find it surprising they say, "We always roll forward." I wonder how this impacts their recovery time.
* "High risk features are always feature flagged" - do low risk features never cause problems?
* "Hands-on deployments" - I'm not sure this is good practice. How much focus does it take away from your team? Would a hands-off deployment with high confidence pre-deploy, automated deployment, automated monitoring and alerting, while ensuring the team is available to respond and recover quickly?
* "Allows a subset of users to receive traffic from the new services while we validate" is fantastic. Surprised they don't break this into its own thing.
My Unintentional Mentorship Lab Rats: Lessons Learned Mentoring Kids
We tend to keep more ephemeral project management stuff in our tracker or google docs and more long-lived content in our Notion tool. I'd be curious how your team balances that.