What the Git tutorial did not teach me …

What the Git tutorial did not teach me …

You visit the website Intertops casino bonus and you start getting dreams in your head of sending off your resume to them to help them make their website even better.  You love playing online casino games, so why not try to get a job writing online casino games?

So do you or do not need a GitHub account? Some say “yes”, while others say “no”.  I am of the view that a “Level 1 Resume” still needs to be 1 page long and just the most important stuff.  If the employer likes your 1-page resume (and there are probably 50 others that are in that ‘like’ pile), then the employer is going to want to see a “Level 2 Resume”.

In some fields, that is just an electronic portfolio which may be as simple as a LinkedIn account.  But in the tech field, tech people want to see tech.  So that will be a combination of GitHub (technical side and how you can manage a project), and the corresponding portfolio that shows off that the coding project actually does something.

And if you have not figured it out, GitHub runs on top of Git.  Although you can technically use GitHub without really understanding the power of Git, a quick conversation with an employer will reveal that you do not know how to use Git.

Do I really need to learn Git?

What is going on in the industry?

• 98% of developers use open-source tools at work.
• 92% of developers say they prefer to use Git repositories.
• 91% of developers prefer to use the same development tools for work and personal projects.
• 81% say it is critical for organizations to use the latest development tools.
• 55% of developers say they have the power to choose the tools they use, but 81% of developers want to have the choice of what tools they use.
• 36% of developers will reject a job if they did not use the latest development tools.

Although, this survey was conducted by GitLab, which is an open-source web version of Git.  GitLab was also created because GitHub was bought by Microsoft.  So it would be safe to assume that a majority of the users on GitLab are pro-opensource and anti-Microsoft.  In other words, the survey is biased.

But regardless of which tools you use or if you are a “Microsoft Developer”, a “Linux Developer”, an “Android Developer”, a “Web Full Stack Developer”, or an “Apple products developer”, the trend is moving towards faster development from idea to production.  But getting unclear instructions and using outdated tools can slow down the process.  Not to mention only listing outdated tools can have your Resume scream “old person”.

What are the expectations of Education in Software Development in 2022?

In 2022, 60% of respondents learned to code from online resources.  Younger respondents learned to code from online courses, forums, and other online resources.  Older respondents learned from school and books.  So if you did not learn coding through a traditional class, don’t sweat it, because 60% of the people who you are competing with for the job also did not learn to program through traditional schools and books.

What are employers looking for in a GitHub account from a programming perspective?

In 2022, it is safe to assume that your GitHub account (or something similar) is your “Level 2” Resume.  Employers will want to look at it before you go in for an interview.  So think about that when you are displaying your public face on GitHub.

• The timespan of the candidate’s contribution history.  Good candidates will have history throughout the year of history shown in the chart.  Inexperienced or bad candidates will often have a dense 1 to 3-week period of activity where they prepared a public-facing project to impress employers.  (My opinion: If you are working full-time at a job where you are not allowed to publish what you are working on, this is not a true statement.   But if you are a student or independent contractor or somebody returning to the industry, then yes, I would say it would be expected that you would have 6 months to a year of work to demonstrate.  In other words, something of substance.)
• Are projects well organized?  By looking at the directory structure, can you figure out what is going on?
• Is the code clean, easy to read, and commented on appropriately?
• Is there an organized branching and tag process being followed?  Gitflow is a good example.
• Is there some sense that the person understands basic design patterns?
• Does the project leverage existing open-source libraries and frameworks (good) or does the coder reinvent the wheel (bad)?
• Does the first thing seen (README.md) clearly show what the project does, how to run it, and how to build it?
• Do I see replicated code (obvious cut-and-paste code) (bad)?
• Are there tests?  Did you do Unit Testing or integration testing?

It does not matter what the project does.  What matters more is that it was developed professionally.

What are clients looking for (the ones who pay the bills)?

• Clients care about the user interface and not the code.  My opinion: In my last project, I spent time writing a Requirements Manual.  It never got read.  I also created a video to demonstrate what the product would generally do without the underlining guts.  From that I was able to get feedback.)  So both are needed.  From the technical side, you need to show the code.  From the client (end user side), you need to show how the product works.
• Contributing to existing open-source projects is not needed.  You are can create your own project. My opinion:  I would agree with this.  Either create your own simple project or else fork an existing project to work from there.  For most companies, you are going to be jumping into an existing project, so being able to do that is a good skill.
• Hiring managers won’t look at code.  My opinion: “They will not look at your code, but you have to have a GitHub account.”  In other words, the “extra stuff” that is listed above.  I remember my first programming teacher.  He believed that getting a program to work was a ‘C’ grade.  It was everything else that is involved in software development that separates out the ‘C’ programmer from the ‘A’ programmer.  20 years later and I still believe that philosophy to be true.
• Hiring managers will still require you to do a technical test or else they will ask you technical questions in the interview.  They want to know if you can program what they need to get programmed.
• Store code on GitHub, but have a separate portfolio website.  My opinion:  From your GitHub README.md file, you need to link to either an online demonstration or a video that shows your project works.

These are general items Employers look for:

• Relevant work experience.  This is a problem if you are trying to return to the industry after leaving for a time to raise a family or such.  So if you do not have relevant work experience, having a GitHub account can help in this area.
• Communication skills.  Everybody needs to be able to communicate.  Almost no projects are single-developer code.
• Extracurricular activities.  The only relevance of this is if what you are interested in is related to what the company does.
• GitHub.  As they say, there is a time and place for everything.  If you are just getting out of college or else you left the industry and are now returning to it, having a GitHub account can demonstrate to employers that you can do the job they are hiring somebody to do.

What is Gitflow?

Gitflow is an alternative Git branching model that involves the use of feature branches and multiple primary branches.   For most projects, you only see the “main” branch.  Developers use this as the “main” branch for development.  In the Gitflow method, the only thing that should be on the main branch is “to the public releases”.  All of the commits that are done in between do not belong in this branch.

• Branch “main” – Stores the history of the actual final releases to the public.
• Branch “dev” – This is the development branch.  It contains everything.
• Branch “feature” – Every feature has its own branch.  When a feature is completed, it is merged into the “dev” branch and this specific feature branch is deleted.  The parent branch is “dev”.  “Feature” branches never interact with the “main” branch.
• Branch “releases” – Every release has its own branch.  You create a release branch when you are formally preparing to release the software and you do not want any new features added to the code.   This is also considered a temporary branch.  The parent branch is “dev”, but it is merged into “dev” and “main”.  The “release” branch is intended to police the release.
• Branch “hotfix” — If you already released a version and there are major issues with the release that need to get fixed, you need to push out a “hotfix”.  “Hotfix” is branched off “main”, but it should be merged back into “dev” and “main”.  This is the only branch that should be forked off of “main”.

Summary

Knowing Git is a requirement in 2022 and moving forward.  If you do not know how to use Git comfortably on the command line, learn it.

GitHub or GitLab or some other portfolio is needed.  GitHub, LinkedIn, or a traditional blog … the goal is that if your potential employer does an internet search of you, have something that you want the employer to see.  How much they look at it is not as important as the employer not seeing something that you do not want the employer to see.

It is not about lying.  It is not about being phony.  It is all about presenting the employer with the super deluxe version of your resume, however you want that resume to be.  For some, it is the actual source code.  For others, it is a video demonstration of the product.  Or it can be actually allowing the users to try out the project you created.  If you are working on a large project, it might just be a demonstration of your part of the product (assuming that it will not cause problems with your current employer).

Be true to yourself and it will work out.