Is constantly looking for code examples a sign of a bad developer? [closed]

Question

I am a CS student with several years of experience in C and C++, and for the last few years I've been constantly working with Java/Objective C doing app development and now I have switched to web development and am mainly focused on ruby on rails and I came to the realization that (as with app development , really) I reference other code way too much. I constantly Google functionality for lots of things I imagine I should be able to do from scratch and it's really cracked my confidence a bit.

Basic fundamentals are not an issue, I hate to use this as an example but I can run through javabat in both java/python at a sprint - obviously not an accomplishment and but what I mean to say is I have a strong base for the fundamentals I think?

I know what I need to use typically but reference syntax constantly. Would love some advice and input on this, as it has been holding me back pretty solidly in terms of looking for work in this field even though I'm finishing my degree. My main reason for asking is not really about employment, but more that I don't want to be the only guy at a hackathon not hammering out nonstop code and sitting there with 20 Google/github tabs open, and I have refrained from attending any due to a slight lack of confidence...

Is a person a bad developer by constantly looking to code examples for moderate to complex tasks?

Answer 1

Copy-paste blindly: bad.

Look up documentation, read code examples to get a better understanding: good.

I'd rather work with someone who looks up things all the time and makes sure everything works as intended than someone over-confident who thinks he knows it all but doesn't. But the worst is someone who doesn't bother understanding how things work, and just uncritically copies code from the web (and then when the bug reports start raining down is unable to fix anything properly).

Answer 2

If you code your solutions in a maintainable way and actually UNDERSTAND what you copy/paste/modify then there is no problem.

I die inside every time I ask a senior developer questions about why he did what and the answer is "I don't know, I copy pasted the code and it worked at that given time".

Answer 3

Just like with the skill to program with/out API documentation, looking for code examples is a sign not of a bad programmer, but of one who lacks fluency...

...Here, I am talking about fluency. About being not just capable of something but fluent.

Do you know what it is to be fluent? It's when for someone looking at you it appears as if you code as you type...

• ...As if the right code simply flows from your fingers to the screen. As if you don't check the API docs, tutorials and manuals. Actually, you do check them all, but that's invisible because it's all in your head. You've got all the knowledge you need right there in your brain - charged, loaded and ready to use.

...That's fluent knowledge. It's when it takes you a minute to do what takes newbie an hour. It's worth the effort, really. It smells like victory.

...and the practice is to me the only reliable way to acquire fluency.

Answer 4

There's a theory of learning called the Kolb cycle (after the person who described it). The entries in this cycle are:

Concrete experience -> Reflective observation
    ^                        |
    |                        v
Active experimentation <- Abstract conceptualisation

Different people like to start at different places in the cycle. So it's entirely possible to be learning by looking for samples (the reflective observation phase), then working out from those samples to the big picture via abstraction.

Other people will learn in different ways: some people like to start by trying (that is, with experimentation) then reflecting on what went right or wrong. The point is that these are just different ways of attacking the problem of learning things: none of them are incorrect.

Answer 5

