How to Code Like A Pro
There are many different routes into and around the programming landscape, all of which can be very daunting to newcomers. Experienced developers can be seen all over the web flexing their coding muscles and talking in riddles.
The focus of this piece is to share with you some of the key things all experienced developers know —there’s a slight focus on Python but most of these suggestions are somewhat language agnostic.
We’re not talking about semantics and syntax here, we’re talking about habits and practices. The advice that follows will be second nature to anyone that has been programming for any real time — perhaps they were given similar advice, or perhaps they learnt the hard way.
Its not that the programming community isn’t generous — just spend five minutes browsing stackoverflow for evidence of that. It’s that its easy to make assumptions about someone’s background and consequently fail to bridge some small knowledge gap rendering the rest of the advice almost useless. Imagine you were writing instructions to explain to an alien how to drive a car, and you opened with “start the engine”. Unless they have very similar vehicles on their own planet, there’s a whole bunch of prerequisite stuff that comes before that around unlocking and opening doors, getting in, and so on.
Use an Integrated Development Environment (“IDE”)
Although this one is super important, I was in two minds about actually including it — I was worried that it might be too obvious. Eventually I deemed it worthy of a place because I personally mess this up all the time, especially when working in Python.
One of the charms of programming is the simplicity of being able to type some words into a file and subsequently make something happen. Old habits die hard, and for whatever reason, I often find myself opening a basic text editor like notepad++and hacking away. I open a prompt in the same folder, and I’ll pass the name of my .py file to python a hundred times, debugging via print, before I catch myself being a chump and force myself to open an IDE.
If you’re already familiar with what an IDE is and what it does, feel free to skip to the next section. For anyone else, he’s a quick summary of what an IDE has to offer and how it will save you time.
There are many IDEs available, but its hard not to recommend Visual Studio Code. Its available on all operating systems, easy to use, and free. It also has an excellent getting started tutorial for most languages, far more detailed than I will be covering here. So what benefits does an IDE bring?
For a start, it’s going to start holding your hand before you even run your code. Syntax highlighting, auto completion and linting are all at your disposal — I’ve lazily captured all three of these in action in a single image:
Once you’re ready to run your python, the IDE really comes into its own. Now instead of just getting a (frankly, hard to read) stack trace dumped to the output when there’s an unhandled exception, it’ll stop dead, pointing to exactly the right line:
Now you can click up and down the call stack (bottom left) to see how we got to this bit of code, and hovering any variables, or sticking their name in the watch window (top left), will show you their current value. If you’re outside an IDE, the usual practise is to run, see an exception, add more logging in that area, rinse and repeat. If the program takes a minute to do some work before it fails, you really want to get as much info as possible at the point it stops, rather than have to sit through that minute again while hoping you haven’t made any typos in your prints!
Finally, being able to set breakpoints and step through the code line by line is an important weapon in the programmer’s arsenal — doing this in VS Code is covered on the tutorial link from above, but any IDE will work in a similar way.
If your entry point into Python is from a data science background, you might be most familiar with something like Jupyter Notebooks. Since VS Code supports these natively, you can have your cake and eat it!
Use source control
Another no-brainer for experienced developers is source control. While singing the praises of a modern IDE might be like teaching grandma to suck eggs, this is definitely advice I’ve found myself sharing repeatedly down the years. If you’re not working in an organization that has its own source control setup, I strongly recommend making use of something like GitHub for storing your code. Your repositories can be kept private though you could always open them up later if you want to share what you have done with the world.
Something like git can seem awkward at first, but persevere and you will be rewarded. Not only will your code be backed up remotely, you’ll also have a history of exactly what was changed with each revision along with the comments you submitted at the time. In fact if you install the right plugins to VS Code, those comments can appear right next to the code as you’re editing it.
Source control really is essential if you want to collaborate with other developers, but even for solo projects there is so much value in being able to look back and see when you changed something, and why you changed it.
If in doubt, push. An unwanted file can be removed later, but a deleted local change is lost forever.
There are a variety of tools that can be used to interact with git repositories — its probably worth trying a few and seeing which one you get on with best. When I want something nice and visual, I usually roll with SourceTree by Atlassian.
Keep your projects portable
Primarily when we talk about portability, we are referring to the ability to take the code and run it on a different system (e.g. from Windows to Mac or Linux). Python is fantastic in this regard — so long as you don’t try to use any modules specific to your development platform, you should have no issue running the code elsewhere. The most common gotcha (in my experience), is file path assumptions — just remember to use appropriate path functions to avoid code falling over due to minor filesystem differences.
It should go without saying, if you are specifically trying to write a windows application for windows users, and some module is going to make life a lot easier, use it without hesitation. The point is if your program doesn’t need to be specific to a particular operating system, then try to keep it flexible. Perhaps you’d like to run something in the cloud later on, and it might be cheaper to use one OS over another. Maybe you’d like a Mac-toting coder friend to help you with your project later. In short, don’t restrict where your code can be used unless you really have to.
Secondly, lets talk about the dependencies for your project. In my previous article about Python user interfaces, I proposed installing CherryPy with a one liner. The implication of that is that we’re going to install that module “globally”, which actually, isn’t ideal. It means I’ve installed the latest version on my system while I was writing up the article, and when the reader runs it, they’ll get the latest version at the time, which, for all I know, might not be compatible with the code I shared.
In the case of Python, the usual solution to this is “virtual environments” and the latest iteration of this is well documented here. In a nutshell, an activated virtual environment lets you install any of the modules you want alongside your project, and later write out the specifics of what you have installed using:
pip freeze > requirements.txtThis will record your current modules (and the versions of them) to the text file, and then the exact same virtual environment can be re-created later and or elsewhere by creating a new virtual environment, and running:
python -m pip install -r requirements.txtSo typically when submitting your project to source control, you would only include the requirements file (and maybe a .bat or .sh to make life easier), while adding the virtual environment folder itself to the “ignore” list for git (which will prevent tools like SourceTree listing all the environment materials as local changes all the time).
This makes it possible to collaborate with others who might be working on different platforms, but it also reduces the surface area for bugs that love to cling onto module incompatibilities and make life miserable. It is undesirable to return to an old project only to find that it no longer runs because it isn’t compatible with the latest version of something you updated globally for the benefit of another project.
Nodejs developers using npm are fortunate in that a local dependencies arrangement is the default way of working — you need to use an additional flag -g to get something installed globally. Again, you do not want to add the downloaded dependencies (in this case, the node_modules folder) to source control — the package.json file updated by the npm commands is all you need to push for other developers to be able to npm install and run your project correctly.
Keep writing code…
OK, so this is less of a tip and more of an observation. Programming is like any other activity — you’ll get better at it with practice and the only way to do that is keep at it. In your second year of programming, you’ll dig out an early program you wrote and laugh at the silly mistakes made by your former self. In year three, you’ll reminisce about how in your second year you were approaching some problems completely the wrong way. Twenty years in and you’ll be giving talks about huge architectural mistakes you made fifteen years into your career. As I’m sure is the case with most disciplines, you will never stop learning — something which for me at least, is a big part of the appeal.
I feel obliged to note — I don’t have any connection to any of the products I have linked to, I just didn’t want to recommend using a bunch of tools without providing specific examples. These are the sites and tools I typically use but the same functionality can be had a variety of ways — what’s important is to apply the broad concepts, what tools you use to do this is up to you!
