Dealing with reactions from colleague about being self-taught

Question

I'm working as a software developer for a big company in Western Europe. I have 2 years of industry experience and 2 more years as a freelancer doing web apps on the side. All in all, I've been from the frontend to the backend of the software process.

However, I did not go to college to study Computer Science. I'm a self-taught developer. This non-formal route has been causing few reactions from a colleague of mine (a CS graduate) with whom I work on a project. Whenever we sit down on a break or discuss some task, she always starts explaining things like I'm junior developer with no programming skills whatsoever. Yesterday, she literally started explaining to me what JSON is and how I can manipulate it. I do not mind technical discussions at all (that is my job), but I find this a bit offensive and I do not know how I should react.

Also, through social media I noticed that she is really proud of her CS degree. Of course, that is a really great achievement, but it seems like she somehow gets challenged by my sheer presence in the room as a self-taught developer without all that university prestige, etc.

My question is how to react to this type of reactions from someone? If I continue listening to it, it will mean that I really do not know basic concepts of programming. If I say something, I risk being labeled as someone who doesn't like criticism.

PS. I passed my technical interview for the job, and the job before that.

Answer 1

FYI, most universities don't teach about things like JSON. They teach things like depth-first tree traversal that you could theoretically apply in creating your own JSON library, but anything more practical than that almost everyone is self-taught or learned on the job.

Try not to get defensive. Explaining practical technologies like JSON is something we expect to occasionally have to do even for university graduates. Someone with better social skills would ask if you're familiar with it first. If they don't ask, feel free to simply interrupt and tell them.

Answer 2

There's no reason you can't indicate that your colleague is providing superfluous information during technical discussions.

Hey Coworker, lets skip the trivial details and get to the crux of the issue. This is not a very effective use of our time.

She may just have a tendency to over explain things or get off topic, but a good skill to develop any time you are interacting with other developers is to politely but firmly keep interactions succinct and on topic so that everyone's time is being spent efficiently.

Answer 3

When you're in the computer technology field, you may find many people who don't have great social skills. Don't jump to conclusions. Also, people from different parts of the world or within a given country may see certain behaviors differently. In the US, people from small towns often see people from larger cities as being loud and aggressive. They may talk louder out of habit and not because they're trying to be aggressive.

You may be surprised to find this person doesn't see what they're doing the same way you do. She may just be "talking shop" and may not think you don't understand any of it at all. If she started out these explanations with something like, "Well if you ever took the Introductory Programming X class, you would know..."

It doesn't seem like you're engaging with this person in conversation. There's nothing wrong with you mentioning that you learned that as well. You may want to say, "I learned that , where did you learn it?" Your tone of voice will indicate if you're being defensive or unable to take criticism. Beware, some people don't always pick up on these subtleties.

I'd be more concerned about formal areas like meetings or code reviews. Be engaging. State your case. Admit when you're wrong. See how she interacts with other people. You may not see a difference.

Answer 4

To be fair, I've got pretty good credentials and I had a former supervisor do this to me all the time. I took an in-depth CS class on database design, had built all kinds of database-driven applications, and had been working professionally for years, and he still had the gall to explain to me (in front of everyone else) beginner database design principles.

But I'm not sure he was doing it on purpose. The truth is, it takes a lot mental energy to put yourself in someone else's shoes and speak to their level. You see it all the time: experts will sometimes throw meaningless jargon at you, or others will talk down to you. But they don't necessarily mean it--they're just not expending enough energy to figure out how to communicate well.

In my experience, that was the hardest thing about tutoring CS. Not only did I have to understand the material in depth, I had to use quite a few brain cycles trying to get inside my students' heads and figure out what they were thinking. But not everyone practices that in casual conversation.

So don't be too quick to chalk it up to malice. It could very well just be their own social awkwardness. I would tell you how to not take it personally, but I'm still working on it myself. I personally can't stand it either...

Answer 5

This is similar to other answers, but with a few concrete examples.

If you're asking for help / you two are discussing the task at hand

When I'm on the other end of this. It's really hard to know what background knowledge someone has when explaining something.