Full disclosure - I am an old person who was trained in a different pre-Internet available at work era. I've watched the skills of the younger developers steadily deteriorate mostly due to them not retaining information or understanding the solution they grabbed from the Internet. I've observed that the level of competence a person had after 1-2 years of experience, 20 years ago, is now the level of competence someone has after 5-7 years of experience. (Yes that is a personal observation but I've done a lot of hiring, I have no statistical data on the matter and yes, I am sometimes old and cranky, take this statement with a grain of salt. And stay off my yard.)

Looking up everything is inefficient in terms of time. It also is a symptom of someone who doesn't have much depth of knowledge. People with depth of knowldge can write code faster than people who don't know how to solve a problem without looking things up. So it is worth it to learn to handle more things without having to look things up continually.

Now I'm not saying you should never look things up, I'm saying you should learn to retain knowledge and only need to look up things you use rarely or when you encounter a genuinely new issue or language or paradigm. And I'm not saying you shouldn't be reading to keep up with new solutions and tools and languages.

My real concern with developers who look up things too often that that too many of them (not necessarily you) never develop the analytical skills to understand the problems they have and the solutions that are needed. Read how many questions there are where the person puts in the error message that he or she clearly doesn't understand, but which should be quite clear to anyone operating at the professional level. Or the ones where the person says, "it's not working, why?" with no reference to the error message or how it isn't working and the code is syntactically correct. Or the ones who are given a piece of code that should work, but in the haste to answer first the person has made an obvious syntax error (like say missing the ON keyword in a SQL join to use an example I saw just today) and the poster comes back with I get an error on line 12. Why yes, if you look at line 12 it obvious what the error is if you have baseline competence.

So if what you are looking up is stuff that is part of the core functionality of the language(s) (BTW this should include SQL if you are accessing databases) you have used for more than six months, I suspect you are looking up too much. If what you are looking up are advanced features, especially those you might use rarely, then you are doing fine.

But how to you learn to retain more information? First understand why the code broke. Even if someone gives you a working solution, if you don't see why that worked and yours did not, then ask. If you don't understand the error message then ask what it meant and then try to solve it yourself.

And never cut and paste a solution you don't understand. In fact, don't cut and paste at all. If you want to retain information, you need to do the typing of it. Actually physically writing the code yourself helps you learn it. That is a well-known learning technique.

Practice generalizing your understanding of the code. I've seen people ask similar questions over and over again over time because they don't understand that the solution they got a month ago to problem ABC is the same solution to the new problem DEF.

So when you've researched something, take some time to think about what types of problems it would be good for solving and write yourself notes about that. Then when you have a problem to solve, first check your own notes to see of you have already noted a possible technique. If you evaluate multiple ways to solve a problem, take notes on the type of problem, the possible solutions you looked at and the pros and cons of each one. Again the note taking is helping solidify the knowledge in your brain, you already have your own thought process in terms of the pros and cons worked out and don't have to do that again (or at least not in as much depth, you may still look for more possible techniques) for the next similar problem.

And when deciding what to learn next, go for some depth in one of your main technologies before jumping into learning the first 30 days worth of yet another technology (this assumes you have enough breadth of knowledge to actually perform your job, if you need to use 6 technologies - get the basics in all six first before going for depth). Then go back and forth, learning new stuff, at a basic level, learning something in more depth, then learning more new technologies at a basic level. If you do this over time, you will find that your basic level of what you want out of a new technology is much deeper because you understand more advanced questions to ask about it.

Another way to learn to retain knowledge is to teach it to someone else. Answer questions at places like this, present training topics to your team, make presentations at your local user groups, write blog entries and help maintain a wiki of information at your company to help other developers.

Answer 6

Looking for code examples is not a sign of bad developer. One rarely needs so few things to remember all the interfaces they need precisely, so it's natural to look things up and code examples are usually the reference that is easiest to use.

What you shouldn't do is copy&paste examples because they work there, so they must work here too, without understanding how they work. That usually leads to lot of useless bits that got copied along incidentally with result being hard to maintain because if you didn't know how it works when you wrote it, you won't know six months later either and won't be able to fix it.

But as long as you understand the code you are copying from an example, it's a valid way to get the work done faster, and that is usually good thing.

Answer 7

These answers are pretty good. But you suffer from a much deeper problem than copy/paste or lack of "skill."

Comparison is lethal. The more you compare yourself with other people and let their talent affect the way you view yourself, the more you will shrivel up and die inside. You don't go to hackathons because of fear that people will see how untalented you are. And the only reason you think you're untalented is because you compare yourself with hackers who can bang out more code from scratch, faster.

Even if "Lines of Code per Minute" were a good metric for measuring skill, you need to accept the fact that there will always be better developers out there than you. And it's ok to show others that you lack in skill.

You do not need to be as good as, or better than, anyone else. You need to be content with the fact that you will always lack in some way, and that you're learning constantly. If you can't be happy with being an inferior developer, you'll NEVER be happy.

One more thing: your fear of rejection by people that you think are "superior" is exactly what is preventing you from rubbing shoulders with better developers and learning from them. So your fear prevents you from growing, which maintains your fear. Which prevents you from growing. See the cycle? You have to break the cycle somewhere.

Answer 8

I think a lot of it depends on how your mind works. My memory stinks, so I'd much rather grab code that is as close to what I want as possible and rework it so it does the new job. It serves as an example and a reminder of all the things I have to do. For instance, I've used simple SQL for 20 years, but I can never remember the layout of a SELECT, or UPDATE statement. (I think one needs parentheses, but I can't remember which.) On the other hand, some few things I can remember; I can throw together a Java Iterator implementation with my eyes closed.

Most of the code I copy is my own, but I certainly copy other's when I'm learning something new.

I don't know about hackathons. They may draw on a subset of programmers with photographic memories. I'd give it a try and see. If looking like an idiot bothers you, you shouldn't be programming.

I'd urge you understand, thoroughly, all the code you copy and modify, but, until I read some of the other answers, it never occurred to me someone might copy without understanding. (I seem to be learning new vices all the time on this site...)

Answer 9

...I came to the realization that...I reference other code wayyyy too much. I constantly google functionality for lots of things I imagine I should be able to do from scratch and it's really cracked my confidence a bit.

Then stop. Head in the other direction for a while. Implement everything yourself, even if you know you could find exactly the thing you need in much less time.

What has happened is that your problem solving muscle (Latin name gluteus mojo) has atrophied from disuse, and you now avoid using it because you know how weak it is. You need to start building and toning that muscle just as you'd work on your biceps at the gym. Start with high repetitions and low resistance -- lots of easy problems. As you build some confidence, move on to longer, harder problems.

You'll gradually feel your mojo return and your need to rely on Google will diminish. Keep exercising that muscle, though, and make sure that you don't fall back into your old ways. Challenge yourself to solve a problem first and only then look up other solutions. Sometimes you'll find that others have found a better way to do the same thing, other times you'll decide that your own solution is better.

Is a person a bad developer by constantly looking to code examples for moderate to complex tasks?

A person who is unable to get anything done without finding examples is a bad developer. The thing is: you won't know whether you're able or not until you try.

Answer 10

You're young, and you've worked with a lot of programming languages. I'm going to guess that you probably pick up on the new languages faster than the old ones. You still have not put enough time into a single language on a large enough application to develop fluency.

Are you looking for broad solutions every time like: the entire process of connecting a web grid to a database table or a smaller part like formatting the connections string (I have to look that up just about every time since I write about four a year.)?

You'll always be looking for references to the syntax of different lines of code or functions. The more you program, the more challenges and different environments and language changes you run into. If you need an entire tutorial everytime you do something, then you have a problem.

Answer 11

I had a professor that used to say he hated giving tests based on trying to retain a bunch of information you crammed the night before because you forget a lot of it afterwards anyway. It is better to know your resources and that you can use them properly to find the information that you do not know. I like to apply a similar principle to everything I do, including work.

I think the most important tools you have are your resources, as long as you use them properly. So when I am writing code, I get as far as I can with my existing knowledge and then do research by asking other programmers or searching the Internet, in order to better understand the appropriate solution. The knowledge will build over time and after a while you will naturally know and understand the skills better. I am constantly looking things up whether I actually need the information or not, and I can honestly say I learn something new every day.

Answer 12

If you understand the problem you are trying to solve, and understand how you want to solve it, looking up the correct syntax is not a big deal in my opinion.

I graduated about two years ago and was thrown to the wolves when I got my job. I had to learn, maintain, and upgrade a large application written in a language I had never touched before. I would get a bug report, go through the code and find out how I wanted to fix it, and then have to google examples of how to do the stuff I wanted in that language.

If you are getting things done, and understanding it enough to not produce unneeded churn, then you are probably OK.

Answer 13

Pure uncritical copy and paste as stated many times in these answers is bad. But so is writing everything from scratch. If it is not a critical component that is core to your business, look for a library or code snippet to do it first. The exception to finding a snippet would be that the problem is very simple, you have a very clear picture on how to do it and if you're not using a library: that you will unlikely need to do anything more.

I know personally if I write something that is common, I'm likely to have some subtle bugs and perhaps one or two not so subtle ones without a lot of testing. So I look for a similar solution, modify and test that to save some time on testing and developing over all. Because in the end I'm responsible for delivering a product that works, is extensible, is on or under budget and meets deadlines. Reusing code and libraries is a good step towards that objective.

Answer 14

I think reading code examples, and just reading source code of what other people have developed in general, is the best way to improve your skills. I really think it opens doors in your brain that would have not been opened otherwise.

If you think up a solution A, and someone else thinks up a solution B, when each of you share your solutions, you can realize solution C which may be even better than A or B.

Answer 15

I think there are many levels of software development proficiency. Just so, because there are also many levels of software development documentation proficiency. Frankly, these days, systems are orders of magnitude more complex than when I began programming computers in the mid 1980's.

Then, you had to know what you wanted the computer to do, and you had written documentation 6 inches thick telling you how the computer did certain more basic things. Putting what you wanted into a form the computer could take was a matter of knowing the contents of those books' indices, and a programming language (or two. Really, after learning four or five languages the others are just dialects.)

Today, that task requires knowing a language, knowing a system, knowing a paradigm, a programming model, and at least one API set, all of which are moving targets.

So, A person with a certain level of basic knowledge who asks around is not a good kind of programmer. He is the best kind of programmer, given today's environments and the disinterest firms like Microsoft have in actually applying any kind of rigor to their own fundamentals documentation. Most of their stuff is self-referential reference material and some very bad sample code. (Two cases in point I've encountered are "Windows Installer" and the API's for making WMV movie files.)

Because Microsoft, Google, and, to a lesser extent, Apple, all rely on "the community" to make up for that very real deficiency, asking around is not just important, it's vital. And being a person who can be asked and who can give solid answers and feedback in today's environment is just as vital. That's why sites such as the stackexchange.com sites are as helpful as they are.

So ask questions, (ask intelligently!) for samples, and respect the people who supply the answers, and doing so will not be seen as a sign of a "bad developer".

And one more thing: Supplying bad samples really is the sign of a bad developer. It makes the bad developers easier to spot, but also gums up the google searches. If you lack confidence in simple, straightforward, specific code samples, don't give 'em.

And, please, don't mock those who ask.

Answer 16

It sounds to me like the problem for you is less in understanding what you're referencing, and more with issues of facility and memory. If it's sapping your confidence, then yes it's a problem – but it can certainly be addressed!

For me, these kinds of challenges come up in many different aspects of my life. For example, to get good at performing a piece of music, I need to develop my independence from the sheet music I'm given – how can you really feel the music if your nose is still buried in your booklet? Sometimes, if I have the time, I'll memorize the whole piece of music – even if it's not required for my gig. Why? With the sheet music gone, it's much easier for me to focus on the more challenging and overarching aspects of the music I need to get right, and it's much easier for me to get into that incredible zone of pure music-making. So I find it's often well worth the extra trouble.

My experience with programming has been similar. I think the keys are:

1. practice the language – type it, run it, speak it if it helps; do so repeatedly.
2. build your facility – use the same feature or pattern in different situations; put features together; make programs.
3. give enough time between repetitions to make sure that things are really making their way into your long-term memory.

These principles seem to apply when learning any language, actually! See How to Remember New Words for example. The Pimsleur method also works like this.

I've found that almost all of the principles, syntax, and common libraries of the language and technologies I use regularly can be completely memorized, by using these keys. Even so, I still constantly scour the Internet for examples and wisdom! But that point, I'm looking for validation on the problem I'm trying to solve, various approaches that have been taken, tools that can help, and consultation for less frequently used libraries. It's a very different kind of search than I use when I'm first learning a language and neck-deep in tutorials and manuals.

From your story, here are some specific stumbling blocks I think you might be running into.

1. If you're struggling with syntax, you might not be getting enough practice. This is especially true if you're copying and pasting straight into your code, instead of developing the repetition and – may I say? – muscle memory that will help you get really good. To counter this, simply develop exercises and discipline, focusing on repetition and time, that will improve your facility in the areas you want. Suggestions:
   • Write a simple program in the same language once a day, every day.
   • Type examples instead of copying and pasting them.
2. If you're struggling with constructing solutions to moderate-sized problems, you might not be getting enough experience with building. Try these:
   • Start a medium-sized project in some technology or language you want to get good at. Or try your hand at a chunkier feature on an open-source project you're interested in. Hack away at it a bit every day. (Remember, when you're going after these larger projects: go at them brick by brick. Don't try and build the whole thing at once!)
   • Use the same new feature on four consecutive days, in four different contexts.
   • Challenge yourself to code something with the web browser turned off!
   • Actually take notes on stuff you're learning. Synthesize what you're learning, and write down your observations. (Actually writing things down, and forcing myself to express something in my own words, helps me a lot.)
   • Write answers, and verify them, for StackOverflow questions on the technology you're absorbing. (This often has the added benefit of earning you a little reputation while you're learning. :-) )
