added some infos on the time spent with programming

Author: thomasWeise

bibliography/bibliography.bib

@@ -612,6 +612,7 @@ @string { p_springer_verlag
 @string { p_story_needle = "{Story Needle}" }
 @string { p_taylor_and_francis = "{Taylor and Francis~Ltd.}" }
 @string { p_teubner_b_g = "{B.~G.~Teubner}" }
+@string { p_tidelift = "{Tidelift,~Inc.}" }
 @string { p_typis_academiae = "{Typis Academiae}" }
 @string { p_unicode_consortium = "{The Unicode Consortium}" }
 @string { p_universidad_del_pais_vasco = "{{Universidad del Pa{\'i}s Vasco} / {Euskal Herriko Unibertsitatea}}" }
@@ -705,6 +706,7 @@ @string { pa_springer_science_and_business
 @string { pa_springer_verlag = l_germany_heidelberg }
 @string { pa_taylor_and_francis = l_uk_london }
 @string { pa_teubner_b_g = l_germany_leipzig }
+@string { pa_tidelift = l_usa_boston }
 @string { pa_typis_academiae = l_russia_petropolis }
 @string { pa_unicode_consortium = l_usa_south_san_francisco }
 @string { pa_universidad_del_pais_vasco = l_spain_leioa }
@@ -1146,6 +1148,15 @@ @inbook{APM1991TOEAP
  doi = {10.1007/978-1-4419-8552-1_8},
 }
 
+@book{AS2019DS2OSRP,
+ title = {Developer Survey~2019:~Open Source Runtime Pains},
+ publisher = p_active_state,
+ address = pa_active_state,
+ date = {2019-04-30},
+ url = {https://cdn.activestate.com/wp-content/uploads/2019/05/ActiveState-Developer-Survey-2019-Open-Source-Runtime-Pains.pdf},
+ urldate = {2024-12-29},
+}
+
 @techreport{ASA1963ASCII,
  title = {American Standard Code for Information Interchange~{(ASCII~1963)}},
  date = {1963-06-17},
@@ -3308,6 +3319,15 @@ @article{T1999TLE
  doi = {10.1145/299157.299165},
 }
 
+@book{T2019MOSWBFDHOT2TMOSS,
+ title = {Making Open Source Work Better for Developers:~Highlights of the 2019 Tidelift Managed Open Source Survey},
+ date = {2019-06},
+ publisher = p_tidelift,
+ address = pa_tidelift,
+ url = {https://tidelift.com/subscription/managed-open-source-survey},
+ urldate = {2024-12-29},
+}
+
 @book{T2024BGAGVCPMATFTND,
  author = a_tsitoara_mariot,
  title = {Beginning \git\ and \github:~{V}ersion Control, Project Management and Teamwork for the New Developer},

text/main/introduction/programming/programming.tex

@@ -50,7 +50,7 @@
 So you now have the file with the program code.
 The problem is solved.
 
-Is that easy?
+Is it that easy?
 On one hand, you may wonder whether you made any mistake.
 We are people, we all make mistakes.
 The more complex the task we tackle, the more (program code) we write, the more likely it is that we make some small error somewhere.
@@ -61,20 +61,29 @@
 What if other programs may later need to use/run it?
 Maybe it can access some sort of sensor measuring something, or maybe it can convert data from one file format to another one.
 Then, other programmers may need to be able to at least understand how to correctly run the program and what kind of input and output data it will expect or produce, respectively.
+You must \emph{document} your program clearly.
+If you write a package that offers functions that can be used by other programs, there must be annotations that clearly explain what kind of input and output datatypes these functions accept and produce, respectively.
 
 What if this program is going to be needed for the next ten or so years?
 Maybe it could eventually become necessary to add new functionality?
 Maybe some of the software libraries you use get outdated and need to be replaced?
 There also are several situations in which a totally different person may need to work, read, modify, and improve \emph{your} code.
+They need to be able to read and understand your code easily.
+You cannot just write stuff down quickly, you cannot just produce one big soup of unformatted code.
+You need to both have good documentation and write clean and easy-to-read code.
 
 Or maybe you are a researcher, using \python~3 to implement some algorithm and to run an experiment.
 In order to make your experiments and results replicable, you would probably want to publish your algorithm implementation together with the results.
-This only makes sense if your code is at least a bit readable.
+This, agin, only makes sense if your code is at least a bit readable.
+The names of variables and functions must be clear and understandable.
+The coding style should be consistent throughout all files and it should follow common conventions~\cite{PEP8}.
 
 All of these things need to be considered when we learn how to program.
 Because you do not just \inQuotes{program,} you develop software.
+Indeed, a good share of programmers usually spend only about 50\%~of their time with programming~\cite{T2019MOSWBFDHOT2TMOSS,AS2019DS2OSRP}.
+Of course, we cannot cover all other topics related to software engineering in a programming course.
 
-In typical courses, such aspects are ignored.
+However, in typical courses, such aspects are ignored entirely.
 In a typical course, you learn how to write a small program that solves a certain task.
 The task is usually simple, so the teachers are able to read your code even if you have ugliest style imaginable.
 Also, nobody is ever going to look at or use the programs you write as your homework again.
@@ -90,7 +99,7 @@
 
 As a result, this will be a course which is very practice centered.
 We will learn programming the \emph{right} way.\footnote{%
-Well, at least, what I consider as the \emph{right} way.%
+Well, at least, what \emph{I} consider as the \emph{right} way.%
 }
 The downside of this approach is that we will sometimes go off on tangents in the text.
 While I am introducing variables in \cref{sec:variables}, for example, I will also explain how to use a static code analysis tool designed to find type errors in variable use.