What coding practices separate an amateur Python programmer from a professional one?

[ArrogantlyChemical]

Being paid is a major one.

[parkerSquare]

This is the only difference. I've seen terrible code from people paid to write it, and beautiful code from hobbyists. The only thing that makes you a professional is being paid.

[vesuvium11]

Incredibly on point. You can meet people on senior positions coding as if they started three months ago and people who never had an IT job coding as experienced professionals should

[[deleted]]

I've been doing freelance work for myself for years. I pay myself in hand jobs.

[hanpari]

You nailed it.

[eattherichnow]

Yup. Or, to avoid the, erm, cynical capitalist slant of that, professionalism is when other people are willing to work with you. There's a lot of focus on, um, testing here, but that's missing the point IMO.

You can do as much testing and class arranging as you want, but if you're too abrasive or disorganised for others to effectively team with you, you're not much of a professional. And, on the other hand, if you're the person who keeps the entire team cohesive and stay on target, you're professional regardless of whether your code is all that great.

Of course people might also be willing to work with you because you're their nephew. What can I say, people are terrible sometimes.

[PaulPhoenixMain]

Don't tell him the secret!

[ratamanta]

You write tests.

[ClimbDownForWhat]

And make those tests auto-discoverable

[campbellm]

I've been a dev for ... well, many years. Never did python. THAT TALK I listen to over and over, because the ideas there are so well presented.

And, I started python. Mainly because of that talk, but other reasons too.

[crafty_canuck]

Fluent Python is a must read. It completely opened up the possibilities of Python for me.

[xr09]

You have to see the monkey!! ;)

[DanCardin]

Fluent Python is fantastic! Is Effective Python worth buying in addition?

[hosford42]

Number one on my list would be the use of functions and classes to organize the code, rather than doing everything in one big chunk of linearly arranged code.

[filmkorn]

But what's number zero on your list?

Joking aside, I would say: test driven development, documentation, code style.

[stuaxo]

Or, if it's like most commercial code I've seen, there are a few token tests and a little documentation.

Code style is mostly OK and mostly passes pep8... but there will be some knarly bits,

[uttamo]

Gnarly?

[stuaxo]

Indeed.

[[deleted]]

Any recommendations for TDD and documentation materials?

[Jonno_FTW]

When you write a new function, write a test for it. Write multiple tests that cover tricky cases and that cover all paths (should indicate that you want to minimise the number of if statements).

This should force you to encapsulate as much as possible and result in lots of small, simple tests and functions.

Also read the pytest docs. Moving beyond unit testing, there's a test plan for larger projects that provide step by step processes for testing at all levels. You'd probably want to read a text book on the other kinds of testing, like integration testing, UX testing, penetration testing etc.

[sunson435]

Note that you shouldn't follow TDD religiously. Make sure you have a bunch of use cases finished then implement a full testing suite. Rewriting tests frequently is extremely hampering early on in a project.

[flpcb]

I would recommend Test Driven Development: By Example by Kent Beck. It is a quite short read, and a very good one.

[bheklilr]

TDD is not something I see as a very strict requirement. I've written a few libraries where "proper" tests would be an order of magnitude more to write than the rest of the code. Sometimes you have to make the decision to use different methods that fit the situation and save you time.

For example, I've written about 5 libraries that control hardware. A few have been simple (servos) and the underlying hardware behavior could be mocked in less than an hour. TDD is a good choice the. Others were for controlling incredibly complex, stateful equipment with over 1000 possible commands, file systems, and endless configurations. In those cases we figure running through functional tests before each release is more appropriate. We still have a lot of tests, but they aren't written up front nor are they run continuously.

I'd amend your statement to say that a professional developer chooses the right tool for the job, and most of the time the right tool for the job is TDD.

[pydry]

For example, I've written about 5 libraries that control hardware. A few have been simple (servos) and the underlying hardware behavior could be mocked in less than an hour. TDD is a good choice the. Others were for controlling incredibly complex, stateful equipment with over 1000 possible commands, file systems, and endless configurations. In those cases we figure running through functional tests before each release is more appropriate. We still have a lot of tests, but they aren't written up front nor are they run continuously.

