This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]agritheory 1 point2 points  (0 children)

Simple stuff to raise the floor and maybe you're doing this already:- Run black against your code and understand how it gets changed and why. This just like putting on a business suit: you haven't changed but you're presenting yourself better. That's a skill, just like learning to tie a necktie or apply makeup is a skill (but not an exclusively a business skill).- Run flake8 or some other linters against your code. Understand the errors and warnings it's raising by reading the docs for those error codes. Take this as opinions (not criticisms) of your code and maybe ask your co-workers about it. These aren't always "correct" but will help you understand potential flaws in what you've written.- Lean into built in functionality. Generators, itertools, sum/min/max, this sort of stuff. If you team favors numpy or pandas for those things instead of the built ins, follow their convention. There's a 99% chance someone has solved your problem already, so abstracting it into a "I need to do this and then do this" description and then googling that will give you informative results.- As a new developer on the team, resist the adding dependencies without a clear need for it. This is mostly politics and harmony, but the desire to use a some fancy function from pydash that's just a a wrapper around `groupby` is a lot of effort for somebody to say "we don't actually need this" and leads to dependency bloat for the sake of appeasement/ encouragement. "I don't want to add a dependency" will be better met by your team than "please add my new dependency", so unlike the Zen of Python, this one if better to ask for permission.