DEV Community: Tobias Günther

9 Reasons Why Code Breaks

Tobias Günther — Tue, 16 Feb 2021 08:26:14 +0000

1. Code is Untested

Changing code in one place all too often breaks code in a (seemingly) unrelated place. No matter how experienced you might be: you won't be able to predict the possible side effects that code changes can have. That's what gives our jobs that "thrilling touch"...

Back your code with automated tests!

2. Code Does Not Report Errors

You won't easily become aware of all your application's problems: some will only surface in very rare circumstances or with seldom used features. Although you cannot prevent or foresee all problems, you should at least make sure you're made aware as they happen.

Use exception reporting mechanisms, e.g. through services like AppCenter or Airbrake.io.

3. Code Remains Isolated too Long

Developing and keeping unfinished code separate from your production code is a sign of good breeding. However, not keeping your feature code up-to-date with other important development in your project will cause problems. Because the later and less often you integrate your new code with the rest of your project, the higher the risk of things not being compatible.

Integrate often! Make continuous integration part of your development workflow.

4. Code is Developed in Isolation

"Mike is the only one who knows this part of the code." And as it stands, Mike just started his 6-week vacation in the Himalaya... When code is developed by a single person in isolation, that code is fully dependent on that person. Whenever the developer is on vacation, sick, or busy with other stuff, that critical bug can't be fixed or that feature can't be added.

Consider pair programming and/or regular code reviews to share "code ownership".

5. Code Solves Problems That Aren't There

Every piece of code solves a problem. And ideally, it should only solve a problem you have (or are very likely to have). Of course, an endless number of other problems can be imagined... but trying to solve them when you're not likely to actually have them will make your code more complex than necessary.

Make sure you don't overengineer. Keep things as simple as possible.

6. Code Reinvents the Wheel

Any time you're looking at a programming problem, chances are that someone else has had the same problem before. And if you're lucky, the problem has not only been solved in a good enough way - but the solution has also been published. In that case, trying to write this code yourself would be the classic reinvention of the wheel - and a waste of your precious time.

Keep your eyes open for good third-party libraries that have stood the test in other projects already.

7. Code Depends on too Many External Pieces

While external libraries can lighten your workload, they can (unfortunately) also bite you: when they introduce bugs, when they increase loading time, when their development is discontinued, when you simply have too many of them in your project to keep an overview...

Use third-party libraries only when you're convinced that they are of high quality - and you really need them.

8. Code is Not Actively Maintained

Code rots. It's a sad but true fact. While some parts in a project change and evolve, others are left behind. These parts become liabilities over time. For example, because framework features became obsolete; or because the new code's demands aren't satisfied anymore.

Schedule time for regular refactorings.

9. Code is Not Properly Version-Controlled

Although most teams nowadays use a version control system like Git, they often don't use its full potential! Git has much more to offer than just "commit, pull, and push". Learning the more advanced stuff (from Interactive Rebase to Git's many "undo" features) can improve the quality of a code base tremendously!

Go beyond the basics and learn to use the more advanced features of Git!

If you want to take No. 9 - your Git knowledge - to the next level, I have a couple of tips for you:

Learn version control with Git, a beginner-friendly online book.
First Aid Kit for Git, a series of short videos on how to undo mistakes.
Git Cheat Sheet, a nice overview of the most important commands.

Become a Better Programmer: 5 Essential Methods at a Glance

Tobias Günther — Wed, 27 Jan 2021 08:35:21 +0000

1. Unit Testing

Why? Every programmer has experienced something like this: you change a bit of code in one corner, and in a (seemingly) unrelated corner, something breaks! The bitter truth is: both new and changed code will inevitably contain bugs. Use automated tests that help you keep old code stable.

Keep in mind: You can also go one step further and write tests before your actual code. This can give you a whole new perspective on how to approach problems!

Read more: XP on Unit Tests and Test-Driven Development

2. Code Review

Why? Code that is ever only seen by a single programmer in your team is dangerous code: if that person gets sick or leaves your team, no one knows how this piece of your software really works. Additionally, no matter how great and experienced that developer is: it might be that he overlooked something, implementing only the second best solution.

