van2z

cross-posted from: https://programming.dev/post/864349

I have spent some time trying to simplify the release process. For a variety of reasons, we can only release on Thursdays. The code is "frozen" on Tuesday before it can be released on Thursday. But we sometimes squeeze in a quick fix on Wednesday as well.

The question, is when should QA test the code?

Here is what I have seen happen:

1. Dev writes code and sends it to QA.
2. QA finds problems, sends it back to the Dev.
3. Dev fixes and sends it back to QA.

I have seen a Dev fix their code on Tuesday, and then QA comes back on Wednesday with problems, when the code should have been frozen anyway.

I am looking, what should be the best solution here.

We have several problems going on at once:

1. Developers test on the same server as QA tests. I am working to switch developers to a separate Dev server, but it is a long work in progress.
2. We don't have an easy way to revert code back from the QA server. It is easier to build revisions than revert changes. We can try to revert code more, but it will require a culture change.
3. QA don't really have a schedule when they are supposed to do functional testing vs regression testing.

I don't know what is the best way to proceed forward. Thus far, I haven't thought too much about the QA because I was focused more on getting releases out. Now that releasing is more simplified, that we can potentially do weekly releases, I am trying to see how we should proceed with the testing process.

I recently decided to think of an algorithm based on natural selection of DNA mutations. Being unclear about its speed complexity, I decided to write it up and test it out. The result was counter intuitive.

First, a simpler variant: Imagine the following sorting algorithm, given an array of numbers: Randomly shuffle the numbers until they are sorted.

What is the median amount of times you end up shuffling the array before it is sorted?

The answer is n! where n is length of the array. This is known as Bogosort.

Now, a slightly more advanced version:

Assume you can tell which numbers are already in their correctly sorted position, and which aren't. Only randomly shuffle the numbers which are not yet sorted. Keep all the others in place.

What is the median amount of times you end up doing this kind of shuffling before the whole array is sorted?

I'll be revealing the answer tomorrow.

Edit: The answer is that you end up shuffling only n times.

Addressing some concerns: this is not a real sorting algorithm, because it assumes you already know whether some of the records are sorted or not.

It shows me how "random chance" in DNA mutations can actually occur much faster than we expect. When a better gene allows an organism to survive better, it sticks around, while all of the other useless genes randomly shuffle around until they can become more useful too. This way organisms with a long DNA code can still evolve rather quickly even if it's by random chance.

There are tons of Rust communities spread on multiple instances. Is the expectation that users interested in rust should just subscribe to all of these? Is there a community which aggregates posts from all rust communities together into one?

I have been working at a large bank for a few years. Although some coding is needed, the bulk majority of time is spent on server config changes, releasing code to production, asking other people for approvals, auth roles, and of course tons of meetings with the end user to find out what they need.

I guess when I was a junior engineer, I would spend more time looking at code, though I used to work for small companies. So it is hard for me to judge if the extra time spent coding, was because of me being a junior or because it was a small company.

The kicker, is when we interview devs, most of the interview is just about coding. Very little of it is about the stuff I listed..