Parent poster a-french-anon may be wrong or at least is making unsubstantiated wishful claims about costs and benefits - "the errors would be extremely rare" - would they really? And would they be evenly spread over in-groups and out-groups?
But at least the question "how is that acceptable?" is in fact a question of a moral nature. It's unacceptable, but it is unacceptable because it is immoral.
How is any error rate, no matter how small, acceptable when it comes to locking people up for the rest of their lives?
While I don't like the death penalty I don't think it's that different from a very long sentence. I don't think it makes sense to say that any punishment needs an absolutely perfect error rate.
I agree with most of this list, and I'd add some kind of null coalescing or ternary operator, even if it was limited to one operater per expression, and a date time handling library that doesn't make me want to pull.my hair out.
There's several things that keep me on Go, single binary, decent built in tooling, and decent speed.
I've started playing around with tinygo on Pi Pico's, and after the dealing with getting C and C++ onto other MCUs it's a breath of fresh air.
But the rough edges are very rough. At some point another language is going to come along with better syntax with the same single binary and good tooling and I'll probably switch over as fast as possible.
Alongside the other reasons mentioned (comfort, right of ways, dedicated corridors), it's blatantly obvious where trams run due to the tracks in the ground.
With a bus, there's always the potential the route has changed, or your specific bus is skipping over your stop for some reason. With a tram, even if you've never been to that city or part of the city before, you know there's going to be a tram along those tracks, and you simply need to walk along the road till you find the stop.
I've run various meetups in the past, some of which have been successful, some not.
The biggest thing I learned was that you if you start it, you have to drive it. If you take a few months off, don't expect anyone else to pick it up and run with it, even if they offer and you give them the keys to do so.
Nowadays I don't have time for anything too involved. Instead of meetup.com, I "run" a small private group (which is me with a mailing list and a google calendar invite) of remote IT workers in Inner North Melbourne (AU) who catch up for beers once a month (email in my profile for details) It's surprisingly better in some ways. The group is tighter, and there's far less stress.
> Usually any given country will have one big spot for tech... ...My guess is that Melbourne is not a very good spot.
It's not an unreasonable assumption, but in this case it's incorrect. Sydney has more tech work, but only in proportion to its larger size.
That said, Melbourne tech work is very heavily (but not exclusively) orientated around finance, insurance, real estate and so on which is not everyone's cup of tea.
I've clocked ~40 years in Australian tech and managed to avoid all of those domains, web development, cubicle farms, and nearly (but not quite) office politics.
Could be why I still have all my hair and good health.
> Could be why I still have all my hair and good health.
If you just mean in regards to stress, then working tech at an insurance company is a pretty low-stress job from my experience.
Finance can be pretty low-stress too in certain sectors. Like I've been working for a wealth management and investment analysis company, and haven't worked more than a 40 hour work week in years, with lots of flexibility during work to go to appointments or run errands, and while we have sprints, they're very malleable, and the real deadlines are more on a quarterly level, and they try to be conservative with their quarterly goals to make sure they hit them.
Now if you meant as far as life fulfillment? Yeah I get that. But I at least have some other things outside of work I can pursue.
More that I've never been much of a fan of working in offices, I like the outdoor life and have done a great deal of coding "on the move" while transitioning old paper mapping systems to WGS84, building and field testing exploration geophysics instrumentation, aquisition and processing software, tagging and tracking trucks and animals in mining and agriculture, and building energy and mineral resource intelligence systems for use and then sale.
I've even managed to squeeze in some work on Cayley|Magma in Sydney (long ago) which is kind of fun as it still seems relevant today, being used to crack Quantum crypto candidates.
I've had burst of planes, trains, and automobiles with a lot of travel about the globe, which I've enjoyed, and long stretches of working from home since I started in the 1980s .. circles and arrows on the back of envelopes, coding and then working in sheds, building etc.
Doesn't work as a lifestyle for everyone but it has for me.
No that sounds awesome, and much more interesting than what I'm working on. Congrats!
I am working from an office, but at least it's a home office. I can crack a window for fresh air, and look out at the prairie beyond my backyard from my office window. When the weather is nicer I sometimes start the work day out on the patio.
> I've never been a fan of TDD and personally I think tests that really hit your DB, Redis, etc. help a lot more than mocked out unit tests or a billion unit tests and nothing else... ...but I do really write to the DB and other data stores in tests
I've come to the conclusion that the idea that "unit tests" should test functions/objects in isolation with completely mocked dependencies is based more on the slow speed of those dependencies in the past than what actually makes for good tests. Now that we have faster computers and storage devices, and easy/fast store creation, we should move past this.
Obviously, this is very dependant (no pun intended) on the dependency in question, but as a minimum, anything with SQL should have a test that hits a real SQL DB (PG in docker for example) at some point.
It's not even about faster computers and storage, but just about better test techniques, and better written tests. You don't actually need very fast hardware for fast tests; you just need to spend some time on it. And roughly know what you're doing.
External dependencies (such as PostgreSQL, Redis, what-have-you) are a pain though. I feel pretty strongly that just a single command ("go test", "cargo test", "npm test", etc.) should run all the tests on all platforms, reliably, with a minimal of fuss and messing about. Things like docker-compose or whatnot quality as "a fuss and messing about".
They can be a bit of a pain, but if you have a lot of logic tied up in your external dependencies (SQL usually bring main offender here) it's not possible to properly test without using said dependency.
That said, in the current job, we have a dedicated Postgres container that comes up with with a just file command. The setup, test, and teardown of schema all happen within the standard test system of the tested platform (pytest or go test specifically).
> > Even with good design, w/o tests you will fear change and so the code will rot. With good tests, there’s no fear, so you’ll clean the code
> Has anyone ever actually found this to be true?
Yes, but you have to have the right kind of test coverage, and that's the tricky part.
Yesterday, I refactored a bunch of functions that changed a bunch of unit tests. However, since we also have integration/system tests on that code, I'm confident that I haven't broken the code as a whole. Without those system tests, I would not have confidence that the change would be successful, and probably would not have refactored.
In another codebase that hadn't been touched for a year, as part of a feature change I refactored an SQL statement to what I thought was a more optimal design and immediately broke a bunch of tests. Based on that, I was able to understand the original intent of the SQL, and updated it in line with the feature change. I added test scenarios for the new feature, but left the existing scenarios as is.
Without those tests, would have broken the system in a subtle way.
What if the sentenced person is actually innocent? No amount of apologies or recompensation will bring that person back.