Does using documentation as a developer make me look unprofessional?

Question

I’m a junior developer and working every other three months in a software development company as part of my corporate studies.

Even though I’ve been programming for almost 1 year (3 x 3 months work experience + side projects) I quite often have to check the documentation and/or Stack Overflow during my workday. I fear this makes me look unprofessional or more inexperienced than I actually am (I’m quite comfortable designing and building software, but often have to search for terms like “PHP/JavaScript function that does XYZ”). In most cases I should already know this, as I have this already used before but want to double check before making mistakes.

The reason for asking this question is that I get kind of mocked for using Stack Overflow/documentation so frequently which makes others and myself doubt my abilities. For me it’s a natural part to work more efficiently and become more aware of the language. Someone once told me something like: “A surgeon cannot read his books every time he has to operate on a patient.” Which is in my opinion nonsense.

I’m also asking for the future; e.g. if I have to write code during an interview for another job I guess you shouldn’t use the documentation.

Answer 1

Don't worry: you are a professional, and you are acting like one.

Professionals use all resources available to get the job done, including documentation, code written by others (libraries), help from experts, etc.

It's not unprofessional to need to consult an external resource. In fact, it would be unprofessional to not use documentation if you aren't sure how something works.

Does your level of reliance on documentation show inexperience? Sure, to a certain extent. But you are inexperienced. After only a few months on the job, you won't know as much as someone with many years of experience. That's just a fact, and no one is likely to hold it against you.

However, even developers with 20 years of experience will be checking the documentation for some things. This is always part of a developer's toolkit.

Programming tests are a slightly different thing.

Since they are designed to assess your own knowledge and ability, you will often have to complete them without documentation. This isn't because documentation is bad; it's just that, in the artificial environment of a brief test that attempts to assess your overall capability, external resources may confuse that picture.

However, typical programming tests are conceptual in nature. They are typically about your ability to create an algorithm, design a solution to a problem, and follow good coding practices. These are not things you would get from documentation anyway. Getting an occasional minor syntax detail wrong is not likely to affect your assessment much.

Answer 2

Does using documentation as a developer make me look unprofessional?

No, it actually means opposite... as you are not disturbing your seniors by asking question which one can easily find on internet or through documentation.

Most of us devs can't remember thousand of lines of documentations... all the times, specially when we switch between technologies

I'm also asking for the future; e.g if I have to write code during an interview for another job I guess you shouldn't use the documentation.

Most reasonable companies would like to test the logic/structure you come up in a coding test.. not that much about syntax.

Answer 3

Someone once told me something like: “A surgeon cannot read his books every time he has to operate on a patient.”

Whoever told you that doesn't know how surgery works. Unless it's a very common procedure the surgeon has practiced a hundred times, the good ones spend a great deal of time studying before every patient they see. They also spend many years in medical school studying a subject that hasn't changed much in several thousand years.

You are in your first year in an industry where new ways of doing things are being invented every week. You are inexperienced, so it should be expected that you have to look up things up frequently. As long as you have the foundations to know whether the solutions you find actually solve your problem and that you learn from the experience, there is nothing wrong with this. I have been a software engineer for 15 years and still need to look things up almost every day. A professional uses every resource they have available to get the job done.

Answer 4

Professionalism and knowledge are two completely different things.

Looking up things from third-party sources does mean you lack knowledge, not lack of professionalism. Lacking knowledge is a topic for itself, but overall there is no person knowing everything.

If you know about your lack of knowledge and handle it by looking things up from third-party sources, this mean you have a professional strategy to solve your specific problem of lacking knowledge.

Not looking things up while not knowing that stuff is unprofessional, but this is not your case.

Further reading on an effect which contrasts your "strategy of using documentation": The Dunning–Kruger effect

Answer 5

Does using documentation as a developer make me look unprofessional?

No. Remembering minute arbitrary details is a waste of your resources. You would have to remember a lot of those both in PHP (which lacks a bit on consistency side) and in web development in general, if you get familiar with several languages and a dozen frameworks.

I get mocked for using SO/Documentation so frequently which makes doubting my abilities

This may be not the most efficient way to solve your tasks.

Do you use any IDE? Do your colleagues use any? Because looking up those minute details can be delegeted to IDE's autocomplete feature. Using autocomplete is more efficient than switching your attention to browser and searching for an answer there.

If your colleagues use their IDE's autocomplete and you use Google instead then that could look unprofessional - not because you consult docs but because you are doing it inefficiently.

If your colleagues rely on their memory and you rely on autocomplete you'll be able to oupterform them in tasks that use some framework none of you are familiar with, which is not that rare in web.