3. You might be spreading your practice too thinly. You seem to be working in many different languages. This has a lot of advantages, but it does have the disadvantage of diluting your experience. If you're spending time working in five different languages, you'll memorize less than if you're spending the same time in one language. Worse, there are lots of not-quite-similar cognates between different languages (was that else if, elsif, or elif??) to trip you up. To counter this, sharpen your focus. Pick one thing to learn and learn it cold. Then move on to the next thing.

Answer 17

I think if you focus on coming up with moderate code yourself, your efficiency and productivity will increase. It probably takes more time to be looking up code, reading/understanding it, copying it your source, modifying it accordingly, etc..

If you come up with it yourself, it is most likely more adapted to your specific situation, and after a while these solutions will come faster to you than looking them up.

The way I look at it, is that it's like you want a second opinion on a certain solution, so you look up how others (on the Internet) do it. If you find yourself doing/wanting this too much, think of it as asking a colleague about what he/she thinks of a solution. If you ask your colleague a question every 15 minutes, he/she will probably be annoyed. Therefore you will ask fewer questions and try to come up with it yourself.

Visualize this when wanting to look things up on the Internet.

Answer 18

The best way to learn what you don't know: google it! I feel you are right on par with most developers. Put the inferiority complex in your backpack and go in with an open mind.

