It assumes that "Skill" is a 1d value. But the ability to write quality code and the ability to debug are a bit orthogonal.
Being better at debugging doesn't necessarily makes you better at writing less complex, more approachable code. Though debugging should teach you which patterns cause bugs or impede debugging.
And what do you do once you are so skilled your software doesn't have bugs? :P
I can't say about France. But in Switzerland, there is a "three strikes" system where if you are caught with drug, the first time you have a $100 fine; Then a higher fine, called "Day-fine" which is proportional to your income; Then maybe, just maybe, a jail sentence.
Comparing that to the US, where if you get caught dealing marijuana, you get a 5 years minimum sentence. That seems disproportionate to me. Maybe police in the US is more compassionate than some militants make it seem, and that's why they don't like catching people for that kind of crime?
Looking at Wikipedia[1] it appears the number of policemen per people is two times higher in the US than Switzerland, and about the same as France. If it is true that "the police are plentiful and they come down fast" in Switzerland (which I would not agree with), it is twice as true in the US.
> Comparing that to the US, where if you get caught dealing marijuana, you get a 5 years minimum sentence.
That is literally no state in the USA, discounting the states (like the one I live in) where marijuana is legal.
I had Switzerland swat come down hard on me just because I wasn't registered correctly in the apartment I was living in when I was staying in Lausanne. You don't screw around with swiss cops.
Diaspora is a book for Math PhDs, involving a lot of physics and math theories. Accelerando is a book that anyone can read. Involving hyperintelligent cats and sentient shrimps (actual shrimps, not aliens).
I would recommend it not just for the philosophical aspect (it has a very interesting way of placating transhumanism) but also for the entertainment aspect (aforementioned shrimps, did I mention the Iranian space program?)
Stross is a very approachable author, Accelerando is not his most accessible book, but if you can go through half of Diaspora, you can easily go through the entirety of Accelerando.
I don't mind technical fiction, and I love a good hard scifi, but I guess the part of science I am most interested on (when I read literature) is the psychological one - Blindsight is by far my favourite sci-f. However I am totally up for trying Accellerando, so thank you for the reccomendation, you sold it to me :P
Yoo, congratulations to the author for going from this blog post dated to October 2023 to shipping an actual rust crate (bevy_light_2d)!
I suspect the author might be reading this post back and cringe a bit. That last code listing with handle_session_completed triggers my inner clippy. Why clone session.customer_id to then pass it as a reference? Why are those CheckoutSession fields Options?
The other advice I would give is to identify what the author calls "Service" as what is called "view type" or "newtypes" in rust. A newtype wraps another type, to give it a different set of methods. For example, a counter could wrap an i32 and only allow incrementing and reading the value. Or put together a set of references to fields/slices of a struct.
It can be useful, but the way it's used by the author here is not very rusty, and the final suggestion of using a function is a descent alternative. Although I think defining handle_session_completed as a method on CheckoutSession or UserRepo might be better.
If you are interested in creative voter coercion, and generally very creative ways of changing law so that the election results always end up how you like them, I recommend reading up on the very innovative Hungarian system https://www.journalofdemocracy.org/articles/how-viktor-orban...
> “Chain voting” ensures that people vote the right way. Voter 1 goes into the polling station,
> appears to vote by depositing an empty envelope into the ballot box, but comes out with a
> blank ballot. Voter 2 is then sent in with that ballot—now marked by a [party] operative—and
> told to put it in the ballot box and exit with another blank ballot in hand. Carried on down
> the line, the [...] party boss in the town can ensure that all have voted the proper way
> while the election workers find that they are short only one unaccounted-for vote
Wow, this is exactly how I felt with regard to my first job as well. This old codebase no one wants to touch but works somehow. The quite nice later-on additions. Even the "build a pipe-separated string using reflection and a 150 classes hierarchy" rings something.
The old codebase was an hairy ball of scala using a very outdated version of a (now) infamous actor framework. Before they figured out that untyped messages kinda left out one of the major selling point of Scala.
The code was readable, but the authors had this strange idea that every little piece of logic should be part of its own "Actor". An actor is pretty much equivalent to a class, and each one of them had their own little file. With this many classes, with very specialized purposes, you ended up with 90 character identifier names.
To understand what would be a single function in a normal code base, you would have to dive through half a dozen files through several repositories to piece together the logic. Generally, at the end, you find that most of the code is about passing around a value, and there is this one file where there is actual logic applied to the value.
It wasn't that awful. The thing was that it was impossible to change anything: no documentation, no test, no bug tracking, not even any PR process, laconic commit messages, no Wiki pages. And the actor framework made it very difficult to add tests. But later developers did manage it pretty well, they drew fences around the old services, with an HTTP API to communicate with it. And all later additions were part of different services that were very cleanly and consistently designed.
> To understand what would be a single function in a normal code base, you would have to dive through half a dozen files through several repositories to piece together the logic.
I've experienced something like this, where the other devs preferred to breakecode down into the smallest units possible. I often saw a half-page procedure changed into multiple function calls, each with their own boilerplate and error handling (as required by the style-guide), such that you could not view the entire logic on one screen.
Every procedure name described the intent, they said, so you know what the parent did without having to worry about details like how it did it. I, meanwhile, trying to track down what the actual implementation was, would hold as many subfunctions as I could in windows with a tiny font, and hold the rest in my head…just to find out stuff like:
"Oh, so it's trying to use system feature foo.x, but I know foo.x is broken current release for a certain edgecase. Which case happens to be what our customer does all the time…"
When your text editor is not enough for a task, and it hopefully is extensible, consider writing little plugins to reduce repetitive tasks.
Here is an example. I was working with a legacy code base using an infamous Scala actor framework. Basically, all function calls were replaced by message passing. All messages were sent as 'Any' objects, then downcast to the expected type, so an IDE wasn't of much use. I wrote a little bash script to populate a jump buffer in vim with the result of a grep, and suddenly, I had jump functionality! Originally, I had to jump to type definition, hope that the associated "received message" type was in the same file, then look for downcasting into that received type. I don't remember precisely the details, but what I do remember is that the little script helped go from a few seconds to just pressing two keys to navigate the code. It's especially useful for legacy code, where the main activity associated with it is reading and understanding.
Our capacity to focus as humans is limited in time and energy. Writing tools to do in half a second what otherwise would take a few seconds can help, not only to make you faster (for that, refer to xkcd 1205) but also to effectively increase your capacity to focus.
Though being able to develop your own tooling is less important today. Languages and frameworks nowadays prioritize tooling as an important feature. And I'm grateful for that, programming used to be much more annoying.
To go in your direction, a few countries in South American did ban advertising for junk food. In addition to education in schools, it dramatically helped reduce overweight-related sickness.
Being better at debugging doesn't necessarily makes you better at writing less complex, more approachable code. Though debugging should teach you which patterns cause bugs or impede debugging.
And what do you do once you are so skilled your software doesn't have bugs? :P
Regarding self improvement, Aaron Swartz put it better here: https://web.archive.org/web/20240928215405/http://www.aarons... (tldr: do things you don't like)