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.

  • 3
    How do you react now when she acts like that? What have you tried? What specific outcome are you trying to achieve? – dwizum Apr 17 '18 at 19:37
  • 46
    Is the coworker a recent graduate? How long has this been going on? (I suspect if they are new, they may have not figured out their role in the food chain just yet..) – user812786 Apr 17 '18 at 20:21
  • 23
    Question: Have you watched her not explain "json" to others? Or does she approach all people as if they don't know basic "technology"? It's one thing if that's how she talks to you... it's another if that's how she talks to everyone - and you just expect to be treated as more knowledgeable. – WernerCD Apr 17 '18 at 23:50
  • 3
    Valid question nonetheless, but nothing in your question tells us that the reason for her behavior is that you are self-taught, or that she looks down on that. Maybe she behaves this way for any reason we don't know? Maybe she behaves this way with others, who also have a degree? – user985366 Apr 20 '18 at 2:01
  • 10
    You're assuming she's patronising you due to your lack of education. The question could equally be "how do you deal with a patronising coworker". Why do you think it's really an issue of degree vs self-taught? – RJFalconer Apr 20 '18 at 10:56

21 Answers 21


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.

  • 25
    I agree with your point that programmers are all self-taught to a large extent, but JSON is very widely known and is not something I'd expect to have to explain to most developers with a bit of experience. So I think, based on the question, it still seems likely that the OP's coworker is being kind of condescending. – David Z Apr 17 '18 at 22:39
  • 13
    I would disagree that universities don't teach JSON or other applicable skills. It might not be common, but those sorts of things are taught in the Software Engineering and Computer Science courses in my current university, and most of the universities that I've looked at. – Lynx Brutal Apr 17 '18 at 23:42
  • 18
    @LynxBrutal - opposite in my experience. At University of Florida, a comp sci engineering major gets 1 programming class in 1 term (java). A few miles down the road at SFCollege (can't be a community college because of a few 4 year degrees) the BAS in software dev gets you python, C++/C#, java, javascript w/ HTML+css, a little PHP, SQL (mariadb/mysql), mongodb, android development, and node/angularjs. Even just a 2 year degree at SF gets you python,C++,Java and Javascript+HTML+CSS+PHP – ivanivan Apr 18 '18 at 1:23
  • 65
    @David Z: CS is a broad field. I doubt I'd recognize JSON if I happened across it, and on the flip side, I'd guess that many people who regularly work with it might not be that familiar with say MPI or CUDA. – jamesqf Apr 18 '18 at 4:32
  • 21
    @Belle-Sophie Serialized data formats for hierarchical data? Mine never touched on anything close. For my CS degree, we learned Java in the introductory courses, and that was about it. All other practical application was self-taught, while the courses either involved high-level assignments ("implement a decision tree"), or leaned heavily on the knowledge/theory side ("balance a red-black tree with pencil and paper"). I get the impression from co-workers that it was similar for them. – Izkata Apr 18 '18 at 12:19

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.

  • 73
    I'm one of these people. I've found myself explaining things to the professor that taught me them before. It's not because I don't think they know; it's because I'm {making sure we're talking about the same thing|refreshing their memory|whatever other excuse I use when I realize my mistake} – Nic Hartley Apr 17 '18 at 22:03
  • 69
    I think there must better way to word this. This could sound patronising or dismissive. Something like 'I'm familiar with json' would be better. As another comment mentioned - this person is probably just a bit enthusiastic and proud of their new degree. – dwjohnston Apr 17 '18 at 22:03
  • 58
    This is horrible advice. Many people go over well known things during technical discussions, just to make sure we're on the same page. Too many times did I have someone interrupt me with a version of your reaction, just to find out after 15 minutes that they were not taking into consideration the same side-effects of a technology that I was. – DonFusili Apr 18 '18 at 6:13
  • 23
    I usually go, "Oh yeah, I used x for a project 3 years ago. I don't remember the specifics, but I'm familiar." It skips the basics and leaves you open to ask/google the little things (syntax and other particulars). – LVDV Apr 18 '18 at 8:31
  • 3
    I don't think this is bad advice at all. Yes, it might be very appropriate to discuss the details of the JSON spec in technical discussions if that is relevant to the project. But if JSON is really off the path, or the discussion is less about the project and more about proving who is technically superior then there is nothing wrong with putting the discussion back on path. – Thomas Carlisle Apr 18 '18 at 17:43

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.

  • I learned that , where did you learn it? I would be inclined to disagree with this. For one, I agree with OP that the explanations are kind of condescending. For two, it's a bad usage of one's time especially in a meeting where it's crunch time and you have to work out a problem or design something. Why would I want to ask them a question to compound the issue? Why would I want to engage them in conversation when in fact I would like the conversation to stay focused on the issue at hand - which presumably is company business, and not how she knows about JSON. That just makes the issue worse. – The Anathema Apr 20 '18 at 19:35
  • @TheAnathema - Part of the question mentions discussions during breaks. I would agree with taking a different approach during meetings, but focusing too much on the task at hand doesn't lead to developing a professional relationship. I prefer to interact with coworkers so they see me as a person and not some cog in the company. – user8365 Apr 24 '18 at 15:15

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...

  • I was going to add a similar answer but this is spot on. That she is doing this because the OP doesn't have a degree is an assumption and it might speak more to the OP's insecurity than anything else. I personally find it hard to determine when you don't know if someone knows something whether you should over-explain, assume the person already knows, or ask it they know. All of these approaches can offend one person or other. Some people seem offended by all of these approaches at all times. – JimmyJames Apr 18 '18 at 21:00
  • 4
    That's the nice thing about SE and similar sites. You are always justified in over-explaining (often via links to sources) because what is written is read by many, not just the person asking. – JimmyJames Apr 18 '18 at 21:01

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.


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.

  • 5
    "The solution is to communicate what you do/don't know effectively and quickly." Indeed. That is the primary issue here. – Trilarion Apr 18 '18 at 9:48

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.)

  • 1
    And now I'm offended that you're assuming that being self-taught as a computer programmer equals not having higher education. Actually, it's the taxpayers in my country that are quite miffed. – Elise van Looij Apr 19 '18 at 9:15
  • 1
    For a non-programmer (actually, full stop!), the example in the blockquote is actually quite good. It has a well-defined meaning, is a very sensible suggestion and is explained well enough for a non-programmer to understand. However, in order to sound like you know what you're talking about, perhaps replace "object" with "unserialised object" (it's technically unnecessary but helps to emphasise the distinction between JSON and "the object directly"). – wizzwizz4 Apr 19 '18 at 16:59
  • @wizzwizz4 Thanks! I'll make note of the term"unserialized." While I don't develop software per se, I work in data science so I know what a JSON is and the basics of OOP. :-) – AffableAmbler Apr 19 '18 at 19:25
  • @AffableAmbler My spell-check didn't acknowledge its existence, both with "s" and "z", so I'm beginning to think that it's not a real word... but I have read it used so it's probably real enough. – wizzwizz4 Apr 19 '18 at 19:26

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

