Tools for New Developers-Part 3

“First we shape our tools, thereafter they shape us” ~ Marshall McLuhan

Part 1 of this series is here. Part 2 is here.

Photo by cottonbro from Pexels

Compared to many other fields, software development is a new discipline. Still, brilliant developers have spent years working on our field’s biggest challenges and have often created free tools to solve them. One of the benefits of working with software is that we can build on top of others’ hard-won wisdom and life’s work without having to understand all of it.

Here are some tools that speed up the way we write, edit and debug code.

Tool 10: Version Control

Photo by Christina Morillo from Pexels

Have you ever found yourself saving many versions of the same document or even folders of documents, adding a suffix like “version_2,” “final” and even “final_final_final”?

Have you ever forgotten which copy held an important bit of information that was removed in later iterations?

Did you ever make changes to a shared document at the same time as someone else and then have trouble merging the changes?

Do you worry about losing your work if a hard drive fails?

If you answered “yes” to any of these questions, then version control is for you. Honestly, I think it’s for everyone, but it’s especially useful for software developers.

As developers, we often work collaboratively with many other people on large, complex projects. Sometimes we create and release multiple versions of a piece of software in a single day.

The centre-point of most modern software collaboration and release tracking is a technology called “git.”

If you’re only going to take away one piece of advice from this article, do yourself and your soon-to-be-flourishing career a favour and read at least chapter 2 of the free “git book.” A solid understanding of this technology will make you much more attractive to potential employers.

Git — Getting a Git Repository

The next step is to create your own github account and get used to pushing your work there (I recommend creating private repositories at first).

Then:

git add .
git commit -m "improvements to my amazing new feature"
git push

As important as all the other advantages mentioned here, github is the world’s top site for developers collaborating on open-source software.

Contributing to well-regarded and frequently-used open-source software is one of the best things you can have on your resumé.

Tool 11: A Framework (or a few)

Frameworks provide the structure — fill in the blanks with your logic. Photo by Maria Orlova from Pexels

How do experienced developers create great software fast? They certainly don’t do everything themselves. They stand on the shoulders of giants, building on cleverly written and (hopefully) secure code.

At most software companies, developers make frequent use of many externally-developed “software libraries.” Developers use software libraries to take care of common but complex tasks that they don’t have time to properly implement from scratch.

A framework is like a set of libraries that all work together to provide the tools needed for building a complete application. This usually includes elements such as:

• database connection and query helpers
• user interface builders
• logging and metrics handling
• a “developer mode” that speeds up debugging

You’ll have a better chance of being hired by a software company if you have experience with a framework that they use.

For instance, if you’re a python developer you should probably be familiar with the Django framework. If you’re a frontend developer you should dive deep into at least one of the top javascript frameworks (at the moment, angular, react, ember and vue but this list could very well change next week).

Some people might tell you that libraries and frameworks aren’t always reliable and that it’s better to build everything yourself. Keep in mind that (unless you’re writing machine code) the very programming languages we use are a kind of framework built on top of lower-level software.

All around the world, developers are constantly relying on the efforts of those who got here before us, looked around and said something like “I think what this place needs is an easier way to serve HTML.”

Tool 12: An Integrated Development Environment (IDE)

Photo by Fotis Fotopoulos on Unsplash

I mentioned in part 1 of this series how important it is to have a good text editor to work in. IDEs are text editors taken to the next level, adding in tools for common developer activities such as:

• working seamlessly with libraries and databases
• running tests
• deploying code

…all in a single application.

You don’t strictly need to use an IDE for development, and some great developers don’t. But at least as many great developers do use IDEs as huge productivity boosters that can even aid in collaboration.

The world’s most popular IDE at the time of writing is Visual Studio Code. It’s a free application developed by Microsoft but much of its power comes from open-source plugins developed by 3rd-party developers.

Visual Studio Code — Code Editing. Redefined

There are many other language-specific IDEs like Xcode for native Mac and iOS apps and Eclipse for Java (although it works for many other languages too). JetBrains has an IDE for almost every popular programming language, including Kotlin, a language created by JetBrains developers. Jetbrains’ “IntelliJ IDEA Ultimate” is relatively expensive, but by adding plugins you can make it work with just about every programming language out there.

A well-configured IDE will allow you to navigate a complex codebase with ease, finding the definition and usages of functions and classes. They’re also great at doing refactoring, allowing you to quickly and reliably rename files and functions without breaking your code.

Becoming familiar with the features of your chosen IDE (and its keyboard shortcuts) can significantly speed up your development process. Find one that fits your language, your style and your budget, then use it to streamline your workflow.

Tool 13: A Terminal (shell) Application

Photo by Negative Space on Pexels

Terminal applications are based on the Unix shell, one of the oldest ways of interacting with a computer. These use plain text input and output to interact with your computer, its programs and the wider internet as well.

Using the CLI (Command-LIne) might seem limited, daunting and even scary at first, but put a little time into becoming comfortable working in this environment and you’ll find yourself able to accomplish some amazing things in a few keystrokes.

Even better, you’ll start taking advantage of the full power of your computer without being limited by a GUI (Graphical User Interface). For example, while there are GUI apps that wrap “git” calls, some of the most powerful functions are only available from the command-line.

Macs come with an app called Terminal, but iTerm2 is better (and free). Windows users can install PowerShell, and I highly recommend adding the Linux bash shell.

Most IDEs also have a terminal window built-in.

A Brief Tutorial of the Absolute Basics of Bash

Once you get used to a few commands you can easily write your own shell scripts, smoothly sending data from one utility to another and automating repetitive tasks.

Your terminal also provides many ways of customising your own workflow, including printing useful information in the command-line prompt.

And you can still become a brilliant programmer if you prefer your terminal to print black text on a white background. I promise I won’t judge you.

As we build exciting and useful software, let’s remember that lots of people have faced the same challenges we’re facing. Many of these challenges can now be easily solved with a well-developed toolset that’s available for free.

If you find these toolsets lacking in any way, please consider contributing to open-source libraries.

Your own contributions could end up running on millions of computers around the world, making life a bit easier for millions of people. Let’s go make the world a better place with our code.

A summary of these points (and more) is available in a “github gist” here.

Part 4 of this article is here.

You can handle it. :-)