Is Software Engineering a good career choice for neurodivergent people?

Computer Science and I.T. jobs are often depicted as perfect for neurodivergent people (for example, autistic, ADHD or AuDHD). Being able to focus long hours on the code without disruption, fewer social interactions, ease to work with predictable machines, working on one’s own, making use of pattern recognition and an analytical mind… all sound amazing for many neurodivergent people. However, the reality is not always as presented in the many articles on the topic.

In this article, I’d like to draw attention to some misconceptions about software engineering and other IT jobs, and share what to look for or pay attention to when choosing a job that accommodates special needs.

I’ve worked for 10 years as an administrative assistant before moving to software engineering for the past 5 years. This dual background allows me to be critical about how things are in the IT industry/jobs, and elsewhere, and to point similarities and differences. As a software engineer, I’ve worked for several companies, including consulting, so I also have experience about the differences between small and big tech companies, and different sectors.

Social interactions

The strongest argument for working in IT as a neurodivergent person is the fact that there are way less social interactions than in other jobs. In my experience, this is not always the case. If this is important for your wellbeing at work, you should investigate about the way the software team is interfacing with the requesters.

Ask questions like:

• who is the customer for the product we develop (internal, external, several ones?)
• how do we interface with them (collect their needs, make sure we’re heading in the right direction…)
• what internal and external regular meetings happen within the team, and which ones you’re supposed to attend
• what happens when there is a conflict in the team, or with someone outside the team

I’ve observed 3 main trends in how software teams interface with the customer (internal or external):

1. Not at all when the product is not customer-facing. For example, when developing the backbone of a system that is solely responsible for handling the communication between several modules. In that case you would only be in contact with developers from the other modules (although that’s still communication with other humans!).
   This is something I really rarely saw. It’s also a job made for highly technical profiles and which can be more repetitive than other development jobs.
2. Developing a customer facing software with a product owner (PO) or business analyst (BA). Most of the communication happens between the customer and the PO/BA, sometimes involving the tech lead or a team leader. Depending on how the roles and responsibilities are defined, developers might be expected to contact the requesters in case of doubts or questions, and for testing. This is the configuration I’ve experienced the most.
3. The team develops a customer facing solution without product ownership. Developers are responsible for clarifying the requests with the customer, validating with them, etc. I had such a job once, it made me contact a lot of people I didn’t know in the company, adapt my speech to each of them, make calls because most people prefer calls over message chat…

Each SW team has its own recipe, so do not hesitate to ask questions and get a clear picture during the recruitment process. If I had troubles communicating with people, I would definitely try to find a development job for a non-customer-facing product, or at least in a team with a Product Owner or Business Analyst who handles all communications with the end user.

If communication is a weak spot, I would also avoid consulting. Most consulting companies expect developers to be able to make presentations and be convincing with the customers, even search for new opportunities sometimes. Also, you get to change teams regularly, introduce yourself to new people over and over again.

In any case, as long as you work within a company, within a team, you will have to handle communication with colleagues. It’s also really important to ask about the meetings that take place in the team (daily standups, retrospectives, alignments…), the general communication style and expectations.

💡If communication is a blocker, you might consider developing and publishing applications on your own, and making money through advertising or membership. However, this kind of self-employed job requires a lot of autonomy and organizational skills.

⌚️When I was an admin assistant, I didn’t have much interactions with other people in the company because I didn’t have a “customer” in the company (contrary to most of my experiences as a developer). I did have to answer the phone for external customers though. The dynamics in a provider-customer relationship is different than the one in a collaborator-collaborator relationship.

Flexibility and Work From Home (WFH)

Another perk of working in IT is the flexibility in working hours, and the WFH policies. As many neurodivergent people experience sensory issues (being overwhelmed by light or sound for example), WFH is a blessing. It’s true that Software engineering jobs often come with a few WFH days per week, probably more often than other jobs.

