I love computer science. I’ll take a deep dive into algorithm speed and efficiency any time. Designing the perfect data structure for a project is a task to look forward to. I eagerly anticipate the day when I can put machine learning or artificial intelligence into practice.
But I’m not a computer scientist. What I do can be described in a few ways: programmer, developer, software engineer. Whatever you want to call it, what I do is write code to solve problems, generally for businesses.
What I don’t do is perform research into information theory or cryptography. I do use the results of others’ research every day and am infinitely grateful for their work. And I’ve been doing that for a long time; for nearly all of my professional career and for more than half of my life.
My experience has led me to be tapped by management to mentor junior developers a few times. On each occasion, the junior developer had an either a bachelor’s or master’s degree in computer science. These junior developers were much more educated than me in computer science. They knew more about efficient sorting algorithms and all the ways to build a linked list than I ever will.
But, they didn’t know how to write software for clients.
Now, it’s not their fault that this was the case. In my mentoring experience, I have found that achieving a degree in computer science doesn’t prepare a person for creating software to solve business problems. It is understandable why a CS degree path was likely chosen: until fairly recently, most universities rarely offered a degree in Software Engineering. This may be the case partly because universities are homes to academia, and there’s a reason that in some contexts “academic” is a synonym for “theoretical.”
I actually considered returning to school to get my degree in computer science, but after my mentoring experience, rejected the idea. It became apparent that such a degree wouldn’t have any practical effect on my daily career. If you are currently studying computer science, or have recently attained your degree in the field, build upon that educational foundation you’ve established with some real world skills to become a savvy developer. Here are some tips on how to create software that businesses can use to make themselves more efficient and profitable.
The Minutiae Can Be Ignored
In a similar vein, speed isn’t the highest priority for most software. There are exceptions, such as 3D graphics, video encoding, etc., but even in these cases there are libraries such as Apple’s Metal framework, that can do the heavy lifting. The highest priority for most business software is that it works and as soon as possible. Leave making it work quickly for when you discover that quick is necessary.
Learn the Standard Development Tools
There is more to software engineering than knowing how to write code. Almost every development platform will use a standard set of tools, and the better you know these tools, the more efficiently you’ll create software. Generically, these tools include:
- A text editor
- A command line shell
- A version control system
My specific instances of these tools are Vim, the Z
git. Like any generalization, there
are exceptions. For years, I worked in a platform called FileMaker, where a text editor was
unnecessary, version control difficult, and the command line seldom needed. But regardless
of whether you’re developing for the web, desktop, or mobile applications, you’ll probably be
working with a traditional text-based programming language, and these are the three tools
you’ll want to know regardless of your specific target.
Depending on the target, there may be additional tools to know, such as an integrated development environment (VS Code being popular with Salesforce, Xcode pretty much necessary for Apple platforms), the browser tools for web development, or perhaps a graphics program like Photoshop if your development includes icon design.
Some specific tools that we at Tython, as Salesforce developers, use every day:
- The VS Code IDE (with the Vim plugin, in my case)
- Z Shell for the macOS developers and Bash for the Linux developers
gitfor version control with GitHub and Jira for collaboration
sfdxfor dealing with orgs and source deployment
nodefor automating local development processes
- Chrome and Firefox for testing and debugging
Whichever set of tools you choose or are chosen for you, know them well. Software engineers are like craftspeople: just as a carpenter will create better woodworks if they know their jigsaw inside and out, the better you know your tools and the features they offer, the more you’ll be able to leverage them to save you time and produce better software.
Know Your Libraries
Every programming language is more than the syntax of functions and loops. It comes with a library of reusable code. But the breadth of each library and the naming of similar features differ across languages. Whatever language you’re working with, read at least the name and description of every available tool. Yes, I do mean every tool. You needn’t do this in a single block of time, but take perhaps 15 minutes each day out of your schedule to read the documentation on a few built-in classes or functions.
you will some day have a need to retain array elements that match a criterion and try to build
it yourself. But if you have read that
Array.filter exists, even if you don’t remember the
precise usage, you’ll be able to quickly look up the documentation.
This goes for your tools as well. Once you’ve gotten the basics of, for example,
git, and have
familiarized yourself with the available features of your languages’ libraries, go back and do
git what you did with your language libraries: read through the various options available
so that you know they exist when you need them.
As a software engineer, you’re never finished with your education. Technology, almost by definition, is an ever-changing field. New languages are invented; new paradigms invented.
Your continuing education will generally take one of three forms:
Updates to Current Tools
Languages, tools, and libraries are constantly updated. When they are, you’ll need to read the release notes so that your deep knowledge of the available features doesn’t grow obsolete.
Learning from Others
You don’t know everything, and you never will. Take advantage of the generous developers out there who write blog posts about their processes. Listen to podcasts that cover your industry. Attend conferences to learn how others have solved specific problems that they’ve come across, many of which will be similar if not identical to those you’ll encounter.
Learning for Its Own Sake
Don’t misunderstand—it’s not that a CS degree is useless for a software engineer. You will put your education to use in building algorithms and data structures at the very least. But a degree alone is not sufficient for a software engineer. Familiarize yourself with your tools, continually upgrade your self-education, and don’t be shy to ask for a mentor’s guidance.
Let us know if you found this helpful and whether you’d like to see more details on this topic.