It depends on what type of project you want to work on. To put it very briefly, Django has far more features and is set up to do a great deal more out of the box. Flask is more simple, but very extensible if you use the right packages. Personally I prefer working with Flask because my projects are usually REST API backends. My frontends are usually made in Node. But if you're doing full websites, and want it all in Python, then you'd prefer Django.

I'm gonna go in the opposite direction of @michielsikma and say that it's very import to be very specific from the beginning on what you spec for a project, especially if it's paid work and your making a written contract. I think you're right. I was thinking more of a specification for developers, rather than a contract that people will sign. But you're right that it's important to leave no room for doubt, as you can expect that to be used against you.

Personally I think it's important not to over-spec at the beginning of a project, especially if it's very big. I also try not to get too bogged down worrying about implementation details. To me, they usually follow naturally from the team's skill set and the desired functionality. Also, making minor adjustments to the spec will usually happen throughout a project, and there's always a chance of the budget being either relaxed or tightened. My project specifications always start with a simple introduction about what it is we're building, what problem it's supposed to solve, and which target audience it's for. When we get to technical details, I care about what technical restrictions there are—what type of server environment we're planning on using, what programming languages we'll use (based on what the team knows), etc. Those are the absolute basics and usually won't change. From there, I usually draft out the alpha releases, up to the MVP, followed by any number of subsequent releases. The further into the future a release is, the more vague they're allowed to be, since you never know what kind of data and feedback you'll gather. There's no point in specifying future versions exactly, when your customers might end up giving you a whole other picture. To me, specific implementation details belong in the issue tracker, and not so much the spec. The spec contains a high level discussion of the project, the basic technical road map, and just enough information to give everybody a decent mental image of the mature product.

@mcoquet I worked as a freelancer by myself for years and personally experienced this! It's an easy trap to fall into :)

Documentation is step number one, particularly the code examples. If things don't entirely "click" or I can't see the practical application of a new technology, I go to the videos.

There are many ways to do this. Personally, I try to keep up-to-date by following people on Twitter, which in my view is the most active source of developer information. Another great way is to work with other people. This is especially relevant for freelance developers who work by themselves most of the time. Interacting with other people in a professional capacity means you get exposed to tons of different ways of thinking.

I'm guessing you're asking for features, rather than simply things that are different. The main advantages Python 3 has: Generally it's more consistent and polished; legacy cruft has been thrown out completely, and more stuff yields iterators to improve performance and memory usage Integer division yields a float if necessary, making code more predictable More flexible rest syntax (e.g. x, y, *rest = range(10) ), simplifying code Keyword-only arguments, which makes your code (and the stdlib) safer by not accidentally mapping positional arguments to keyword arguments Chained exceptions to improve error reporting when something goes wrong The asyncio module in 3.4 is excellent stuff 3.5 features async and await syntax similar to ES2015 Also, new features will only be added to the 3.x branch from now on. Python 2.7 is legacy. This is a very simplified answer since there are tons of other differences, some of them more significant than others, but these are good selling points that might make you want to switch. If you're worried about compatibility with your older code, try 2to3 , which can help you make the transition. Most code does not take a very long time to port in my experience, though!

It's on top of my "would like to learn if I had more time" list!