DEV Community: Ray M

Press pause on your imposter

Ray M — Tue, 02 Apr 2019 13:01:15 +0000

The first time I came across the term 'imposter syndrome' was in a conversation. After looking it up, I was quite surprised to see that there was a well-known label to a feeling I have had throughout my career. Today, it is a much more common phrase that I hear in conversation when people are describing themselves.

If this is the first time you have come across it, let me explain it. It is the feeling that you are not as good as the people around you. The belief that all that you have done to date is average or below average. For some reason even though people compliment you about the things that you have accomplished. You only hear a version that focuses on what could have been better. It is also the feeling that you don't deserve your position or compliment or award you received.

Despite a lot of evidence that you are doing well, you find it hard to acknowledge your wins as wins. For me, it was a moment of frustration that pushed me to want to change the way I felt. I can't say I am on an expert on this topic yet. But I am improving, and I also love helping others in their imposter feelings. I distil imposter syndrome into two parts.

Internal - Where your struggle to validate yourself internally against your own set of standards.

External - Where you struggle to validate yourself externally against a set of standards you have made up to compare yourself to others.

I would like to share the six tips that I do to help me pause my imposter's voice. Long enough to write and publish each article. And to give me the confidence to ask for something or take on a new challenge.

One. Recognise your imposter. You need to reflect on your feelings over the last week, month or year. If you have always felt like you are not good enough. Felt like someone is going to discover that you are an imposter and don't belong here. Then it is time to accept that you have imposter syndrome. I hope reading this article will be your first of many steps to improve how you deal with that kind of self-doubt. One of the first steps of recognition is to tell someone how you are feeling. It can either be someone close to you or speak to your manager. Your manager is an excellent place to start as they are in a prime position to help you through this.

Two. Don't be your own anchor. When you set unreachable standards on yourself. You create a negative framework that is not in line with a growth mindset. Some examples could be "My work is not good enough", "This isn't ready to submit", "I need to do it a lot better" etc. Remind yourself that this isn't the first time you have felt this doubt. The standard you are holding yourself to is likely above the expectation. The exceeding expectation is a good thing, but it needs to feel like you are exceeding it. Exceeding an expectation while feeling you are below average can be taxing. Becoming more aware of the gap between your expectations and the real expectation will free your mind for more productive work.

Three. Are you sure you can't do that? At times you will see something that you might want to do or try, but your imposter holds you back. You get the feeling of self-doubt or a sense of not knowing where to start. How many questions have you wanted to ask or tasks you have wanted to take on. Only to keep quiet and carry on with what you are doing. There is an excellent book called The Art of Possible by Kate Tojeiro (link). In the book in it talks about things that limit people's ability to believe in themselves. One of the points is around how people have a reluctance to be uncomfortable. When you are not sure if you will succeed in something new your imposter voice will pull you down to your comfort level. To help progress past this and take on the new challenge you need to remind yourself of the last 3 things that you didn't think you could do and now can. Switch the negative fixed thoughts to growth thoughts. Why don't you think you can do it? If you pretended you could do it for a moment what are the steps you need to learn to achieve success? It comes down to having a growth mindset and then applying effort so you can do what you want to do.

Four. Are you keeping score? One big thing I found with myself is since I was focusing on my improvements all the time. I would forget about my wins. So I decided to write my wins down. I didn't base them on my self-standards and just wrote down anything I did well. It didn't have to be a grand win. It could have been as small as handling a difficult conversation better than the last one. You don't have to show the list to anyone as the goal is to change your mindset. Looking back at my list several times a year helped me recognise my wins more. You will see that in the record that some of them are actually big wins and you should feel proud. When the next opportunity came, and my imposter started whispering doubts. I read my list and felt better that this was not the first 'new' thing I took on and completed well. Don't get caught up on needing only to write perfect wins and get started writing.

Five. Create a small win ritual. I am not the type of person that runs around a room screaming in glee when something good happens. I am more of a quiet fist pump in the silence of the night alone in front of my laptop. And I am okay with that. Although I found I was not pausing for long enough to let the win sink in and get stored in memory. So I needed to form a new habit to ensure I register the win so I can recall the feeling at a later time. This would help battle the imposter when it comes up again. I can't say I have mastered this, but I do two things. One is simple, I stop and go for a walk and tell myself that I did something right and I am allowed to feel proud of it. Ensure I am mindful enough to embrace the emotion. Second, is a give myself a treat. It can be as simple as a chocolate doughnut or buy something I kind of want but don't really need. I know they are still not grand gestures but they work for me and it is a work in progress.