The downside of WFH policies is that no one has a fix desk anymore, every one is supposed to find a free spot in big open spaces on the days they’re expected in the office. Open spaces are the worst. If noise and/or bad lights are a problem to you, search for companies that offer a lot of WFH days per week, and try to organize most meetings and conversations on the days you’re in the office, so you can escape from the open space.

Regarding flexibility, it’s also something you should make clear with the company from the start. I’ve worked in some companies where the word was “you work when you please” during the interview, but once on the job, there were actually fixed hours during which everyone was expected to be reachable. Also, mandatory meetings didn’t allow for total flexibility.

This is a very good example of unclear communication which led to some tensions between those who didn’t want to stick to fixed hours, and those who expected team members to be reachable during “normal” hours.

💡Some companies offer full remote positions. There are not many of them, and the legit ones are usually very difficult to join (their employees don’t want to quit, the recruiters tend to be more demanding during recruitment). Focusing those companies also limits you to the languages and technologies they’re using. It changes the way you search for jobs (from a skill focus to a company focus).
Those companies sometimes work based on the “asynchronous communication” principle. Since workers are distributed worldwide, most of the communication is written. Therefore, everyone can choose their working hours/work according to their local time.
🔍One interesting example is the GitLab all-remote workforce, you can read their whole policy on their website.

💡WFH policies can always change over time. We’ve seen many companies stop or reduce WFH days allowance over time. Never take it for granted. Also ask if the WFH days are imposed by your boss or if you have full flexibility over them.

⌚️My admin assistant career dates pre-Covid19, I don’t know how much it evolved in the meantime. Back in the day, there was no way for me to work from home, none of my employers ever allowed it.

Hyperfocus and high interest

A software engineering job is great for those who thrive in the flow (the state of concentration where you loose track of the time and what’s going around you) and need hyperfocus in order to be motivated. However, this is only true if IT and coding are a passion to you. You might discover that you’re passionate about software after you give it a try. But it won’t necessarily be the case.

Also, software engineering, and related fields like data engineering, can be fascinating and exciting at times… but they can also be boring or overwhelming. The state of flow requires a good balance between challenge and comfort. Which means it breaks when you encounter a bug too difficult to understand or fix “quickly”, or when you’re stuck doing repetitive tasks (coding CRUD, http calls…).

The fact that you reach the flow easily in the first years of your software developer’s job doesn’t mean it’ll stay as satisfactory over the years. I guess this could be said about most jobs anyway. The good point is that IT offers a lot of careers options, moving from software engineering—either technical or non-technical.

Another thing to consider is that the software industry changed a lot. Nowadays, you’re expected to handle many technologies, complex applications, multiple languages. Developing a single mobile application is different from developing microservices in a Cloud infrastructure for example. This is another thing to consider when choosing a job. Some will thrive in a fast changing environment, while others need to focus on a limited number of tools.

💡Before considering studying/training to become a software engineer, make sure to test development by yourself, going past beginner tutorials. Develop a full project by yourself, even if it ends up imperfect, to make sure you actually like it and find satisfaction in it.

⌚️Being an admin assistant, I could reach the flow just because I loved organizing and structuring things. But over time, the job always became too simple for me to enjoy it. The support roles often lack career evolution possibilities.

Autonomy

I often see the software developed represented as a man working on his own in front of his own computer. No one to dictate what to do or how. Full power at hands. Well… that’s not what happens in companies. As soon as you depend on other people, and other people depend on you, you loose autonomy.

Depending on the management style at your company and in your team, you might have a lot to absolutely no independence in your work. In some development teams, tasks are assigned to people upfront, in others, there is a backlog from which you can pick from. Sometimes, you can choose your tools and languages, other (most) times, there is a strict framework.

💡Knowing how autonomous you’ll be on the job is tricky, because not every manager judges “normal autonomy” the same way. Prepare concrete questions and examples about situations where you need a lot of autonomy, or those where you need full directions.

⌚️It might sound weird, but I felt way more autonomous as a secretary than in my software engineering jobs. Most of my admin jobs were in a “one woman team” setup. Of course, my role was to support colleagues or customers, but I had total liberty over how I made it happen. Even when I was part of a team, I was dealing with my own client portfolio. As long as I could present the results, no one would tell me how to do stuff.

