On the whole, I agree with the points made here. Another thing that can make feedback unreliable is that people can sometimes be rejected for reasons that have nothing to do with being skilled enough for the job, e.g. personality type/image doesn't fit the team's. However, they can't (or don't want to) officially say that, and so explain it as something else.

Gemma Black Yes, you're right. Much like everything else in software development, how much to plan is a delicate balancing act. It's a bit like writing tests. Too little and making changes becomes scary as there's no safety net; too much and it takes too long and makes requirements changes painful. I think the more we collectively do, the better we are to judge where the optimum point is.

Good explanations! For a more in-depth discussion of merge vs. rebase, I've written a few articles here and here that may help.

I used to think so too. I now think of it like this: a project will take a certain amount of time, e.g. 1 week. I can either: Spend a day upfront doing some planning, and then four days of implementing, or Jump straight in and start implementing. I'll finish in 3, but then spend a 2 or more days rearchitecting the solution, or rebuilding it because of misunderstandings in the original design and/or requirements.

Fabien Schlegel I don’t know of any off the top of my head. But at a high level, it’s the button where the icon looks a bit like .* . When you toggle that on, the search bar matches uses Regex rather than plain text. You can use any of the regex expressions described in this article. The most powerful thing about it is creating capture groups. Let’s say I’m writing a unit test in C#, and I have a constructor like this: public class MyClass { public MyClass ( MyInterface1 myInterface1 , MyInterface2 myInterface2 ) { } } Suppose I now want to write some mocks to pass into the constructor. I can copy/paste the parameter list, and then do a find for ([ a-z0- 9 ]+ ) ([ a-z0- 9 ]+ ) And replace it with var $2 = new Mock < $1 > (); I would then end up with the following: var myInterface1 = new Mock < MyInterface1 > (); var myInterface2 = new Mock < MyInterface2 > (); This works by matching a group of letters and numbers, a space, and then another group of letters and numbers. Each group is captured by wrapping the subexpression in () . We can access the groups using $1 for the first group, $2 for the second, and so on. By using them in the Replace field, we have managed to write some new code using find/replace. This example is fairly simple because our types are very similar, and we only have two parameters. But it can be a huge time saver for more complex code though.

Great intro to Regex! It's not just in programming logic that Regex can help. Some editors like Visual Studio and VS Code allow doing find/replace with Regex. I like using VS Code because it gives live feedback for the search expression. By using capture groups, it's possible to do lots of code replacements that would otherwise take a while if done manually.

I too know of people who love to just dive straight into writing code, but I completely agree that at least some form of planning upfront is worth it. It’s very much like writing unit tests: by writing them, it makes us think in different ways that the system could operate. As a result, we might include additional handling for different use cases that we may not have otherwise thought of. The same is true with a project plan too. When it comes to system design, I also think it’s helpful to draw up some diagrams. Architectural diagrams help with design and modularisation, and sequence diagrams can show how the systems will communicate with each other. Once we have those, we have a clear direction and (as mentioned in the article) can move much faster as a result.

A very comprehensive article! In my experience there are two things that we should be careful of when writing tests to avoid potential false outcomes. Firstly, we should try to control all variables in the test. If a function relies on the date, and we use something like DateTime.UtcNow , there could be times of the month where this fails but passes at others. In this case, a good idea is creating a separate 'time' service where we can mock such values. Another is when testing logic that has some aspect of concurrency, as the threading can potentially complete in a different order each time. In this case, it's best to try to get the logic to run single threaded for the tests, if possible.

Nice overview. I remember using this in one of my coursework projects during my studies. I remember one of the tricky aspects when I tried it was how to initialise the clusters. When I picked random data points as the cluster centres, the results could be quite poor if they happened to be initialised near others.

Good solution! You can do the same by relying on the truthiness of a value too, e.g. myArray.filter(n => n); . Something to be careful of is that 0 is considered a falsy value.