I was a factory worker for many years. It was not until recently that I was hired as a developer in a huge company. I was hired largely because I have an app and a portfolio to show.

Now that I've started, I can't shake the overwhelming feeling that I don't belong. Everyone else has an exceptional background and some are fresh out of college. Everyone else has a background with computers, but I'm the only one who does not.

I learned to program and to build apps by myself. I've never done the things that coworkers talk about and do, like test-driven development and unit testing. I just build, and build, and refactor as needed. I've also never worked in a team like this. I always did my programming alone; now I have to talk to— and deal with people, who think they are far better than me.

My questions are:

  1. How do you get rid of imposter syndrome?
  2. How do you deal with egotistical coders who think you're no good because of your background?
  3. What impact do you think it would be if a lot of people at my workplace know that I don't have a computer technology background?
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – user44108
    Commented Sep 2, 2019 at 14:20
  • I just want to say thank you everyone for responding and giving a good answer
    – Tifa
    Commented Sep 5, 2019 at 21:40

11 Answers 11


Congratulations on been selected for the job!

You got hired because, you showed results of what you are capable of.

  • Don't pretend to know things you don't.
  • Be aware: others are also fighting imposter syndrome. You are not alone.
  • This industry continually evolves. Everyone has to keep learning, or they fall behind.
  • There will always be someone who knows something better than you, so don't worry about it.
  • If others know a topic better than you, ask them to teach you something or ask for references.
  • If You know something better, be open to requests to teach it.
  • Just continue improving Your skills... until retirement day... And beyond ;-) .
  • 1
    @Tifa Also, cooperation in general is absolutely essential; you're saying you're used to single-man projects, which is fine. But you must improve your team skills to succeed further. Communication is extremely important when you're designing and developing software among peers. You might be frustrated for a few months about how much harder it is to develop software as part of a team, compared to being the sole developer. Persist, improve, and don't forget to look for the things that make being part of a team worth the while - like having another pair of eyes on your code :)
    – Luaan
    Commented Sep 2, 2019 at 8:34
  • 12
    I have background in computers and still struggle on a daily basis with imposter syndrom. I'd almost argue it's part of the job description Commented Sep 2, 2019 at 8:43
  • 1
    "This industry continually evolves. Everyone has to keep learning, or they fall behind." This is very true. I heard some years back that the half-life of your knowledge is 7 years, meaning that in 7 years half of what you know now will be obsolete. You have to keep running just to stay in place. Commented Sep 2, 2019 at 10:13

I'm one of many, many people who develop software without an academic background in it.  (I got a GCSE in Computer Science, but didn't study it at A-Level — sorry, I don't know what the equivalent of those would be in other countries — and my degree was in Mathematics.)  But I've been working in IT for two-and-a-half decades now, and still seem to be getting away with it!

I have no doubt that you know your stuff, and have the potential to be a great programmer.  You wouldn't have been hired otherwise — and you wouldn't be asking here if you didn't care and want to be better.  And those are probably the most important things!

None of us is perfect, and as long as you're aware of that, you're probably going to do fine.

I'll mention a few of the things that I'd tell the 21-year-old me — you can judge whether they apply to you at all.  And because I've got pretentious in my old age, I'll use some quotes:

“Programs must be written for people to read, and only incidentally for machines to execute.” — Abelson & Sussman [preface to Structure And Interpretation Of Computer Programs]

It's really important for code to be as clear as possible.  (Almost) anyone can write code that runs and does what it's supposed to; but it's really hard to write code that anyone else can read, understand, and work on.  And you will be working with other people: you'll need to read and understand their code, and they yours.  (And you'll need to read your own code, months or years down the line, so you'll be doing yourself a favour too!)

A more vivid way to put this is:

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.” — John Woods [comp.lang.c++]

On complexity:

“Everyone knows that debugging is twice as hard as writing a program in the first place.  So if you’re as clever as you can be when you write it, how will you ever debug it?” — Kernighan & Plauger [The Elements Of Programming Style]

It pays to keep things as simple as you can.  Simple code is easier to understand, easier to maintain and extend, and more likely to be correct in the first place.  When you know advanced techniques and clever hacks, it's tempting to use them to show off.  But resist the temptation!