These problems can easily be avoided by always having team members approve each other's code. It's both a quality control as well as a means to create collective ownership of your project's code.

Keep in mind: If pair programming (see below) is already an integral part of your workflow, you might not need additional code reviews!

Read more: Code Review on the blogs of IBM and Jeff Atwood.

3. Pair Programming

Why? Pair programming is an ideal tool to share knowledge in a team. Having a junior and a senior developer sitting side-by-side is the best way for the junior to learn. And since teaching is a great way to sharpen your own skills, even the senior can benefit.

Keep in mind: Make sure that each person gets in front of the keyboard on a rotating basis. It shouldn't become a "I teach, you listen" event.

Read more: XP about Pair Programming, Martin Fowler on Pair Programming Misconceptions, WikiHow on Pair Programming

4. Keep it Simple

Why? Planning for the unlikely makes code unnecessarily complex. Don't try to foresee your project's requirements in two years from now - too many things can (and will) change! You would waste time on an overly complex solution for a problem that proves to be different than you thought.

Keep in mind: Keeping it simple shouldn't be confused with "quick and dirty". You still have to work thoroughly and carefully!

Read more: KISS on apache.org

5. Design Patterns

Why? At its core, most programming problems belong to one of only a few general categories. These general problems have already been solved thousands of times - and are well-documented in a couple of "design patterns". Step back from the problem in front of you. And you'll be able to apply a proven best practice instead of reinventing the wheel.

Keep in mind: Applying design patterns shouldn't become a religion. Sometimes, all that's really necessary are a few lines of simple code...

Read more: A classic design patterns book, A beginner's guide to design patterns on net.tutsplus.com

(Bonus) 6. Version Control with Git

Why? Git and version control are often underestimated: being proficient with Git has the power to make you a better programmer - and help you build a better code base!

Keep in mind: Git is about more than just "commit, push, pull". Take its many "undo" features and you'll quickly understand how helpful it can be!

Read more: A completely free online book on Learning version control with Git and the First Aid Kit, a series of short videos on how to undo mistakes in Git.

First Aid Kit for Git

Tobias Günther — Wed, 02 Dec 2020 08:49:22 +0000

Here's the good news: Git allows you to undo almost any mistake! 🤩
But the bad news is: You have to know the right commands & tools! 😩

To help you learn the various ways to save your neck, I've compiled a series of 17 short videos and a handy cheat sheet - free to download!

You'll learn how to...

...correct and fix your very last commit
...discard uncommitted changes in your working copy
...undo and revert an old commit
...return to a previous version of your project
...restore a deleted branch or commit
...deal with merge conflicts like a pro

Go ahead and download my "First Aid Kit for Git" for free and learn how to undo your mistakes like a Pro!

Understanding the Concept of Branches in Git

Tobias Günther — Thu, 26 Nov 2020 07:47:13 +0000

Using branches in your day-to-day work might very well prove to make you a better programmer or designer. Be that as it may, it's definitely one of the main reasons why Git is so highly respected. And although desktop GUIs like "Tower" make all of this a lot easier, it still makes sense to have a firm understanding of the underlying concepts!

First of all, if you're coming from another version control system, I kindly ask you to forget the things you already know about branching & merging. It's true that Git hasn't invented this particular wheel: many other VCS also offer branching. However, Git's concepts in this area are absolutely unique when it comes to ease of use and performance.

Now, let's look at why branches are so important.

Working in Contexts

In every project, there are always multiple different contexts where work happens. Each feature, bugfix, experiment, or alternative of your product is actually a context of its own: it can be seen as its own "topic", clearly separated from other topics.

This leaves you with an unlimited amount of different contexts. Most likely, you'll have at least one context for your "main" or "production" state, and another context for each feature, bugfix, experiment, etc.

In real-world projects, work always happens in multiple of these contexts in parallel:

While you're preparing 2 new variations of your website's design (context 1 & 2)...
you're also trying to fix an annoying bug (context 3).
Besides, you also update some content on your FAQ pages (context 4), while...
your teammate is working on a new feature for your shopping cart (context 5),...
and another colleague is experimenting with a whole new login functionality (context 6).

