Five Valuable Non-Tech Skills for Software Engineers

Key competencies to be successful in a tech career

Jonathan Rasmussen
The Startup
7 min readJul 9, 2020

--

Man looking up proudly at high rise complex
Photo by Razvan Chisu on Unsplash

The field of software engineering is one known for technical complexity, creativity, and innovation. With the job of software developer currently ranking #1 in the US, competition has been drastically increasing, especially in the midst of COVID-19 layoffs and hiring freezes. While technical skills are essential to success in this field, here are five skills that will supercharge both your career and life trajectory:

1. The ability to learn

Bookcase full of books
Photo by Iñaki del Olmo on Unsplash

The domain of computer science and software engineering is one that is both massive and in constant flux. Moore’s Law states that the number of transistors on a densely integrated circuit doubles every two years. This means that the software that runs on said circuits can become increasingly complex, and this is further bolstered by the existence of massive distributed systems via cloud computing. New libraries and frameworks seem to be popping up daily, with NPM (Node Package Manager) now containing over 1 million packages.

Whether trying to learn a new programming language, mastering a framework, or studying for technical interviews, it’s very easy to become overwhelmed just by the sheer amount of material available or required. Before diving head-first into these studies, I’d recommend taking the free Coursera course — Learning How to Learn: Powerful mental tools to help you master tough subjects.

This course is one that has helped me immensely in building good study habits and presenting me with many helpful tools to help myself with studying new material for both university and my professional career. Examples of these tools are spaced repetition, taking advantage of both the focused and diffuse modes of thinking, the concept of einstellung, and active recall.

2. Perseverance

Kickboxer roundhouse kicking heavy bag
Photo by Justin Ng on Unsplash

There are two inevitabilities when working in the world of software engineering: failure and tedium. It’s no secret that getting a good job at a competitive tech company is incredibly difficult. It’s been reported that Google hires 0.2% of those who apply for positions there. Whether working on projects or interviewing for jobs, if you work in this field for any amount of time, you are all but guaranteed to encounter failure. However, failure itself is normal, and often a catalyst to better learning. Failing means that you’re trying to accomplish something new and outside of your comfort zone, which is a massive step towards success.

Successful people don’t fear failure but understand that it’s necessary to learn and grow from. — Robert Kiyosaki

Albert Einstein once stated, “It’s not that I’m so smart, it’s just that I stay with problems longer.” Anyone who has worked in the software engineering field for a decent amount of time can relate to the issue of starting multiple projects and struggling to see them to completion. Starting on new projects is often exciting, but as the project lifecycle continues, the difficult and tedious work often begins to wear on the developer(s). After all, the Pareto Principle, when applied to software projects, conjectures that 20% of the work will take 80% of the time, and this is often the last 20%.

To deal with both failure and tedium, one must have the perseverance in seeing a project or goal through. While this sounds like it’s a matter of willpower, humans have limited willpower to draw from each day. My suggestion is to instead focus on building self-discipline through the use of good habits. The topic of creating good habits is covered extensively in the Learning How to Learn course linked above, but in essence, instead of focusing on goals and other outputs, focus on the process. Tools like the Pomodoro Technique are invaluable for splitting up work sessions into manageable pieces of time while still maintaining the focus on the process (useful tool — https://tomato-timer.com/).

3. Problem Solving

Man working on engineering drafting table
Photo by ThisisEngineering RAEng on Unsplash

Contrary to some of the notions I’ve heard, the most difficult part of software engineering isn’t coding — it’s solving problems. All of programming is essentially composed of algorithms and data structures, and knowing how to recognize patterns and solve issues using the appropriate tool at the proper time is essential.

One common pattern for solving problems is the “read, search, ask” workflow. When you’re trying to find a solution to a programming problem, it’s often best to start with reading the documentation for either the APIs or the technical specifications. If the answer isn’t located there, searching on Google or StackOverflow will often result in something useful. Once those resources are spent, then you can ask coworkers or seniors — they will greatly appreciate that you did research first.

In regards to the problem solving process itself, it’s often helpful to have a repeatable process for whatever product/task you’re working on. Here’s a workflow that I find handy whether working on algorithm/data structure problems (a la programming interviews) or designing systems:

  1. Understand the task at hand
  2. Clarify inputs and outputs
  3. List edge cases
  4. Create a brute force design
  5. Optimize the design
  6. Code out the optimized implementation
  7. Write and run tests (if doing TDD, this can be done after step 3)
  8. Reflect on the results

4. Communication

Message bubble made from paper
Photo by Volodymyr Hryshchenko on Unsplash

Contrary to the all-to-common stereotype of the cave troll living in the server room cowering whenever sunlight touches them, a software engineer requires proficient communication skills to succeed in this career field. Software engineering is a team endeavor, and any large product will require coordination and teamwork between engineers, engineering managers, product managers, and project stakeholders. Communication includes (but is not limited to) written, verbal, and non-verbal communication.

In regards to written communication, it’s generally best to keep things as concise as possible. When writing emails or messages, try and have the main question or update as close to the beginning of the email as possible. Research shows that up to 28% of an office worker’s week is spent on emails, which is a staggering amount of time. The more clear the purpose of and to the point the email is, the less time needs to be taken to digest or even write it. However, tone is still very important, and extra caution must be taken not to come across as overly terse when more formal language is called for.

The interpretation of a message is 7 percent verbal, 38 percent vocal and 55 percent visual

In-person communication is another matter entirely. A study by Dr. Albert Mehrabian, a Professor Emeritus of Psychology at the University of California, Los Angeles, has shown that “The interpretation of a message is 7 percent verbal, 38 percent vocal and 55 percent visual” (Read more here). While this study was directly related to expressing emotions, thus rendering the percentages less precise for general conversation, the point remains that nonverbal communication is massively important. Mastering non-verbal communication will have a massive impact on your overall communication skills.

One method that I have personally found to improve my nonverbal communication patterns is to practice presence. Being present in the conversation and giving it ones full attention will often result in one automatically having better eye contact, more engaged posture, and even less nervous patterns. By solely focusing on the person(s) speaking, you’ll be able to read their nonverbal cues better and pick up on the undertones of what they are trying to express (also known as active listening). As an additional bonus, heightened presence can also help one become more aware of their posture as they engage with the rest of the world.

Here’s a good article for some steps to improve presence:

https://www.psychologytoday.com/us/blog/in-flux/201201/the-practice-presence

5. Adaptability

Close-up photo of a chameleon
Photo by Ante Hamersmit on Unsplash

While this skill is quite similar to the ability to learn, adaptability also has to do with being able to adjust to various scenarios thrown ones way. When working on any large software project, requirements are bound to change at some point. Being able to roll with this and pivot as requirements change is essential to being able to execute well during the implementation of a product or infrastructure design. This is a non-trivial part of what is meant by Agile.

I highly recommend reading the Agile Manifesto and the Twelve Principles of Agile Software to get a better idea of what is meant by the word Agile.

There are also other variables at play that myself and many other engineers/developers have had to work through. There can be anything from a teammate moving to a different position or company, a budget cut related to your assigned project, or even being shifted to an entirely different project based on priority. A perfect example of unexpected changes would be the move to primarily remote work due to COVID-19. Being able to adjust to these changes effectively and efficiently will give you a leg up in this field.

Here’s a great article from Drexel University on how to practice adaptability.

Resources

--

--

Jonathan Rasmussen
The Startup

Professional software engineer. I’m passionate about education, engineering, science, technology ethics, and philosophy.