Most programming languages have libraries with mathematical functions. Usually, these functions provide more complex calculations, such as trigonometric functions, numerical methods, or special mathematical functions. The libraries also provide simpler functions. The power function is one example. Sometimes developers can directly implement the calculations of the functions in the application code. The best practice is not to do that. There are some exceptions. You can calculate powers by performing multiplications. The pow() function calculates the result with arbitrary parameters, including fractional powers. The difference can be vastly different when measuring the time needed. Consider the following code snippet.
for( uint32_t j=0; j<hit_max; j++ ) {
hit = 0;
x = 0;
y = 0;
for( uint32_t i=0; i<rnd_max; i++ ) {
x = static_cast( dist(gen64) ) / static_cast( numeric_limits::max() );
y = static_cast( dist(gen64) ) / static_cast( numeric_limits::max() );
if ( y < std::sqrt( 1 - x*x) ) {
hit++;
}
}
}
The if() condition performs a calculation. To square a number, you just need to multiply it by itself. If you run the code with hit_max=rnd_max=5000, then two loops take about 5.4 seconds. The code executes two loops for comparison. Replacing the multiplication with pow(x,2) leads to an execution time of 8.6 seconds. That’s a lot, especially for loops running more often. So when calling a function from the math library, you should first consider if direct numerical operations can replace the call to the function in your code. The compiler cannot know what you want to calculate, so the optimiser cannot replace the function call. Deciding this with the pow() function and integer power values is easy. When faced with more complex calculations, it is not so easy. You can still try dividing the calculation into parts and check if those parts are directly computable. For numerical simulations or approximations, this is an effort well worth spent. Focus on the things you do in loops. You should also get to know the functions of your math library. The templates in C++ enable the compiler to select different data types. The size of the chosen data types also affects the performance, because floating-point values have different precisions and sizes. Some calculation might even be pre-computed with integers alone and then converted to floating-point data types. Inspect these sections in your code. Use integers with fitting sizes wherever you can. Use floating-point data types only if necessary.
Learning by doing means you spent a lot of time with reading documentation and exploring example code that illustrates the features of your favourite development toolchain. Getting a well-written example code has become substantially more difficult in the past years. Once upon a time, Google offered a search engine just for source code. It was active between 2006 and 2012. Now you are stuck with search engines and their deteriorating quality. The amount of AI-generated content, copy-&-paste from documentation, and hyperlinks to gigantic forum discussions filled with errors and even more copy-&-paste snippets destroys the classical Internet research. You have to select your sources carefully. So what is a good strategy here? I have compiled a short checklist that enables you to avoid wasting time.
Dealing with text is a major task for code. Writing text means to string characters in a row. Characters are the symbols. The encoding determines how these characters are represented in memory. There are single-byte and multi-byte encodings. The 
Testing software and measuring the code coverage is a critical ritual for most software development teams. The more code lines you cover, the better the results. Right? Well, yes, and no. Testing is fine, but you should not get excited about maximising the code coverage. Measuring code coverage can turn into a game and a quest for the highest score. Applying statistics to computer science can show you how many code paths your tests need to cover. Imagine that you have a piece of code containing 32 if()/else() statements. Testing all branches means you will have to run through 4,294,967,296 different combinations. Now add some loops, function calls, and additional if() statements (because 32 comparisons are quite low for a sufficiently big code base). This will increase the paths considerably. Multiply the number by the time needed to complete a test run. This shows that tests are limited by physics and mathematics.
Learning about programming first and then learning secure coding afterwards is a mistake. Even if you are new to a programming language or its concepts, you need to know what can go wrong. You need to know how to handle errors. You need to do some basic checks of data received, no matter what your toolchain looks like. This is part of the learning process. So instead of learning how to use code constructs or language features twice, take the shortcut and address security and understanding of the concepts at once. An example method of classes and their behaviour. If you think in instances, then you will have to deal with the occasional exception. No one would learn the methods first, ignore all error conditions, and then get back to learn about errors.
The words legacy and old carry a negative meaning when used with code or software development. Marketing has ingrained in us the belief that everything new is good and everything old should be replaced to ensure people spend money and time. Let me tell you that this is not the case, and that age is not always a suitable metric. Would you rather have your brain surgery from a surgeon with 20+ years of experience or a freshly graduated surgeon on his or her first day at the hospital?
Yesterday the CrowdStrike update disable thousands of servers and clients all across the world. The affected systems crashed when booting. A 
If all you have is a Large Language Model (LLM), then you will apply it to all of your problems. People are now trying to find 0-days with the might of LLMs. While there is no surprise that this works, there is a better way of pushing your code to the limit. Just use random data! Someone coined the term fuzzing in 1988. People have been using defective punch cards as input for a while longer. With input filtering of data, you want to eliminate as much bias as possible. This is exactly why people create the input data using random data. Human testers think too much, too less, or are too constrained. (Pseudo-)Random number generators rarely have a bias. LLMs do. This means that the publication about finding 0-days by using LLMs should not be good news. Just like human Markov chains, LLMs only „look“ in a specific direction when creating input data. The model is the slave of vectors and the training data. The process might use the source code as an „inspiration“, but so does a compiler with a fuzzing engine. Understanding that LLMs do not possess any cognitive capabilities is the key point here. You cannot ask an LLM what it thinks of the code in combination with certain input data. You are basically using a fancy data generator that uses more energy and is too complex for the task at hand.