Help Learning C++

Help learning c++

So at my internship a whole bunch of people have to switch to C++. And because management is incompetent, there are no learning package or company resources to help this. So I am converting some of my code notes to help this along. And I am also sharing them here. They are created on, and meant to be used on godbolt. They contain explanations and some of them instructions for how to investigate what you are looking at. The ones I have for now are: Understanding objects ( Constructor, destructor, assignment and copy operators ) https://godbolt.org/z/EaMc1fW44 Access modifiers (IE, do you know what public, private and protected means?) https://godbolt.org/z/v3nejaYhh

Pointers (Basically, to not use raw pointers and what to use instead) https://godbolt.org/z/4745PK38n

OK, who will be up for this idea? CODEBLR CODING ADVENT CALLENDAR! ( "BEST IDEA EVER!" - Everyone) So basically, Advent of Code is a online competition of solving a daily programming puzzle the best. As they write on their website "please don't use AI to get on the global leaderboard.". So anyone who wants to be an asshole, can just use AI and get on the leaderboard. Which basically means the leaderboards are worthless. BUT! It is still fun to do. It is just more fun together with people SO I HAD AN IDEA! How about we on the codeblr discord makes a channel to facilitate this? Where each of us uploads github repository links and talk about our solutions and how we are thinking about the problem and how our code works? I think that would be SUPER fun (I would not be able to participate every day. But on the days I have time I will definitely join in!!!) (I was inspired by xiacodes post: )

Tumblr

Advent of Code 2023 Reminder