Dealing with criticism

For those suffering from Rejection sensitive dysphoria (RSD), or other conditions making it painfully hard to receive feedback and criticisms, software engineering is probably not a good choice. A lot of the developer’s time is dedicated to code reviews. Which means giving and received feedback. In the worst cases, it becomes like a never-ending unpleasant ping-pong game (it can be the case when your work is sloppy, or when you have a very stubborn colleague).

It requires the developer to be able to receive feedback and accept to make changes to their initial proposition when the feedback was right. Either you decide to change your code or try to defend your idea, you have to do so with self-control and not take things personally.

💡Some companies, usually startups, don’t do code review because they don’t consider code quality a priority. They prioritize fast-paced deliveries. If that’s ok with you and you care more about results than code itself, you might want to look for such companies. When code review is part of the job, it’s written in the job description, so it’s easy to avoid.

⌚️As an admin assistant, I don’t remember receiving feedback on my work as long as I could provide results. There is no way a manager will look at your Excel spreadsheets or Word documents to check that you used the right way of doing things…

Need for completion, short tasks and difficulty to commit to long term projects, need for change and tasks diversity

All my jobs in software consisted of creating or maintaining long-run applications. I can think of very few cases where you would develop something and not maintaining it on the long term. Company applications, either for internal use or for sale, are rarely one-shot projects and single deliveries.

The only opportunities I can see for shorter term projects are Proofs of Concept (POC) or Minimal Viable Product (MVP) to get the buy-in of the customer (in which case you will anyway end up working on the final, long-term product), or developing helper tools to support the team operations (which cannot represent a full time job).

The code review process can also be frustrating, as you finish coding your feature or bug fix but might have to go back at it in the future.

As a rule of thumb, the development tasks that take the shortest time are the most boring ones, while interesting tasks require more time. It’s just nice to have a mix of them so you can balance your level of frustration.

Consulting can help you get more diversity, but projects are rarely shorter than a year, and often span over several ones. When you were involved in a project, it’s difficult to get your manager to move you to another project if the first one is not finished (unless you were part of a really big team and didn’t show specific knowledge or skills to that project).

💡Ask about opportunities to develop side-projects, like helpers or experimental features. Some companies also have departments dedicated to innovation, developing POCs and MVPs before handing the actual project to another team. If you need short term projects and a lot of variety and freedom, look for “innovation labs” or similar team names.

⌚️In all my admin jobs, tasks were really short. However, there was a lot of repetition daily. On the other hand, administrative jobs can take many shapes, and the content of the job vary greatly from one company to another, or from one job title to another. I had opportunity to work in logistics, marketing, medical… and it always offered me a totally different job.

Need for structure and clear instructions

How much the team and the work are structured highly depends on the maturity of the team, the size of the company and the sector. Agile frameworks (Scrum, Kanban…) offer great models to organize software teams, but they require committed people in the team to work. In the real world, they’re often half-implemented and loose their sole purpose.

Clear instructions mainly come from clear tickets created by the Product Owner or the Business Analyst. Without those roles, developers usually have to look for additional information, or go with their intuition (meaning, sometimes, they have to start all over because they didn’t meet expectations, leading to a lot of frustrations).

I also noticed that some senior developers are really bothered by questions from junior or medior developers and give half-answers instead of properly coaching those who need it. This also leads to unclear directions and risks of taking the wrong approach to complete a task.

I only had one experience where the business analysis was super structured and precise, and the senior developers would be great coaches. Other experiences were either bad or mid in that regard.

💡Whether you thrive in anarchy or hyper-structure, prepare precise questions to evaluate how things are going at the company you’re targeting. People usually tend to present their team or company as more organized than it really is.

⌚️Being an admin assistant, I was the master of the organization in the team, and no one could mess with my work. Requests came from a single person for their own interest, which led to way clearer instructions and simpler communication flows.

