• Software Development
• Education
• Career

Contents:

• Introduction
• The Skills
• Interpersonal
• Tips For Interpersonal Skills
• Communications
• Tips For Speaking
• Tips For Writing
• Tips For Diagramming
• Time Management
• Tips For Time Management
• Deep Focus
• Tips For Deep Focus
• Asking For Help
• Learning New Skills
• Tips For Learning
• Resilience
• Tips For Resilience
• Conclusion

Introduction

In Skills For Embedded Systems Software Developers, I covered the hard skills. But we get so focused on those that we tend to overlook the soft skills required. They don't get emphasized much.

Certainly no soft skills are going to make that peripheral on your board function properly, but they can make a critical difference to success, for both your organization and your individual career.

Much of the need for soft skills comes from the fact that projects are a team effort. Even if you're the only software developer, there are always multiple people involved. If you're a manager, you should realize that your developers need soft skills for that reason.

There are different people involved in different roles, both technical and management. The technical roles provide domain expertise across the range of technical disciplines necessary to have a successful product, from the electrical, mechanical, and industrial design to the software design and development, to the UX design (since actual people may be interacting with the product once it's released!).

The management roles provide direction, guidance, requirements, prioritization, and interaction with other organizations.

Across the life of a product, there will be multiple people figuring out what the the product will do, designing, implementing, testing, and maintaining its various aspects, and writing instructions for using it.

Across the span of time, multiple people will come and go in those roles. The team exists across multiple dimensions.

This all results in lots of interaction and information flow back and forth. Feelings and egos get involved.

Beyond that, products are used by and affect the lives of people. You need to think about them as well.

As developers, we tend to have a reputation as introverted, inarticulate loners who would rather spend time tinkering with the system than interacting with other people. I can certainly see aspects of that stereotype in myself; I'm an introvert, possibly to the point where some might think of me as unsociable.

There are other stereotypes such as arrogant and toxic personalities that can be ruinous to an organization, whether among developers, managers, or executives.

Some of the things below might be considered simple personality traits and characteristics rather than skills. It's important to temper things across the diversity of personalities and not try to hammer people into things they aren't. That includes neurodiversity.

It's also important to realize that these soft skills apply all through an organization, through all the technical, management, and executive people, from the most junior to the most senior. Interpersonal interactions take place up, down, and across the management chain, technical roles, and seniority levels.

That's right, people matter! All that soft, squishy stuff really does make a difference.

The Skills

The first step in learning these is awareness that they're required. The second is assessing your own skill level for each one. The third is finding and consuming learning resources. The final step is actually putting them into practice, and refining as you go.

Finding good resources can be a challenge in some cases. It's always worth using more than one, so that you get various authors' perspectives and experiences. I've included a few resources that I thought were interesting.

One book I've recently found that includes useful tidbits in a number of these areas is The Effective Engineer by Edmond Lau.

None of these skills is particularly magical. We all possess them to some degree; they're all just human nature. But different people with different personalities will definitely be stronger or weaker in specific areas. For some a given skill will seem effortless and natural, while for others it will be a struggle.

The skills break down into the following areas:

• Interpersonal
• Communications
• Time management
• Deep focus
• Asking for help
• Learning new skills
• Resilience

Interpersonal

This is the really squishy stuff. It's vital because it really is a team effort, with a number of people involved both inside and outside the organization.

The specific skills:

• Empathy
• Compassion
• Humility
• Respect
• Listening
• Assertiveness
• Giving and receiving feedback

Empathy is the ability to understand and share the feelings of another.

Compassion is sympathetic concern for the sufferings or misfortunes of others.

Humility is a modest view of one's own importance.

Respect is due regard for the feelings, wishes, rights, or traditions of others.

Listening is actually paying attention to and considering what others are saying.

Assertiveness is confident and forceful behavior at an appropriate level.

Giving and receiving feedback means giving and receiving positive and negative information, fact and opinion, on something.

There's a great deal of interplay between these. Empathy and compassion mean being able to step into someone else's shoes and see things from their perspective. They drive you to do something about their problems. Humility and respect mean acknowledging what others say and do as being important. Listening means you're willing to take in what they say and think about it, even if you don't agree with it. Assertiveness means you're able to stand up for what you believe, even in the face of opposition.

Giving and receiving feedback is an amalgam of all of the above. This tends to be where conflict can grow, because this is where feelings and egos enter the picture.

It's critical to offer feedback in a compassionate, humble, and respectful manner while listening to the other person. It's critical to listen and accept feedback in a compassionate, humble, and respectful manner. A suitable degree of assertiveness is required in each direction, so that you can advocate for yourself. Even if you disagree, this is an important information flow. If you create defensiveness or anger on one side or the other, that flow is blocked, and nothing useful will come from it.

Feedback can feel like a personal attack, and may very well be if done in bad faith. I try to assume it's in good faith as my default position, and see where it goes from there. Tone and body language are just as important as actual spoken words; non-verbal communication can be very powerful.

If feelings or egos do get bruised during any kind of interaction, it's often best to back off and let things calm down so you can return to it as a rational person.

Sometimes someone might need to step in as peacemaker and mediator. This requires all of the above skills, with a calm, assertive hand.

Tips For Interpersonal Skills

There are many ways to learn these, and many resources. There's certainly no end to advice on them. This is also the place to understand the limits of how far personality traits can be treated as learnable skills.

One approach I find useful is role-playing. This can be as simple as watching videos of people role-playing various scenarios where they bring the skills to bear (or fail to).

A more active approach is to participate in role-playing scenarios under the guidance of a coach, although some people may find that extremely uncomfortable. The coach helps set the scenario, keeps things within the guardrails, prompts to carry it through, and then prompts for analysis at the end. How did it make you feel? What if you had done something differently, would it make things better or worse?

The goal is to learn to recognize and manage these feelings, positive and negative, and learn how to apply the skills.

These skills are also referred to as emotional intelligence, with an associated EQ (Emotional Quotient) analogous to IQ (Intelligence Quotient). Those terms can be helpful terms when looking for resources. Just recognize that it's not a precise science, and can be easily subject to bias.

Communications

This is communicating to others.

The specific skills:

• Speaking
• Writing
• Diagramming

Speaking is basic public speaking in front of other people.

Writing is writing information in a variety of forms.

Diagramming is the visual version of writing.

Communications are addressed to a variety of audiences and situations. Sometimes you need technical deep dive, sometimes you need high level. Sometimes you have a receptive audience, sometimes you have a skeptical or even hostile audience. You need to tailor your material to the audience. Is it composed of executives? Managers at high or low levels? Developers? Support personnel? Users?

Are you communicating online, in an interactive space, in person, at a conference, at a customer location, at your company's location? In formal material, or informal material?

The nice thing about communication skills is that they respond well to practice. The more you do, the better you get. Intentional practice can transform poor skills into sharp ones.

It can be very helpful to have someone go through what you produce and give you feedback on it (remember that skill!). If others aren't getting the information you're trying to convey, you need to work on conveying it better.

One simple approach is to imagine yourself standing in front of a whiteboard and explaining things to a colleague, with a laptop nearby to look at code. What would you describe? How would you take them through the code? What diagrams would you draw?

You can even make an informal video of yourself doing this, either talking to the camera or to someone else, then transcribe that video to provide the raw material for creating more refined material.

Tips For Speaking

Public speaking is a common fear. I had great difficulty with it well into my career. If there were more than 3 people in front of me, I couldn't physically speak.

What helped me was Toastmasters International. This is an organization dedicated to helping people learn to speak in public through mentoring and practice opportunities. There are many clubs at companies and colleges. Find one and participate. It may take a while, but it will help you transform sweaty palms and panic attacks into calm confidence.

Tips For Writing

A colleague recently showed me a documentation model that I thought was excellent: the documentation system. It provides a framework for 4 specific types of technical writing:

Image source: https://documentation.divio.com/.

Tutorials are lessons that take the reader by the hand through a series of steps to complete a task. They show a beginner how to do something. They are learning-oriented, toward learning how rather than learning what, assuming no background knowledge.

How-to guides take the reader through the steps required to solve a real-world problem. They are goal-oriented, assuming some background knowledge, answering a question that only someone with some experience could formulate.

Reference guides are technical descriptions of the topic showing correct usage, without explaining basic concepts or how to achieve common tasks. They are information-oriented.

Explanations clarify and illuminate a particular topic. They are understanding-oriented. They provides discussion of the topic, including background and context, alternatives and opinions. They don't instruct.

See the documentation system web page for more detail and examples. It includes a nice video summary as well.

This is where you can apply intentional practice. Pick some parts of a system you're familiar with and write documents of each type, even if such documents already exist. Repeat that a couple times on different things. Then circle back around and rewrite the first one.

Tips For Diagramming

There are several diagramming techniques for software. These act as the equivalent of schematic diagrams for hardware. They create visual models of software.

There's no single diagram that captures all aspects of a system. It takes multiple diagrams of different types, from multiple perspectives, just as it does for hardware.

UML (Unified Modeling Language) combines several modeling techniques and diagrams that have been developed over time. It provides standardization of visual elements and their interpretation. Many basic drawing packages support UML elements.

PlantUML is a free tool for creating UML diagrams using text language. Other tools such as AsciiDoc support integrating inline PlantUML text to render into the final document.

SysML (Systems Modeling Language) extends UML to systems engineering.

The C4 Model (https://c4model.com/) creates "maps" of code at different levels.

As with writing practice, do some intentional diagramming practice. Create diagrams that can be incorporated in the practice documentation.

Time Management

This is managing your time in order to get things done in a timely manner. Other people downstream from you depend on getting work done by certain times. This may be driven by fixed external factors, such as getting consumer products shippable in time to be stocked in stores for holiday sales.

The specific skills:

• Prioritization
• Estimation
• Allocation
• Breaks

Prioritization is evaluating the various tasks you need to work on and prioritizing the order in which you'll work on them (or parts of them).

Estimation is estimating the absolute time it will take to complete those tasks or parts of them, absent interruptions. It includes evaluation of risk factors.

Allocation is dividing up your available work time to work on those tasks.

Breaks are time for you to rest and recover to avoid burnout and exhaustion.

There are two goals for time management: providing adequate time to get tasks done; and not letting a task runaway with time, leaving no time for the other tasks.

Time management takes place at multiple scales: on a daily, weekly, monthly, and yearly basis, subject to project management time periods, such as sprints or milestones. You allocate work time across those scales, and take breaks at those scales.

Some parts of time management are straightforward. You know how much available work time you have, and you can schedule breaks in between allocations.

Prioritization is more difficult, because priorities can be unclear or fluid. Last week's priorities may have been superseded by this week's.

The real challenge is estimation. This is absolutely fraught with peril. There are often multiple risk factors that can blow an estimate out of the water. Risk factors tend to be unknowns, so they're hard to plan for. That's why it's key to think about them.

The worst thing you can do is assume everything will go perfectly according to plan. That's overly optimistic. You need to allow for contingencies. The more risk factors you face, the broader the contingencies need to be.

You also need to allow for interruptions. Even a well-defined task that usually takes half a day may take a calendar week to complete if it's interrupted repeatedly by things that take time away from it. Those interruptions may be perfectly legitimate and a necessary part of the job. Acknowledge and account for that.

You can think of yourself like a single-core CPU with an RTOS scheduler. You have various tasks to execute, so you allocate execution time to them according to priority, switching between them when appropriate. Interrupts take CPU time away from them, extending the total wall-clock time required to complete their work.

Estimation is a contentious subject, because it's trying to predict the future. Sometimes there are so many unknowns that it becomes ridiculous. Unfortunately, estimates tend to be taken as hard commitments, effectively measuring something that hasn't happened yet, and often ignoring the effects of interruptions. Some people advocate for not doing estimates; simply do the work, because it's impossible to know how long it will take.

But the reality is that people are taking actions based on the expectations of the work being done by a particular time so that they can combine that work with other work. So some level of reasonable estimation is needed, with margin to cover contingencies.

Tips For Time Management

Identify available work time in blocks at the various time scales, with appropriately-scaled breaks in between. For the day, identify the work times interleaved with meetings and meals. Break those up into work blocks with 5 to 10 minute breaks in between, using a duration that works for you. Then allocate the work you've prioritized for the day to those work blocks. Allow some margin for unplanned interruptions.

For longer scales, identify the work days interleaved with weekends, holidays, and vacations.

Make sure to take breaks, both the short one during the day and the longer ones across the calendar. I have a bad habit of working for hours without taking a break, so that when I stop, I've used up all my energy. Breaks allow you to parcel out your energy, so that you don't run to exhaustion. They're an important part of pacing yourself.

I've become a big fan of the pomodoro technique, where you use a timer to alternate work periods with rest periods. I use the free Brain Focus app on my Android phone, which defaults to 25 minutes working and 5 minutes rest, with 20 minutes rest every 3 cycles. You can customize the various settings. The regular timer function on the phone is a good alternative.

I use the technique for everything, from technical work to house work, yard work, and hobby work. For some things, I'll increase the work period to 45 or 55 minutes to allow me to maintain a longer flow state before stopping.

During breaks, I'll often spend the time doing a simple deep-breathing relaxation meditation; eyes closed, counting breaths up to 10, then restarting at 1. Some people like to go on walks. That disconnection from the work can help clear your thoughts and give you new ideas.

I've just recently started using the free individual level of Asana as a Kanban board, based on recommendations from our office administrator and Edmond Lau's book.

To combat unrealistic estimates, you need to apply the assertiveness skill and call out risk factors and concerns explicitly.

If anyone has some practical estimation techniques that they've found truly useful and reproducible (as in other people have been able to reproduce the process effectively), I would love to hear about them. In over 40 years of software development, this has always been the biggest problem across multiple organizations, and I've never seen a method that works reproducibly.

Deep Focus

This is the next step beyond time management, putting your time to effective use.

The specific skills:

• Flow state.
• Eliminating distractions.

Flow state is a highly-productive mental state of total immersion in the task, where you barely notice the passage of time; being "in the zone".

Eliminating distractions is finding all the things that interfere with or disrupt flow state and eliminating them or moving them to times where they won't do that.

Software development is a complex task. It takes deep focus and concentration. You're holding a lot of things in your head. That's all the context that goes with the design and code that you're dealing with. In flow state, you're working with it effectively.

Disrupting flow state shatters that context in your mind. Once disrupted, it takes time to reacquire the mental context and resume flow.

Unfortunately, one of the characteristics of modern technology and communications is that we've multiplied the number of ways to interrupt each other. There's email, chat systems, texting, automated notifications, hardline phones and mobile phones, and social media. These are the equivalent of someone honking a car horn in your ear every few minutes.

Tips For Deep Focus

There are a number of authors and presenters who have offered advice in this area, for instance Cal Newport in his book Deep Work and his YouTube channel.

One of the simplest things you can do is shut off notifications of all types in all the systems you can.

Then, at least when you need to do focused work, disconnect from email and chat systems, close their tabs and windows, and put your phone in airplane mode. That may require negotiation in some work environments, so establish "quiet hours" where you let everyone know you are not reachable, but then establish "office hours" where you're open to interruption and will respond to anything that accumulated while you were offline.

Total disconnection may also be difficult for personal reasons, since our cell phones have become our entire connection to the outside world for all things. You may have to stay connected to some degree.

Once you've gone to the effort of quieting things as much as possible, you need to resist the urge to check on them. That's why closing tabs and windows can help, because they won't be tempting you. It may take some time to train yourself to this and be comfortable with it.

You also need to be sensitive to the needs of others to focus, so be respectful of their quiet hours. If you're a manager, allow your people to have that time, and try not to interrupt their flow state; that's when they're your best asset.

Asking For Help

This is relying on your team to help out when you run into difficulties.

Rather than specific skills, I think of this as three stages:

• Recognizing when you need help.
• Asking for help.
• Accepting help.

We tend to want to be self-reliant, and can often be dogged in pursuit of a problem. But eventually, after you've put in a reasonable effort, you have to recognize that you're not making the progress you want.

This ties into time management, because there's a real risk of letting time get away from you. Meanwhile, there may be someone else who can help you get through the problem.

The challenge is that you don't know ahead of time that you're going to have the problem, so it's hard to know how much time is enough once you're in it. This is where you can use your time allocations and estimations. When you've used up a time block and step back for a break, that's a good point to assess the situation and ask yourself if you need help. You've spent the time; how does that compare with your estimate of what it should have taken? What is the likelihood that more time will get you through?

This is also where humility helps. You can't let pride get in the way and prevent you from asking for help. Admit that you need help, then ask for it.

When asking for help, your coworkers will appreciate it if you've put in the appropriate due diligence to explore the problem yourself and state it succinctly, with appropriate evidence. They and your management will also appreciate it if you don't go on a long time-sink adventure.

Accepting help becomes a learning opportunity. Capture and share the information that helped you through so that others can benefit from it.

Learning New Skills

The ability to learn new skills is critical, because it never ends; school was just the start no matter how many degrees you completed. You need to be a lifelong learner.

Technology marches on. There are always new things being developed, new hardware, new software, and new techniques. There's also the huge body of things that already exist, but are new to you.

That requires the ability to rapidly assimilate information in multiple forms. You need strategies for learning and navigating codebases and documentation. You need to do things hands-on, from coding to hardware, because actually doing it reinforces the information you learn.

Doing is a major part of the learning process. That's more intentional practice.

Teaching a skill is also a fantastic way to reinforce it (see my post Sodoto: See One, Do One, Teach One). It also helps with refining communication and interpersonal skills.

Once again, time management and deep focus are important, so that you are able to learn in a timely manner. You need to decide how much time to invest in learning something, and spend that time effectively.

Tips For Learning

Different people learn in different ways. These are some of the things that work for me.

I gather all the resources I can together for a particular topic or project. This may be datasheets, codebases, documentation, wiki pages, books, tutorials, videos, etc, as well as the necessary hardware (or some representative hardware). There's usually far more information than I have time available to get through it all, so I prioritize learning areas within that.

I pick some topical thread or work flow and follow that through all the resources. I start with the broad introductory resources to establish enough context, then dive into the detailed resources and follow it through them. I defer other things that I run into for the moment, just focusing on that one thing, but note them for follow-up in their own learning round.

I've never been very good at straight note-taking, but I've found that an alternative form of note-taking is very helpful. I build call trees of code and draw diagrams of interacting components, showing their structure and behavior. I tie together schematics, datasheets, and code to find the path that the functionality follows. These steps force me to go through things in detail. I capture information from running code to see what things actually look like; debugger backtraces can help quickly build call trees.

I draw diagrams of the explicit and implicit architectural components. That forces me to step back from the details and look at the larger abstractions.

I play with the examples in the books and vendor libraries, experimenting with them to try different things.

Overall, I've found that if I can draw a picture of something, I can understand it. That requires zooming in and out at different detail levels.

Once I have an initial understanding, I expand to other areas. The information I've previously put together provides a skeleton on which to hang additional items.

It's not always a clean process. I may think I have a good understanding, only to find out it's inaccurate as I get into other areas. That's why I like to use the hands-on work to confirm things. This combines theoretical with empirical study, just like a class in school that included lab sessions.

Resilience

This is the ability to get through the day and the year, no matter what and no matter who. This is being the calm in the storm.

Working with embedded systems requires patience, persistence, perseverance, and a high tolerance for failure.

A lot can go wrong. There's complexity at many different levels. This can be frustrating, especially when there are deadlines with people waiting on you.

You have to have the patience to deal with it, and the persistence and perseverance to continue working on it. Each failure is a learning opportunity. To paraphrase Thomas Edison, you've learned something that doesn't work.

Tips For Resilience

A number of the other skills help with resilience. The interpersonal skills help with patience when dealing with other people and with yourself.

Time management helps, because it paces things out. Take the breaks, both the short ones during the work day that help you back off a problem for a few minutes, and the long ones between work days that help you recover from the intensity of the effort. These help clear your mind. Then resume persevering in the next time block.

I also find that keeping an electronic "engineering notebook" helps. I record all kinds of information, notes, code snippets, logs, screenshots, cell phone photos of hand-drawn diagrams and hardware setups. I use a simple Google Doc with hierarchical headings like this blog post. It's searchable and can hold of lot of content. I start a fresh one each month. It can get quite long.

This information gathering is a concrete output of my work, even if it doesn't contribute directly to the project deliverables. It reminds me that I'm accomplishing something if I get frustrated and impatient. It also gives me something to refer back to when I forget things, and provides the raw material for more polished communications.

If I really get wound up and need to calm my mind, I'll stop and take a longer break of 10-20 minutes. I'll sit back in a comfortable chair and do an extended calming deep-breathing meditation. That's why regular intentional meditation practice is helpful, because it becomes a skill you can call on when you need it.

This is also good when I get tired but need to keep working. Rather than trying to push through the tiredness and drag on for an unproductive hour or two, it's more efficient for me to do a 20-minute "zone-out" meditation, with a timer running in case I fall asleep. I usually don't, but it turns out to be amazingly restful and restorative. Then I'm back working productively much faster.

All the different meditation sessions I use follow the same method. The difference is just the duration and my mental and physical state when undertaking them, whether a normal break, a calming break, or a tired break.

And yes, I also use them when I wake up in the middle of the night with my mind racing and need to get back to sleep. Because sleep is a vital tool for resilience.

Conclusion

This is certainly not an exhaustive list. But it provides a good start. If you work on these, they'll lead you to other useful soft skills. You can also see how they interlock and reinforce each other. Exploring the tips will lead you to other resources.

These skills aren't specifically related to embedded systems. They apply to any kind of software, and indeed to any kind of engineering.

Sign in