Greeting, friends!

AI software engineering is here, and it’s fundamentally reshaping how we build, test, and run software.

And yet, some fundamentals never change. No matter how powerful AI becomes, the core practices of software development remain the backbone of everything we do: Git and pull requests as the currency of collaboration, Agile boards to organize delivery, testing and continuous integration to keep speed from breaking quality, and patience as the developer’s most underrated superpower.

1. Git and Pull Requests

​Configuration management is the foundation of team collaboration in software. Many tools exist for it, but luckily one has become the absolute and ultimate reference: Git.

Documentation on the key aspects is well described in the Git Book.

There are plenty of turnkey services to get started: GitHub is probably the most popular, but also BitBucket or GitLab.

A great graphical tool to work with is SourceTree. I recommend you master the command line before reaching for UI tools, though.

Below are the questions you should know how to answer:

• How do I merge or rebase my branch, and what is the difference?
• How do I resolve conflicts? For example, mine versus theirs versus manual merge
• What is a feature branch?
• What is a pull request?
• What are the different collaboration workflows in Git?

That’s it, and this is pretty straightforward. After reading the theory and with some practice, you will become a Git master in a jiffy.

2. The Agile board

The first thing a team needs to do when starting a project or a larger task is to split the job. Over the last 10 years, the “Agile” methodology replaced the traditional waterfall planning. The Agile manifesto is here.

Practically speaking it says “let’s not plan too much ahead, because inputs and assumptions we have today about the project will change”. This is almost always true, and nowadays there is hardly any team under the sun that is not (sometimes self-proclaimed) “Agile”.

Here are the practical things you need to know:

• The most popular Agile way of working is Scrum. Divide your project into “sprints” of two weeks and put “tasks” in the content of the sprint. All the rest is for the future and is called the “backlog”. This is useful to track progress, adjust planning going forward, and improve team velocity over time.
• Another Agile approach is Kanban. The idea is to limit the number of tasks that are “in progress”. This way, you are sure to close one item fully before moving to the next. There are no sprints or time frames like in Scrum. You just go through tasks one after the other until you’re done.

In Agile, a software project will be split into tens or hundreds of tasks. You need a tool to manage them. The reference tool is JIRA.

Other tools exist of course, but you will probably have to work with JIRA at some point. So if you are new to these all the tools, just go for JIRA. There is a free 7 day trial. It is more than enough to get an overview of how things work. Again, this is fairly straightforward, and very well-documented.

3. Testing and Continuous Integration

Git and agile tools allow teams to go fast. With speed inevitably come errors and bugs. Consider a team of five developers working on rather independent pieces of code. Each of them will make a pull request to the repository. Two problems can arise:

• Once the code of the “first developer” gets to the Git repository, the code of the others is no longer valid or working because some things have changed. This is not a mistake from “the first developer”, it is just life and it will happen.
• Once all the developers pushed their code to the Git repository, chances that everything work as expected out of the box are rather low. Again, this is not a reflection of poor teamwork. It will just happen.

Therefore, you need to test your software. Even after each developer has pushed their code? It would be great, but a waste of time.

When other developers push their code, we’ll need to repeat this task. Should you test once everyone has pushed their code? Also great, but you’ll find bugs late in the process, which can delay the whole project. So how can you solve this?

Automated tests and Continuous Integration are there to the rescue.

Automated testing is a topic one could write many books about. Each language and framework has its own set of tools. Listing them all would not make sense here. Just keep in mind that testing is time consuming and not always planned for.

Regardless, you should know how to write unit tests for your code and be proactive about writing them. If you don’t have time to actually do it, you should at least be aware that it’s wrong.

Continuous Integration is a process in which every push to your repository triggers a build and runs your tests automatically. A red flag is raised as soon as a faulty commit goes in. Pull requests should also be tested automatically before merging to avoid bugs that impact the whole team.

Continuous Delivery is the extension of Continuous Integration. If the tests pass properly, the tested version is pushed to the production environment automatically.

As an example: at Quora, they track the time between a push to the repository and deployment of that code to production servers. The last benchmark I read about was 15 minutes … for around 100 developers. This is the most powerful setup a team could hope for.

Popular continuous integration servers are Jenkins, Travis, CircleCI, and a few more. You do not need to know how to set the server up and everything, but you should know such tools exist, and a red alert should trigger in your head if your team do not use any.

4. Patience and understanding

As a developer your main frustration will not come from the code. You might spend a few hours searching chatgpt for answers but this is a driving activity. The real pain will come from the outside:

– Unclear or misunderstood requirements

– People unhappy with the end result of your work because they didn’t knew what they wanted in the first place and they expected you to figure it out

– Tools that become slow or stop working for some reasons

– Interruptions now and then because people think that sitting at your desk means they can disturb you any time

The keyword here is “patience”. Try to understand the people around you. They don’t know everything. Remember that you don’t either. Do make them understand though that your time is valuable and that they should respect it.

The last but not the least when it comes to customers and requirements: do not accept low level or clumsy detailed requirements if you didn’t get a brief on the big picture. You need to understand the business you are building software for. At the end of the day your code is here to improve an existing process or enable new ones.

Hope this helps,
Abi