-
Notifications
You must be signed in to change notification settings - Fork 22
/
Copy pathSune.tex
58 lines (37 loc) · 6.42 KB
/
Sune.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
\chapterwithauthor{Sune Vuorela}{The Circle of Four Steps to Become a Good Developer}
\authorbio{Sune Vuorela is a software developer who has been around KDE and other open source projects for more than a decade. Sune works as a software consultant doing Qt and C++ and whatever else is needed, mostly in areas of logistics or medical technologies. When not in front of a computer, Sune enjoys cooking, reading books, and being outdoors. Either alone, or with the scouts.}
\noindent{}KDE recently formulated a vision:
\begin{quote}
A world in which everyone has control over their digital life and enjoys freedom and privacy.
\end{quote}
Free software is a important step for that vision, and that has been how KDE has done its things since forever. But for free software to matter, people also need to be able to take advantage of the freedom they are given. Having more and better developers is needed for that. Partially to be able to understand code, partially to be able to write readable code. Both plays into being a good developer, and especially for newcomers asking how to become a good developer is a frequent question.
When I have the time and am in a joyful mood, my answer has been "Just follow Sune's four steps", partly serious, partly tongue in cheek, because they aren't actually formally described anywhere.
This is an attempt to write it up and how they are applied within various KDE projects as a part of KDE producing many new skilled developers.
The four circular steps to become a good developer are:
\begin{itemize}
\item Read some theory
\item Write some code
\item Read other people's code
\item Have other people read your code
\end{itemize}
These steps can be applied in any order, but to become a good developer it is important to visit all steps frequently.
\section*{Read some theory}
Extending your base of knowledge is an important thing to always be doing. Depending on your area of expertise and interests, it can be anything from reading about what a for-loop is, to the newest upcoming meta programming features in the upcoming standard of C++, the theory behind the Java Virtual Machine or how to do basic OpenGL for games. A simple, but important theory document originating from KDE is the document about binary compatibility in C++ libraries\footnote{\url{https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C++}}.
The theory can just be an introduction to new design patterns or a starter guide in a new programming language. But read. Learn. Try. Which leads me straight to the next point about writing code.
\section*{Write some code}
No one ever becomes a good developer without practical coding experience, or as they says it at the scouts, “Learning by Doing”. Not all code should be production quality or actually meet the public eye, but do publish as much as possible. It helps you and others with many of the other steps. Write code for fun. For experimentation. And for actual real life use cases. Have experimentation projects both in your primary programming languages as well as other programming languages. Maybe the other programming languages have features you like that are coming soon to your primary programming languages. This points nicely back to reading some theory.
KDE offers a quite fast “code to production” path with a large userbase that helps keep up the motivation for actually writing code.
In order to be able to write better code, getting experience with other people's code and improving other people's code is a really good way to become a better developer. And this points again forward to the next point about reading code.
\section*{Read other people's code}
A part of being able to know what good code is is to see good code, as well as bad code. Especially in various open source projects, it is very easy to get a hold of other people's code.
Reading other people's code leads directly to writing better code, as well as pointing to interesting areas for studying more theory.
The code reading can both be in private behind closed doors, or as part of public/formal code reviews, where you can discuss the code and suggest improvements.
By reading other people's code, one learns a lot by example about what to do and what not to do, and usually it ends up supporting the theory one has read. A simple thing like the importance of proper variable and function naming becomes much more clear once one has tried reading both code where the original author(s) had cared for that kind of details, and reading code where all variable names are single letter ones. Once you have tried reading both, you know how it actually helps.
KDE has only open source code, so it is easily available for anyone to learn from, and several KDE projects also have optional or mandatory code reviews for all new code, where everyone can jump in and participate in the code review to let both the reviewer and the author learn from each other.
\section*{Have other people read your code}
You need to know when you have done well and where you have room for improvements. When contributing to existing projects, the current developers usually review your code and help you raise the quality if needed.
KDE is full of people who do what they do for fun, and put a lot of work into ensuring that whatever code they have is maintainable. Reviewing incoming code is important for this. This also gives a unique opportunity to discuss your possible code changes with the original authors of whatever piece of code you are contributing to.
KDE has several systems in place for that. New projects have to go through an initial review to ensure that the basics are sane, and many subprojects either have optional or mandatory code review where experienced developers have to sign off on new code for existing projects.
\section*{End notes}
These four steps are crucial to continuously educate both new and existing developers. Most people want to get better at what they like doing, and this approach really helps. There is no requirement to spend an equal amount of time and energy on all steps, but all steps should be revisited. Also, make sure to occasionally get out of your comfort zone to learn something new.
Interacting with others around your code is important, and working with an existing code base is often better to learn from, in both good and bad ways, than starting all projects from scratch. KDE with its 20 years of history has an amazing code base and an amazing set of experienced and new people always helping each other in making everyone better.