I have been programming for around 3-4 years now (completed my degree in CS where we were taught the Java programming language).

Now my question is:

Do many people find it a difficult task knowing how to write code from off the bat?

What I mean by this is that when I approach a task I would normally look on google to find examples of pre-existing programs to which I would cut and pick sections that would be of use to create my programs rather that think totally logically, knowing what I would need to use from the class libraries to puzzle together to reach my end goal.

An example of this is say I was creating an animated GUI. Now for that GUI to work I would usually look at other examples on google and piece together code to reach my desired effect, rather than going to the class libraries and working out exactly what I need to piece together a working program as the libraries can be quite daunting in knowing where to start to find sections that would be useful to you!

Just wondering if many others do the same as me or if I'm a minority?

Don't know if others find it hard but sometimes I just get confused in knowing what classes I would need or what would be the best way to approach a task.

One can't expect you to know all them libraries and their intricacies by heart. After you've written 4 animations, you'll write the 5th one blindfolded, but until such time, nothing wrong with copy-pasting stuff around.

What I usually do (10 years experience) is copy-paste someone's code and then re-write it ENTIRELY. This way, my code ends up a) visually pleasing (since MY code is the most visually pleasing code to ME), b) I understand what's happening in there, and c) in the process I delete a couple of lines I should have actually kept and run into some problems that cause me to actually start figuring out the technology.

That said, if you need a Base64Decoder or some such, no point re-inventing the wheel - just grab it off the web and don't feel any lesser man for it.

When you're beginning, programming is pretty daunting. You have to think about the problem that you're trying to solve (analysis), and you have to think about how to solve the problem (design / coding).

The person that suggested returning to the waterfall method was trying to help you divide the problem you're trying to solve into small enough steps, so that you won't be overwhelmed trying to solve the problem of each of the small steps.

As you gain experience in design and coding, you'll start to learn patterns. These patterns are part design and part coding. Some patterns appear in more than one coding language, although the coding for the patterns is language specific.

There are books that describe design patterns. I'm not sure how helpful they are until you've gained enough coding experience to understand the concept of patterns.

Once you've mentally accumulated some design patterns, then you'll find yourself thinking less about how to solve the problem, and more about the problem you're trying to solve.

I still look up code snippets on the Interwebs. Mostly because I forget the syntax of some Java language features like the Set iterator.

Learning how to effectively leverage existing libraries is an important skill in professional software development that is often under-emphasized in school. That said, the ability to think about a problem logically is perhaps the most important skill to develop while in school. If you aren't learning how to do that then I feel your CS education is sorely lacking. You don't want to go about constantly reinventing the wheel, so it's OK to sometimes find a useful code snippet elsewhere. However, that's not enough to be a serious professional.

At some point, you have to get back to basics, and that means waterfall method.

You look at what you have to do. Identify your requirements (lists are good for this.) Determine how you're going to implement each requirement. Then do it.

This is not easy as a fresh programmer. You're going to get a job where none of the existing code is documented, the knowledge exists in people's brains only, and they aren't going to want to waste their time on some new know-nothing-full-of-acedemia developer.

Or you'll get lucky with your first job, but that just makes it easier, not easy.

Our line of work is very hard. Solving problems in a smart way is hard. You did not go to college for 4 years to learn to code. You learned to solve problems. Focus on solving problems smartly and the code will come to you.

errr... basics.... waterfall... That never worked for me and trying to stick to it as I was thought was probably the one biggest setback in my career. Good design require knowledge, knowledge is acquired through reading, understanding but most importantly through experimenting. When one lacks the experience no amount of doodling on a piece of paper will advance their understanding of the problem enough to design something that will work. I'd much rather see a design emerge from knowledge gathered by experimenting than having come at me like an epiphany.
–
NewtopianApr 1 '11 at 3:15

2