A World Without Branches

Not working in clearly separated contexts can (and sooner or later will) cause several problems:

What happens if your client likes variation 2 of the new design? In the meantime, a host of other changes have happened! How do you launch the new design while integrating all these other changes instead of losing them?
What happens if the shopping cart feature became obsolete because the client changed his mind? How do you get all that unwanted code (and only that code!) out?
What do you do if that new login functionality proves to be impossible to implement? It's already mingled with all of those other changes, being almost impossible to separate out!
How can you avoid losing track? Most likely, you shouldn't be bothered with all the topics from all of your colleagues. Things will start to get very confusing when you try to handle multiple topics in a single context:

A tempting workaround might be to simply copy your complete project folder for each new context. But this only leaves you with other problems:

You circumvent your VCS, since those new folders won't be under version control.
Not being version controlled, you can't easily share & collaborate with others.
Integrating changes from one context into another (maybe your main context) is difficult and error-prone.

To make a long story short: if your goal is to work professionally, you'll have to find a way to deal with multiple contexts in a professional manner.

Branches to the Rescue

You might have already guessed it: branches are what we need to solve these problems. Because a branch represents exactly such a context in a project and helps you keep it separate from all other contexts.

This was an excerpt from my (completely free!!) online book "Learn Version Control with Git". Feel free to read more if you want to understand How branches can solve these problems, How to create and manage them, How to integrate changes between branches and where remote branches come into play.

Best Practices for Version Control with Git

Tobias Günther — Tue, 03 Nov 2020 16:46:36 +0000

Today, version control should be part of every developer’s tool kit. Knowing the basic rules, however, makes it even more useful. We’ve compiled some best practices that help you get the most out of version control with Git.

1. Commit Related Changes

A commit should be a wrapper for related changes. For example, fixing two different bugs should produce two separate commits. Small commits make it easier for other developers to understand the changes and roll them back if something went wrong. With tools like the staging area and the ability to stage only parts of a file, Git makes it easy to create very granular commits.

2. Commit Often

Committing often keeps your commits small and, again, helps you commit only related changes. Moreover, it allows you to share your code more frequently with others. That way it’s easier for everyone to integrate changes regularly and avoid having merge conflicts. Having few large commits and sharing them rarely, in contrast, makes it hard to solve conflicts.

3. Don’t Commit Half-Done Work

You should only commit code when it’s completed. This doesn’t mean you have to complete a whole, large feature before committing. Quite the contrary: split the feature’s implementation into logical chunks and remember to commit early and often. But don’t commit just to have something in the repository before leaving the office at the end of the day. If you’re tempted to commit just because you need a clean working copy (to check out a branch, pull in changes, etc.) consider using Git’s “Stash” feature instead.

4. Test Before You Commit

Resist the temptation to commit something that you “think” is completed. Test it thoroughly to make sure it really is completed and has no side effects (as far as one can tell). While committing half-baked things in your local repository only requires you to forgive yourself, having your code tested is even more important when it comes to pushing / sharing your code with others.

5. Write Good Commit Messages

Begin your message with a short summary of your changes (up to 50 characters as a guideline). Separate it from the following body by including a blank line. The body of your message should provide detailed answers to the following questions: What was the motivation for the change? How does it differ from the previous implementation? Use the imperative, present tense („change“, not „changed“ or „changes“) to be consistent with generated messages from commands like git merge.

6. Version Control is not a Backup System

Having your files backed up on a remote server is a nice side effect of having a version control system. But you should not use your VCS like it was a backup system. When doing version control, you should pay attention to committing semantically (see “related changes”) – you shouldn’t just cram in files.

7. Use Branches

Branching is one of Git’s most powerful features – and this is not by accident: quick and easy branching was a central requirement from day one. Branches are the perfect tool to help you avoid mixing up different lines of development. You should use branches extensively in your development workflows: for new features, bug fixes, ideas…

8. Agree on a Workflow