Master your tools and show performance, that's professional.

Answer 6

Others have provided solid answers, but nobody really addresses this head-on; bold emphasis is mine:

The reason for asking this question is that I get mocked for using Stack Overflow/documentation frequently which makes others doubt my abilities.

Who are these people “mocking” you and how do you know it “…makes others doubt [your] abilities?”

This all sounds like garden variety (aka: common) hazing to me. If you are a junior developer you are naturally in a hierarchy where others will test you and push buttons as part of their own hazing behavior. This happens whether they are conscious about it or not; it’s just par for the course.

At the end of the day, every single person in the world uses reference tools to get work done. Heck, do lawyers and doctors not have tons of references and books they refer to constantly? Programming is no different.

Your job as a programmer is to bridge the desires of a project with the reality of the code itself. Your job is not to memorize arcane nonsense. and if you do get to the point you can remember—and even visualize—arcane nonsense, then congrats! But that doesn’t happen overnight and sometimes doesn’t happen at all for some.

FWIW I have been doing computer work for 20+ and it’s only in the past few years I can literally visualize solutions in my head without writing a line of code. It‘s a skill that one grows into and cannot be demanded that someone has on demand.

Answer 7

Although this won't make you look unprofessional to a professional (the vast majority of the time) you might want to use caution in front of a naive customer or manager. Just as you, with almost a year of programming experience, aren't sure if professionals need to look things up, so people with even less relevant experience might also be unsure.

In fact, I have defended other developers on a few occasions when a customer of a consulting engagement said something along the lines of "why am I paying good money for someone who can't even write code without looking it up on the internet?"

This has been rare, but of course I don't know how many people got a bad impression but remained silent.

Answer 8

It is certainly not unprofessional to look things up when you are unfamiliar.

However, if you are not retaining that knowledge and are continually looking up the same things, then there could be a problem. That is inefficient. It makes you slower and that could be the cause of the mocking. You need to learn the basics of your profession to the point where you do not need to look them up every time.

Answer 9

It is far more professional to read the documentation and get your code right than to guess and get it wrong. This is especially true of a language like PHP, where the standard library is haphazardly designed, hard to memorize, and full of gotchas.

Take, for instance, the mail() function. Did you know…

• additional_headers does not have mail header injection protection. Therefore, users must make sure specified headers are safe and contains headers only. i.e. Never start mail body by putting multiple newlines.

  If you aren't aware of that caveat, then you end up introducing a security vulnerability.

• When sending mail, the mail must contain a From header. This can be set with the additional_headers parameter, or a default can be set in php.ini.

  That means that your application's behaviour could depend on a global configuration setting. That is useful to know, so that you can avoid writing code that seems to work correctly on one machine, but isn't portable to another.

• The $to parameter must comply with RFC 2822.

  You've seen thousands of e-mails, so you think you know what an acceptable e-mail address looks like, right? Read the spec — you would probably be surprised.

Sure, you might be able to crank out more code by not reading the documentation carefully, but it would probably not be professional-quality code. There is no shame in checking the documentation frequently to make sure you are using the language and libraries correctly.

Answer 10

Looking up things that you are not sure about saves time and also allows you to check for better ways of doing something. Getting stuck doing the same thing over and over again inefficiently when there is a better way just by checking the net isn't good.

Answer 11

As others answer provided, there is no such thing as being unprofessional for checking the documentation especially considering you are junior, especially considering programming is vast and there is always a detail you can forget and you have a mission for your code to be correct.

There is however cases I would consider being documentation abuses.

I have a collegue who is sometimes unable to come up with his own solution about a given problem. Therefore, he sometimes proceed on checking the web about how to solve his problem. Last time, for example, he checked how a web framework was architecturing validators and error counters because he had a seemingly similar feature to design.

This is a case where what you are looking for is far too abstract for the Internet to help you. Worse, you could find solutions that seemingly fit, but in fact don't, because they are applied to a different use case. By trying to grab some premade code/architecture/pattern he would have more or less injected code in our base that may have worked, but would be hard to maintain because written by someone else for a different purpose.

I don't look the documentation often because I write code that uses mostly core language features (no framework) and I am gifted with a reliable memory when it comes to code, but I do use the doc everytime I'm stuck on something trivial. However, if I'm stuck on something higher level, the good thing to do is to seek help from a more experienced collegue, you will get a much better answer.

Answer 12

There is a difference between "professional" and "knowledgable". If there is some information that I need to know, and I have the choice between stupidly sitting on my chair and being stuck, or to check the documentation, then I check the documentation. That's absolutely professional.

