\documentclass[a4paper,german,12pt]{article}

\usepackage[utf8]{inputenc} % Kompatibilität
\usepackage[ngerman]{babel} % Deutsche Silbentrennung
\usepackage{mathtools} % Viele Mathe-Tools
\usepackage{hyperref} % Links, die man klicken kann
\usepackage{xcolor} % mehr Farben
\usepackage[margin=1.5cm]{geometry} % Seitengeometrie einstellen
\usepackage{graphicx} % Bilder einbinden.

\begin{document}

Einleitung

In dieser kurzen Abhandlung wollen wir erklären, wie man auf die (scheinbar) 
falsche Aussage kommt, dass die Summe aller natürlichen Zahlen 
negativ ist und einen Wert von minus einem Zwölftel annimmt.
% man kann Umlaute auch schreiben, indem man bspw. \"o für ö eingibt (sollte man
% bspw. die Umlaute nicht auf der eigenen Tastatur haben)

Warum diese Aussage zum einen nicht ganz falsch und zum anderen 
auch wichtig ist, wird euch vielleicht im Verlauf eures 
Studiums klar werden. Ansonsten kann man sich auch einfach darüber freuen, dass 
man etwas gelernt hat, was manchen Mathematikern die Haare zu Berge stehen lässt 
-- nicht aber Bernhard Riemann.

1846 -- 1849: Studium in Göttingen und Berlin

1849 -- 1851: Promotion bei Carl Friedrich Gauß

1854: Habilitation

Erklärung

Wir können die Aussage aus Abschnitt 1 auch in eine Formel 
schreiben, das Resultat sehen wir vielleicht in einer Gleichung.

Ist das wirklich korrekt?

Diese Frage ist durchaus berechtigt. Man kann aber auf formale Art und 
Weise zeigen, dass die richtige Interpretation zum 
Ergebnis führt.

Na klar.

Im vorigen Unterabschnitt haben wir bemerkt, dass wir die Summe auffassen 
können als einen Grenzwert der Zetafunktion.

Epilog -- Ein paar Programmiertipps von Rob Pike

Most programs are too complicated - that is, more complex than they
need to be to solve their problems efficiently.  Why? Mostly
it's because of bad design, but I will skip that issue here because
it's a big one.  But programs are often complicated at the
microscopic level, and that is something I can address here.

You can't tell where a program is going to spend its
    time. Bottlenecks occur in surprising places, so don't try to second
    guess and put in a speed hack until you've proven that's where the
    bottleneck is.

Measure. Don't tune for speed until you've measured,
    and even then don't unless one part of the code overwhelms the rest.

Fancy algorithms are slow when n is small, and n
    is usually small. Fancy algorithms have big constants. Until you know that
    n is frequently going to be big, don't get fancy.  (Even if n does get
    big, use 2. first.) For example, binary trees are always faster
    than splay trees for workaday problems.

Fancy algorithms are buggier than simple ones, and
    they're much harder to implement.  Use simple algorithms as well as simple
    data structures.

\end{document}