Geek's diary

Someone shared a link on Twitter to this article from 2013:

https://pythonrants.wordpress.com/2013/12/06/why-i-hate-virtualenv-and-pip/

and I wanted to comment on that, which then turned into somewhat longer reaction, so I'm writing this article.

Most are fair points, Python packaging is far away from perfect and any good Python programmer won't try to convince you that it is perfect.

The truth is though, that it's not worse than packaging in Ruby (Bundler), NodeJS (NPM) nor PHP (Pear, PECL, Composer) nor Go. The same applies to environment isolation, where NodeJS, PHP, Go have basically no proper solution and the hack called RVM for Ruby? Well, it kinda works, but I'll better be using Virtualenv if I'm supposed to choose between these.

There's no reason to point to Python and say that it's Python's problem, it's generally a problem across most languages and yes, LXC is trying to solve it across all languages.

Also, author should realise there wasn't LXC or it definitely wasn't part of almost every Linux kernel, so it definitely wasn't as easily adoptable as it is now in 2015, when we've got Docker and Rocket on the way.

I don't want defend Python or other languages that do things the way they do or pretend that there's no problem. There is a problem, but it isn't about Pip nor Virtualenv, the problem is much broader.

More importantly, I think that people like Ian Bicking and others who contributed to the Python ecosystem and at least moved it a bit further and brought a decent solution at that time (2007) deserve respect.

These guys IMO definitely deserve much more respect than author of that article.

When it comes to scalability, most people think that it's all about HA systems, oversized machines (or cloud instances) etc. In general, they just think about the whole scalability issue in technical manner.

Well, it is technical but from my point of view scalability is more about how you can scale as the whole company and company is not created just from computers, but also people.

Company pays money to programmers, therefore it is crucial for any company to use programmer's time as effectively as possible. It is crucial for any company to increase the long-term value of the whole company (or its product) while using the human power of programmers.

What do I mean?

How long does it take a new programmer to understand your codebase in order to make changes effectively?

Does it take weeks, months, or even years? You're probably doing good job if it takes just days.

Programmers usually spend more time on reading (understanding) the code then writing it, that's just the fact, but you can still decrease that amount of time needed to understanding the code.

This is not a definitive list, but it is the list of my recommendations coming from few years of my programming experience:

1. Do Code Reviews

There's just no better way of getting know each other's code than doing code reviews. There's much more (advantages) behind code reviews, which would be for separate article.

In fact, two persons (author + reviewer) knowing any specific piece of code is always better than just one (author). Ideally, you can even find a bug or performance issue before it even reaches any user testing phase.

And - what's more important - when there are two different opinions (between author & reviewer), these guys will have to find compromise, which will most probably help any third guy to understand the code easily and it will help both guys to learn from each other.

2. Define Coding Standards

Coding standards doesn't need to be any sign of large corporation or European Union, where you need everything to be standardised. It may help all members of your team, even you and even the future members.

It actually helps you to become one team instead of bunch of individuals. It is obviously important to find a consensus and ensure that the majority of your team agree with the definition of standards and again, it is not necessary to standardise everything.

You can start with just couple rules, eg. where to put braces, how many (if any) spaces to put around which keyword etc.

When you write down this list, it is also good to have tools in place which will help all developers easily check whether the new code is compliant with these standards.

3. Choose a “good” framework

At first, it is really useful to use an open-source framework. Unless you're Google or someone, who anyway probably already tried to use all available open-source solutions, only then you may think about building your own framework (actually you should have a really good reason even if you're in that situation).

Why? You save time (= money) and headaches of your development team. Why? Because someone else in the community already covered the most use-cases. Why? Because you can scale up by just using existing code somewhere in the community. Why? Ehh...

Why on earth would you like to spend money on reinventing the wheel? There's probably no reason, but still so many companies are reinventing the wheel (or actually trying to do so).

What's the conclusion? Choose a framework which is well extendible and have active community.

4. Write the Clean Code

This would be for a whole new article or even more articles, but to make the long story short, just read the Clean Code.

Read it and encourage all other members of your team to do so as well.

This may sounds like an advertising, but this book has been written by programmers for programmers. These guys created its own best-practices which helped them to increase readability of code = reduce the amount of time needed to understand the code by others = save money.

Be aware that others === yourself after couple months.

You would probably find the same things after couple years of coding, but here you can have all this available without having to make your own path with many fails on it.

5. ?

It is almost 3 years since I started working with Socialbakers. There were up-s and down-s (as in any other company), but all the time, I really loved it here and I learned a lot (on all of my 3 positions there). I enjoyed working in that environment and watched how Candytech with tens of people rapidly grew up in such a large and known company like Socialbakers with over 200 people and over thousand of clients over the whole globe. Many people there did (and still do) a great job.

What did I love at most as a developer?

quite a flat structure of the company (~3-4 levels consisting of developer, Scrum Master, Product Owner, management)

the variety of technologies they use in production (PostgreSQL, MongoDB, ElasticSearch, NodeJS, Redis, RabbitMQ and much more)

internal lectures and workshops for knowledge share across the whole dev team

build something really global for customers around the whole globe

dealing with timezones and being aware of that you have nothing like "the time when your customers are sleeping and you can have downtime"

If anything of above sounds like a challenge to you, send your CV over to Martin Homolka.

Anyway 3 years is a really long time and I love changes and challenges even more.

I got a chance to fulfil couple of my life goals:

to work abroad

to learn english more by speaking it on daily basis

and that's the type of offer I cannot just let pass through my fingers.

I'm joining guys from Zappit in the North London at the very beginning of May as a Senior Developer.

Why them? Because I see a great potential in NFC and QR and there's still a quite small amount of companies, which really build business up on that and that makes them almost unique.