Thursday 30th November 2023 Just a reminder that Advent of Code 2023 starts tomorrow! (Totally didn't have a reminder set for a whole year

Link to the competition website:

I love GDB (Gnu debugger). It is only useful when something have gone wrong, but GDB just makes it sooooo much easier to find the issue. The picture is of a particularly deep stack. It is a short overview of every stack-frame, and where in the code it was called from, and to what. I can also easily investigate every single stack frame alone, finding what each variable contained the moment the crash happened, what arguments each function took, and the memory position of every single element. By the way, to run this, all I did was: gdb ./build/MyAwesomeProgram run bt

If you work in C or C++, it is SUCH a handy tool to know. And it is pre-installed on basically every machine.

A beginners guide to GIT: Part 2 - Concepts and terms

Table of content: Part 1: What is GIT? Why should I care?

Part 2: Definitions of terms and concepts

Tumblr

A beginners guide to GIT: Part 2 - Concepts and terms

Table of content: Part 1: What is GIT? Why should I care? Part 2: Definitions of terms and concepts. <-------- You are here Part 3: How to

Part 3: How to learn GIT after (or instead of ) this guide.

Part 4: How to use GIT as 1 person

Tumblr

A beginners guide to GIT: Part 4 - How to use GIT as 1 person

Table of content: Part 1: What is GIT? Why should I care? Part 2: Definitions of terms and concepts. Part 3: How to learn GIT after (or in

Part 5: How to use GIT as a group.

Tumblr

A beginners guide to GIT: Part 5 - How to use GIT as a group.

Table of content: Table of content: Part 1: What is GIT? Why should I care? Part 2: Definitions of terms and concepts. Part 3: How to lea

Now, a few (I PROMISE only a few!) concepts that are needed for being able to talk and read about GIT.

Just to be difficult, several of these have multiple names (Plø!)

GIT refers to its commands as "porcelain" commands (user friendly and clean) and "plumbing" commands (Not so user friendly, dirty). Yes. We are starting out with references to toilets :p

The workspace/working tree is all the files and folders you would have if you did not use GIT. It is folders, codefiles, headers, and build system files. All the good stuff we want to work on.

A repository is technically the hidden folder called “.git”. It is all the files GIT uses to keep track of your files and their history, and which enables you to do all the git things to the files in the working tree. You do NOT have to interact with these directly. Just know they are here ( Sometimes people refer to the working tree AND the repository together as “The repository”. Because we work hard on making life harder and more confusing than it needs to be)

The index/cache/staging area is a single, large, binary file in the .git. folder. It keeps track of the differences between last time you saved, and how the working tree is now. Every change, every new file, every file deleted.

Commit. To differentiate what GIT does from how you normally save files, we use the term “commit”. But it is just a save. Different commits are different saves. Easy peasy. Every commit, except the very first one is based on the commit before it. That is called the commits base.(This is the base that REBASE refers to).

The structure of GIT is actually very simple. It is a whole bunch of commits, and each commit knows the commit it came from (IE all commits except the first have a base). This makes a long chain. That's it. That is the entire idea

Staged files

So you now know that we can commit(save) and we have files that we change, but have not been committed. We need a name for files between those two. Files that we are getting ready to commit. All files that will be committed if you commit RIGHT NOW, are “staged for commit”.

HEAD. Because you can switch between different commits easily, we need a way to say “what commit are we looking at right now?”. That is HEAD.

HEAD can be “detached”. This basically means that the commit HEAD is pointing at, is NOT the latest commit. And while you CAN do work on a detached head, it gets messy and is not the smartest way to do it, so “detached head” also works as a bit of a warning.

(If you have ever worked with pointers, HEAD is simply a pointer to a commit)

If we make 3 commits, one after the other (which means HEAD is pointing at the last commit), then your commits could be represented like this:

Branches. These are commits that are done one after the other. You always have at least your starting branch (Usually named master or main). If you create new branches, then they start from a specific commit and can be merged into the original branch whenever you are done. 

If we expand the previous example, make a branch from the first commit, and then merge it before the third commit and delete the branch, it could look something like this:

Make the branch and add to it:

Then merge it into the main branch and delete the new feature branch:

origin/upstream. This refers to what commit and branch a branch came from. In our example, the "New feature branch" would have the upstream/origin "Main branch" , "Initial commit".

Trick or treat :)

As a treat, I offer cute puppy picture!

Designing systems with bad Implicit requirements. (Or "How to hire people")

So I have now been searching for a job for half a year. And my conclusions are: 1: Firms have no idea what they are doing. Everyone seems to make decisions based on "What does everyone else seem to be doing" and "How do we usually do it" 2: Your ability to do the job you are applying for have just about 0% relevance in your ability to GET the job you are applying for. I am a system designer. And when I get exposed to the same system many times, I start analysing it... it is basically habit at this point. And so, I analyse the hiring system. And so far, in all the interviews I have been to I have been asked 0 technical questions about the position I was interviewing for. 0! And the little feedback from my many many rejections, was that I am not experienced enough. That is weird. Because they are making a judgement on how skilled I am... while not at all asking about or testing my skills. And yesterday I finished my internship (Which is a polite way of saying "Whored myself out for 0 pay in desperation"), and I was in a room with 6 other developers, who was all programming in C++ And I now know that I was the best person at C++ in that room. Better at designing with C++, building architecture with it, knowing the intricacies of the language, and knowing tiny weird little details of the language. (Most of the others had different things they were better at. More experience working with the specific hardware and codebase at the job, better at 3D simulations and so on) So I know for a fact I am skilled. But the system that is build with these interviews mean that skills do not count. Someone with terrible skills who had done bad work at their student job for a year or two, is considered better than someone with great skills who have focused on their studies and not yet worked. Or said in another way. There is an implicit specification in the system design that "Being good at the job, does not matter" So since that is frustrating as hell, and I need to interact with it to stop my brain exploding, lets design a better system. First of all, the OBVIOUS (That... I have seen exactly 1 firm do):

Blind recruitment.

The system will have to have humans make the judgement of who to call into interviews, and who to hire. And humans are stupid little monkeys with brains with software that is just layers covering for the flaws of other layers. Yes, that also means you. And yes, that also means me. We are biased. You can try to constantly evaluate yourself, be aware of your biases and minimize them, but they cannot be removed. Science ( as in, the entire field , have tried for several hundred years and is only "meh" at it So how do we deal with that? We remove the info that is not needed, and can ONLY lead to bias. A person making a judgement if a candidate should be called in for a interview should not know the candidates gender, name, age, skin color, religion or any other information we can remove that have no value when it comes to figuring out if that person will be good at their job. You may think "Hey wait a minute. Age DOES have an influence!" but it really does not. EXPERIENCE does, and SKILL does, and PERSONALITY does. And yes, age can corelates with that. But that is it... it MAY corelate with it. We want to value 2 people with the same skills, and the same experience in the relevant fields equally, if they are 25 or 40.

Throw the letter of motivation in the trash where it belongs

Does the job you want someone to do involve writing 1 page marketing nonsense, that follows standards that is never specified? No? Then stop making people write those to get the job. Letters of motivation should only be required for jobs where the skills you showcase by WRITING such a letter is relevant.

Throw the CV in the trash where it belongs

There is NO agreement on what a CV should contain. You can find people claiming that THEY know, and that you should ignore the thousands of others who say the exact same thing but disagree on what it should contain. You may be able to boil it down to "relevant skills" and "relevant experiences"... but now you are having the person who have no information about the job or the inner workings of the firm guess what skills and experiences are considered "relevant". So unless the job you want them to do involves blind guesswork, don't do that. Simply have a website that asks the candidates the relevant questions. Write down the very specific skills you want (Embedded C++, Javascript in React, Kotlin for Android etc) and ask the candidate if they have those. Simple yes/no questions. And for each of them, have a more general question (Low level programming, front end web development, Android development). Now, ask the candidate the general question, and if they say yes, ask them the specific questions that relates to that. Do the same for experience. A specific question could be "Do you have 1 year or more experience working with relational databases via C# ?" and a more general question could be "Do you have more than 1 year or more experience working with C#" or "Do you 1 year or more experience working with relational databases?". And yes, you can also have them write a paragraph about their extra experiences: "What hobby or work in other industries have you done that have help you develop as a worker?" "For how long did you do that?" This is essentially the specific bits you are interested in from the CV. And basically, anyone in the codeblr community could make this website in a few days, AND have it output files that is nicely formatted. Give them a few more days, and they will have a website for setting up the interview question website so it can be done quickly and efficiently.

You CANNOT know if a person will work well in the firm, or in the team

What to ask at interviews have been studied a lot. And we have data to at least make SOME statements. One of which is that it is IMPOSSIBLE to determine if a person will work well together with a team based on interviews. People simply do not act in a way at interviews where you can judge it. No amount of personality tests that con artists have sold your firm will help, and no, people cannot figure it out just by talking to someone (People however THINK they can. Which is worse that simply not being able to). The only way to find out is to hire people. We can do a middle ground technique and hire people for a trial Period. Which is NOT a guarantee that they will KEEP working well with the team... but it is MUCH better at predicting it than people who think they are somehow better at psychology than the entire scientific field of psychology. And yes, this costs money. But it costs LESS money than the alternative.

Either know what you want from a interview, and be able to test it, OR, throw the interview in the trash where it belongs

Interviews are THE most expensive part of hiring someone. And I have yet to be at a interview where ANYONE asked themselves "Why are we doing this?". I would say, in 8/10 cases, they are wasted. If you need someone to do design, architecture or development or other work where thinking in creative but structured ways are required, then you can gain some value. Either ask questions that 100% of candidates should be able to answer, and then dig into the "why" of their answer. For example, ask a software developer to name a software pattern they are relatively familiar with. Then ask them what that pattern does, and when it should be used. And when it should NOT be used. You can also give people homework to do before the interview. Again for programming, FizzBuzz is a great choice. Why? Because it is a solved problem, that is solved in a unsatisfying way. The problem is basically: "Make a program that takes a number to count up to as a input. If the number is divisible by 3, have the program output "Fizz", if it is divisible by 5, yell "Buzz". If it is both, yell "FizzBuzz"". Basically, you will quickly find the optimization that you never check for "FizzBuzz!". You just check for the two other things and output the relevant word. If both are true, then FizzBuzz will appear. So you make your 3 checks into 2 checks.... and then you are stuck. There IS no way to optimize further. Ask the candidate what extra information they would want to solve this test better. You can ask this at a interview or again, via a website that also gives the candidate the problem. Because fun fact, if you know if the program should be optimized for Speed (IE CPU efficiency) or how much space the program takes, or both, then you can actually make the program a LOT better. And knowing to ask the right questions when you are given requirement to your program IS a very great skill to check if the candidate have. You can also check the code. Was it easy to read? Is it easy to modify? Did they do anything cleaver like use linear programming to make it run faster? Did they do clever optimization tricks? (If they did that is good... but it DOES also mean they might pre-maturely optimize, which is a deadly deadly sin in software development.) I went through that in detail, because it showcases HOW to approach designing questions and tests for a candidate for a specific job.

And if you think it is too much work, or if you cannot come up with relevant questions and tests... THEN DO NOT DO INTERVIEWS. If hiring someone without an interview feels like a blind shot. You are correct. But it is LESS of a blind shot than hiring a candidate based on random and irrelevant skills. And it is a shit-ton cheaper.