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.

The Catalyst

In April of 2017, something important was happening to me. My team and I were in a difficult situation. The morale wasn’t very high, we were in the middle of a death march. Extreme overtime had become a routine, the level of job satisfaction was really taking a hit. The 4 first months at this workplace were the best of my career, and suddenly I was going to work reluctantly.

What happened?

At that moment, I figured my influence as a Scrum Master was limited to my team and its immediate environment. I had a hard time improving the global culture in which my team lived. To the point where, as turbulent as I can be, I was bombarding myself with questions such as “I am a good Scrum Master? Is it what I really want to do? Should I be doing something else, and if so, what?”

The Why

At about the same time, I was developing an interest in Simon Sinek’s work. His conference and book “Start With Why” were fascinating me. Without going into too much details, it is the theory according to which people will follow you not because of what you do, but because of why you do it.

Given the situation I was in, I started to wonder “Why” rather than “What”. At that time, I had no idea how powerful the answer to this question would be, but I had the feeling that I had to find the answer at all cost.

The Common Denominator

Why do I get up in the morning? Why do I go to work every day? It took me months of introspection to get to the bottom of it.

I started collecting data. From time to time, I would come back home from work and say “Well, that was an AWESOME day, today!”. I tried to find a pattern, the common denominator. What makes a day awesome, for me?

After a few weeks, the puzzle was starting to give me some kind of answer. A good day was when I had the opportunity to help someone improve their work environment or work conditions. When I helped someone take charge of their own future. Not only someone in my team, but anyone within my organization, or within my external network.

The Why, On Every Level

I was on the right track, but I still wanted to figure where my “Why” standed globally. For what noble cause do I want to help people improve their work environment? On what sort of scale can I make a difference?

I decided to apply my reasoning to many levels :

• Globally, I want to change the world. Like everyone.
• I want to put an end to this “debate” about whether or not it is worth investing in employees’ happiness and organizational culture.
• Locally, I wish to contribute in making Montreal the city where the most people are happy at work.
• And in my immediate environment, I want to bring more humanity at work. A necessity that I find is becoming increasingly rare.

It Can Change a Career

After such a revelation, questions like “What do I want to do?” and “Am I doing what I should be doing?” became irrelevant. Now that I knew my Why, I would try to spend as much time as I could applying it.

I took the risk of investing a percentage of my work time helping my teammates take charge of their work environment, individually or as a team. I also spent time doing the same thing with people outside my team, and outside my organization. My team went off on a very positive tangent, gradually improving their level of autonomy. Individually, my colleagues started owning their own destiny.

I realized that 100% of the human-centric value generated was made possible by this small percentage of my time during which I helped my peers grow.

At this moment, I stopped being a Scrum Master, and simply started being “someone who helps others grow”. My title had lost all its importance, because the totality of my raison d’être now resided in my Why.

I completely rewrote my LinkedIn profile, removing all the technical buzzwords as well as the elements that made it look overly professional, asepticized and cold. Rather than tell about where I am from, I started to tell about why I do what I do. In a human way that’s imbued with everything I’m passionate about.

Some time later, I get a call. This person tells me “I’d like to talk about what you believe in. We believe the same thing, and we need someone like you”. I’m offered the opportunity to invest 100% of my time helping people grow. Where do I sign? I now am a Software Development Manager at Marine Press. My title could have been anything, what’s important is that my role is to apply the reason I get up in the morning, every moment of the day.

Let me conclude with this quote from Gandhi, which easily summarizes what I learned in this journey.

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