If that information is something that a knowledgable person in my position ought to know, then looking it up may show that I'm not as knowledgable as I should be, but it's still entirely professional - since the alternative is not knowing it, and not learning it. Which (the not learning part) is entirely unprofessional.

It would be daft to assume that you know everything you should know, because every day there will be something fresh that you should know, that wasn't there yesterday. Even if you know something, how do you know that your knowledge is the best possible one? You consult documentation to find out if there is any better knowledge out there about the same subject.

It's rare that there is a problem that I can't figure out myself. But it takes time. Given the choice between taking one hour to figure it out myself, and five minutes using Google, spending the hour is unprofessional.

Answer 13

You have a few good answers already, but let me add a little twist...

I like people using documentation and it is a great sign for your professionalism.

Not using documentation

I know enough programmers that stumble along without a real plan for long spans of time, trying this and that by chance, picking through old source code where whatever they want to achieve seems to have been done already (but hasn't quite) and so on. Frankly, I detest this kind of approach. They never get very far, often have to ask people, seldom take advice and prefer to continue like this forever, seemingly.

Only tutorials?

People frequently googling for tutorials or code snippets including SO, without ever referring to documentation, irk me to no end. This behaviour is a huge trap, in my opinion. It leads to a kind of programming fueled by half-baked, arbitrary, unsystematic "knowledge". Those programmers tend to end up with a lot of prejudices. This is where nuggets like "never use git rebase", "never use not in in SQL", "always do XXX", "never do YYY" come from. They will find it very hard to think out of the box, come up with new ideas, form intuition about how to structure their applications and all that stuff that makes up great developers.

I would urge you to solve any problem first by looking at the documentation/reference, and then look for SO or other snippets.

Of course, there are exceptions. If your problem is quite obviously something like a bug, or something very, very, very special which is unlikely to be handled in any sort of documentation (e.g., a special combination of libraries/modules etc.), then by all means go straight to SO.

If it is something that could easily be figured out by documentation/API, then I would suggest sitting down and working on that particular part of your programming language / libraries etc. so your knowledge gets tighter.

Documentation

The best kind, for me, is a programmer who, when encountering a new topic, takes the time to really sit down, dig into it, get a good overview and good technical understanding. This is most times achieved (again, in my experience, with the many programing languages I had contact with) by reading the good old documentation including API references and so on. This can, in my opinion, never be replaced by anything else.

I do not find it outlandish to read, for example, the old C++ classics (good old paper), the Gang of Four Design Patterns, the (online version of the) "Programming Ruby" manual, the extremely well done Perl manpages, the Git book, certain RFCs, the HTML/XML/etc. specifications and so on from front to back. I would do and have done that even in my spare time and would, frankly, expect it from any programmer worth his/her salt (depending on what they are working with, obviously). I am also thoroughly aware that I am (at least in the companies I worked in, in the past decades) quite alone with this opinion.

(N.B.: Obviously you do not need to memorize huge lists of API references, but at least gloss over them to see what's available and what the "spirit" of the API seems to be.)

After being thoroughly comfortable with the topic, then is the time to look at 3rd party code for inspiration, or to look at older SO questions (or ask new questions yourself).

You might also find that when you have absorbed one field like this, it gets very easy to find answers by zooming right into the meat of wherever you get your documentation from (man pages etc.). At this point, the autocompletion of your editor might also just be enough already. And you might as well pretty soon know when something is just not possible with the tool you are working with, saving a lot of futile searching.

Answer 14

Your skill as a programmer is about how you can take in the full picture and design effective solutions, not how many APIs you can memorize. The goal is to get the job done correctly and efficiently. If you had to look up every API and every detail, then I would say you have some issues. I would expect a good developer to be thoroughly familiar with everything used frequently, recently, and routinely, but not waste brainpower on things used infrequently when they can be easily looked up. If you visited stackoverflow more or less once a day, not an issue; if you're on it most of your typical workday, that would be an issue.

Answer 15

I get kind of mocked for using Stack Overflow/documentation so frequently

Other people's opinions of you don't define you, they only define them

Does using documentation as a developer make me look unprofessional?

No... part of being professional is competence in getting the job done. You are being mocked because your colleagues are bullies, not because of anything you are doing wrong.

“A surgeon cannot read his books every time he has to operate on a patient.”

Why not? I'm skeptical of that assertion unless there's an unusual time crunch. Using reference material only takes seconds.

if I have to write code during an interview for another job I guess you shouldn’t use the documentation

Depends on the rules of the interview, some allow it, some don't. In particular, if it is a test it may be allowed. It's a good idea to check first!