Struggle with organization and prioritization

As a complement to a few previous paragraphs, it’s important to understand that a lot of software engineering jobs have become complex and require personal and communication skills. If you struggle with executive functioning, you have to be very careful about what job you take.

Developers have to manage priorities (you often end up working on at least two tickets in parallel, either because you’re blocked by an external factor, or because your first one is pending code review), participate in some meetings and sometimes give presentations, meet deadlines…

I’ve never worked somewhere where developers were not expected to take ownership and initiatives. Although it would not necessary cost you your job, you might feel pressured by peers and management if you don’t go above and beyond code.

You also need to organize your workload and fight procrastination. You usually get assigned tasks to be finished by a certain date (few weeks or months). It’s more difficult to organize one’s workload on a such a long period than to complete a single same-day task without dealing with a backlog.

Things that really matter when searching for a job as an autistic or ADHD person

As you can see, IT is not a perfect solution. It’s just a possible solution among many others. Any job can be a perfect job for a neurodivergent person, if well chosen. Having specific needs, it’s even more important to ask a lot of questions before accepting a job. What usually will make you run away from a job are the company culture and politics. Unfortunately, it’s not easy getting a full picture before stepping foot in the workplace (physically or virtually).

Investigate what the company does to improve Diversity, Equity and Inclusion (DEI). Most of the time, I noticed that there are projects in higher levels of the company, but team managers are not on board with it or not included. Your direct manager will probably have the most impact on your wellbeing.

Official DEI campaigns are not the only thing to investigate. In fact, I would personally feel more confident if my potential manager seems to understand and accept that each individual has their own way of working, rather than with a company showing DEI banners on their corporate websites but not making sure their people leaders are aligned and really understand what it means.

It’s important to be aware of what exactly you need to be successful and happy at your job. Usually, it requires try-and-error: you will only learn what you don’t want anymore when you’ve been disappointed by a job. Take some time, regularly, to write down things that give your energy and joy at work (or in life in general), and things that drag you down and make you sad, angry or frustrated. Use it as a compass for your future job searches.

If you require accommodation, talk about it during the interview process and observe the reactions of your interlocutors. If you notice the conversation is difficult from the start, it’s a red flag. If they can share similar accommodations they made for people in the past, it’s awesome!

Startups vs Big companies (and everything in between)

Generally speaking, startups offer great spaces for creativity, free thinking, experimentation, and few rules. They run in a loose organization and don’t focus too much on quality and standards in the beginning. Big companies tend to have more structure, more communication channels, more reporting and more regulation.

Of course, this is very dependent on each company, but this general rule can help you focus your job search.

The sector (consulting, pharmaceuticals, medical, automotive, government, software editor…) has a great influence on how the company works too.

Self-employment and freelancing

The examples I gave in this articles are related to corporate jobs. Things can be quite different with self-employment or freelancing.

As a freelancer, you can end up in exactly the same role as a regular employee, but you have more freedom (it’s easier to leave the company), you can focus on short term contracts if that’s what you like, you’re less impacted by the company politics…

You can also work on your own and develop solutions that you publish and sell (or monetize) by yourself.

The first solution offers a good balance regarding job security and income, the second one offers the most freedom and allows you to create your dream job, but is less secure and not great for anxious people.

Finally, both solutions require you to be able to organize your job, beat procrastination, search for opportunities and/or work on your marketing, handle your finances… although a lot of those tasks can be delegated (with a cost…).

A few resources about neurodivergence and STEM (Science Technology Engineering Mathematics)

Is there truth to the neurodivergent STEM stereotype? Busting the myth: Neurodivergents are only good at STEM roles (Mentra)

Understanding the Challenges Faced by Neurodiverse Software Engineering Employees: Towards a More Inclusive and Productive Technical Workforce (Microsoft research)

Neurodiversity in the tech sector – Global research of accessibility, barriers and how companies can do better (Change the Face)

It’s not all about IT…Breaking the stigma in employment choices for autistic & neurodivergent people (Xceptional Academy)