Version control is an important part of software development, all commercial software development projects use some form of version control, these days it’s likely to be git but there are other alternatives. Even if you are working on your own small personal projects, get into the habit of committing your code changes frequently and pushing to a remote repo.
Why would you bother doing this even for personal projects?
it gets you used to using a tool like git, before using it on a larger project
you can checkout any previous commit if something breaks and you need to roll back changes
if you’re pushing to a remote repo you also have a remote backup
I’m not talking about quantities of pizza consumed, neither Amazon’s now commonly known two-pizza rule as the ideal team size. Rather how pizza has played a common part of many firsts and iconic moments in software and internet history:
Solaris 2 had a demo app developed with the NeWS toolkit called PizzaTool, that was well known if you ever worked with Solaris.
CyberSlice, an online pizza ordering company formed in 1996 which facilitated online pizza ordering for other pizza restaurants even if they didn’t have an internet connection, the system automated phone calls to restaurants to place orders on behalf of customers. The system was built with NeXT WebObjects, and Steve Jobs demo’d the first online order using the system live at a press conference.
We write code to solve problems, to be executed by computers, but perhaps more importantly, to be understood by other humans.
Programming paradigms like imperative and declarative programming languages and data structures are abstractions of the real world that help us express the real world in code. We need abstractions because real world problems are difficult and complex, so we model them in programming code with abstractions that help us, humans, put into words (code) what it is that the computer needs to do to solve a problem.
Data structures are another abstraction that help us think about and work with data in the same way. They are a simplification, a categorization of data that helps us group and manipulate data in a way that helps us understand the data we need to be processed, but also to structure the data in way so it can be processed by our code.
Do you need to study and learn things like data structures to be a developer? Maybe not. But having a common set of problem solving tools makes it easier to approach specific types of problems and talk about how to solve these types of problems with other developers when we have a shared understanding and basic set of knowledge that we work with.
Interesting question I saw asked on Reddit recently – “what tips do you have for getting started on a software development project with a small team for school?”
The interesting thing about this question is that the recommendations are not much different from practices and approaches you would use for any ‘real world’ development project with a team.
Here’s some things I would recommend:
Host a shared repo somewhere, for example Github or GitLab. Watch some intro videos on how to use git, how to clone a repo, how to commit and pull changes
Establish who on the team is working on what, even if it’s just a list of features and then you divide them between the team. This sounds obvious but it will avoid confusion and wasted effort from more than one developer on the team working on the same feature.
Think about the structure of the app and how you will be implementing different features, Worst case: if you have a single Class with all your logic in a main() method, how are multiple developers going to work on this at the same time (hint: this will make things very difficult)
If there is a basic skeleton of the app put in place at the start with placeholder empty methods with ‘feature A goes here’, that will make is easier for each developer to go off and work on their part. Even better if using an OO language, thing about your Classes that will represent your solution.
Encourage everyone on the team to commit their parts back to the repo often, daily, if not more often. You don’t want devs on your team to go away for days and then commit a ton of code in one go. That will lead to unpleasant surprises
Encourage use of unit tests, they’ll help not only you to understand that your code is working, but allow the whole team to run tests for the parts they’re not working on and confirm that the addition of their changes has not broken something else in the system.
Think about how you’re going to build your code as a whole, and how/where does it get deployed?
How are you going to manage your library dependencies? Set up the project at the start using Maven or Gradle. It will make it easier for everyone to pull in the right libraries and the right versions.
For a small team and for a school project this is a good start.