Git lets you pick from a lot of different workflows: long-running branches, topic branches, merge or rebase, git-flow… Which one you choose depends on a couple of factors: your project, your overall development and deployment workflows and (maybe most importantly) on your and your teammates’ personal preferences. However you choose to work, just make sure to agree on a common workflow that everyone follows.

9. Go Beyond the Basics

It's true that you can "survive" knowing just a handful of Git commands. But you'll be missing out on much of Git's power if you don't learn about advanced features like Interactive Rebase, the Reflog, or Submodules. Take some time to go beyond the basics and let Git help you write better software!

10. Use Tools to Be More Productive

In the last couple of years, the ecosystem around Git has become incredibly powerful: from code hosting services like GitHub, Gitlab, and Azure DevOps all the way to desktop GUIs like Tower. Choose your tools carefully and let them help you work more easily and productively with Git.

Learn More

Of course, there's a lot more to know and understand about Git! If you want to learn more, have a look at my free online book on "Learning Version Control with Git".

Understanding Rebase (And Merge) in Git

Tobias Günther — Tue, 20 Oct 2020 15:26:53 +0000

While merging is definitely the easiest and most common way to integrate changes in Git, it's not the only one: "Rebase" is an alternative (and slightly advanced) means of integration.

The Case Against Merge Commits

A normal commit, carefully created by a human being, is a meaningful unit: it wraps only related changes and annotates them with a comment.

All this gets lost in a merge commit: it's created automatically by Git to cram in all the differing changes. It has no semantic meaning, no separation of topics. Of course, the contents of those individual commits are preserved. But the history - commented and nicely separated into individual, meaningful commits - that lead to this point is not preserved in a merge commit.

This is why some people dislike merging and instead use rebase.

The Beauty of Rebase

Instead of cramming all changes into a merge commit, a rebase preserves the original commits. The project's history then looks as if it had evolved in a single, straight line. No indication remains that it had been split into multiple branches at some point.

Let's walk through a rebase operation step by step. The scenario is simple: we want to integrate the changes from branch-B into branch-A, using rebase.

The command for this is very easy:

$ git rebase branch-B

First, Git will "undo" all commits on branch-A that happened after the lines began to branch out (after the common ancestor commit). Of course, it won't discard them but rather save them away, temporarily.

Next, it applies the commits from branch-B that we want to integrate. At this point, both branches look exactly the same.

In the final step, the new commits on branch-A are now reapplied - but on a new position, on top of the integrated commits from branch-B (they are re-based).

The result looks like development had happened in a straight line. Instead of a merge commit that contains all the combined changes, the original commit structure was preserved.

In case you're using the Tower Git GUI, you can use rebase simply by dragging the to-be-integrated branch and dropping it on the target branch, with the ALT key pressed. That's it!

Learn More

Of course, there's a lot more to know and understand about rebase in Git! If you want to learn more, have a look at the chapter "Rebase as an Alternative to Merge" in my free online book on "Learning Version Control with Git".

12 Ways to Undo Mistakes with Git - Part 2

Tobias Günther — Tue, 06 Oct 2020 17:26:30 +0000

Accidentally deleting files... Making typos in your commit messages... Committing on the wrong branch... a lot of mistakes happen when humans write code! But do not despair: Git offers countless tools to undo and recover from small and big mishaps.

In this second part, you'll find another set of 6 short & handy videos that help you undo mistakes with Git! (Take a look at part 1 if you missed it!)

Resetting a File to an Old Revision

Apply in cases of: "Yikes! 🤔 I know this file was correct sometime!"

Disaster summary: Not everything was better in the old days! Just this one particular file, that you now long to restore from a previous revision. Here's how!

Recovering Deleted Commits

Apply in cases of: "Sweet baby Jesus! 😱 Did I just delete the wrong commits?!!"

Disaster summary: Using "git reset" is a wonderful way to get rid of some unwanted commits. But it's also a wonderful way to get yourself into trouble - if you got rid of the wrong commits! But chin up! You can undo even that!

Moving a Commit to a New Branch

