Professionalism

Table of Contents

What is Professionalism in Software Engineering and Why is it Important?

Definition of Professionalism in Software Engineering

Professionalism can be defined as the conduct, behaviour, and attitude exhibited by individuals in a professional setting.

In software engineering, professionalism includes a wide range of behaviours that demonstrate a commitment to delivering high-quality work, effective collaboration and communication, and maintaining ethical standards. It is a combination of technical expertise and exhibiting behaviours that reflect positively on oneself and the software development community. It involves taking responsibility for one’s work and continuously improving one’s skills, whether they are technical or soft skills.

Professionalism in software engineering can also be defined as a movement to make software engineering a profession, with aspects such as degree and certification programs, professional associations, professional ethics, and government licensing. (1)

The Role of Ethics in Software Engineering

Ethics play a significant role in software engineering as they guide engineers in making responsible decisions that impact users, clients, and colleagues. Ethical considerations include data privacy, security, accessibility, and fairness, ensuring that the software development process benefits all stakeholders without causing harm.

According to the Software Engineering Code of Ethics and Professional Practice (2), the eight guiding principles for ethical behaviour in this field are as follows:

  1. Keep Public Interest in Mind (Public): Software engineers shall act consistently with the public interest.

  2. Interest of Client and Employer (Client and Employer): Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest.

  3. Highest Professional Standards in Products (Products): Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.

  4. Integrity and Independence in Judgment (Judgment): Software engineers shall maintain integrity and independence in their professional judgment.

  5. Ethical Management (Management): Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.

  6. Advance the Profession (Profession): Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.

  7. Fairness and Colleagues (Colleagues): Software engineers shall be fair to and supportive of their colleagues.

  8. Learning and Ethical Behaviour (Self): Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.

These guiding principles are further broken down in the code into more concise and actionable items. Feel free to take a look at them using reference (2) to improve your understanding of ethical behaviour in software engineering. The titles of the principles have been changed to be more descriptive on this page, but the original titles are in parentheses for reference.

According to a Fellow article by Brier Cook (3), five tips to help software engineers ensure they behave ethically are:

  1. Ask yourself how the software could be misused. Assuming that your software will be used in good faith or for its intended purpose, is not good enough. Thinking about the ways in which the software may be misused, will allow you to inhibit unethical use of your software before it occurs in the first place.

  2. Be honest about your intent. “Use simple language and be honest about your product!”. Ethical behaviour in software engineering involves users being able to make informed decisions about their use of your product, which can only occur when we are honest.

  3. Avoid biases. “Don’t let enthusiasm cloud your judgment!” Always ask for a second opinion on your work to ensure it adheres to the ethical principles of software engineering.

  4. Take accountability for the software. “As a software engineer, you should aim to advance the integrity and reputation of the profession.” Take responsibility for detecting and resolving errors in your software. Take both the successes and failures of your software as your own.

  5. Act as a responsible citizen. Be a responsible citizen first and a software engineer second. Only work on projects which you believe to be safe and ethical.

Examples of Professional Behavior in Software Engineering

  1. Adherence to coding standards: Consistently following established coding standards and best practices ensures that the code is readable, maintainable, and efficient.

  2. Clear and concise communication: Effectively conveying ideas, requirements, and progress updates to team members, clients, and other stakeholders fosters understanding and collaboration.

  3. Time management and meeting deadlines: Managing one’s workload, prioritizing tasks, and delivering work on time demonstrates commitment and reliability.

  4. Accountability and responsibility for one’s work: Owning one’s mistakes, learning from them, and taking necessary corrective actions reflects maturity and professionalism.

  5. Collaborative and respectful teamwork: Treating colleagues with respect, actively listening to their ideas, and collaborating to achieve common goals contributes to a positive and productive work environment.

  6. Continuous learning and skill development: Pursuing ongoing learning opportunities and staying updated with industry trends and advancements showcases dedication to one’s craft and adaptability.

Importance of Professionalism in Software Engineering

Professionalism is important in software engineering because it allows you to be a respected member of the software development community. It can allow you to get jobs, stand out at a job and generally be a person others think of for opportunities. Professional behaviour also ensures that one is a reliable and respectful co-worker and allows software engineers to foster positive working relationships with others. (4)

