>>66148Some engineering advice for you:
(1) Don't try to over-abstract your code. Write what you need and if a pattern emerges frequently then you can write a general abstraction.
(2) Don't bother trying to optimize your code. Work on building the project you want and optimize when you run into performance issues.
(3) Avoid using every language feature. Every additional feature you use imposes complexity and increases the cognitive load of working with your software. This is also true of frameworks.
(4) Object orientated programming is mostly bullshit and will make your program into spaghetti. There is one exception though: encapsulation. Use classes as if they were related functions and state. This lets you build parts of your project as components that only have to focus on only thing. Avoid using every feature of OO programming if you want a program that's actually maintainable.
(5) You need to write tests to verify that your code works. At the very minimum you need tests to check that a feature you write can be used. Call this an 'integration test' if you will.
(6) There are some ways of solving problems that will only be suitable for toy apps and make it impossible to re-use in professional software. As a noob you won't know what these are but expect there to be a long learning curve.
(7) If you're trying to debug a highly complex error and you're drowning in complexity start adding assert statements everywhere. E.g. your function takes n. Assert n is within the range you expect. Assert all different variables for sanity checks. It can drastically reduce the amount of time you spend trying to guess what's wrong.
(8) Python packaging isn't great. If you want to make things easier on yourself try to avoid packages that have C dependencies (they need complication) and use only packages that use the standard library. Don't bother with Python 2 support. For building your own packages I recommend you just put all your source files in one folder with one init file. Trying to over-complicate how you organize your project will lead to you losing to complexity.
(9) You need to get serious about continuous integration across different OSes and versions if you want to release something to actual users.
(10) When it comes time to building a 'stack' for maybe a centralized system you should understand this: being able to deliver the most minimal system that solves a problem elegantly is the measure of good engineering. Any idiot can over-complicate a system and more often than not – they do. You want to have the smallest stack possible. Ignore neckbeards that use their stack to flex every buzzword they're using as these people are foolish and clueless.
Python is pure sex.