Apply in cases of: "Damn it! 😣 I should have created a new branch before committing!"

Disaster summary: You've worked busily on a new feature and solemnly made the first commit - although you haven't created a separate feature branch for it. Let's get that new feature commit off of the "master" branch and move it to its own feature branch!

Editing Old Commit Messages

Apply in cases of: "Christ on a cracker! 😱 Did I write this commit message?!"

Disaster summary: Sometimes you hit RETURN and notice instantly that you just made a typo in your commit message. No problem: Git's "amend" feature is here to help! Other times, however, it takes days and weeks before you notice your spelling mistakes - and yet there's still a way to save your good reputation!

Deleting Old Commits

Apply in cases of: "Knock me over with a feather! 🤔 Did I create that commit?!"

Disaster summary: Buried deep inside your commit history, there's a commit that just shouldn't be there. Let's make it look like it never happened!

Squashing Multiple Commits Into One

Apply in cases of: "Holy cow! 🐮 Why did I create so many commits??"

Disaster summary: Committing in small, granular doses is actually a virtue. But of course there can be "too much of a good thing". If you've overdone it and want to combine multiple commits into one: here's how!

It's probably quite obvious by now: Git is an excellent safety net! You can undo and repair almost anything! The tricky part is mostly just knowing the corresponding workflows and commands.

To help your memory, you can download all 12 cases + 5 extra episodes and 1 cheat sheet as part of my free "First Aid Kit for Git".

About the Author

Tobias Günther is the CEO of Tower, the popular Git desktop client that helps more than 100,000 developers around the world to be more productive with Git.

12 Ways to Undo Mistakes with Git - Part 1

Tobias Günther — Tue, 29 Sep 2020 15:30:49 +0000

In this first part, you'll find 6 short & handy videos that help you learn how to save your neck! (Stay tuned for the second part with the remaining 6 cases!)

Discarding All Local Changes in a File

Apply in cases of: "Oh my goodness! 🤔 When did I write that?!!"

Disaster summary: Let's not sugarcoat this: you've had better days. You've worked on a certain file and wish you hadn't. But at least, you haven't committed your changes yet - so let's go ahead and discard all local changes in that file!

Discarding Chunks / Lines in a File

Apply in cases of: "Mama mia! 🙄 Was that me?!!"

Disaster summary: It's not that you messed up completely. It's just that some parts of your changes aren't as brilliant as they seemed at first. That's no reason to throw the baby out with the bath water: let's keep the changes that make sense and discard those that don't!

Discarding All Local Changes

Apply in cases of: "Bloody hell! 🙈 Let’s start over!"

Disaster summary: You had a feeling this morning, and it was correct: you should have stayed in bed. Because you clearly coded yourself into a dead-end street. So let's just discard all uncommitted work and return the project to its last committed state.

Fixing the Last Commit

Apply in cases of: "Holy moly! 😤 Too quick with that commit…"

Disaster summary: Word is on the street that you commit faster than your shadow. While you normally take that as a compliment, in this case it's more of a problem: because you littered the last commit's message with typos. Let's clean this up and make it so that no one ever hears about this!

Reverting a Commit in the Middle

Apply in cases of: "Deary me! 😩 How can I get rid of that commit?"

Disaster summary: Recently, it became clear that you and your old friend, commit a4f780b, don't get along so well anymore. Unfortunately, he's been in your code base for quite a while now. So instead of "deleting" him from your commit history, let's neutralize him in a friendly way: by creating a new commit that reverts his effects!

Resetting to an Old Revision

Apply in cases of: "Good gravy! 😖 I wish I could turn back time…"

Disaster summary: There was a time when everything was wonderful in your repository, when everything worked. Here's to these good old days! Luckily, you can turn back time and reset your project to an old revision.

It's probably quite obvious by now: Git is an excellent safety net! You can undo and repair almost anything! The tricky part is mostly just knowing the corresponding workflows and commands.

In the second part of this little series, I'll show you 6 more cases.

If you don't want to wait, you can download all 12 cases + 5 extra episodes and 1 cheat sheet as part of my free "First Aid Kit for Git".