you(smiling/friendly): Exactly! Have you ever heard of XML? It's a [explanation of something very obvious]

  • 1
    That's how I would handle the issue. It doesn't really matter what the person's intentions are, you just need to provide a small proof that you understand what they are talking about so everybody can move on. – Paula Hasstenteufel Apr 18 '18 at 14:33

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?"


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.


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.

  • 1
    I am self-taught and have a pile of textbooks which are specifically made for universities. Some fractions of knowledge come from reading master thesises and tons of papers. Most of this university stuff is not teached on most universities - oh the irony. Last time I attended to university courses ("object oriented programming", they called the course), they were pretending that each line of code must be commented, like in if (x == true) // check if x is true, or points will be lost. [...] – phresnel Apr 19 '18 at 8:32
  • [...] I've yet to see a CS programme that teaches important things I've not looked into already, and that out-balances all the stuff that students have not learned in their student-years (while I have). I don't claim that I'd earn just A+-scores when I decide to re-attend, for each exam is not only a function of knowledge. Exams are negligible random samples when we're honest. They do not in any way reflect what happens in individual real life. – phresnel Apr 19 '18 at 8:38
  • 2
    You both miss the point. Programming courses in university are a complete and total disaster. I'd recommend learning to code by watching YouTube videos over a university course any day. Every language I learnt after university I self-taught. But there are more fundamental courses in university that you don't get if you jump straight into coding. The entire math and logic background, functional programming (useless in the real world, but conceptually important), the entire theory of algorithms, fundamentals of processing and databases and so on. – Tom Apr 19 '18 at 10:07
  • 1
    (in case with you address me with "both") I am quite well-versed in algorithms, data structures, the many categorizations and topologies of languages and grammars. I've done compiler construction and - optimization in my spare time. Computer Graphics is another favorite of mine. I like micro- as well as macro-optimizations [and as mentioned the optimizations compilers derive automatically]. I think I am way more into CS than most people I've met who actually studied it. "What's static single assignment?" "Rendering Equation, WTF??", "FP? We only had Java.", "Imperative PLs? Elaborate!". – phresnel Apr 19 '18 at 12:23
  • One data point does not make a statistic. :-) I've met genius people who didn't got to or finish university. I met idiots who did. And idiots who didn't as well as geniuses that went. Still, a lot of the fundamentals are not in most of the self-teaching books or courses. You can, of course, study university textbooks. Nonetheless, the approach of assuming that the other person just might have something they can teach you still seems like a good approach to me. – Tom Apr 19 '18 at 12:29

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.

  • This is useful and relevant, but it doesn't really answer the question. Can you add how to specifically apply this to the case at hand? – reinierpost Apr 20 '18 at 21:10
  • @reinierpost Thank you for your kind comment. Unfortunately there is not enough context to be specific. However, I am sure that I can round out this answer more. All I could get from the OPs post was the Parent, Child, Adult posture. Without an actual transaction, I would not be able to dig deeper. I want red meat to chew on! Trust me. This is one reason why I posted the example story. Perhaps I can come up with more detail of what TA is and how it works. I will sleep on it to come up with something more fruitful. Cheers!! – closetnoc Apr 21 '18 at 1:20
  • I understand, but perhaps you could give examples from your own experience to illustrate different transactions, or something. I would think only one type applies here, but maybe not. – reinierpost Apr 21 '18 at 9:56

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:


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.

  • I like the advice, but Franklin does not match. – usr1234567 Apr 22 '18 at 11:32

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.


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 know1. 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"2)

