My story

I work in tech. I have been a professional programmer for over two years now. But I am an impostor, or at least I get to feel like one on a nearly daily basis. I do not have a computer science degree. I have a B.A. in psychology, another B.A. in history and a Master’s degree in history. My programming education came in the form of online courses. What’s more, I have never had a passion for technology. I was certainly never afraid of it but I have never seen myself as a techie or dreamed of becoming a programmer. It was after realizing that my career options were limited and that going back to school was not realistic that I decided to try my hand at web development. I discovered freeCodeCamp and realized that technology was not only a good career and learning opportunity, but it could be used to do good things. I was hooked.

In the following months, I would take any free time I could to continue learning, often waking up as early as 5am on weekends just to get some work done. I started hanging out with tech community groups and kept going. Even after I started working as a web developer, I continued to learn constantly. Work would often highlight some holes in my knowledge that were just another opportunity for me to learn.

Still, in the world of professional programming, I am often seen as an impostor or a pale copy of a ‘real’ programmer. I have failed many interviews. Despite having a lot of practical knowledge, I am easily stumped by some basic computer science concepts. I have never had to write any exams or learn anything by heart, so my answer to a lot of questions would be to google it and figure it out. There are many things that I know are lacking in my knowledge. There are surely still a lot more that I am not even aware that I lack. This is all a work in progress.

However, I am not alone in this situation. According to Stack Overflow’s latest survey, 1 out of 4 programmers do not have a university degree, and of those who do have a degree, 1 out of 3 have it in a field other than computer science or software engineering. Every day, more and more people try their luck at their first line of code and start their journey as a self-taught developer. To alleviate some of the doubt that might plague them along the way (and still affects me more often than it should), I would like to present the ways in which having an unusual path to a programming career can also be a great perk. Although it is hard to make general statements about such broad groups of people, in my case, I see my background as an advantage in many ways.

Keeping the “why” in mind

For me, programming has never been about technology for technology’s sake. Technology is a tool. I am interested in creating cool, useful things with it. This is not to say that I have no interest in the theory. I love learning about algorithms, the underpinning of how javascript works, how to properly structure code. These help me get better at thinking about the problems I need to solve and write clean, maintainable code (what good is a cool app if you can’t maintain it?). However, these theories will never overshadow the need for the code to be useful first and foremost. For many self-taught developers, the basic computer science theory might be lacking, but the approach of learning-by-doing really puts the “why” of every line of code in the front of our mind.

Continued learning

Although the phrase “I don’t know” is one that I utter all the time, it is almost always followed by “… but I can figure it out.” Lack of knowledge is not an insurmountable obstacle, more like a small detour. By learning online, I have had to figure things out from day one. I got stuck constantly, got frustrated quite often and always made it through somehow. I learned how to identify problems and where to find the information I needed. I learned it the hard way, repeatedly. As the years went by, I continued to get stuck, but on more and more complex problems. I have also become more efficient in solving these issues.

I have also had to learn new javascript tools constantly and I have gained experience not only in those particular tools but in the best ways to learn them. I know what works for me to learn a new tool or technique, and I want nothing more than an excuse to do it again and again.

If you taught yourself programming, no matter how you might feel about your abilities, you would not have made it that far without becoming a resourceful learner and problem solver.

Seeing from the point of view of a lay-person (or beginner)

One of the advantages I see of not being a ‘techie’ (or at least not having been one for long) is that I can more easily relate what I am doing to non-techie people. Furthermore, my experience of going from an absolute beginner to a professional programmer make it easier for me to empathize with more junior programmers and teach from their standpoint. Although my two years experience still put me a ways away from ‘senior’ status, it is my goal that in reaching towards this, I will be able to work as a guide to more junior members of my team to help bring out their potential. For many self-taught programmers, this is a second career and they can bring to the table a point of view that is different from that of a lifelong techie along with empathy towards – and desire to help – more junior members of their teams.