Don't be afraid to ask questions, do research on Google, try and fail. It's all part of it.

Answer 19

Software development in a corporate settings requires a fair amount of code reuse. Why rewrite a function/method if an API already exists and is widely used? It most likely will be just as efficient as anything you write and take less time.

Of course, succeeding in software development also requires a break from the keyboard, so that you can read and comprehend what is really going on. Take any web framework. You should know what is going on underneath so you understand the code you are writing, but you likely will never have to write a web framework from scratch yourself.

You just have to write code which takes advantage of the type of framework (say a component-based framework requires a certain style) and this comes from understanding the larger picture. Learn the larger picture and you will be fine.

Answer 20

It's clear from the answers already given that there's nothing wrong with researching your problem, instead of coding blindly. But the question that wasn't addressed, because you didn't ask it directly, is why are you feeling so insecure-- and what can you do about it? After all, lots of people google their way through problems and have plenty of confidence (even those who shouldn't...)

So, what to do? Maybe you just needed a few hundred pats on the back, which you just got, and can now code with confidence. But if that didn't do the job, I suggest you look into automated testing and Test-Driven Development. Nothing says "well done" like an "All tests passed" from your testing suite: When you get there, you know you've done it right.

You should also try challenging yourself a little: You say you're always looking up syntax you already know; so force yourself to write some code without looking up the syntax, and you'll (soon, if not immediately) find out that you're doing just fine after all.

Answer 21

Developers are not born “great,” but greatness does not automatically come with experience. Conversely, lack of experience does not make a developer “bad.” The difference between a great developer and a bad developer is not in their domain knowledge, but their methodology. The distinguishing mark of a great developer is that he codes consciously. Put another way, a good developer always knows why he is doing something. From the perspective of personal ethics, this requires intellectual courage and integrity.

It is so important to take some time and get to understand the basics, more complex things pretty much build on top of that. If there is no foundation in understanding the language and what is going on behind the scenes, coding will be simply hacking…

Answer 22

So reading books with examples and referring to them is bad programming is the context of your question. Well seeing as few people document their API a book is all we have left.

I don't know what your reasons are for asking this question perhaps you can answer this yourself after reading my situation as I refer to a lot of code examples.

I never had a chance to go to university as I was on the street at age 16. Somehow at 24 I was in the position to study through a correspondence college and do vendor certifications as SCJP, SCJD, SCBCD and SCWCD. I must admit that at times I struggled and had to turn online for examples. Unknowingly though at this time I had a brain tumor growing in my head (by 2010 it was the size of an orange). After my 5 brain surgeries, 6 weeks combine chemo/radiotherapy and 10 months of chemo, I still am programming with hand written coded sites up that are viewable from my profile.

Yes I need a lot of code examples now with brain damage, so does that make me a bad programmer?

Answer 23

So I see you mentioned that you're going to a hackathon. I've been to quite a few this past year (more than 15) and noticed that they are great for learning. And by great for learning I mean learning how to never code like that ever again. I mostly try to do something new at every hackathon I go to just so I can learn new things. As there is a huge time constraint, you rely on just copy pasting all the code you can find and this comes to bite you in the ass when you're testing it.

However, good things do come out of it, you: A) LEARN so much during bug testing (also cry heavily) B) Know to never code like that again and learn better coding practices. Also, at hackathons you'll meet people that can teach you so many new things you never knew about, and you'll do things you are never going to do in school.

So what I'm saying is copy pasting is bad, and you won't learn anything, and the time you saved by copy pasting will bite you later on during bug testing and you have no idea what you even wrote, it's 8 AM, and are fueled with all the caffeine. But, I think as long as you bug test your code, you will HAVE to learn everything you copied before.

Answer 24

Well, I don't call myself a good programmer. But what I do is simple. If I don't know how to do something I actually look at some code / example around the Internet. Then after reading it, I try to rewrite it, optimize it and using the stuff that it suits best for the code I want.

Note: Reading code from Internet doesn't make you a bad developer. It is always good to look how other people do it, and you'll always learn something. But then, copying it blindly isn't good.

Answer 25

If a developer/student goes to say.. Wikipedia.. to copy/paste code into their project, then simply tries to get it to "work" then the only skills this person is developing is 'How to google'. There might be some process of osmosis there, but not a whole bunch. (You wouldn't believe how many people do this in college courses)

HOWEVER, If you analyze other peoples code and really think about what is going on in the code itself, then that does not make a person a bad developer. It makes them a determined developer and probably indicates a learning style that is more tactile or visual. I learn by example very well. If someone tells me something or tries to explain it to me, I usually ask them to show me wtf they are talking about.

Looking, analyzing, and learning from code actually makes them a good developer over time, because they are reading and learning in the language they are using.

I often joke that I know the ins and outs of computer languages than I do my native English language. Which begs the question; "Will you explain that to me in Java plz?"

Answer 26

I think it is a bit like playing Chess. We check the pieces individually and trace where they can move according to the rules, and we must go through that conscious checking for some amount of time until the subconscious joins in, revealing patterns and inspired sequences.

With programming there can be more pieces and rules, I am often stumbling with syntax and stuck on bugs which take forever to find by going through 'the rules', but eventually the subconscious will kick in. When it stays long enough, i can read back sometimes and marvel at what it can do.