I can second Django. I have a pinned tab of Django in github.dev. Whenever I need to understand how something works, I feel through the source code and it’s extremely pleasant.
Every good programmer was once a bad programmer. They typically evolve into good programmers by iteratively identifying what they don't like about their own code and fixing those issues. Those fixes will often need fixes down the line, but that's okay.
Your first step for that identification should be to list your priorities for the end result. Readability? Robustness? Speed? Compactness? Reusability? Extensibility? Once you know by what metrics you want your code to be "good", you can start to examine where your code falls short.
The other key thing is to be unafraid to write bad code. It's hard to know when or why something's bad until you've held it in your hands, fiddled with it, given it a good swing. From there you can refine it by whatever metrics you've prioritized (per above).
Such a profound and counterintuitive truth - shows up everywhere and it is easy to miss the second order effect by focusing on the immediate impact.
For example, science tries to be more correct by seeking out the places where it is wrong, but so many people who would be afraid to be shown to be wrong and will pretend they aren't even when they are.
Or for another example, evolution makes things robust by intentionally eating shit and dying. Yet humans use this as an insult! So you have a beautiful idea that outperforms what we think is clever when given long enough, but look how badly our culture evaluates it!
The cleverest approaches are actually intentionally stupid: game theoretic reasoning in complex situations under imperfect information calculates the counterfactual regret of the worst outcomes it could experience relative to what it actually did. Collecting the right experiences is actually what lets you get to the better experiences.
Stop using python. Learn a typed language and realise that whilst python is great for the odd script, it sucks for anything larger.
Rust to me is a better python, can make python modules (py03 ftw) and the 30x speed up you get from using it is great... Oh yeah there is a borrow checker but it is not that bad once you grok it.
I love both python and rust, both have their trade offs and their purpose. It's like having both a manual saw and a chainsaw, and knowing when to use each.
What forced me to understand more fundamentals was actually studying leetcode. It led me to learn more about data structures, things like itertools, and other other algorithms.
Combined with a good book (eg learn python the hard way) it’s an approach that worked for me.
Really really read the Python tutorial and library reference. I mean really read it. There are so much nuggets in there that you'll be way above average Python developers by the end.
Whenever I am on a project, I try to write any tooling (code generators, utils, scripts, etc) in the tech that it uses. This forces you to broaden your horizons in the tooling. I even have a toolbox git repo that has a bunch of different tools written around this concept that I have often reused.
I would also recommend trying to 'think' in the language. Don't just try to push a solution into the language. Dig deep and see if there is something specific that makes the most sense to use.
Overall, I wouldn't try to push away your style entirely. I don't think you truly can. I would say the best bet is try to be a great engineer, with strong baseline principles which you then apply in the best way for each environment. Every decision is a tradeoff and many of the big schisms in tech come down to taste. Actively work to learn new ways of doing things. Work to understand other's code longer than you think you should.
Install linters, they will correct one class of unpythonic code.
Next google "idiomatic python." Idiom is the software word for the "right" way to do something.
After linters and idioms, code will probably look pythonic. Next is overall structure, which IMHO, python is not super opinionated on.
What becomes more useful to understand are the different software paradigms: procedural, functional, and object oriented.
Once you understand paradigms a bit, it's worth understanding object oriented in more detail. Misko Hevery has a lot of great things to say on that.
At this point, you should be able to write extremely boring python. Nothing is better than extremely boring code.
After that, watching videos, reading books, reading code, and writing code is the way.
Learning google's Bazel is probably also important, since any sufficiently large python project will crumble under its own complexity without Bazel or a system like it.
30 comments
[ 2.9 ms ] story [ 79.2 ms ] threadEffective Python is a great book which aims to teach people who already know the language how to use it well.
I ended up going to a front end team working in Angular. Now I miss it.
I believe this was a good one back in my day. https://github.com/psf/requests
That’s Django speak for “do not mess with these - they are not intended for the developer to use in any way.”
I like how Django’s documentation is so complete, that leaving something out feels like it’s a protected class.
The monkey patching worked great.
Your first step for that identification should be to list your priorities for the end result. Readability? Robustness? Speed? Compactness? Reusability? Extensibility? Once you know by what metrics you want your code to be "good", you can start to examine where your code falls short.
The other key thing is to be unafraid to write bad code. It's hard to know when or why something's bad until you've held it in your hands, fiddled with it, given it a good swing. From there you can refine it by whatever metrics you've prioritized (per above).
Counterintuitively, being afraid to write bad code actually leads to bad code.
Good code is not a state, it's a process.
For example, science tries to be more correct by seeking out the places where it is wrong, but so many people who would be afraid to be shown to be wrong and will pretend they aren't even when they are.
Or for another example, evolution makes things robust by intentionally eating shit and dying. Yet humans use this as an insult! So you have a beautiful idea that outperforms what we think is clever when given long enough, but look how badly our culture evaluates it!
The cleverest approaches are actually intentionally stupid: game theoretic reasoning in complex situations under imperfect information calculates the counterfactual regret of the worst outcomes it could experience relative to what it actually did. Collecting the right experiences is actually what lets you get to the better experiences.
Rust to me is a better python, can make python modules (py03 ftw) and the 30x speed up you get from using it is great... Oh yeah there is a borrow checker but it is not that bad once you grok it.
Edit: autocompelete!!!!!!
Combined with a good book (eg learn python the hard way) it’s an approach that worked for me.
I would also recommend trying to 'think' in the language. Don't just try to push a solution into the language. Dig deep and see if there is something specific that makes the most sense to use.
Overall, I wouldn't try to push away your style entirely. I don't think you truly can. I would say the best bet is try to be a great engineer, with strong baseline principles which you then apply in the best way for each environment. Every decision is a tradeoff and many of the big schisms in tech come down to taste. Actively work to learn new ways of doing things. Work to understand other's code longer than you think you should.
Every now and then read Zen of Python and try to understand it. Tim Peters somehow managed to fit enormous amount of wisdom in it.
Then set up some compete workers that read in jobs from a RabbitMQ queue. Have the Rest service add jobs to the queue and get back the results.
Also you can just read the official Python tutorial for learning stuff like with contextmanager.
Next google "idiomatic python." Idiom is the software word for the "right" way to do something.
After linters and idioms, code will probably look pythonic. Next is overall structure, which IMHO, python is not super opinionated on.
What becomes more useful to understand are the different software paradigms: procedural, functional, and object oriented.
Once you understand paradigms a bit, it's worth understanding object oriented in more detail. Misko Hevery has a lot of great things to say on that.
At this point, you should be able to write extremely boring python. Nothing is better than extremely boring code.
After that, watching videos, reading books, reading code, and writing code is the way.
Learning google's Bazel is probably also important, since any sufficiently large python project will crumble under its own complexity without Bazel or a system like it.
Review code and ask lots of questions, you wont learn anything if you don't ask why?
Once I understood fstrings, list/dict/set comprehension, and tuple unpacking, it became much easier to read and learn from others' python code.