Why?

In my previous talks on how to build an app I’ve discussed source control briefly. Github, owned by Microsoft, is probably the most popular cloud service for source control. OK, but how does that help me?

If your app based startup is going great, then your team will be implementing product features and code for that will be going into your source control system many times a day.

But what about if something is going wrong? How can you check up on that? Do you wait for your engineering team to tell you? I’ve talked about the problems a startup can have, especially in that first app building phase, and especially if there’s poor engagement between the founders and the team:

* My developer left me / Get the Code

* How Does my App Work as a Business / Code Repo: Core to Automation

* How to Build an App / Backlog, Doing Done 

I’ve done to death the “Why” of being a founder who understands how to find the code. In this session I am going to look at the “What” and then the “How”.

If my business was a sandwich bar or a t-shirt printer I could go down to the kitchen or down to the factory floor.

But if source control is a mystery you need to take some time out to decode that, because it's the one thing that keeps your business running. 

What

In the next 10 minutes I’m going to show you what source control might look like, and give you an idea of how it works. Finally I’ll wrap up with a short list of next steps to give you as an appreneur to get ongoing insight into your project so you can work with your team collaboratively.

As a bonus, if you’re an engineer you’ll see the way I work with Git on the command line and you will likely discover something new. 

For non-tech Appreneurs trying to get a handle on source control can be tricky. 

Think of the difference between a document on your local computer or phone, like say a PDF you downloaded; and an email. You know where that PDF is, it's in your Downloads folder. Now compare that with your emails that you read on your phone or computer. Where are those exactly?

A code repository is a bit more like that. In the cloud, synced locally. Kind of.

But another big difference, and it's what I’m focussing on in this session, is a code repository for your project is built in small steps. And source control is designed with that in mind.

Demo of Git

First we’re going to look at a couple of projects from the Engineer perspective and you’re going to see how I would explore code, download it, make changes to it and then update those changes to our cloud - to the Github repository.

Let’s look at a project I started some years ago. This is an app written in C++ that runs on Mac, Windows and Linux. 

It’s stored in a source control repository, and then pulled down locally. That project is private, and only accessible if logged on and allowed access.

Another project of mine is open source and is publicly available for view.

# Pull down the project from github

Signed Commits

* https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits

As an engineer I can sign my commits so that you know they are done by me. This is an added layer of security and it's worth doing to ensure that code is being modified by who you think it is.

What if you had a disgruntled employee – call them Joe – who left and decided to put a back door in your code? As long as Joe doesn’t have access to the local GPG keys that your existing engineers have on their computers you can see that all any changes are by legitimate folks with access to the code.

It’s possible to have Github reject unsigned changes but that’s not something I have seen on any repo, and I would not recommend it.

The Git Log

Git never forgets. At least you have to do a lot of work to make it forget, which for all practical purposes is the same. In this article I go through what is required to make Git forget and its a nuclear option - generally you never do this.

* Make Git Forget

The How

* Make sure you have your own account 

* on Github, Bitbucket or whatever system is being used for source control.

* NOT the user name and password of someone else's account or of a jointly used generic account.

* As founder and one of the owners of the company get admin rights to the repo

* You will use this access very wisely, very carefully

* It's generally not easy to inadvertently change anything on Github.

* If you need to appoint someone new to work on the repository you need to have the power to do that, if key personnel leave.

* This is really important: if you get some other account and have the password, it can easily be deleted by that other person who has access to it, or the admin rights revoked. Imagine - some people have left the company and you go to use the username and password to get your project back on the road again, only to find it was owned by someone else. And now it's gone.

* Regularly, ideally after a release or a sprint cycle.

* Log on to github and navigate to the list of commits. If your team is using PR’s then check those too.

* Look for the following:

* Commit messages - should be descriptive

* Commits / PR’s should be small

* Names of files that are edited

* Signed commits

* For extra credit:

* Documentation

* Function names

* Signs of 3rd party or cut-n-pasted code

* What dependencies are introduced?

* The goal is to better understand the pressures and work load of your engineering team. If you are an engineer yourself then reviewing the code others are writing is important.

* You don’t need to introduce PR’s and slow down development to have code review, just read code together

* Ask:

* From the commit messages and files touched is it clear what the change is doing? Is this change improving the product and moving forward the goals of the team and the product?

* Are there signs of technical debt being introduced - for example is code being commented out, instead of deleted? Is the word “temporary fix” and “hack” being over-used to apologise for code. You can ask the engineers to explain what they meant in a non-blaming way.

* Are there signs of churn or spats between developers being fought out in the code base - changes done and then undone.

Totally a Thing is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.