You're missing a key element of what I was trying to say. He's having problems writing code. That's the problem. He's focusing on the code. He needs to focus on the problem the code solves. You're right, experimenting is VERY important. But you need to make sure you're not just trying random things until they work. It is an important practice to start with a problem, break it down into individual requirements, and devise a solution. Otherwise you're just going to be a cowboy coder your whole life.
–
corsiKaApr 1 '11 at 5:08

1

well that's just it. His first reflex when faced with a problem is to go out and find a pre-digested solution. This per say is not wrong but without a healthy dose of curiosity to de-construct the example and play around with it to understand it he will never gain the knowledge necessary to get to the stage where he can create. Curiosity and experimentation are the first skills he should be focussing at this stage if he has any hopes of climbing past his limitations. This is an unfortunate side effect of the way many places teaches programming...
–
NewtopianApr 2 '11 at 6:26

... they will give you pre-digested sample programs that you have to modify following a pre-set path to achieve an expected end-result. This can take extremes that lead to a big lack in the more fundamental values of creating software namely creativity. Please not I am not saying that Jason is devoid of it just that instead of enforcing creativity and curiosity they inhibited, albeit unintentionally, by providing a standardized education profile.
–
NewtopianApr 2 '11 at 6:31

Some are more comfortable with big design upfront, I find I learn more when I see it run.

Start small, take your problem and make it as simple as possible. Code it, don't worry about how good it looks, just spring up a class and do it all in the main. Then add a bit that is missing and see it run. you will get to a point that your main becomes big and hard to read. Refactor it by creating a class that encapsulates some of the functionality and keep at it. Your goal is to keep that main as small and easy to read as possible, when you read it it should be obvious what the application is doing.

Once you get into this cycle I find things evolve pretty fast. Looking for example on the web will help when you compare with what you are doing. With time and experience your designs will improve but the main thing is that you will finally put behind you that uneasy feeling you get with a blank editor.

There is a catch though to this empirical way to build and design software. There are times when you feel you just cannot nail a particular problem. My advice, stop right there, look at the bigger picture and search for a solution, chances are you took a wrong turn earlier that ends up making things more difficult for you now. Never fear to trash code and replace it with a cleaner, simpler solution. Deleting large swath of code because they have been made obsolete by a simpler system is one of the things I enjoy most, means I just learned something.

Tests are your friends, nowadays I mostly do this experimenting in unit tests rather than in a main class. Then when I know what I want, I write an interface and create a new test, then just implement it. I still try however to get a working prototype as soon as possible and add meat around the bones.

There is no absolute methodology, it all depends on your personality. Some feel more comfortable with a detailed plan and build according to plan, I do my best chipping away one bit at a time constantly stepping back to see where that fits until the full picture is revealed.

I do a bit of both, myself. Being completely self-taught, I rely heavily on resources such as the Internet and books. However, whenever I do find a piece of code that does what I want it to do, I always try to find out why it works, so that I have a better understanding of what I'm doing.

Anyone can go out to the web and assemble a program from pieces and samples, but it's another to understand the why behind it. Because once you understand why it works the way it does, that's one more piece for your arsenal. Remember, knowing is half the battle!

FYI, I marked this response as community wiki because it's more of a discussion of practices and principles than it is a straight question and answer scenario.

Make sure that programming language are not important! Its only your problem solving skills; before going to google it, try to find an algorithm for the question, if you does find an algorithm then your on the right way!! and coming back to your question:

This is fine. Try to change those examples got from the google result and see how does it work, change stuff and have run. And in some point, if you don't understand what that code does, think for a moment, take a paper and pencil try to analyse what that code does. After your try,but still you couldn't able to figure out, then post your question in stackoverflow.com.. Community is there to help you :)

This is a good point. When I'm designing something new, I make a lot of notes in pseudocode, and when I finally get the algorithm figured out I write it up in whatever language the project uses. Don't let the implementation language dictate your approach.
–
TMNApr 1 '11 at 17:20