Best Practices for Maintaining a Professional Demeanor in Various Situations

Professionalism is essential in all aspects of software engineering, and maintaining a professional demeanour across various situations is crucial for career success. Below are examples of best practices for maintaining a professional demeanour in remote work environments and during client interactions.

Remote Work Environments

  1. Establish a dedicated workspace: Create a separate, distraction-free area for work to maintain focus and productivity.

  2. Set boundaries: Clearly define your work hours and communicate them to your household members or roommates to minimize interruptions.

  3. Maintain a regular schedule: Following a consistent routine helps manage time effectively and maintain work-life balance.

  4. Stay organized: Use productivity tools like task managers, calendars, and note-taking apps to keep track of tasks, deadlines, and meetings.

  5. Communicate effectively with team members: Utilize appropriate communication channels, provide timely updates, and engage in virtual meetings to stay connected and aligned with the team.

  6. Invest in reliable technology: Ensure that your computer, internet connection, and other essential tools are up-to-date and reliable to avoid technical issues during work.

Client Interactions

  1. Active listening: Pay attention to the client’s needs and concerns, and ask clarifying questions to ensure a clear understanding of their requirements.

  2. Professional appearance: Dress appropriately for video calls and ensure your background is tidy and uncluttered to present a professional image.

  3. Setting realistic expectations: Communicate the scope, timeline, and potential challenges of a project upfront to avoid miscommunications and manage expectations.

  4. Provide regular updates: Keep clients informed about project progress, milestones, and any changes or obstacles that may affect the project’s outcome.

  5. Delivering high-quality work: Strive for excellence in your work, thoroughly test your code, and address any issues promptly to ensure client satisfaction.

  6. Handle difficult situations with grace: If conflicts or misunderstandings arise, remain calm, listen to the client’s concerns, and work collaboratively to find a solution.

Handling criticism and feedback

Before we begin, you should recognize that we deliberately chose to use the word “criticism” in the title of this section. We intend to get you to understand that the strategies we list below are not just applicable when receiving nice and polite “feedback” but also harsher “criticism.” The goal is to leave the critic (giver of feedback) with a better impression of you. This section is quite long because, arguably, the marker of someone with outstanding professionalism is that they are masters of managing criticism.

