Minor rephrasing

Co-Authored-By: Lucas Rademaker <44430780+lr4d@users.noreply.github.com>

Author: sebastian-neubauer-by

_posts/2020-01-26-Pycon-de-writeup.markdown

@@ -173,7 +173,7 @@ Link: [https://www.youtube.com/watch?v=ZzKaFJxiDzA](https://www.youtube.com/watc
 
 Speaker: Tin Marković
 
-Summary: Tim currently works at [Kiwi.com](http://Kiwi.com) and focussed his talk on reducing "code debt" by refactoring the code base regularly. The key elements he touched upon were easy wins, like automating some checks by using `black`, `mypy`, `coala`, etc., patterns that hint to "smelly code", and possible reasons ranging from "historical reasons" to "high priority urgent hacky requests". This is often not easily apparent, however, tools like "SonarQube" can help in identifying sections of code that might need refactoring. Another element that he talked about are over use of decorators, which may seem like a good idea but can lead to non-obvious functionality, and recommended that they be only limited, and shouldn't at least alter the function signature and calls. Another suggestion that I liked was around code reviews, in which it may be good idea to structure the reviews at overall scope, followed by system scope, and finally code scope. This can help save coding time in case the architecture or overall scope needs to be changed. Overall, the focus was to always keep an eye out for code debt and try to improve little by little.
+Summary: Tim currently works at [Kiwi.com](http://Kiwi.com) and focused his talk on reducing "code debt" by refactoring the code base regularly. The key elements he touched upon were easy wins, like automating some checks by using `black`, `mypy`, `coala`, etc., patterns that hint to "smelly code", and possible reasons ranging from "historical reasons" to "high priority urgent hacky requests". This is often not easily apparent, however, tools like "SonarQube" can help in identifying sections of code that might need refactoring. Another element that he talked about are over use of decorators, which may seem like a good idea but can lead to non-obvious functionality, and recommended that they be only limited, and shouldn't at least alter the function signature and calls. Another suggestion that I liked was around code reviews, in which it may be good idea to structure the reviews at overall scope, followed by system scope, and finally code scope. This can help save coding time in case the architecture or overall scope needs to be changed. Overall, the focus was to always keep an eye out for code debt and try to improve little by little.
 
 ### Title: 10 ways to debug Python code