Back when I was fresh out of school and I started to program professionally, I didn’t care about the job titles I’d get. I was comfortable if the position was either an “IT Analyst” or a “Development Engineer” or even “Junior Developer”. If the position would involve programming and I felt like I was a good fit, then I would take it.
As time passed, I started to notice the industry has a distinction between people who are just “Programmers” and those who had made the merits to call themselves “Software Engineers”. I started to wonder where did I fit in the broad and blurry spectrum of job positions. Was my career extensive enough so that I fall in the coveted rank of Software Engineer?
As it turns out, years of experience is an important factor—there’s no better teacher than practice—but there’s more to it. In my quest to become a Great Software Engineer, I noticed seven important things you must develop before you can call yourself an engineer, that I want to share with you.
In civil engineering, a building’s foundations must be solid, or else the building could fall. Similarly, a software engineer should be able to lay down sound foundations for the things they create. You must be capable of envisioning a ’big picture’ overview of how your software system is going to be assembled, and how it will operate. The ability to “draw on paper” blueprints for a project will make you great. Don’t just wait for a nice set of UML files to come along—get involved in making them. People expect true engineers to have a say from the beginning about how a system should be built. Even if your design tools are just pen and paper.
This one was a little difficult for me to accept when I was a beginner. No matter how much you love a programming language, it’s more important to know that languages are just tools. It’s not unusual that you will be required to learn a new language on the spot for a variety of reasons. It’s no coincidence that a great programmer does not put “Java Developer” or “_____ Developer” in his or her résumé. Always be open and prepared to learn and play with new technologies.
Be Proficient with one low-level Programming Language
If you’re curious, I’m sure you already looked into “Software Engineer” job posting from Google, Facebook, etc. Did you notice what they have in common? They’re usually adamant that you’re proficient with at least one “general purpose programming language”. I believe there’s no better career investment than learning C/C++, which is not only general purpose but also low-level, unlike some newer counterparts such as Java or Python. C/C++ is powerful and mastery of this language will make it easier to understand how a computer works under the hood. And the fact that so many languages are modelled after C/C++ means you’ll be able to pick up many other language more easily.
Understand your clients
Part of your job as an engineer, when you interact with clients, is to clarify what is it that they really want. Clients may have a great idea, but often they won’t know how it translates to real, concrete software, until an engineer comes to help. The ability to make the client’s ideas evolve is a great skill to cultivate.
While not all projects share the same level of difficulty, a time will come when you will be required to manipulate huge chunks of data. How well you deal with a tricky task like this will make you stand out from the crowd. Are you able to recognize why a linear implementation is better than an exponential one, why is it worse than a logarithmic one? If your project is critical, this can make the difference between success or failure.
If you want to learn algorithmic complexity and other important computer science concepts, be sure to check out our book Computer Science Distilled.
This one applies to a variety of duties that are part of creating software. From writing commit messages or API documentation, to choosing good variable names. Are your commit messages clear? Do they represent an isolated chunk of work? This can save the life of the next programmer trying to find which change introduced a bug. When you throw a fancy/tricky one-liner in the codebase, you should have the courtesy (and skill) to add a comment that explains what you did in clear English. Everyone will thank you for it!
Throughout your career, you should ask yourself if this is really what you want to do. Do you see yourself doing this for the rest of your life? Do you have a true passion for coding? This fundamental question should always guide you. While it may not always be possible, try to get those jobs that pick your interest. Be sure to take the initiative, keep a positive attitude and show genuine care for your clients and coworkers. This is one of the earliest advice I received, and that I’ll never forget: in the end of the day, interpersonal skills matter more than technical skills. For me, nothing has proved to be more true than that.