Someone with a degree can certify a minimal base of knowledge3, 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.

1Of 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.

2Right now I am modifying a program done

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


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.


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.


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:

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.


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 ?

  • No way! Say: Sorry, but I've used JSON here and here, then possibly give some assessment related to JSON. Make your knowledge of JSON immediately clear. Groveling is all very well, but save it for appropriate circumstances. – reinierpost Apr 20 '18 at 21:05

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)


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.

  • 7
    co-worker is a she. i'm not sure OP giving a challenge that OP doesn't understand is really an ideal solution. i'm not sure OP giving a challenge OP does understand is a good solution either. personal skills > trivia challenges in interpersonal issues. – bharal Apr 17 '18 at 20:48
  • 2
    @bharal The problem is not difficult to understand at all. The algorithm to solve it is hard. – gnasher729 Apr 17 '18 at 21:07
  • Assuming this is the package-merge paper - there is nothing super clever about it and I'd expect a competent CompSci major to have no trouble with it - that said, this is a very aggressive way to go on about it - the goal isn't to "beat" the coworker in some perceived contest. – Benjamin Gruenbaum Apr 18 '18 at 9:34
  • 1
    This doesn't answer the question at all. – reinierpost Apr 20 '18 at 21:19

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.

  • This doesn't even attempt to answer the question – pwdst Apr 23 '18 at 15:15
  • Yes it does. The question was "how to react", the answer is "be open to learning new things". – Michael Kay Apr 23 '18 at 16:35

Your Answer