First, we should ensure our attitudes about criticism and feedback are proper. Understand that when a co-worker, client, boss, manager, senior developer, or whoever gives you criticism or feedback, they may not fully understand what they want you to do. In other words, treat criticism and feedback as an open conversation, similar to how we learned in lectures on how to build solutions for clients. When someone approaches you with criticism or feedback, they often have a problem in mind, but may be unable to articulate it in such a way that you will immediately understand. As a professional, it is up to you to determine the exact problem they have and to communicate with them to arrive at a solution that you can also be happy with (this last part is super important!!! Being happy with the solution will help you give off the impression that you genuinely cared about their opinion and are not just reluctantly resolving the situation). Once you’ve solved the problem and implemented the changes, go back and check to see if there are other areas of your code or your work where you can apply the same feedback.

  1. Ask for suggestions or examples of how to solve the issue when unsure of what their feedback means or entails. For example, suppose your boss tells you that you are not engaged enough in online meetings (vague!). Ask your boss for suggestions on how to be more engaged. Your boss might say they want you to talk more (still vague!), but at least you now sense what your boss means. Moving forward, you might want to ask your boss if saying “Hello” to everyone when you join the call or giving signs of affirmation throughout the meeting, such as nodding your head, are actions you can take to be more engaged. Note that by asking ahead of time, you can save some of your own time and your boss some frustration. If so, you can start doing these things and later follow up with your boss to ask if they feel you have improved. If they say no, then you try something else and ask for more clarification until you’ve narrowed down what exactly was the problem and its corresponding solution.
  2. Avoid being overly defensive and overwhelmed by taking a step back if the criticism seems too harsh. You can step back in various ways, but we recommend being honest and communicating that you need a few minutes to compose yourself. This pause will also give the critic time to adjust their tone and thoughts so that the conversation can be more productive and beneficial to everyone involved.
  3. Acknowledge valid points that the critic gives by stating what you agree with (e.g. “I agree with you that this line of code here could be more readable”). Be very specific here so that there is no misunderstanding caused later on.
  4. Listen attentively, especially when they can see your face and body. What this means is to ensure that your body or, at least, your head is facing them, and ideally, you will give signs that show you are following along, such as nodding your head and so on. However, the more important thing is that you are paying attention to what the critic is saying and thinking about how you will respond using the first three tips to guide what you could think about.
  5. Do your own additional research if necessary and fully understand the feedback before replying or making changes, especially for code reviews. Following this advice shows others you are willing to take the initiative to improve instead of just being reactionary. However, if it seems like it will take too much time or if you are in a busy stretch, you may want to consult with the reviewer in question and ask for feedback directly, which may be more helpful, less prone to miscommunication, and faster. Especially for code, make sure to go back and check other code that you wrote to see if you can apply the same feedback and make improvements.
  6. Summarize the feedback once you’ve gone through all the steps and believe you have a strong understanding. In your summary, go over the problems that you’ve identified and the solutions and fixes you’ve agreed upon. If the person who provided you feedback is happy with your summary, then you can now go ahead and make the changes.
  7. Bring in a mediator to sit in if you feel that the critic does not want to have a productive conversation and is just personally attacking you. This mediator can be a co-worker, HR person, TA, etc.. The mediator should be unbiased (ideally they know you two to an equal degree), have no stake in the issue (they do not prefer one side over the other for personal reasons), have the communication skills necessary to calm the critic down, and point out when either of you is making a comment designed to personally attack the other person. Make it clear when asking someone to be a mediator why you feel the need to bring them in. If no mediator is available for whatever reason, and there is no higher authority you can appeal to, then we would recommend performing step 2 with a longer pause and remember to be honest with the other person.
  8. Self-reflect on the criticism and feedback you receive when it has been resolved. It’s important for us to re-iterate that feedback is a communicative process for resolving issues that naturally arise when working with others. As such, taking the time to reflect on the feedback you receive by thinking about how you can use this feedback to proactively avoid problems in the future makes your lives easier for the future. For example, suppose a co-worker tells you that your variable names are not meaningful enough and suppose you go through the feedback process and resolve the problem. The key thing to reflect here is to think about what your co-worker believes is important when it comes to variable names and to understand their reasoning. If you don’t understand their reasoning, then take the initiative and ask. When you go to write future code, you ought to think back to this exchange you had with your co-worker and aptly name your variables which will show the co-worker you took them seriously.

Other things you can do:

  1. Ask for feedback often by asking your co-workers, clients, managers, etc., to actively think about ways you can improve. We do not mean “often” as in constantly asking for feedback on every little task that you complete, but “often” as in making a consistent effort to let others know that you are always open to receiving feedback.
  2. When asking for feedback, always make a strong attempt to communicate to the other person how much you value and appreciate their feedback. Use words such as “appreciate”, “value”, “grateful”, “thankful”, etc..

Additional practices:

You can find additional professional practices on this website: https://engineerscanada.ca/professional-practice-in-software-engineering

By implementing these best practices, you can maintain a professional demeanour in various situations, enhancing your reputation as a software engineer and fostering positive relationships with colleagues and clients.

Business Communication as it Applies to Professionalism

Another very important professional skill for software engineers is the ability to communicate technical information to a non-technical audience. Often, projects in software engineering will involve stakeholders or managers/team members with varying technical knowledge regarding the product. These folks want to understand the impact that your technical contributions have had on the project, what the new features are and how they work from a user’s perspective. Software is not nearly as useful if it cannot be sold to the people who need it, so it is essential to know how to perform business communication with non-technical stakeholders or co-workers.