Sometimes I think the most important — and difficult — task we programmers face is that of fighting complexity.  In the face of increasingly complex and demanding requirements and requests, ballooning codebases, and ever-more-complex tools, keeping things simple is a real challenge, but it's vital!

“Be consistent.” — Larry Wall [the perlstyle manpage]

(Yes, you might well find that funny coming from him… :)

Consistency is really import in a codebase. No code is perfect, and the code you inherit will probably have unhelpful indentation and spacing, confusing names, out-of-date techniques, and/or worse.  Many of those are worth fixing when you work on that code.  But before you do, look around the codebase and see if those things apply everywhere.  If so, grit your teeth and leave them alone — and even write new code in the same style.  With a large codebase, a uniform style/naming/&c is much easier to read and work on than a patchwork of different styles — even if that one style isn't the best.

(That's not to say you should never look to improve existing code — just do it in a way that your colleagues will approve of.)

And finally, a point I don't have a quote for: always question requirements.  Always ask “What's the ultimate goal here?  What is this actually trying to achieve?”  Because very often, what they've asked for won't actually do all they need it to, or will cause problems elsewhere, or will perform badly, or will add unnecessary complexity, or will be hard to maintain in future, or will prevent other planned improvements, or will take far more work than necessary.  It still surprises me how often a bit of investigation can lead you to a different and much better solution.

— As I said, you may already be aware of some or all of these points.  In which case, you're part-way to being a great programmer already! 😀

  • Abelson & Sussman presumably write code for fun and not for actual paying customers.
    – rghome
    Commented Sep 2, 2019 at 8:37
  • 2
    @rghome: No; the effect of that quote would be that they write code that's less likely to have subtle bugs, is easier to maintain and enhance, needs fewer comments, is more amenable to optimisation, is kinder to colleagues, and is less likely to be thrown out and rewritten from scratch by a future maintainer. (And the wide recognition and influence of their book would seem to support that.) Of course, that won't interest you very much if you just want to take the money and run; but this question is about being a good programmer!
    – gidds
    Commented Sep 2, 2019 at 9:40
  • I don't have a problem with readable code (except that it's a subjective measurement), it's the "only incidentally for machines to execute" bit I have a problem with. Incidental = happening as a minor accompaniment to something else. If the code doesn't run on a machine, it is useless; if it doesn't perform or functions badly and people don't buy it, it is useless. Hardly incidental.
    – rghome
    Commented Sep 2, 2019 at 11:15
  • 2
    I think they expect the reader to understand that the quote exaggerates to make its point…
    – gidds
    Commented Sep 2, 2019 at 11:24
  • 1
    Consistency is really an important point. My own experience is that mediocre but consistent code is far easier to maintain than elegant, beautiful, very diverse code. Of course, if you can be consistent AND elegant, it's even better.
    – gazzz0x2z
    Commented Sep 2, 2019 at 14:18

You have an app and a portfolio to show. You can write software. That means you are far ahead of many people applying to jobs, and ahead of quite a few people who get jobs.

"Fresh out of college" isn't exactly an "exceptional background". "An app and a portfolio to show" is a much better background. I have seen a small number of developers who came fresh from college and were good. I have seen many more who came fresh from college and were useless.

If anyone judges you by your background, they are stupid. If they say that they judge you by your background, they are stupid and deeply insecure. Someone who is confident in himself will judge you by how you do your job, and help you improve if needed.


Ultimately, you need two things. One is programming ability. If you did not have that to a really impressive extent, you would not have been able to produce a portfolio that would convince your employer to hire you. That is an achievement worthy of pride.

The other is background knowledge. Programming is sufficiently complicated that there is literally more to learn about it than can be learned in one lifetime. I've been learning to program off and on since 1967, and I'm not done yet. No matter what your education and experience, most colleagues will know something you don't. Everything you can learn from others is something you do not have to reinvent. Unit tests and TDD are useful techniques, so learn them, and apply them when appropriate. It does not matter if a colleague is silly enough to look down at you for a different background. Just learn whatever you can from them.

For now, learning on the job should be your main agenda. At some point, when you have settled in and sufficiently picked your colleagues' brains, consider taking some evening classes to get a more formal background.

Don't worry about coming from an IT background. Spend a year or so in the job you have, learning everything you can from it, and you too will have an IT background.