Overall, my point here was not to downplay the benefits of a formal computer science education, but to argue that programmers with an unusual background can help widen the diversity of points of view and bring unique skills to the table. For those beginning on this journey, the road ahead is difficult, both in terms of learning and of job recognition, but more and more companies are seeing the value of hiring driven, self-motivated learners to their teams. Keep your chin up, and don’t let being an impostor keep you from getting real work done.

Marie Pelletier

I work with javascript, sometimes as a front-end or back-end web development or as a software developer. Above all, I am passionate about learning and interested in using technology for good.

Of all the jobs I’ve had, only one place asked me to come up with my own goals for my probation period. Not that I believe that personal goals are absolutely necessary, but they can be a very powerful tool for self-assessment.

To avoid leaving anything to chance, I take upon myself to create my own goals. However, what should they be aligned on? Most personal goals in business are aligned with organizational goals. Is there anything more off-putting than having to align personal goals to support more revenues, or lower costs. It isn’t very exciting.

In order to create goals that stimulate and motivate me, I tried using a concept that was popularized by the company Spotify. The “Definition of Awesome” is a list of elements one judges necessary to master in order to be considered Awesome. Nothing less.

This can apply to individuals as well as teams or even organizations. The idea is to answer these questions : If we were the world’s best team, what concepts would we master? What reflexes would we have? What would we do that we’re not doing right now?

Without necessarily aiming for perfection, while staying on the verge of utopia without falling in it, it is a challenge to identify a set of behaviors, knowledge or reflexes we would have if we were the best at what we do.

An awesome beacon on the horizon

The purpose of the exercise is to create a destination point on the horizon. A point of reference that we will recognize at all times, and will guide us. When an obstacle will rise between us and our destination, we can go around it and find our way again. One can even use this as a guide in a dilemma where multiple course of actions are possible. All in all, it’s a beacon we need to keep an eye on.

When our Definition of Done is defined, we can even add milestones to it, or create SMART goals that can help us measure our progress towards Awesomeness.

I will end this article by sharing my own personal Definition of Awesome, that I printed and displayed near my desk, as a reminder to myself. For those who want to experiment, I created this infographic with Canva.

Olivier’s Definition of Awesome

1. Work is not delegated as teammates volunteer
2. The team is focused on achieving excellence
3. Olivier supports the team that is mostly self-managed
4. More developers want to work here than we can hire
5. Other companies talk about the Marine Press culture

Now, what is YOUR Definition of Awesome?

Olivier Fortier

Owner of Primos Populi, partner and coach at Moabi. As a former manager, I prefer to use a “people first, the rest will follow” kind of approach. My favorite topics are organizational culture, safe work environments, and lowering the center of gravity of the decision making process. I cultivate people’s awesomeness.

www.primospopuli.com

However, being a Scrum Master also means, as I like to explain, being “a specialist of human beings in a technological environment”. The SM training teaches very little about the diverse ways we can achieve self-organization within a team, the ways to empower our coworkers, and making sure they take ownership of their work.

Here’s a rough estimate: 90% of the time, people that are now Scrum Master or Agile Coaches were previously either developers, project managers or team managers. Some of them chose this path, others were assigned to this role following a change in the business. It is not rare, for instance, for a developer to become Scrum Master because he knows the Scrum processes better than his colleagues. It is also common, for a project manager to become Scrum Master “by default”, after the adoption of Agility in the company.

Sometimes, though, one’s past will dictate how one tackles the present and future, and I think this is especially the case for Agile practitioners. Our past experiences have a high potential of influencing our approach as Scrum Masters, and most of us will encounter certain challenges and will be tempted to use old reflexes while coaching our teams. Since 50% of the problem is solved by acknowledging it, I thought it would be a good idea to write about this subject.

I came up with a list of what I think are the “good qualities of a Scrum Master”. I am not claiming I am right about everything, but the idea is to see what challenges a SM will face based on his/her professional background. To cover most cases, I will focus on those that have backgrounds in software development, team management as well as project management, using a simple list of pros and cons.