About the Author

Tobias Günther is the CEO of Tower, the popular Git desktop client that helps more than 100,000 developers around the world to be more productive with Git.

8 Reasons Why Git is so Popular

Tobias Günther — Tue, 15 Sep 2020 07:11:27 +0000

When it comes to version control, everybody is talking about Git these days. But because it has become a standard, it's often adapted blindly - without knowing why exactly Git is superior to other systems like Subversion, Mercurial, or CVS. Even if you're already using Git, I think it's good to understand what makes Git great.

Read on for some hard (and soft) facts about why Git has become so popular.

1. Save Time

Imagine that, every time before moving your mouse, you’d have to wait for 5 seconds. Pretty annoying, right? With version control it’s quite the same – we’re also only talking about a few seconds per command, but it quickly adds up in your work day. Git, however, is lightning fast. Use your time for something more useful than waiting for your version control system to get back to you.

2. Work Offline

What if you want to work while you’re on the move? With a centralized VCS like Subversion or CVS, you’re stranded if you’re not connected to the central repository. With Git, almost everything is possible simply on your local machine: make a commit, browse your project’s complete history, merge or create branches… Git lets you decide where and when you want to work.

3. Undo Mistakes

Sometimes I make mistakes (it was a shocking discovery for me, too!). What I love about Git is that there’s a little “undo” command for almost every situation. Correct your last commit because you forgot to include that small change. Revert a whole commit because that feature isn’t necessary, anymore. And when the going gets tough you can even restore “deleted” commits with the Reflog – because, behind the scenes, Git rarely really deletes anything. This is peace of mind.

If you want to learn how to undo your mistakes with Git, take a look at the free First Aid Kit for Git, a series of short videos that teach you how to save your neck using Git.

4. Sleep Easy

Have you ever smashed a Subversion repository? I have (and I say this with the associated headache still in vivid memory…). With Git, I can be totally confident because every clone that someone on the team has on their machine is a usable backup. Additionally, almost every action in Git only adds data (deleting is very rare). That makes it pretty hard to really screw things up. And this is a good feeling.

5. Make Useful Commits

There are (at least) two problems when throwing milk, ice cream, and a tomato into a blender. First, after switching it on, no one can tell what you actually put in from looking at this mess. And second, you can’t “roll back” the tomato. The same holds true if you commit a bunch of unrelated changes (a little bit of feature A, something from feature B, a nice little bugfix, …). It’s hard for your teammates to understand what happened and they cannot easily roll back feature A if it causes problems. Git helps you to avoid this mess and create granular commits. With its unique “staging area” concept you can determine exactly which changes shall be included in your next commits, even down to single lines. This is where version control starts to be useful.

6. Work in Your Own Way

When working with Git you can use your very own workflow. One that feels good for you. You don’t have to be a code acrobat to qualify for using Git. Of course, you can connect with multiple remote repositories, rebase instead of merge, and work with submodules when you need it. But you can just as easily work with one central remote repository like in Subversion. All the other advantages remain – regardless of your workflow.

7. Don’t Mix Things Up

Separation of concerns is paramount to keeping track of things. While you’re working on feature A, nothing (and no-one) else should be affected by your unfinished code. What if it turns out the feature isn’t necessary anymore? Or if, after 10 commits, you notice that you took the completely wrong approach? Branching is the answer for these problems. And while other version control systems also know branches, Git is the only one to make it work as it should: fast & easy.

8. Go With the Flow

Only dead fish swim with the stream. And sometimes, clever developers do, too. Git is used by more and more well-known companies and Open Source projects: Ruby On Rails, jQuery, Perl, Debian, the Linux Kernel and many more. A large community often is an advantage by itself because an ecosystem evolves around the system. From code hosting platforms like GitHub and GitLab, to GUI tools like Tower all the way to tutorials and documentation: everything you need is already there!

Take Your Git Skills to the Next Level

Git can add tremendous value to your development workflow. But only if you go beyond the basic "commit, pull, push"!

There are lots of free tutorials on Git available - you only have to invest a bit of your time to become a better developer.