There is a solution to these concerns: work hard and prove you are deserving to be there and deserve their professional respect.

As far as a non-IT background (prior professional experience an/or post secondary education), only elitist people care and this is their problem, not yours. What you are capable of doing is far more important. Two of the best programmers I ever worked with had NO formal college education; plenty of Masters degrees that were terrible.


I got hired because I have an app and a portfolio to show.

Always remember this. The company wouldn't have hired you if it didn't see any promise in you.

When I started I can't shake this overwhelming feeling that I don't belong to my job.

That will go away with time, as you settle into your new role.

But I was not doing any TDD or any unit testing.

That is ok, as long as you are willing to learn and implement them. Many companies don't do Tests, and use manual QA's instead, so take heart in the fact that you are at least getting to learn the best practices.

I also used to work alone and now I got to talk to and deal with people who thinks they are far better than you.

That is how most IT projects are structured - team work is the key. It seems that you haven't developed this skill completely, so it would do well to be open and receptive to new ideas, and try to think team first over me first.

  1. How did you managed to get rid of imposter syndrome?

You remember that you are not alone in having the imposter syndrome. Everyone have their shortcomings. Maybe some of the other coworkers (SOTOCs) haven't struggled as hard in life as you. Maybe SOTOCs haven't worked on a project end to end by themselves. Maybe they believe there are other things they are not so good at.

There are things that you are good at, and there are things that they are good at. Your task is to learn the good practices from them to do your job better.

  1. How did you deal with egotistical coders who thinks you're no good because of your background?

Think with a cool mind, do these people appear egotistical just to you or everyone? In my experience, arrogant people / egomaniacs are that way with everyone, not just specific people.

If they behave that way with everyone, learn how others deal with them - could be by keeping communication professional and short, or talking to them after doing complete homework.

If they behave that way only with you, analyze what are the shortcomings in your communication, and try to overcome them. Maybe they expect you to do some self-research before asking questions, or be more observant in general about what they are talking. You mention not having had to talk to others previously, so maybe its causing frustration inside you? Think through it all.

  1. What impact do you think it would be if a lot of people at my workplace knows that I came not from an IT background?

I've worked with people who have had different backgrounds (not as factory worker, but not an IT worker either). In general, what matters is what they do at current job, rather than what their background is. As long as you are doing tasks right, it should not be much of a bother.

So don't worry about what would people think. Remember the first point, The company wouldn't have hired you if it didn't see any promise in you.


All of the people worked on my company came from an IT background. This really gets me as I was the only one who is not.

As someone who has been a Systems Administrator for over 10 years now, (working at a few different software development companies), I'd say that your definition of an IT background is too broad. Most of the programmers that I've worked with, (including my egotistical brother, who has a number of programming degrees and 15+ years of programming experience), are clueless when it comes to actual IT knowledge. Some of them were only able to turn on their computers and load up their IDE to work with, and they were the senior programmers. One bit of advice, if you ever see a command that starts with: chmod 777 that is an evil spawn that you should ask your IT department to help you with. It gives too many permissions and can compromise a computer.

  • I don't think this is really an answer to the question asked. The OP is not an administrator, he's a programmer. IT doesn't really tell much about what you're doing, but it's clear from the question the OP cares the most about the "software development part". Not that anything is wrong with what you wrote - it would work as a great answer on another question. The world is full of people who have too much confidence in their poor skills ("this is immune to SQL injection!"), and people who have too little confidence in their great skills ("I don't know how to fix all 42 possible exceptions!").
    – Luaan
    Commented Sep 2, 2019 at 8:40

How did you managed to get rid of imposter syndrome?

Don't do this. Instead of worrying and feeling unadequate because of the "impostor syndrome", don't put yourself down. Don't beat yourself up and belittle yourself and your achievements because of the "impostor syndrome". You should not feel bad, discouraged, or intimidated.

Instead, use the "impostor syndrome" to accelerate your learning progress. You realize that there are many things that you should know, but you don't know them yet, so start learning. You have a lot of things to learn and master, so don't waste time watching tv and porn! If you feel that you are inferior to your colleagues in knowledge and abilities, only hard work and studying will shrink that gap.