Under explaining and over explaining are both bad. The solution is to communicate what you do/don't know effectively and quickly.

In your example before she dives too deep into explaining JSON, interrupt (politely) so she can tick that off her 'list of things to explain'.

Oh I got what JSON is. What I dont know is how to deserialize it to an object in C#. How do you do that?

Or in the discussion. Like say if someone proposed to use JSON as the format and you have concerns. You would still interrupt because you want to get to the relevant part of the conversation quickly.

I'm familiar with JSON. I think XML might be a better choice since our upstream services already expect it in XML.

If you're being taken to task for not doing something. Then you follow the same pattern.

Her: You could've used X. X is a -

You (interrupting): Yea, I'm familiar with X. I used Y because X has this downside. I also considered Z but decided against it as well.

Her: What about A which is a -

You (interrupting): Ah yes I considered A as well. But it didnt work because of REASONS.

Her: If you combine A with Z you can solve REASONS.

You: Yea that could work. I'll look into that.

I usually prefix with 'Yea' as a more agreeable short form of 'Yes I'm aware of that' and it takes the edge off.

As long as in general, you maintain a neutral tone you won't come off as not listening to criticism.

Also, you will be wrong some day. Just make sure you when you are, you are similarly open and honest.

If you're chatting in general

Now we're into the area of polite conversation etiquette. Not exactly my forte but here's how I'd handle it.

In many cases I just nod and wait til they're done. After which I'll say something like 'Ah yea I'm familiar with JSON. I've used in X.'. And just continue the conversation.

If I have some place to be, there's no choice, I have to interrupt. Which is harder in a regular conversation. But basically I just say 'Yeah' and nod while they're talking. And as soon as they pause even slightly I say the line from the previous paragraph.

Caveat

I'd caveat all the above with: Sometimes it's good to listen anyway as you might pick up something you didn't know. In fact I often ask people to explain concepts like I didn't know anything about them.

Answer 6

Disclaimer: I am not a software developer

I'd recommend you avoid making the assumption that she is intentionally being condescending. It could very well be that she thinks your lack of higher education means you don't have knowledge of basic programming concepts but you have no proof of this so you're better off not thinking it. I often explain basic concepts in planning meetings because it helps me to wrap my head around certain problems and ensures that everyone is following my thought process, not because I think the other people in the room are idiots.

In addition to @Link0352 and @JeffO 's excellent answers, where possible, I'd recommend just gently steering the conversation back down to the level it needs to be at for productive discussion.

Sure, we could manipulate the JSON, but this could lead to problem X. In this case, I'd recommend manipulating the object directly (Or whatever).