Six. Change your language. Something I observed in myself and noticed in people around me. Are we are comfortable in saying we don't know something. That is ok as you are being honest. The issue with it is that it keeps you where you are. All you need to do is add one word "yet" to the end of the same sentence. So it now sounds like this. I don't know how to do that yet. It changed the way I thought about the task. I know it is achievable now and I need to invest time to get there. Saying or thinking fewer negatives is an excellent tool in pausing your imposter before embarking on something new.

I hope these six tips help pause your imposter long enough to feel good about yourself and take on your next challenge. I don't think you can completely remove your imposter. In a way, your imposter can be used to drive your excellence. But I know I feel much better just being able to pause my imposter a few times a month and be grateful for those small and significant wins.

Opinions expressed are solely my own and do not express the views or opinions of my employer.

So, you want to be a techie

Ray M — Fri, 22 Mar 2019 12:40:06 +0000

A short time ago I wrote an article about how a techie can upgrade their tech skills to a management role. (https://www.linkedin.com/pulse/upgrading-your-tech-skills-management-role-ray-moukaddem). I was grateful to have people reaching out with positive messages about the article. I also received requests to write about how a non-techie could become a techie. Considering I started as a coder, I have not experienced this transition but I have observed it. So, I did some research and talked to different people to find out their experience, thoughts and reasons for their aspirations.

The first thing that you need to consider is what you think a techie is. There are many levels of being technical as well as perceived levels. Is being able to installing a driver on a PC being technical? Is being able to code a Machine Learning algorithm in R being technical? Over the years I have heard comments like if you know VB.Net but not C#.Net you are not a real coder. Java is the ultimate 'real' coding language. If you are not managing your memory, manually you are not a 'real' coder. SQL or HTML is not 'real' code. Javascript is not a 'real' code. This one stopped after the rise of JavaScript frameworks which now rule the web. The judgement will always be there as some people like to define what they do as more important as others. I'm also here to tell you their judgement is irrelevant. The only measure you need is your goal on what kind of technical career you want and which skills you need to get there.

First consider which level of technical knowledge you want? Is it you need to know SQL to run more complex reports to boost your current role? Or do you need to build an AI prototype of an idea that you came up with on the weekend? Either way the below six points should help you get there. I have leaned the six points towards someone wanting to be a techie coder as most of the requests I received were directed at this.

Second, are you clear on your purpose in wanting to be a techie. What is your driving force making you want to stay up till 3am debugging code not doing what it should be doing? Is it you don't want to be excluded from this mysterious language of acronyms? Unless you are clear on your purpose that is making you drive down the binary road. It will be hard to persevere through the early feelings of frustration. It will be hard to find and fix an Uncaught TypeError.

Here are six things I believe you need to make quick progress into your quest to become more technical.

One. Start being curious about how everything works. There are so many things we use or interact with every day that you wouldn't stop to consider how they work. A techie is always curious about how things work. How does cloud storage work? How does the internet work? Why do Amazon's Audible personalised emails not look up the books that I have completed and exclude them from suggested books to me? Take the time to watch videos explaining how things work. Make reading tech articles part of your weekly routine. The process of being curious about the details is a big part of the skills you need as a techie. Through curiosity, you will learn about the smaller things that make up more significant things. Knowing more about how things work, means you know more about how to change them or fix them.

Two. Start small. You don't need to be an expert in all things at once. Technology is ever expanding. There are more and more platforms and frameworks being released every month. Choose something simple and specialise. This will make your journey quicker as well as easier to establish confidence and credibility. If you want to start connecting things together. Take a look at https://ifttt.com/. There are simple applets as well as more complex multi-step applets. For something in code. Take a look at SQL to help with data reporting. Most BI platforms allow you to write SQL which will give you more flexibility in deriving insights in your data. For coding languages either Python or Javascript is a great place to start and both languages are highly versatile. Remember you do not need to know everything at once. Also, don't be discouraged by comparing yourself to seasoned techies.

"Don't be discouraged by comparing yourself to seasoned techies."

Three. Break things down into small steps. You can start doing this on any aspect of your life. Here is an example. I want coffee. First, I need a vessel to carry the liquid in, a keep cup is the best type. Then I need coffee beans. I need to grind the coffee beans, but before that, I need to make sure I have a grinder. I need to check if I have milk. I also need to check if I have sugar. I need a coffee machine and hot water. Once you have all the items and utensils, you can start the process. Some elements in the process are repetitive. Like if you want 2 teaspoons of sugar. I won't list every single step in the process as you can see already. There are many little steps that make up one task. As a programmer, you are writing lines of code. Each one is a step in the process or a container for an object. Before you start writing anything you will think about the outcome you are after and work backwards on what steps you need to get there. Making this process something you do will help you have an analytical mindset. That's the mindset you need to be a techie

Four. Learn the basics. You are in luck. There are so many initiatives around the world that are teaching people to code for free. They even make it fun. Check out https://code.org/ or https://www.madewithcode.com/ and build your own SnapChat Geofilter. These platforms will step you through the basics of coding. Instructions, loops, functions etc. Each activity builds on the last. A few hours a week over a few weeks will get a good sense of basic programming. If you managed to get through them and love what you are doing. You are indeed on the path to becoming a techie that you can be proud to be. You can then start to challenge yourself by writing simple apps from scratch. Everyone starts with a Hello World app. But you could start with Hello Ray and send me a screenshot :). Google search will be your best friend through this stage. Don't worry even coders with 15+ years experience are Googling errors to find a solutions daily.

Five. Find a tech buddy. You want to find someone happy to walk you through something till you are able to understand it. Even if it is several times. Some will not have the patience and dismiss you back to non-techie space you came from. Ignore those people. Find anyone that has the knowledge and is willing to support you through your becoming a techie experience. Ask them what they are working on. Ask them to explain how it works. Ask them how Siri knows which apps to put in the app suggestion section with relative accuracy. If you have multiple people that can support you, it would be even better. Don't think any question is too simple or to dumb to ask. Something's you read or view online will not make sense right away and having someone you can talk about it with will really help.

Six. Earn credibility. Now that you have the building blocks of being a techie you need to put it all together in different shapes and sizes. To earn credibility start building your own apps in your spare time. Build a new report using SQL. Tell people what you have done and also explain how you did it. Start talking like a techie. Use confusing acronyms 😁 and make it sound complicated. Okay. Don't do that but do try and use the right language. It is more accurate and you will feel more like a techie. You can also ask people you trust directly what else you need to do to get on a project. Or remind them that you are eager and will deliver.

These six steps should start your adventure into the world of being a techie. For all those that were curious, I hope you enjoyed the read and can form a goal and action plan to become the techie you dream to me. My first tip is everything in code starts at 0 just like your coding skills. Be Patient and, and you will progress in no time.

"Everything in code starts at zero just like your techie skills"

Opinions expressed are solely my own and do not express the views or opinions of my employer.

Upgrading your tech skills to a management role

Ray M — Fri, 01 Mar 2019 01:41:03 +0000

I fell in love with coding at an early age. After my dad bought us a Commodore 16 and my techy uncle visited us from Los Angeles. He brought a Basic programming book with him, and I started copying the code and feeling the thrill of executing it. I wasn’t one of those whiz kids that could actually code at an early age though. But something clicked inside me, and I knew what I wanted to have a career in. Over the years I realised I am more of a logical thinker and the logical problems coding supplied was a good challenge.

Throughout my career, I spent a significant amount of time contracting. Being parachuted into different teams, projects and industries. The constant change allowed me to move through the tech roles of dev, architecture and leading teams. I then started to be exposed to the mechanics of the things that need to happen before a project being approved to build. I was able to observe the commercial decisions that are made, and their impact on the business before a project even started. I started to enjoy the management and business side and was fortunate enough to have some fantastic managers that could see my potential. They were willing to give me the responsibilities and coach me on my gaps.

This was a big deal for me. Since up until this point I would hear remarks or comments like "you are too technical for the management side" or "You're too techy". Hearing this and seeing most manager roles go to people without a technical background was disheartening. So, having a supporting manager investing in me is something I will always be grateful for.

I wanted to write this article and share ten tips for techies with an inkling to do more than coding. Your technical knowledge can be your greatest power and your greatest curse. All depending on how you use it. I leverage coding principles and apply them to non-technical situations in management. Below I have provided some mappings that I hope you will find useful and might help you move in the direction you want to go.

“Your technical knowledge can be your greatest power and your greatest curse.”

Zero. Commenting code. Let’s first address your self-doubt mindset. Unfortunately, there are always some that are going to make comments that label your skills. Or worse the comments are self-inflicted and anchoring you down. Think of it as running a performance analyser over your code. The lines that are coming up in red indicating a performance bottleneck is your self-doubt. How can you expect to take on a new role with a mindset that has a performance issue slowing you down? All you need to do is put the doubtful methods in a class all on their own. Then go through and comment out the lines of code instantiating the class or calling the methods. This can be a gradual process. One line of code at a time. I would recommend reading or listening to summary versions of The Subtle art of not giving a F*ck (link) to get you started on the right mindset.

The lines that are coming up in red indicating a performance bottleneck is your self-doubt
One. Big Fixing. Bugs have to be the most frustrating and most rewarding thing with coding. Business problems are like a coding bug. The main difference is the humans that are involved that are telling you which path to follow and what they think the real problem is. In management, you just got to follow your same pragmatic approach as you do in code. Ask the questions that start at the top of the problem, followed with questions on the next level down. Like you are debugging in methods and their sub-methods. You are trying to sort through the assortment of facts and opinions to find the root cause of the problem. Once you see it, you need to spend the time to understand it before working to resolve it. If you jump into a hack fix, you don’t know what the ripple effect will be. Take your time, ask the questions you want to ask and avoid going down random rabbit holes. If there is anyone more resilient to working through stress to find a root cause of a problem it is a coder.

If there is anyone more resilient to working through stress to find a root cause of a problem it is a coder.
Two. Mutual authentication. The notion of authentication is on the premise of trust. People are no different. You need to work on building trust with the people in your team and cross-functional teams. This is a time investment that is required. Going for a coffee to get to know someone better will make a problematic discussion down the road easier. The time invested in building trust has a very high return. I recommend reading Speed of Trust by Steven R Covey (link) or a summary version. It breaks trust down into 13 logical steps which are easy to apply in real life. Once you establish a trusted connection, communication becomes more efficient.

Three. Source control. There is a constant to what your team needs. The constant is they want to feel valued. They want to feel like their work means something and want to work with great people that are open to sharing. It is your job to create an environment where this will thrive. Lone wolves will make this environment very hard to build. You should be talking to the knowledge hoarders to understand if it is intentional behaviour. Then help coach them around the benefits of collaboration and sharing. Once you have improved the checking in of code. You need to be deliberate in linking the work they are producing to the business outcomes. Like checking in code related to a user story. Sometimes they can’t see the connection themselves, so you need to help map it for them.

Four. Variables. The thing that I have come to enjoy most is the fact that humans are variable. When you are coding, and you stop halfway through a method and go home and come back the next day. The code will be there waiting for you. In those 24 hours a human might of endured all sorts of highs and lows. They might have new information that has changed their opinion and are now less aligned. Now you are discussing the same thing with a new angle. The code has changed, and that is ok. This is normal and something that is not going to change. You need to use your curiosity and listen. Ask questions and discuss different approaches to a solution.

Five. Methods. Communication is key to your new role. But unlike a method, the same input will not return the identical output with people. You need to get to know some profiling basics and to work to adapt your approach when dealing with the different types of people. Consider people with an optional parameter for their profile. The profile parameter could be one of the four main groups. Amiable, Expressive, Driver or Analytical. Don’t make a mistake to think that all coders are analytical. Also, don’t make the mistake that you can approach non-techies with an analytical approach all the time. You want to improve the success of your communication messages. Try having a looking up those profiles and thinking about who you are interacting with and what the best approach would be to get the desired result.

Six. Separation of concerns. When you are trying to get an idea across, or you are trying to influence people. It is difficult when you are in a room with different types of people. Different personality profiles and different end goals. You wouldn’t add multiple items of logic in one class, would you? So why would you do it with people? When you have an idea, don’t go into a dark corner and flesh out all the details and set up a meeting for everyone to attend. Start by putting a 1 pager together and spend time with individual people who have different goals or approaches. Gain insights and feedback and iterate your plan with a common goal in mind. By separating the conversation from 1: M to 1:1 it allows you to have conversations that won’t get diluted or distracted by rabbit holes. Keep things simple and gain early consensus and then set up the meeting.

Seven. Micro APIs. Your success in your new role cannot be defined by one monolithic coding method. We are in a new age of micro APIs where each API has a distinct function. The cumulation of the APIs working together is what makes them successful. Your success is no different. Don’t look for a big win to define your success. Your success is an accumulation of small wins that work together.

Eight. CI/CD. Don’t expect that the first time you check in your code that it is going to compile against the trunk. Or worse it does, and the defect is deployed into a production environment. In management, you are going to make mistakes. The key is to recover quickly. Focus on what is wrong and take action to resolve. Be vulnerable and admit you made a mistake and you will do better the next time. It is about continuous learning especially from the failures that will make you better in any role. You can read more in my article 5 Tips for continuous improvement through failure (link)

Nine. The trade-off. The requirements have changed, and now you are faced with a dilemma. Focus on speed sacrificing best practice or Focus on best practice and sacrifice functionality. The tradeoff comes up all the time in many forms. In management, it is no different. It is easy to review someone else's code out of context and criticise it by saying you would have designed it differently. The reality is the grey area is the trade-off. Making a decision for your team one way or another means it came at a cost. Although we think coders are binary. The approach to management/business decisions is made in the same way. You factor in the environment, the outcome, the pros and cons of the decision. Then choose a direction and move forward.

I hope you have found this article useful in your journey to your next management role. If you have any other coding principles that would apply. Feel free to reach out as I would love to hear about them.

For any non-techies that have read down to the end. When I was discussing this article topic. It was also suggested to write the reverse article. For non-techy people wanting to move into a techier role. I will take that on and start thinking about the main obstacles and how to overcome them.

Image Credit: Photo by Jefferson Santos on Unsplash