Don't compare yourself to others. Realize that you are at the beginning of your programming career and you have a lot to learn, so get into it. Don't just half study, really study and try hard! There are a lot of free resources to learn programming out there, such as YouTube and eBooks. I am mentally supporting you in your journey to become a better programmer. There are thousands of us out there, people who are decent programmers but just not great ones yet. It takes many years of studying and practice to become a great programmer, but eventually you'll get there. Then you'll give advice to other programmers who have the "impostor syndrome".


Congratulations! You're an adult human being!

That might sound flippant, but the problems you described are common to people with decades of experience and sizable bodies of work.

I attended an in-state university in a town with a better reputation as a "party town" than a "center of serious learning." I also worked my way through college, including doing blue collar work. Early in my career this wasn't a great thing, but having worked as a professional programmer for about 80% of the time I was in college meant that I had more experience than people who were fresh out of college.

Over time, my career took off and I found myself in more challenging positions and suffering from what we now call "Imposter Syndrome". I've also worked with colleagues from "better" universities with more than just an undergraduate degree. It doesn't matter that there was no such thing as a graduate degree in Computer Science when I attended college, they had a Masters or PhD and I had a BS. And decades of experience.

What you have described is not at all unique to you.

What you do have, which many of us with degrees have also experienced, is a demonstrable track record as a developer. That's all the proof you need, or needed, to get your foot in the door.

Mind you, you weren't hired as a senior- or mid-level developer. If you stick with what you know, build on that, continue to prove your ability, you will progress in your new career. And as you do that, as others of us have found, you will continue to encounter both self-doubt (which is normal and natural) and small-minded people (who you should just ignore).

It's a great field, with lots of great people, and some who are just not so great. Ignore the bad people, focus on yourself, challenge yourself to improve, and you'll do very well.

And welcome to my little corner of the workforce. I've been a developer for almost 40 years and it has been an amazing experience.


While having some technical background helps some, at the end of the day, your code on your pull request will be the only thing that matters if your pull request will be approved or not... your career background will be irrelevant as a pull request approval criteria. You’ve got bigger problems if its the other way around.

I’ve seen horrible code from guys with and without BS/MS CompSci degrees and I’ve seen really good code from both camps too so degrees really aren’t really good indicators for competency / skill.

Yes, there are elitist CompSci degree holders out there but they are not representing ALL CompSci folks so don’t lump everyone into one category... you will miss out learning from the good ones if you do.

I think writing tests provide a lot of value on all code bases so it’s worth looking into. Leaving code bases largely without tests is just plain irresponsible.

If you’re in a good company, you having a non technical background will be irrelevant, your work is what’s going to count.

About me - someone that doesn’t have a CompSci degree that worked with a lot of folks that do and a lot of folks that don’t. 2 decades in and still having a blast developing software.


IMHO, imposter syndrome is not fitting for what you're experiencing since you do have shortcomings when it comes to your work such as not knowing test driven development. From your post, it's also not reasonably inferable that you're co-worker think less of you.

I was in a similar situation when I was hired for a development job based on my good grades although I didn't really have all the skills for the job. I felt that everybody was judging my slow tempo (I didn't know the stack either) and I was once close to going to my boss and just tell him that I'm obviously not good enough and I should probably leave. I think being in a new working environment is just extra stressful when one has to learn things on the fly.

  1. That's not imposter syndrome, that's not having the same background and less experience and it's okay. Just be friendly and honest about what you can and cannot do. I often didn't ask and try to cram like for a test so that nobody can tell what my limitations are. When I started to know my team better, it was easy to ask for help because no one was expecting me to know everything in the first place. Most people will give you the resources to learn if you just ask nice. The term is used a little too often for my taste anyway. Just like not everybody who's sad has a depression, not everybody who feels out of place at his/her job has imposter syndrome. Especially right after starting a new job in a new career.
  2. If that's truly the case then I suppose that it's best to keep a formal relationship and do your work as best as you can. But I would suspect that you read a lot into their behavior due to your rightful insecurity which comes from not knowing as much as you think you should.
  3. It depends on how you present the fact and how you deal with your shortcomings. If you do good work and are eager to learn then it should be fine. Just remember that some people with degrees are elitists who will never see you as equal. Prove them wrong by being an important part of the team.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .