Like all professionals, software developers built themselves tools, many software tools, to help them get their job done better. They used other tools, too. The chalkboard (replaced by the whiteboard), and paper & pencil have been with us from the very beginning. People wrote the algorithm, converted it by hand into machine code (in octal at first, then hexadecimal), and input it bit-by-bit into the machine. Later, as compilers were developed, the compiler became an essential tool. There are more tools now in the developer’s toolbox, each serving a unique purpose in the software development life cycle. With each tool comes the need to learn how to use it, to become good at getting the work done with it.
This the fifth and final article in the series on Starting in a Software Development Career. The other four articles in the series are:
As a software engineer you are designing and implementing software. You, like most people, might start out with a sketch on the whiteboard or on a pad of paper. You sketch out what the system will look like, sometimes the UI, sometimes the internal structure, sometimes how it will interact with other systems. These sketches can be invaluable in conveying to the rest of your team your ideas. So practice sketching. You don’t have to become an artist at drawing. Just get good enough so that others can understand what your drawings mean and can build upon your ideas. And make sure that your writing is legible. Your good ideas will be lost if a day later you can’t read your own handwriting.
Most likely not all of your team will be in the same location, so you must take at least a picture of your sketches and share them with others. Or, you may need to draw them using a drawing, sketching, or diagramming tool that aids you in the capturing of designs. The more popular diagramming tools are Visio and OmniGraffle, but there are many others, too. You can also use a presentation software as a diagramming tool, since many have decent drawing capabilities. Either PowerPoint or Keynote will do. An open source alternative is Apache OpenOffice, which has a drawing tool and presentation software as well. An added benefit is that it also runs on many Linux variants. Some diagramming tools maybe already built into your favorite online tools, like draw.io, Gliffy, or Lucid Charts. Another popular online option is Google Draw. Many new tools are popping up every day.
Of course, you’ll also need a code editor. Pick an editor or an IDE and learn it well. People who have been in the software world for a long time tend to gravitate toward a few favorite editors: emacs, vi, TextMate, Sublime Text, Atom, or towards some of the popular IDEs: IntelliJ IDEA, Visual Developer Studio, Eclipse, Oracle JDeveloper, Xcode, NetBeans. Sometimes your workplace or your project determines which editor or IDE you have to use. Then you need to learn that tool, too. It is worth spending a few extra hours learning the tool that you need to use day in and day out—instead of fighting the tool every day. This is true for all other tools you have to use as well, not only code editors.
Set a personal goal to learn how to accomplish the most common tasks with keyboard shortcuts with just about every tool you frequently use. Write on a Post-It note 5 shortcut keys, and keep it in front of you. When you mastered those, add 5 more. As you get more proficient in the use of your tools you will notice that you can focus on the task at hand, instead of focusing on the tool or how to get a particular task completed. Once the tool blends into the background your performance will improve and others will start to notice the improvement as well.
Every now and then one still bumps into a developer who doesn’t deploy their code to see it running after he or she made changes to it. The basic process that all developers need to be able to perform on every project is at the minimum: compile, build, install and deploy, and test. There is no substitute for seeing your own code run and do what it is supposed to do, regardless of how confident you are that the one-line change or new feature you just implemented works. At the beginning of every project take the extra hour or even extra day that you need to ensure that you figured out how to run the code that you are about to work on.
Write a “Hello, World!” application for the platform that you work on, and make sure that you have automated your development loop. The work of compiling, building, installing, and testing of the code should be automated. Automation ensures that the build steps are performed consistently, so when there is an error it is easier to find the cause of that error. It allows you to focus on writing code for the desired new features and not focusing on the mechanics of the work.
Just as much as you are writing code, you will also need to fix it, too. You need to learn to use a debugger for the platform that you are working on. Even if at first you don’t have to do this, it is a good idea to learn how to debug your code, so you don’t fumble with the debugger the first time you really badly need it, because you will need it. Besides, you probably should consider stepping through code in the debugger from time-to-time, just to ensure that you know what’s going on when the code is executed.
Using revision control can be a mystery to new folks entering the field of software development. Why would you want to use it? Couldn’t you just have regular backups? Revision control is not a substitute for backups. Revision control is the mechanism to help you write better code by isolating the additions, deletions, and modifications you make to the codebase for each meaningful unit of change, be it a feature or a defect fix. Revision control helps you work as a team, where there are many others who also work in the same codebase. These days (late 2016) Git seems to be the revision control tool of choice for a lot of companies and projects. You should learn how to use Git, and get really good at it.
In addition to a tool, you also need a revision control process. Gitflow is one such process. As you work, adapt the process to your and your team’s needs.
Software development projects extend over several weeks or months and as such, guiding them toward a successful end is a significant effort. To assist in this effort, every project needs a shared task list to plan, guide, manage, track, and report on the work. A such tool is a centralized issue management system. “Issue” is a generic term; it can be a feature, a trouble ticket, a task, or any other work item that someone on the team needs to work on. The issue tracking system can assign different workflows to each type of work item to ensure that each follows the appropriate process toward its resolution.
Jira and Bugzilla are popular issue management systems. They even have connectors into revision control tools that allows the user that opens a work item to optionally create a code branch for the new code associated with that work item. GitHub Issues is the issue tracking system integrated into the popular GitHub revision control tool.
As you work with an issue management system, keep in mind the following:
- Once you write up an issue, that issue becomes inventory and you have to manage it, which means: define, prioritize, validate, refine, develop, verify, and support it.
- Keep the issues relatively small, meaning: each issues should require about 1 to 2 days of work to complete. Following this rule, you will have about 5 to 7 issues for a week. This allows you to maintain a good pace for your work, and always able to report where you are.
Here are a few more tools that you should know about. Each can help you get your work done better, faster, more effectively:
- Code review tool that provides a collaborative environment for code reviews. Some revision control systems have such capabilities, but a specialized tool will improve your team’s output.
- Unit test framework to run all unit tests. Some of these capabilities are part of almost every modern build system.
- Unit test code coverage tools that measure how much of the product source code base is exercised by the set of unit tests your team wrote.
- Code analysis tools to identify dependencies, measure code size, cyclomatic complexity, etc.
- Requirements capture and management tool. The wiki or the issue management system can do this job, too.
- Code performance measurement tools. Some of these are capable of estimating power consumption (which is very important on mobile platforms).
You owe it to yourself to learn the tools that you use every day to get your work done. By getting proficient with the tools you use, you allow yourself to focus on the task at hand, and sooner or later your tools will blend into the background, allowing your creativity to shine.
Enjoy the journey!