(I'm assuming this interaction occurred during a technical meeting and the co-worker didn't just wander over to your cube and start rattling off about JSON. If that is the case, my answer doesn't really apply.)

Answer 7

From another female dev

I'm a university educated developer and have worked for a while now. I have to say that I have nothing but admiration for self-taught developers. Honestly there is a so much stuff that I struggled to learn that I just can not believe you guys actually managed to teach yourselves. And I love discussing with those who are self-taught because you usually have a whole other kind of skillset than the uni crowd. It is inspiring and pretty badass tbh.

And as for the lady who started explaining a JSON to you, don't give it much thought. We have this happen to us a lot. Men who are well-meaning but end up explaining mundane things because we are girls and we are so uncommon in this field that they feel like they have to help us a bit more, even if it becomes kind of insulting at times. I'm lucky to have been met with nothing but respect in my work place, but I have heard some horror stories.

She probably didn't mean anything bad by it, but it was most likely just her own insecurities shining through a little bit and maybe she felt like she had to prove herself by teaching you some stuff.

Answer 8

Additional to other answers, my generic solution to people explaining you obvious things:

When they are done, turn the table. Start explaining more deep knowledge about the recent topic or explain another very obvious e.g.

other person: Json is a great for ... and you can do ...
you(smiling/friendly): Exactly! What I also like about Json is that you can ....

or if you want to be a bit mean

other person: Json is a great for ... and you can do ...
you(smiling/friendly): Exactly! Have you ever heard of XML? It's a [explanation of something very obvious]

Answer 9

I'd advise patience. I've witnessed conversations among people with the best training and decades experience discussing a programming situation where they started from absolute square 1. That we need to represent a real world entity in the software, that a data structure has been created to be that representation, that this data needs to be sent over the network to another system, etc.

What I inferred from their approach was that by taking a couple minutes to make as many assumptions explicit as possible and establish a shared chain of reasoning, a solid foundation was laid for working together.

It may or may not be that these explanations are a sign of disrespect or resentment (or an attempt to prove her knowledge to you), but it can be turned into an opportunity to get on the same page and share perspectives to make the working relationship better.

If it ever gets out of hand or you really feel the need to say something, I suggest asking a question that shows the limit of your understanding.

"JSON is a format for representing data structures as text."

"Oh, JSON, I was just reading about the different implementations, do you know if there is a reference example of a parser built with lex and yacc for JSON?"

Answer 10

Open your mind.

University does teach skills that you will not find in books (aside University textbooks) and that you probably lack if you are self-taught. How I know? I studied, but some parts of the field were not part of my curicculum and I'm self-taught in those fields. So I know both sides.

She probably has something to teach you, but both of you don't realize what that is. She thinks she needs to explain basic concepts. This could be either because she is condescending, socially awkward, arrogant, has an inferiority complex or whatever else you want to believe in - or it could be because she genuinely wants to support you.

In dubio pro reo, so until proven otherwise, assume the best and welcome her discussions with an open mind. However, once you realize you already know what she is trying to explain, thank her and explain that you understand this already. Ask her what else she has to offer, you are eager to constantly learn and improve. This is the advantage of being self-taught: You understand that learning is a constant process that doesn't end with the exam or the master thesis.

Use that advantage. Learn from her, that can be only to your advantage.

And one day, there will be something that you know and she doesn't. Teach her in a friendly, non-condescending way and you two could be off to a brilliant, mutually supportive work relationship.

Answer 11

I have seen this many times as a consultant over the years. The answer is simple. This is a coping mechanism.

It is one of two complexes and can be a combination of both.

• Inferiority Complex

  An inferiority complex is the lack of self-worth, a doubt and uncertainty about oneself, and feelings of not measuring up to standards. It is often subconscious, and is thought to drive afflicted individuals to overcompensate, resulting either in spectacular achievement or extremely asocial behavior.

• Superiority Complex

  Superiority complex is a psychological defense mechanism that compensates for an inferiority complex.

Both are a defense mechanism.

If you are the only target of such behavior, then the subject is likely threatened by your skills or ability.

If you are one of several targets of such behavior, then it is a general feeling of inferiority within the offender.

Generally, you will see compensation mixed with grandiosity of some form. It could be as simple as being overly proud of their degree. No one is immune from being a target. For example, I have seen people with lessor degrees attack those with superior degrees such as engineers. It is a leveling mechanism that attempts to raise ones self esteem by diminishing another stature. We see this behavior on the p!ay ground as kids.

While you may not want to attack someone for such an insult, this behavior can be a danger to you and others especially in the work force.

Likely, there is little you can do to combat this without making yourself look bad. The reason is that the transaction is designed to not only indicate superiority, but to also solicit a response that enforces the superiority.

In this case, it appears that the offender has taken Parent role. Only an Adult response will do. A Parent or Child response means you lose. This can be seen by reading I'm OK, You're OK and Games People Play. Both are based upon Transactional Analysis. It would help to read the first book. It is relatively simple to understand and teaches you to recognize the three states and how to respond.

Simply put, this is gamesmenship.

I am reluctant to offer suggestions on how specifically to combat this verbally since the advice could potentially be harmful. This needs to be combated in the moment.

For reference, Transactional Analysis is not pop psychology. It is a real tool that should be understood. I used TA in my consulting career and was highly significant in my success as an IT consultant. It allowed me assert myself as the adult in the room, make my points, and hopefully make an effective case for my solutions.

I was often called in to fix a problem or replace a system for which someone was responsible. Often, the power was being taken from the individual who was now defensive. Battles such as these are often about power, either the loss of or the aquiring of power. The goal is to minimize the threat by minimizing the loss. For example, at a global company Microsoft Mail was aging and had to be replaced. The responsible employee held the reigns tightly and managed all the servers requiring them to be in one location. For a global Telecom, this was a disaster. People in Japan would have to connect to servers in Virginia to read email. The burden was huge and email would not be delivered within 24 hours. The employee was afraid of technology that he did not understand or know and was worried about his job with a distributed global system. The solution was to walk the employee through training, test installs, supporting remote systems, and having him realize that he still played a pivotal role within the organization. He was not losing power but gaining power. All this through TA.

Okay. Well and good. The short answer I have is to understand the three transactional types and learn how to present an Adult posture and how to recognize the real goal of the transaction you are presented with. You can quickly and easily short-circuit the problem without anyone ever realizing it and position yourself as a leader in a silent but effective way. The overall effect will be seen.

Answer 12

Most of the answers here discuss confrontation or commiseration w/ your experience. I do not believe confrontation is worth your time or this other developers time.

Instead I recommend a bit of social engineering that was often practiced by Benjamin Franklin aka the Benjamin Franklin Effect:

Ask for help, for advice, for suggestions. Asking for a favor is a sign of intimacy and trust.

This may seem counter initiative, but if you ask a few pointed questions about trickier subject matters it will subliminally cause someone to acknowledge that you understand the foundational subject matter and thus give you more trust. It will also make them feel more trusted by you because you came to them for this "difficult" topic.

This is a quick non-confrontational solution that will work in most cases.

Answer 13

Talk to her about it.

Your interpretation of her behavior is that it is because she thinks of you as inexperienced. Many of the other answers have given suggestions for alternate interpretations to her behavior, and some give suggestions as to how to shut the behavior down, which, without knowing why she does it could just needlessly put additional stress on the relationship.

The only way to know why she is doing it is to talk to her about it. Ideally you could just ask her directly, let her know why you are asking, and assure her that if you don't understand something you will ask.

You know her better than any of us so should have a better idea how she would react but consider starting with something like this:

Hey Sue, I know we've not been working together very long and are still learning what to expect from each other. I've noticed that when we talk shop you often fall into pretty basic explanations of what I consider standard topics.
Why is that?
I'm hoping it is because X or Y (give one or two of the more generous interpretations from the others), but it often feels like I've given you the impression that I need these things explained. If that's the case, it seems we are wasting valuable time that could be used more productively discussing the required features. If you are unsure of my experience with a topic, you can ask what I know about it, and if the discussion touches on something outside my experience trust that I'll ask.

I wouldn't initially interrupt her while she is in one of her explanations to have this discussion because it seems more likely to come across as reactionary or defensive. Better to approach her separately.

Going forward from there, depending what comes of the initial discussion, when and if it happens again, you could interject that this is one of those basic explanations, or start applying some of the suggestions from the others on how respond in-line.

As an aside:

In a project last year I had to explain what JSON was to couple of team members. They both have at least a decade (or two) of industry experience on me, and at various points in their careers both had worked on web projects. They just never worked with any frameworks or needed techniques where it was particularly relevant.

In the same project, we had some of the business folks we were working with interchangeably use the same two or three terms referring to two closely related but (as it turns out) distinct topics. Which topic a given term meant depended on which of them used it and in what context. It actually took a few iterations for us to catch on. Up until that point, it was never clearly laid out that there even were distinct topics. They assumed we knew, and we assumed they were all referring to the same thing.

More recently in a discussion of a mis-configured application, I had a team member go off on a tangent for a half-hour proposing misguided changes to our configuration framework to prevent the wrong default environment from being selected, when the problem was that the application had the wrong default value for an individual setting. (The framework allows for default fallback values in case it is not overridden for the current environment, the application had what should be a production only value set as default, so when a test environment didn't override it...)

What's the point? Almost any professional field is broad enough that for any given person, regardless of level of experience, it is impossible to know everything. Everyone will have different holes in their knowledge and experience, and there may well be subcultures and specializations with clashing lingo. You can't just make assumptions about what other people know, or mean, or why they make certain decisions.

It has been my experience, unstated assumptions can (and eventually will) be very expensive. A few minutes spent to ensure everyone is on the same page before beginning any discussion will save a great deal in the long run.

In this case your assumption that she is doing this because you are self taught, and/or (if your assumption is correct) her assumption that you need the instruction is causing harm to your working relationship.

Answer 14

IT is a very wide field.

Assuming that someone has to know JSON just because he has a grand total of 4 years of experience (or 40) would be a rather dumb thing to do by your coworker. You could have been developing applications that do not use JSON, or frameworks that hide the details of JSON.

Worse yet, you could just have partially learnt to use JSON (for example, by modifying the work of someone who was not careful enough); assigning you a JSON taks without ensuring that you know how JSON is used at your organization could lead to a substandard product. For example, maybe your code must work not only for success but also to show an appropiate message in case of error.

Given that you are new to your position, one of the means of your coworker to ensure that the job is done properly is to review your knowledge. The method described above is one of the available, she could alternatively opt to question you or wait until your task is finished and review the code. I do not know if you would prefer any of those. Certainly, just letting you be is risky (for you, for her and for the business) until she is sure that you are up to the job.

Note that none of the above is related to your lack of academic certification.

And the "I passed the technical interview" point does not absolve you from getting examined. A technical interview gives only a very superficial appraisal of your competence; it tells that you can write code that works but not that you can write good code.

There are a lot of aspects that are important but cannot be examined easily:

• Ability to understand problems.

• Ability to read other people's code.

• Ability to use a proper architecture.

• Write good structurated code.

• Defensive programming.

• Good practices in the use of tools (version control, automated testing).

And for the "degree vs self taught" issue, accept that the lack of a degree means that your interlocutor can make less assumptions about what you know or what you do not know¹. Specially in relation to the above explained points (many self taught people just do not even know about the existence of those factors and just go to the "I want to do a program that does X"²)

Someone with a degree can certify a minimal base of knowledge³, the lack of a degree makes stronger that your interlocutor may be unsure of your level until you prove yourself. So, do not get defensive if your interlocutor choses to to double check that your knowledge is complete enough for the task at hand.

TL/DR Give that programmer some time so she gets to check by herself your capabilities.

---

¹Of course, that does not means that someone with an academic degree is always capable of writting good code because someone explained "defensive programming" to him. But the degree ensures that at least he should know what the concept means.

²Right now I am modifying a program done

³In fact, that is basically the utility of degrees.

Answer 15

Developer with or without degree must be respected equally at workplace.

I read all the answers above and most of them are pointing out that she is being kind and you are over thinking it.

But from your question, it doesn't seem like so. You seemed like feeling insulted by her behavior.

In my opinion, it is the time,you need to showcase your skills. It may be her perception that degree is what makes a Software Developer, but in my experience working on real time projects and solving critical scenarios is what makes a 'Software Developer'. Don't Brag, but take part in the technical discussions proactively.

For showcasing without bragging, start helping your fellow mates, juniors etc. Your work, skill set and everything else will speak for yourself.

Answer 16

This is a little bit trickier than some of the answers make it out to be. You shouldn't just come out and say you don't need help (arrogance), nor should your silently keep listening (it's annoying!).

My advice is to... dazzle her with your knowledge. If you understand something that is being explained to you in the software development industry, show the person who is explaining it to you that you understand it, by discussing it, and then gradually introducing your advanced knowledge of the subject to show you understand it. When somebody just listens, a lot of folks, and especially engineers are prone to think the listener is unable to engage in the discussion because they don't understand.

Case and point, when somebody is explaining something obvious to you in the industry, stay silent, chances are they will explain it again in a slightly different way... several times with incremental frustration. Respond, show you know it, and they tend to leave you alone, or find something better to discuss.

To stop the technical badgering completely, show that you know MORE than the person trying to teach you and they'll quickly learn not to lecture you and if anything come to you with questions.

Now if they're explaining JSON to you because you made a critical error, or have just demonstrated a missed architectural concept, that's where you shut up and listen.

Just my two cents on what has worked for me in the past, everybody's a bit different though.

Answer 17

Warning: This only works with some people in some situations; YMMV. This answer has no warranty.

---

What I would* do in this case is interrupt them with a topic summary. For example, with JSON:

Them: JSON is JavaScript Object Notation, which is a way of representing —
Me: Dictionary-like objects and, erm, arrays and primitives and, JavaScript primitives I mean, in a serialised format.

This accounts for the following situation:

Them: JSON is JavaScript Object Notation, which is a way of representing —
Me: Any object in JavaScript as a string.
Them: No, because it can't store functions, or objects that have hidden properties; it's a very simple representation of...

Interrupting them with "yes, I know" in this case would lead to problems later when I turned out not to actually know what JSON was, so caused problems in the code with my assumptions.

Your colleague is probably just trying to make sure that you know everything that you need to. If you're "self taught" then that means you could have gaps that most people would assume you have filled since you know the "harder stuff" (though most educational establishments teach such things in a really weird order too!) and that sort of assuming can lead to subtle, hard to find problems due to false assumptions.

---

*: see the top of the answer.

Answer 18

I guess you could say - I already know a little (emphasis on little) bit about JSON. So, can we skip JSON for now ? But, if there is something I don't know about JSON, can I ask you for help later ?

Answer 19

You did not mention the industry, which will make quite a difference.

I work in a large high tech company and often hire young developers (0-2 years of experience). The school they attended to and their degree does not make the slightest difference to me.

I recently rejected two candidates from the best school in the country to hire one from a school I do not even remember the name of. The difference between them was that the two first ones were good and the third was brilliant, also because he was self-taught. It was obvious after 5 minutes that he would do great.

What does this mean in the context of your question? Probably that you may be better suited in an industry which gives a higher importance to knowledge vs. the school.

Depending on the country this may be more of less difficult as different countries regard on their schools with different levels of deference (France being the extreme where you almost wear underwear emblazoned with your school, if you are from the right one -- this is not a bad thing depending on the kind of work)

Answer 20

Self-taught developers will often be experts in technologies where they have practical experience, but sometimes the problem is that they don't know how much they don't know. For example, I've often encountered self-taught developers inventing a new algorithm to solve a problem when there's a well-known standard algorithm, which is often much better.

Try to remember that if you were a plumber or an electrician, let alone a doctor or a lawyer, you wouldn't be allowed to practise without formal qualifications. Programming in fact is fairly unique in allowing those whose skills are entirely self-taught to work in the profession. And many of those who do so, do an excellent job. But try to recognize that those who have done a CS degree have learnt things that you haven't, and be open to learning from them.

Incidentally, a CS degree won't teach you much about JSON. It will teach you, though, about what class of grammar JSON belongs to, and therefore what class of parser you need to process it: it will teach you to avoid the mistake of trying to parse JSON using regular expressions, because the theory tells you that can't be done. You only have to follow StackOverflow for a few weeks to see how many programmers are unaware of such fundamentals.

Answer 21

Let's just say to your example that you don't manipulate JSON. You take JSON, convert it to a model object, manipulate the model object, and convert it back to JSON. I would bet that if your colleague tries to manipulate JSON directly, there will be bugs because JSON is simple, but not that simple.

Now if he is so clever, print out a copy of this paper https://www.ics.uci.edu/~dan/pubs/LenLimHuff.pdf which is about calculating optimal Huffman codes with limited code lengths (Huffman codes with unlimited code lengths are simple) and ask him to explain that algorithm to you. Most likely he won't be able to do it, worst case you shut him up for quite a while. (Length limited Huffman codes are important, because they allow for much more efficient decoders). PS. If he or she can explain the algorithm to you, then he or she is good. I doubt it.

Apart from that, if someone tries to explain JSON to you, you ask them what they are trying to achieve there? Does he think JSON is something difficult that you can't understand without a CS degree? Seriously? Doesn't he think that he is a bit full of himself? His behaviour is insulting, so you give back as good as he deserves.