Being a Scrum Master with a software developer background

It’s a very common case, and sometimes a developer will even be a part-time Scrum Master. I will refrain from discussing this practice too much, as I haven’t tried it myself, but in my experience, a dedicated Scrum Master can have more than enough work to focus on his/her role. Everything depends on the expectations held by the company and the team.

A former developer will be good at:

• Understanding the technological dimensions of the product, as it will be useful every day;
• Finding the balance between quality and efficiency;
• Applying concepts such as a simple design, refactoring which he/she should already know;
• Facilitating any processes related to Quality Assurance;
• Applying and defending practices such as pair programming and peer code reviews;

A former developer might have difficulty to:

• Manage interpersonal relationships and conflicts if he/she isn’t used to it;
• Ensure self-organization within the team if, for instance, he/she used to be a team lead with the responsibility of deciding “who does what”;
• Keep in mind that principles are more important than practices;
• Be an agent of change, or dare disrupt established order;
• Know when to let the team fail when necessary;
• Use his/her power of influence;
• Follow up the state of the sprint and make projections;
• Create burn-up charts as well as roadmaps;
• Facilitate relationship with the client;

Being a Scrum Master with a project manager background

A typical case, following change management in a company, that went from “waterfall” to agility. For some, a project manager can fulfill both Scrum Master or Product Owner roles, as if it was a simple Tetris block that fits perfectly in the equation. I have seen numerous cases where this worked perfectly well, and some others that were more problematic.

A former project manager will be good at:

• Following up the state of the sprint and make projections;
• Creating burn-up charts and roadmaps;
• Facilitating relationship with the client;
• Coaching the team to focus on a common objective;

A former project manager might have difficulty to:

• Manage interpersonal relationships and conflicts if he/she’s not used to it;
• Ensure self-organization within the team, and refrain from deciding who does what;
• Keep in mind that principles are more important than practices;
• Be an agent of change, or dare disrupt established order;
• Know when to let the team fail when necessary;
• Balance quality and efficiency;
• Be at the service of the team, and not the opposite;
• Master concepts such as simple design, refactoring, quality assurance, pair programming, peer code reviews;
• Let the team estimate the work;

Being a Scrum Master with a team manager background

This is a little less common, and everything depends on which kind of manager we are speaking of. Let’s take for granted that it’s proper people-oriented management. Someone with this kind of experience will probably have no trouble understanding the concept of being a servant leader.

A former team manager will be good at:

• Managing interpersonal relationships and conflicts;
• Ensuring self-organization within the team;
• Keeping in mind that principles are more important than practices;
• Being an agent of change, and daring to disrupt established order;
• Letting the team fail when necessary;
• Using his power of influence;
• Coaching the team to focus on a common objective;

A former team manager might have difficulty to:

• Understand the technological dimension of the product;
• Find the balance between quality and efficiency
• Apply concepts such as simple-design and refactoring
• Facilitate processes necessary for quality assurance
• Apply and defend practices such as pair-programming and peer code review

In the end, no matter the direction a Scrum Master’s career takes, he or she will have to master elements that are outside of their expertise or experience. What we need to keep in mind is that without Agility, there is no Scrum, and no software. The Scrum Master must keep his/her focus on the fact that teams are composed of human beings, it’s the team that must be developed in priority.

I will conclude with a quote that I saw in my LinkedIn feed while I was writing this article and that magnificently summarizes the biggest challenge of every agile practitioner:

Thanks to my colleague Éric Laramée for the quote!

Olivier Fortier

Owner of Primos Populi, partner and coach at Moabi. As a former manager, I prefer to use a “people first, the rest will follow” kind of approach. My favorite topics are organizational culture, safe work environments, and lowering the center of gravity of the decision making process. I cultivate people’s awesomeness.

www.primospopuli.com