Jump to content
  • Advertisement
Sign in to follow this  
Ntvu

Knowing How to Program vs. Knowing How to Code

This topic is 3498 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

How can you tell whether you know how to program, or only know how to code? That's a question I've been thinking about for a while, and to be honest, it really does confuse me. I really don't know which group I belong to (I don't know whether I know how to program or only know how to code). I'm assuming that if you know how to program, then you can "describe" your solution to a problem using a programming language, and you can easily learn another language once you grasp general/common programming practices. And I'm thinking that if you only know how to code, then you are only learning the syntax of a language instead of learning how to actually program effectively and solve problems using it. But what do you think? And how can you tell which group you belong to?

Share this post


Link to post
Share on other sites
Advertisement
There's a difference in knowing how to code and knowing how to program, imo.

The former is easy to learn, the latter is hard to master.

Share this post


Link to post
Share on other sites
Really?

A while ago some people on Gamedev said that knowing how to code isn't enough and that you need to know how to program.

Share this post


Link to post
Share on other sites
Quote:
Original post by Zenix
The two words are synonymous..

Yes, but the OP gives a little clarification as to what he is trying to say.

Anyway, one good test is to try doing the same thing it two different languages. If you can write it in multiple languages, chances are you have a decent fundamental understanding of what you're doing. A good test that doesn't involve multiple languages is analyzing your code and fundamentally understanding what's going on. If you write a sorting algorithm, do you understand *why* and *how* that sorting algorithm works? Do you understand *why* it may or may not be faster than other sorting algorithms? If I were to ask you why you wrote that specific line of code, could you give me a good, detailed answer as to what it's doing and why it's important? Understanding algorithms is crucial to knowing how to properly program.

Then you also have to know how to build/construct/design your program. How do you handle user input? How to you separate game logic from rendering? There's lots of questions you have to ask yourself. To be honest though, designing a program is a learning process. Being able to properly design one program does not guarantee you'll be able to properly design another program. If you catch yourself writing redundant code, lost in the guts of your program, or something else bad program design can lead to, then you know two things: 1) You probably didn't design the program properly, and 2) The fact that you were able to identify these problems shows that you have an understanding of program design. If you don't catch these problems, then you're missing something. If you're catching the problems, then it shows you're learning and you're on the right track. The fewer of these problems you have, the better your program design was.

[Edited by - MikeTacular on April 18, 2009 6:03:53 PM]

Share this post


Link to post
Share on other sites
Quote:
A while ago some people on Gamedev said that knowing how to code isn't enough and that you need to know how to program.
That's a statement I could see myself saying. But you can't really code without programming unless there's a programmer next to you telling what keys to hit while a text editor is open. The question you asked is, "How can you tell whether you know how to program, or only know how to code? ". I think that's a distinction that, even if by some arbitrary measure were possible to make, would not be meaningful.

In learning to program something non-trivial, one needs to acquire a significant amount of knowledge. Let's assume your goal is to write an IRC client in C++. The most visible aspect of the knowledge required is that of the programming language. It's easy to see examples of C++ code, and with limited understanding of what it means to program, it's easy to have an approach not too different from "say the right magic words". Type in the right arcade code, and you get what you want. But as you already know, it goes beyond understanding elements of the language syntax.

You need to understand the idioms that are in use with the language. RAII, for example. Then, programming concepts, practices, and idioms independent of language. Error checking and handling as an example. And general computer science knowledge. Sorting algorithms for example. And then good design principles and approaches. Do you avoid abusing globals? (Because you were told to, or from experience and understanding?) And we haven't even gotten to general software development ideas and practices like using version control.

So rather than making a distinction as to whether you know how to code or program, you should recognize whether you are focused on learning the magic words (the syntax), or you are making efforts to learn the broader aspect of programming. It doesn't matter how much you know. It matters that you recognize how much you have to learn, and that's it more than just the syntax.

Share this post


Link to post
Share on other sites
Quote:
Original post by oler1s
But you can't really code without programming unless there's a programmer next to you telling what keys to hit while a text editor is open.
That's pretty much how I learned to program/code ;)
I had a huge C++ code-base for a game, which I didn't understand at all, and I became a coder by randomly tweaking numeric values, and by following step by step "insert this line of code here" tutorials.
After doing enough of these tutes, I began to pick up the syntax and could really call myself a coder.

I don't know where the term 'programmer' comes into it, but I wouldn't say that I was an 'software engineer' until after I had completed my formal studies.

Share this post


Link to post
Share on other sites
I think the problem here is the phrasing of the question "program" and "code" really are synonymous. Perhaps the question you should be asking is "How can I tell if I am hacking together programs, or properly engineering software?" The problem is that it's difficult to set an objective metric to answer this question properly. You can use certain metrics such as code repetition and code coverage to help you answer some of these questions. Honestly, though, the "art" of programming is something that is only partially formal and is very hard to quantify (that is to assign a strict measure of good vs. bad code). I suppose its somewhat like the Supreme Court definition of obscenity; I know it (bad code) when I see it. Maybe you can give us a more concrete example, and we can tell you what we see.

@MikeTacular
Quote:
Anyway, one good test is to try doing the same thing it two different languages. If you can write it in multiple languages, chances are you have a decent fundamental understanding of what you're doing. A good test that doesn't involve multiple languages is analyzing your code and fundamentally understanding what's going on. If you write a sorting algorithm, do you understand *why* and *how* that sorting algorithm works? Do you understand *why* it may or may not be faster than other sorting algorithms? If I were to ask you why you wrote that specific line of code, could you give me a good, detailed answer as to what it's doing and why it's important? Understanding algorithms is crucial to knowing how to properly program.


I have to disagree with you a bit here. I think that understanding good software engineering practices is completely different from (and in many cases orthogonal to) mastering algorithms. There exists very theoretical computer scientists; brilliant people, who can explain to you in painstaking detail an asymptotically optimal algorithm, yet who write atrocious code. In fact, often the most theoretical guys, who come up with some of the most interesting algorithms, are precisely the people who don't code often (or well). That is not to say that there are no counter examples, but just to draw a distinction between mastering the concepts of computer science (discrete math, algorithms, etc.) and mastering the concepts of software engineering.

Share this post


Link to post
Share on other sites
Quote:
Original post by gfxnomad
@MikeTacular
*snip*

I partially agree and disagree, and perhaps I should clarify. I'm not talking about any specific algorithms. I'm talking about algorithms in general. It's a matter of being able to think algorithmically. If you can't employ algorithmic thinking, your software won't be engineered as effectively as it could have. More than anything though, I was trying to get across the importance of understanding the code you're writing. You don't have to know every nitpicky detail. But if you don't really understand what you're doing, how are you ever going to properly write a program on your own?

Share this post


Link to post
Share on other sites
As a lot of people have said, coding and programming are pretty much synonymous. I think the distinction you're looking for is software/algorithm design vs software/algorithm implementation.

I think gfxnomad came closest to answering this distinction. I have known a LOT of extremely talented people in both theory and implementation, but very few people are both at the same time.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!