Is it normal to be so slow at programming?
Hey there!
Just wondering, is it normal to be slow at programming? By that, I mean that everyone in my class always seems to finish things way way before I do. Heck, I even timed out on the final last class, because I was still working through the programming problems when the timer rang. I was the only one still left in the room.
I'd like to think I'm a pretty bright guy, never had major issues with anything like this before. I'm spending close to 30 hours a week on programming, but no matter how much I practice, I still don't get any faster, I just get more correct with what I write.
Maybe it's how I think about problems that holds me back? When I code, I think about things using real world examples and images, if that makes any sense. I can't just think about the code and go, so I think about images and examples, and then work on converting those processes to code instead.
Sorry if that's not really a clear explanation^
Anyhow, is there a wrong or a right way to program? Or at least a trick to getting any faster? Or am I just doomed to be stuck at turtle speed forever? I'm really tired of hearing the buzzer and only having half my code done.
-Drew
Just wondering, is it normal to be slow at programming? By that, I mean that everyone in my class always seems to finish things way way before I do. Heck, I even timed out on the final last class, because I was still working through the programming problems when the timer rang. I was the only one still left in the room.
I'd like to think I'm a pretty bright guy, never had major issues with anything like this before. I'm spending close to 30 hours a week on programming, but no matter how much I practice, I still don't get any faster, I just get more correct with what I write.
Maybe it's how I think about problems that holds me back? When I code, I think about things using real world examples and images, if that makes any sense. I can't just think about the code and go, so I think about images and examples, and then work on converting those processes to code instead.
Sorry if that's not really a clear explanation^
Anyhow, is there a wrong or a right way to program? Or at least a trick to getting any faster? Or am I just doomed to be stuck at turtle speed forever? I'm really tired of hearing the buzzer and only having half my code done.
-Drew
Do you type slowly, or it just takes you a long time to think of what to write? If it's the former, just learn to type (Google it). If it's the latter, then I guess it'll improve over time.
closed account (3qX21hU5)
Either way the good thing is that programming isn't a race and usually not to time sensitive. Yes there will be dealines on projects but generally people would want a program that has almost no bugs that was completed in a month instead of a program that was completed in a week but with a large number of bugs and sloppy code.
I type fairly quickly, it's more a matter of putting the pieces together in my head quick enough to make my proffessor happy.
That sounds less like actual programming speed and more about design and solution development. Perhaps you should read some books on design patterns etc.
You're probably spending too much time focusing on the low level structure of the code.
There's basically two ways in which programs are constructed. Top-down design can be likened to first splashing buckets of paint onto a canvas and then gradually using finer and finer brushes until the final picture is created. Bottom-up design is then like starting by painting very detailed independent fragments (e.g. the nose in a portrait has no bearing on the ears), and once everything is completed, sticking it all together like a collage.
My guess is that you're taking a third approach of using an eye dropper to pick color droplets to fill a very large grid. This works, but it's very inefficient because you're unable to distance yourself from the fine details to look at the big picture.
As you gain more practice this will go away (or at least it will be considerably attenuated) and you'll be able to abstract details away more easily.
There's basically two ways in which programs are constructed. Top-down design can be likened to first splashing buckets of paint onto a canvas and then gradually using finer and finer brushes until the final picture is created. Bottom-up design is then like starting by painting very detailed independent fragments (e.g. the nose in a portrait has no bearing on the ears), and once everything is completed, sticking it all together like a collage.
My guess is that you're taking a third approach of using an eye dropper to pick color droplets to fill a very large grid. This works, but it's very inefficient because you're unable to distance yourself from the fine details to look at the big picture.
As you gain more practice this will go away (or at least it will be considerably attenuated) and you'll be able to abstract details away more easily.
I've never understood why they think stressing you with a time limit will make you a better coder. I think it is better to challenge yourself or pick up other languages (I'm doing the latter and wouldn't recommend it until you pick up some of at least one language). I honestly don't know of any way to improve your understanding outside of just coding things and looking at others code while timing yourself to try and increase your performance.
I've noticed that when I try to rush, I end up taking longer and produce worse code.
Sometimes it helps for me to just sit for a few minutes, think about the problem, work out the algorithm, logic, and math on paper, then start type once I have a well thought out plan.
Sometimes it helps for me to just sit for a few minutes, think about the problem, work out the algorithm, logic, and math on paper, then start type once I have a well thought out plan.
Last edited on
Yes there will be dealines on projects but generally people would want a program that has almost no bugs that was completed in a month instead of a program that was completed in a week but with a large number of bugs and sloppy code |
Don't underestimate the time-to-market advantage. Usually those win who get their product to the customer faster, not the ones whose products are better at the moment of initial release. Unless you don't release something completely broken, releasing something buggy-but-doing-its-job-somehow is much better than releasing a polished product two months later.
That's why Hadoop took over the market of BigData, although it is neither fast, bug-free nor easy to use. Even if you managed to create something better now, e.g. fine tuned performance by carefully coding everyghing in C++ with assembly, fixed all bugs, added an awesome GUI, I'm 99% sure you'd fail miserably.
So, maybe you are too picky about details (e.g. user interface or error handling)?
Last edited on
the biggest problem in this regard is usually messy code.
if you use non descriptive variables or constants you will reach a point where any change will get tougher until there's no other way than rewrite it.
What you need to do is breaking a problem in smaller parts and then build your program step by step (and don't forget to test after a step is done). it needs discipline, but it pays.
It is usually not necessary to care for speed or size of the program.
if you use non descriptive variables or constants you will reach a point where any change will get tougher until there's no other way than rewrite it.
What you need to do is breaking a problem in smaller parts and then build your program step by step (and don't forget to test after a step is done). it needs discipline, but it pays.
It is usually not necessary to care for speed or size of the program.
closed account (3qX21hU5)
| Don't underestimate the time-to-market advantage. Usually those win who get their product to the customer faster, not the ones whose products are better at the moment of initial release. Unless you don't release something completely broken, releasing something buggy-but-doing-its-job-somehow is much better than releasing a polished product two months later. |
Well this also deals with what field your producing the program for. Like as you mentioned some fields yes it is sometimes better to get your product to the market faster with a below-par product, but in other fields it can ruin you. Take the game industry for example. Especially the MMO market. If you release a product to soon that is not totally complete you will lose your player base because it is lacking certain aspects and they just don't want to wait for them to be released later. Like SWTOR for example. EA rushed them to release the product before it was finished, and they thought they could get away with releasing a sub par product, but in the end it destroyed the game. Sometimes it is better just to take your time and make sure your product is complete.
So yes I agree that time is important but not in all aspects of programming.
| @rapidcoder Unless you don't release something completely broken, releasing something buggy-but-doing-its-job-somehow is much better than releasing a polished product two months later. |
I think that it is a general delusion that is used to justify a bad code, low qualification of programmers and managers and so on.
Such approach can exist only if there is no competition. If I do not like a product I will change it to other provided that the other product has the same functionality. It is not important to me and I think for others that it will appear through for example three months later.
Last edited on
@hellfire1 could you give us an example of a problem and your solution using real world examples? Maybe we can show you how to skip the real world stuff. As unfortunate as it is, a lot of real-world analogies don't work properly in programming.
Last edited on
@rapidcoder ... I wish you'd be available for freelance, ... are you?
(you've helped me to win an argument with my C++ programmer, now I'm in trouble, lol)
@hellios, you speak out from the bottom of my heart ...
... it always seemed to me that I was working twice as hard than the others, running 24hrs shifts on gallons of coffee, but then ... when I'm done, I rarely need to go back to it again ... more importantly: it was always a great fun and challenge to me ... and ... I knew I can utilize it sometime later on (most of what I have done), regardless on that I haven't been paid this time ...
like rapidcoder says ... I've lost a bunch of customers / deals, but also won a few of a real big fish who wasn't much in rush and didn't mind to part with a sweet sweet amount of money for piece of "solid work" ...
Drew, what's you favored language?
(you've helped me to win an argument with my C++ programmer, now I'm in trouble, lol)
@hellios, you speak out from the bottom of my heart ...
... it always seemed to me that I was working twice as hard than the others, running 24hrs shifts on gallons of coffee, but then ... when I'm done, I rarely need to go back to it again ... more importantly: it was always a great fun and challenge to me ... and ... I knew I can utilize it sometime later on (most of what I have done), regardless on that I haven't been paid this time ...
like rapidcoder says ... I've lost a bunch of customers / deals, but also won a few of a real big fish who wasn't much in rush and didn't mind to part with a sweet sweet amount of money for piece of "solid work" ...
Drew, what's you favored language?
could you give us an example of a problem and your solution using real world examples? Maybe we can show you how to skip the real world stuff. As unfortunate as it is, a lot of real-world analogies don't work properly in programming. |
Sorry, I really don't know how to explain how I think things through... : /
I don't really know how to acurately describe my thought process. I just start programs with a piece of paper and write down a generalized process of what I have to do to solve it, then I take each bit and break it down into more specific parts, using actual C++ ideas this time. After that, I break it down some more, and that's usually where I start having to mix things up in my head, because I just can't think in code sometimes. It's just that that takes me up to an hour sometimes...
Drew, what's you favored language? |
C++ is the only programming language I know currently, although I'm still learning parts of it. I'm up to the chapter on classes. I'm spending about 4 hours a day with it, and it's just not helping me get quicker... I get perfect scores on my projects assigned to me, but it took me 7 hours to do a little breakfast billing system, while someone else finished it in 2.
I guess I should be happy with the results, but I know that my speed is going to hurt me when I'm trying to do much larger and in depth projects...
closed account (3qX21hU5)
You cant really base what your speed will be until you get more experienced. Also it takes time to program it doesn't just happen. When I do a project most of my time is spent researching new functions , libraries, examples, debugging, ect and and very little is actually writing the code. So I wouldnt worry to much about it cause most of the time it isn't a race.
Also when you do have more experience (like 2 years from now) you will not have to think to much aboutthe code because you will know most of it you will just have to think about the design and other design related elements.
Also when you do have more experience (like 2 years from now) you will not have to think to much aboutthe code because you will know most of it you will just have to think about the design and other design related elements.
Last edited on
Topic archived. No new replies allowed.