Here are seven tips from a Lucidchart article (5) on communicating technical information to a non-technical audience:

  1. Know your audience. Think about who your audience is and what they know. What are their areas of expertise? What is their level of technical knowledge regarding the product in question? Answering these questions will allow you to decide on the nature of the information you should share; how technical can it be and what should it be focused on? It is important to curate the information you share for the people you will be sharing it with. “It’s best to not give the impression that you are oversimplifying for specific members of your audience.”

  2. Be attentive to your audience throughout your presentation. Be observant of body language and the general tone of the room. This will allow you to adapt your presentation to the reaction of your audience members. If feel as though you are losing the attention of the room, it may be time to move on to the next topic, you may have gone into too much depth regarding this topic. If you have many confused faces looking back at you, you may need to dive more deeply into the current subject or re-explain yourself.

  3. Incorporate storytelling when sharing technical information. “Storytelling is more convincing than facts alone.” For audience members who may not be as technically versed, the facts alone may not be convincing enough. Use storytelling to engage your listeners. In general, storytelling is a good idea since it allows you to plant ideas in the minds of the listeners.

  4. Use visuals to explain technical information and processes. Visualizing your concepts can make them easier to understand. In fact, research suggests that visuals can improve one’s ability to synthesize information by 36%.

  5. Avoid technical jargon when possible. Certain technical jargon may confuse or disengage non-technical members from your presentation. Try to say exactly what you mean instead of using shorthands that are familiar to only other software engineers. This will ensure all audience members benefit in the same way from your presentation.

  6. Focus on impact when explaining technical concepts. The most important part of your presentation to the non-technical audience members will always be the impact of your work on the business and on the consumers/customers. To them, it does not matter what specific technology was used to decrease the CPU time of the product by 50%. It only matters that the consumer/customer can now enjoy a user experience that is 50% faster or that the business can now make 50% more money. It is not their job to worry about the technical details behind the product, so it is often not relevant to share those details with non-technical stakeholders or co-workers. “Focus on the initiatives and pain points that your audience cares most about, and your interactions will have a much greater impact with executives and other non-technical employees at your organization.”

  7. Encourage questions. Sometimes audience members may be uncomfortable speaking up and asking questions when something is not clear to them during your presentation. “As you go through your presentation, pause and ask, ‘Are there any questions?’ Create an atmosphere where stakeholders feel comfortable asking for clarification and starting conversations. “

External Resources for Professional Development

Included in this section is a list of resources of various types that provide interesting insights into the worlds of professionalism and professional development.

Articles:

  1. https://ethics.acm.org/code-of-ethics/software-engineering-code/ —– “Teaching and Learning Guide for: Software Engineering Ethics” by Don Gotterbarn, ACM SIGCAS Computers and Society

  2. https://medium.com/geekculture/soft-skills-for-software-engineers-part-2-get-things-done-cb41a49b9958 —- Soft Skills for Software Engineers — Part 2: Get Things Done by Andrei Vlasiuk

  3. https://medium.com/geekculture/soft-skills-for-software-engineers-part-3-effective-mindset-d9072d6ae7f9 —— Soft Skills for Software Engineers — Part 3: Effective Mindset by Andrei Vlasiuk

Blogs:

https://www.pluralsight.com/blog/it-ops/training-tips-for-it-pros —– 4 reasons IT pros need to train (even when they think they don’t) By Don Jones on August 17, 2015

Podcasts:

https://www.podchaser.com/podcasts/software-engineering-daily-62587 —– Software Engineering Daily - Daily interviews about technical software topics.

Resources from the University of Toronto:

The Arts and Science Internship Program (ASIP) can provide materials on how to become a professional software engineer. The resources are not publically accessible on the internet, but computer science students participating in ASIP can reach out to their ambassadors for help in this area. The CSSU also hosts many events or shares information about opportunities/events that may be useful in expanding one’s knowledge about professionalism in software development.

References for this Wiki Page

(1) https://en.wikipedia.org/wiki/Software_engineering_professionalism

(2) Don Gotterbarn, Keith Miller, and Simon Rogerson. 1997. Software engineering code of ethics. Commun. ACM 40, 11 (November 1997), 110-118. DOI: 10.1145/265684.265699.

(3) https://fellow.app/blog/engineering/engineering-everything-you-need-to-know-about-software-engineering-ethics/

(4) https://www.indeed.com/career-advice/career-development/why-is-professionalism-important

(5) https://www.lucidchart.com/blog/how-to-explain-technical-ideas-to-a-non-technical-audience