When I started programming, I knew nothing about anything. Well, development-wise anyway. ;)
I had no clue what version control was or what "the cloud" really meant. I didn't know about kanban boards, user groups, what Agile was, or what the point of points were (okay, I still don't know that last one). I worked in a small IT shop where the "production release" consisted of a few hasty prayers on Friday, copying files to a network folder over the weekend, and preparing for the worst when everyone logged in Monday morning.
You learn a lot in a decade - different technologies, different techniques and approaches, and lots of different tools. In fact, if someone were interested in software development, it'd be a good idea to brush up on some of the many useful tools available that make development work easier.
Here are my top 10 development tools.
Hands down, GitHub is probably the most useful tool to get started with. It's mainly used for tracking a complete history of code changes, but it's frequently used for lists, tracking bugs, and collaborating on documentation, among other things.
My first experience with source code control was Visual SourceSafe, which tended to "lock" files you were merely viewing (right before you left for vacation), screwing the rest of your team. Subversion was a huge step up, but the full repository of code existed on a single server, from which you could only get the latest version of files. Git is decentralized, so every developer clones the whole thing, which has some real advantages. And GitHub has become the de facto standard for serving up Git repos. Nearly anywhere you go or any project you work on will involve GitHub.
If you're interested in learning more, here are a few resources to get started:
- Resources to learn Git
- Learn Git- Git tutorials, workflows and commands
- Learn Git Branching
- GitHub Guides
I've also written about Git / GitHub a few times too:
- Markdown Tricks for GitHub
- What is a Git alias, and how do I use it?
- 5 Things You Can Do With a Locally Cloned GitHub Wiki
- Hosting a GitHub wiki on Ubuntu (and keeping it in sync)
NUnit, xUnit, etc
Writing code and safely storing it isn't enough. How do you know it isn't broken right now? Or tomorrow? Or next year when 10 other people have updated your code a hundred times? That's where writing tests comes in. Some even write the tests as they're writing the code.
There are a lot of test suites out there, depending on the scope of what you're trying to test and what environment you're developing in... NUnit or xUnit for C#, JUnit for Java, EUnit and CT for Erlang, Cucumber for Ruby, and the list goes on and on. It's impossible to recommend one as better than the rest - there are simply too many things you might be trying to test.
But there are some important basics for any type of testing... here's a few links to get you started:
- Software Testing Levels - Software Testing Fundamentals
- What Is Unit Testing?
- What is Integration Testing (Tutorial with Integration Testing Example)
- A quick intro to Dependency Injection: what it is, and when to use it (important concept for testing)
- Software Testing Training – Testing Basics for Beginners (a YouTube playlist)
Travis / Jenkins / CI
Right, so your code is safely stored and you've got a nice test suite you can run to prove it's behaving correctly. Wouldn't it be nice if you didn't have to run that test suite manually every time you made a change?
Another incredibly useful tool to get familiar with is a continuous integration (CI) server, that can automatically compile and test your entire codebase on every push to GitHub. It's a game-changer. As a developer pushing new code, you'll have made sure everything still compiles, added some new tests for your changes, and run all the tests to make sure nothing is broken. Right? You did that, right??
Just in case your forget, or if you'd like the world to see how stable your wonderful program is, you can setup a CI server like TeamCity, Jenkins, or Travis CI (a few of the more popular services). Personally, I like Travis CI. Integrating with GitHub is easy, and free for open source projects. You can read about how I implemented it for GhostSharp, and see the results here (it even runs my several hundred tests as part of the build). You can place a nifty little badge in your repo to show off your build status too.
Here's a few other links to get you started:
- What is Continuous Integration? - Azure DevOps | Microsoft Docs
- What is Continuous Integration? – Amazon Web Services
- How to get to Continuous Integration | Atlassian
- Continuous Integration: What is CI? Testing, Software & Process Tutorial
- What Is Continuous Integration and How to Benefit From It?
Browser Dev Tools
As you progress in development, whether you're doing front-end work or just trying to troubleshoot the connection between a front-end and some back-end server, you'll find these built-in web browser tool suites more and more helpful. You'll definitely want to at least get familiar with them.
- How do I view the dev console in my browser?
- What are browser developer tools? | MDN (I just love MDN docs and tutorials...)
- How to Use Web Browser Developer Tools
I've experimented with dozens of APIs, and once you really get into programming you'll deal with your fair share too. It seems like every site and service has an API to make it easier to Beyond a doubt, one tool has made it loads easier to test APIs and that's Postman.
Let me back up a sec. If you're really new, you might want to read about what an API is first. If you're writing an API or trying to access one, it might be helpful to take a look at the many ways APIs can authorize access. And if you need to wrap an API in some language to make it easier for others to consume, check out What is an API wrapper and how do I write one?
So if you'd like to do a GET, POST, PUT, etc on an API endpoint, and don't want to reinvent the wheel just to test it out, Postman is the tool for you. You can access an API and save all your work as you go - even sync it to access data on multiple machines or share it with your team.
- Sending the first request | Postman Learning Center
- Navigating Postman | Postman Learning Center
- Syncing | Postman Learning Center
- Collaboration | Postman Learning Center (I haven't used this, but it seems cool...)
If you're lucky, you'll find yourself developing in a language with a nice IDE available for it - Visual Studio for C#, RubyMine for Ruby, PyCharm for Python, etc. That's a matter of opinion of course, like everything. A full IDE is always going to be more bloated and more sluggish than doing your programming in notepad or vim. But I think the trade-off for things like intellisense (code suggestions), static code analysis (compiler warnings, suggested refactorings), and other integrations (into GitHub for example) more than outweigh the performance hits, assuming you're developing on a powerful enough machine.
For many languages though, or when you're working on an app that needs to run in a Windows VM from your OSX machine, you might prefer to use a text editor on steroids rather than a full-blown IDE. A few of the more powerful ones are Notepad++, Atom, and Sublime, but there's a relatively new player that I prefer almost exclusively, and that's VSCode.
VSCode has great GitHub integration, and is extensible through tons of extensions. There's syntax highlighting available for nearly any language you choose to develop in (through extensions). It also has a built-in terminal window for debugging, etc.
Since its release in 2016, it's shot up in popularity according to the Stack Overflow developer survey. Like, it's shot up really fast. I'd recommend at least trying it out - it's likely you'll end up using it sometime.
If you want to learn more:
- Visual Studio Code - Getting Started
- Top Ten Visual Studio Code Pro Tips (and the YouTube version if that's your thang)
- VS Code Can Do That?!
"All the best things about Visual Studio Code that nobody ever bothered to tell you"
- How I Write Online Articles - John Papa (he uses VSCode to write blog posts in markdown)
It used to be that if you wanted to run a continuous integration server, or Subversion, or a backup service, or just spin up an Ubuntu machine to try something, you needed a spare machine to run it. If you wanted more memory or disk space, you needed to install it. Those days are gone... or should be. Let the pros worry about the hardware - scaling up, fire suppression, data redundancy, backup generators, etc, etc.
Providers like DigitalOcean let you spin up dozens of different environments in just a few minutes. I use them for this blog, but I also sometimes spin up a quick environment, try something, then destroy it. It costs me pennies, and it's faster and less aggravating than trying to set it up myself. There are other types of services too, like AWS Lambda which lets you run jobs periodically and pay only for the time your jobs use. I used it to tweet random posts from this blog (and from generic RSS feeds) when I still had a Twitter account. (I've since decided social media is a waste of time, but that's a different story.)
My current place of employment has typically written software to run on traditional in-house servers, but we're moving more and more to "the cloud" as time goes on. It's cheaper, faster, less error-prone, more secure, and scales better. Here's a few articles to check out if you'd like to learn more:
- What is cloud computing? A beginner’s guide | Microsoft Azure
- What is Cloud Computing? - Amazon Web Services
- What is cloud computing? - WhatIs.com
- What is Cloud Computing Technology? Salesforce.com
- Everything you need to know about the cloud, explained | ZDNet
- What Is Cloud Computing? | PCMag
The last tool I'll mention is the wiki. I've tried documenting things many different ways, but a wiki has built-in history and promotes collaboration by allowing the whole team to update pages and link them together. Done properly, they're awesome. I even setup a DokuWiki instance for my personal notes.
Every GitHub repo you create comes with a (severely stunted) wiki, which is itself a completely separate repo. That has some cool possibilities, like being able to clone repos locally or even host repos remotely, then serving them up with Gollum for more flexibility. If you need something outside of GitHub, you might consider doing what I did with DokuWiki or using a service like Confluence - if your team is small you could get away with a meager $10/month.
Traditionally, developers have sucked at documentation. Writing a piece of code and seeing it come to life is satisfying. Documenting it is a necessary evil at best, and one that usually gets shunted to the back burner. But knowing how to correctly use your software (and resolve problems when they arise) is the most important thing in the world to your customer. If they can't figure out how to use your software, they won't.
I could go on and on with other suggestions, but these are the top ones I've come to depend on in the last decade. Do you agree with my list? Do you have your own tools to add? I'd love to hear about what you use - maybe you'll help me discover the next great tool I just can't live without. :)