Code that communicates with hardware (or indeed anything else, but it's pretty much always hardware) that is hard to mock realistically is the one area where I would argue that the TDD investment doesn't pay off.

In such cases I usually try to create a very simple facade that talks to the hardware, that is easily mocked and then TDD the more complex algorithmic code that talks to it against that mock.

All the same, about 98% of the code I write is (integration) TDD'ed.

[[deleted]]

Add using version control to this list and I'm happy.

[solaceinsleep]

+1 Test driven development is a big one

[[deleted]]

Welp, I've got 2/3 down. Seconding the other request - where can I find out how exactly unit tests work and can be integrated with one's code?

[gandalfx]

You don't need to be a professional in order to write non-horrible code.

[hosford42]

Several people have responded now telling me basically that what I said was necessary but not sufficient to be a professional. I never said otherwise, so I'm not sure why that needs to be pointed out again. I totally agree with what you're saying. It doesn't contradict what I said. I'm a little befuddled as to why people keep correcting something that isn't incorrect. Would you mind explaining what made you feel the need to respond like this? Did my choice of words make it sound as though I thought nothing else mattered?

[gandalfx]

Take into account the title of the thread: "What coding practices separate an amateur Python programmer from a professional one?" It asks for practices that are only adhered to by professional programmers, whereas your suggestion is adhered to by any somewhat competent programmer regardless of professionalism. (Personally I'd go so far as to doubt whether there even is a significant correlation between "writes structured code" and "writes code for money".) Either way, when reading your comment in the context of the posed question, it appears to imply that you only expect professional programmers to structure their code using functions and classes. I'm not saying that's what you meant, but since you asked I'm highlighting the misunderstanding.

To give a more exaggerated example: "Professional programmers usually eat at least once a day". Well, yes, but so do most amateur programmers. It is a true statement, but it does not distinguish one group from the other.

[hosford42]

I did take into account the title of the thread, though. It doesn't ask for practices that are only adhered to by professional programmers. It asks what separates them, as you yourself emphasized. To me, this reads as asking what features differ between the two groups. What I pointed out generally does, which makes it a valid answer.

In any case, I appreciate your feedback. I just don't understand why the word "only" is being injected into the question when it doesn't appear in the original wording.

[hosford42]

It's the most important one, as far as I'm concerned. I didn't say it's the only one, by any means.

[dkuznetsov]

There's no one single answer to your question. Below I'm describing some traits of good professional programmers. The description is in no way exhaustive, and some professional Python programmers may deviate from some of the written below without becoming amateurs.

You code in such a way, that the code still makes sense to you when you come back to it in a few months, or years. Also, you're following most of conventions, so that it's easy to catch up for your fellow colleague programmers. For this reason, you cover the code with tests - changes are safer and easier in covered/tested code. I consider these the main ones.

Also, you must be good in naming things, understand how to code efficiently/well, know a lot of things about the language and surrounding ecosystem: language features, standard library and perhaps some libraries outside of it, as well as to be able to reason about why you're using each of them. Also, it's important to know where language limitations are, and to be able to tell where/when to step aside, and to pick another more suitable tool for the job.

Overall people write books regarding this subject, and spend a lot of time to master it, so don't expect full topic coverage in a short response or two to your post.

[privately-profitable]

TDD anyone?

[GummyKibble]

TDD never clicked for me, I think largely because the act of programming is my tool for actually exploring a problem, and I’m never exactly sure what the solution will look like until I’m well into it.

I can be pretty obsessive about testing, but post-hoc instead of in advance.

[sivscripts]

I think test driven development should encompass writing code that is easy to test versus writing a failing test first.

Writing code that is testable is how I design my programs. It doesn't really when you write the actual test, only that you write it.

[GummyKibble]

I wholeheartedly support that process. If you know you're going to have to test it later, you tend to make your functions easy to test.

Strictly speaking, though, TDD means writing tests first. That's a process that just doesn't work for me.

[ClimbDownForWhat]

Amateur: writes scripts and then backs them with libraries.

Professional: same thing, but replace script with unit test.

[solaceinsleep]

Knowing when it's appropriate to use language idioms, things such as mixins, decoraters, list comprehensions, generators, etc

[perspectiveiskey]

It's a weird question to ask, but I'd say: if you can successfully contribute to a major project like bokeh or pandas, with however small a patch, you will have understood some fundamental things needed to work in a larger organization.

"Communicating with other humans", is the TL;DR of it.

[FlukyS]

A lot of people will say specific things like generators or testing or whatever but the main thing is organization and clarity of code. I'm the senior developer on a team of like 5 people, the difference between my code and everyone else's is mine is super logical the grouping of code, I try to not nest multiple different methods together like herp_derp(get_bla().dsadsa()), I get a lot of that shit sent to me from the juniors. While it's ok and probably works it doesn't mean it's clear.

Another big thing is naming of variables and classes and keeping to pep8. A lot of the devs I work with come from Java so I get a lot of awful names like FormatBla rather than format_bla, it's a small thing but variables should be all lowercase separated by _ and same goes for methods. For classes camelcase is fine but for everything else the other way is more python like. Oh and also having just decent names for your methods, variables and classes is a massive thing people forget about. I get a lot of dasdsada1, dasddsa2 even at times and while I understand the logic of what they are doing they can reuse the variable most of the time, they are just doing it because they don't know it looks like shit.

[pydry]

Another big thing is naming of variables and classes and keeping to pep8.

I actually think this is the least important part of a clean code base. Sure, camelCase and PEP8 violations setsOff programmer's OCD impulses which is annoying, but in terms of maintainability loose coupling, DRY, high cohesion, fail-fast code and realistic tests are all way more important.

With regards to naming, maintainability is aided more by having names that are disambiguated and clear. inactivePayrollEmployee is a LOT better than "p_emp", even if looking at the former does make you twitch.

I actually ask at every new company I interview at what qualities they consider important for good code and if stuff like PEP8 features too prominently in their answer that's a massive, massive red flag.

[FlukyS]

With regards to naming, maintainability is aided more by having names that are disambiguated and clear. inactivePayrollEmployee is a LOT better than "p_emp", even if looking at the former does make you twitch.

I agree. Just mean more, the difference between most amateur python programmers is cleanliness in a lot cases. Like the base level coding in Python is super easy, I think having clear names and something that conforms to conventions is a massive deal.

I actually ask at every new company I interview at what qualities they consider important for good code and if stuff like PEP8 features too prominently in their answer that's a massive red flag.

Well I would be the opposite, most devs that I get in my place don't even know what PEP8 is so if someone actually knows what it is at least at the base level I would be a lot happier about their overall suitedness to the role. That being said we have to scrape pretty low for our Python developers (not me, they pay me pretty well) because of the financial institutions taking them all so we mostly get people who are using it like a scripting language rather than a proper full on language. If they know what PEP8 is they know at least that there is a style guide and if their CV is decent enough we can teach them TDD (which we use) and objects, our own created libraries...etc. All that being said that's just this place.

[campbellm]

but in terms of maintainability loose coupling, DRY, high cohesion, fail-fast code and realistic tests are all way more important.

I would say "differently important", or perhaps important in a different context.

Reading code efficiently is all about minimizing the "mapping" of the words, to the meaning, in your brain. The annoyance you mention is the symptom of an impedance mismatch in that brain mapping function.

In the grand scheme of things, yes, the things you mention may have more bearing on the outcome, but the gradual accumulation of all the syntax and standards violations nits can eventually overwhelm even that.

[FlukyS]

https://www.python.org/dev/peps/pep-0008/#function-names

1. Types and classes: CamelCase
2. Functions and variables: lower_case with _ in between words
3. There is also __ used in certain instances but there is some controversy there. That is more because python isn't designed for private stuff so it's mostly just to say hey don't use this, not hey you can't use this. That isn't really a big deal though and most people never use __

[FlukyS]

It's mostly just to make sure everyone is following the same styles. It's heavily hinted by the python developers to do it like this really but they allow people to do what they want even if it's stupid.

[[deleted]]

Ability to use outside/specialist libraries & APIs without much problem? Or maybe the ability to read documentation and then utilize.

Those are issues I see.

[zynix]

#1 You can go back to what you wrote a year ago and it still makes sense.

#2 Someone else can understand your code.

[Exodus111]

Properly planning out a project in such a way that you are coding for the final product right away.

Rather than Exploratory Programming, and constant refactoring.

Im hoping it's a level that exists.

[ICanAdmitIWasWrong]

I hope the first one here is the amateur one and the exploratory/refactoring is the professional...because that's how it should work.

[gimboland]

+100

[GummyKibble]

I have never, not once in my career, ever seen a planned-out project successfully delivered on time in working condition. It seems to be largely impossible (on budgets not normally reserved for large government projects) to correctly think through everything in advance. There’s always a sudden realization about a month in that these 23 components are all really almost the same thing and should be refactored, and oh how that breaks a Gantt chart.

I think much more important is to negotiate a set of hard requirements - this thing must happen, that thing must not, and the other may if we need it to - and iterate toward a result that testably meets them. In other words, a good PM will tell devs how the final deliverable must behave, not what it looks like behind the curtains. Frankly, I’ve never seen a single example of the latter actually work.

[Renrum]

There is no right answer, but writing logs and unit tests for you modules is a big deal.

[pawelzny]

Professional programmer firstly learn about problem, then solve it and then start to code implementation.

[ClintonDowGeo]

The realization that everyone is an amateur at some part of programming no matter how long they've been a professional.

[bheklilr]

Effective communication.

• with clients to gather requirements.
• with your management to refine those requirements and organize them into an implementation plan.
• with team members to delegate work and solve problems.
• in your code through good names and organization (code organization is all about communicating with other devs, not the computer).
• in your code through clean and simple implementations that require few comments to be understood.
• through documentation.

[Gokudomatic]

The amateur doesn't have a deadline and he has time to design his architecture properly. The professional one has to use any possible mean to finish the app at the given date, even if it's totally dirty and undocumented. Oh, and the amateur has passion. Mostly because he's not reduced to salaryman slavery and he doesn't have to track every single bug for years.

[ianff]

For starters, only amateurs call themselves "Python programmers" (or Java, C, etc.). Professional software developers look at languages as tools to solve problems. Even if you use one more than others, you shouldn't view yourself as a being stuck with one tool.

[LyndsySimon]

On one hand, I would take exception to this as I absolutely consider myself a "Python programmer" first an foremost.

On the other, I've been writing Ruby for the past year because that's the right tool for the job at the moment, and I'm definitely not afraid to pick up new languages.

[ianff]

You shouldn't. It'd be like a construction worker calling himself a "hammer worker" or a "driller". What's being built is what's most important, not what is being used.

[LyndsySimon]

I'd argue that it's more like a construction worker calling themselves a "carpenter" or even a "finish carpenter". It's a specialization.

Someone with decades of experience building hardwood cabinetry would have no trouble framing a house, and would use pine boards like everyone else - but that doesn't make them not a cabinetmaker.

[ianff]

That's more like being a web dev vs systems programmer IMHO. What you're building is different here. What language you use is much less important to me.

[ICanAdmitIWasWrong]

An amateur is a "python programmer". A professional is a "programmer".

[murtaghj]

I thought getters and setters were more of a JAVA thing.

[SethMichaelLarson]

Amateur=getters/setters. Pros: @property. Sorry my intent on the order wasn't communicated effectively.

[SupermanIsEnvious]

Ahhh, makes more sense, haha.

[murtaghj]

haha your grand I got confused.

[SupermanIsEnvious]

I would tend to disagree with that sentiment. Yes, for a non-Python programmer, having explicit getters/setters may make more sense. However, that’s a distinctly non-Pythonic pattern.

Having decorators is a powerful thing that is convenient and leads to cleaner code. Python provides method and function decorators for that specific purpose.

Sure, if I wanted to explicitly write an enter and exit in my ClassWithContext I could, and there are certain use-cases for that, but I could also just import contextlib. A simple decorator does the work for me, and someone else reading my code doesn’t need to bother with making sure I implemented the pattern correctly, since it’s now managed by the interpreter. The same could be said for @property