I just feel so frustrated right now as I just finished one task.
Seems like every time I program (homework or other stuff), I make stupid mistakes that take me hours and hours to fix, sometimes it takes me the whole night just to finish a fairly small homework. Even if I do debug, still need lots of time to finish.
I love writing code and I'm constantly learning but there are a lot of those nights that I feel that maybe I'm just too "dumb" or careless to be good at it especially when I'm at the workplace in the future.
Any advice on this? Is this normal?
If learning to program doesn't make you feel dumb you're doing it wrong.
You will get used to it. I know - I feel the same way.
It would be better if you gave some examples of stupid mistakes, but still I have some suggestions:
Even the most experienced developers have those moments/days. I call them the "Damn I'm an idiot" family of errors.
It's where you spend hours going over your code trying to work out what the hell is wrong with it only to find it's something ridiculous you took for granted.
e.g.
etc.
This is a good time to learn best practices... write small, testable pieces of code, write unit tests. Write comments in your code so when debugging, you can immedately see what it should do (not just what it actually does...), etc.
Even developers with years of experience often spend hours resolving problems that turn out quite simple in the end. Feeling frustration is normal - software development is very hard by its nature. As you practice and gain experience simple tasks will take much less time but you will shift to harder tasks and they will consume their share of your time.
Sounds like you might want to look into Test-Driven Development [1] - it can significantly reduce that kind of frustration.
But never eliminate. There's a very revealing quote from one of the guys working on the first computers (unfortunately, I don't remember the name) about how it was harder than expected and the moment he realized that he would spend much of the rest of his life finding errors in his own programs.
[1] http://www.agiledata.org/essays/tdd.htmlIt might happen because you write unmaintainable/unreadable code. Many students (I am a student as well) I know do this.
Try to adhere to standard coding practices and try to make things reasonably generic and well-separated. Have a look at open-source projects and see how nice code looks. Trust me, it's better and easier to write 500 lines of nicely-formatted code instead of a lump of 250 lines of unreadable, hard to extend and hard to debug code.
Here's a list of things you should be doing and which can be a time-saver later:
With time, you'll get better at debugging code and spotting mistakes. But I believe it's best to prevent exposure to such problems whenever possible. And no matter how good a programmer is, obfuscated or badly-written code will still slow him down a lot.
It's much better to be aware of the fact that you are making errors (even "stupid" errors!) than to believe that you are perfect! Everebody makes mistakes...
If you know your limits and take care you'll be a much better programmer than another person that believes it is a genius.
Hey don't worry about these. I am a similar guy like you and am working in a software company now. These often happens. Just try to keep a track of silly mistakes you do and at a point you will avoid most of your mistakes. Just keep going... don't waste your time worrying about these because you can learn better than others if you make a mistake.
Programming is not programming that you've seen in the movies such as Die Hard 4. Every programmer makes mistakes. The more you discover it, the lesser chance for you to make the same in the future.
The biggest mistake you'll ever make in programming is the fear of committing one.
This is normal - although as time goes on and you persist at your craft, you'll become more efficient.
I think we all go through periods like this. If you persevere, things should get better. If your problems stem from lack of experience, the only way to get better is to keep on trying.
To try and minimise time-consuming errors, it is worthwhile to design your solution fully, on paper perhaps, before you actually start writing code. Not thinking through all aspects is a common reason for finding errors that cause you to backtrack and recode sections of your solution.
This is normal. In the beginning you have to get used to a certain way of thinking: What steps must I take to accomplish my task. As you refine these steps, you get closer and closer to a solution that can be put into code. The smaller the steps, the easier the coding.
The most important thing is to try and not feel too frustrated, instead try to learn as much as possible from the mistakes you make. Next time you start a new programming task, concentrate also on identifying situations where you've made mistakes before and the ask yourself what you need to do differently this time.
Remember programing is very much an art form. There are always an infinite number of solutions to any problem, some which are much better then other depending on the problem.
So even when you no longer think you are "dumb" and doing everything right, someone is still going to come along and show you a better way to do something you thought you had nailed.
There are two big things that will help tremendously with this. The main one is experience, and it will come naturally.
The other thing is learning to troubleshoot problems in a logical manner, which is something that will also come naturally as you gain experience, but you can save yourself a lot of effort by thinking about how you approach your problems now instead of learning what works by trial and error. Whenever you find a difficult bug, think about the things you tried before you arrived at the correct solution and figure out how you could have known they were less likely to be the correct answer. This will help you learn to analyze problems and try the most likely solutions first, and you won't waste as much time on things that don't work.
Some general tips:
Learning to code isn't easy, even though there will always be a few people that make you feel like it should be. Hang in there.
Debugging is one of the most difficult skills to learn when you're first starting out. I've found that the hardest part of debugging is when there's something that I assume to be true that turns out actually to be false. I'm convinced that the program should behave in a particular way, and it doesn't. What I basically have to do is:
foo
succeeds, I think it fails somewhere in function bar
).The second step also takes experience in learning how to simplify your code and inputs so that you're testing only the particular assumption.
If you are not struggling you are not challenging yourself. One good thing to do is look over your code from a few weeks, months, or years ago. This is very common and don't let it discourage you.
The Software Engineering Institute [1] has a methodology to help you become a better developer. It's Called PSP [2]: Personal Software Process.
It should help you with these issues, however, on a more general view, I would say that following ANY methodology will help you produce less errors and be more productive.
[1] http://www.sei.cmu.eduLots of great advice! All I can add is that only once I became disciplined to follow the guidelines I set for myself, did I start to become comfortable. And only just! Oh, and don't fuxx with working code the night before a demo unless you can EASILY redact it.
When you start feeling like this, go outside, take a quick walk, stretch your eyes, take some deep breaths. You need to rest your mind, with alot of stress or distractions its easy to make silly mistakes. A quick break can make these mistakes more visible.
You can do it! Just don't be hard on yourself, keep at it, and take regular breaks!
For a new person learning to program it usually involves changing to an entirely different method of thought. An entirely different way of wrapping your head around problems that you've never faced before and learning to deal with them in a manner appropriate to the world of computers and technology. When you start to understand data structures, how computers/electronics work, and get used to it, you'll find it's much easier.
It is frustrating, we all understand. and we are all still going through it.
There are good tools out there that help you build a library of reliable code snippets. Snippely [1] is a nice little example, but there are others.
If it makes you feel better, there are also many articles on line about how long it actually takes to become an overnight success;
http://www.codinghorror.com/blog/archives/001207.html
http://www.37signals.com/svn/posts/1624-overnight-success-takes-years
http://www.firelily.com/opinions/overnight.html
I know the feeling but you'll learn to look for abvious failing points and you'll also get better at debugging for sure.
Persist! :)
divide any project you're doing into small chunks, that will be easier to handle
write short methods, that perform one precise bit of functionality
write unit tests. This is very important !
write the unit tests before you write the code that will be under test.
once you're done with a tasks, take a step back and look from a larger perspective at what you've just done : have you done similar things in other parts of the project ? Can you improve/refactor any of the code in order to make it clearer/simpler/etc ? Can you reuse any of that code somewhere else ? Are ther things that you haven't covered with the unit tests ? Are there any things that you've done in a quicky & dirty manner that you should clean up ?
log things using the framework that's available for your language ( log4j or similar )
read some good books ( Refactoring, Code Complete, Writing Solid Code )
Cheer up and do your best, you'll get the T-shirt ! :-)
First, debugging is harder then writing code. It take more practice and also takes longer. So it is how we spend most of our time.
Because debugging is harder then writing code, write simpler code. The simpler and clearer your code is the easier it is to debug. There is a famous programmer quote, to paraphrase, "debugging is twice has hard as programming. If I write code at the limit of my ability, then by definition I am not able to debug it".
To avoid careless programming follow the best practices mentioned here. But also make sure you're of sound mind when coding.
Don't force yourself to code. Remember to take a break. Sleep [1] is good too.
It's possible that you can spend 3 hours solving a problem that would take half an hour in the right mindset. Also if you walk away and come back you'll see the code with fresh eyes, or notice something you've overlooked before.
[1] http://news.bbc.co.uk/1/hi/health/8090730.stmWhat sometimes helps me when I get stuck on something is to write a new StackOverflow question, detailing everything you're trying to do and where it goes wrong. Often, I realize what the problem is halfway through writing the question and it's usually a real case of "ooooh of course, stupid stupid stupid". I guess the reason this works for me is that you're forcing yourself to look at the problem from a different perspective as you're writing it for others to read and they need to be able to understand what you're doing. And if you're done writing the question and still haven't found the problem yourself, post the question ;)
I think it is completely normal and it is good in a way that you have identfied it.
The most important thing here is that you dont lose hope. Instead you should strive to get the solution. Implementing the solution would give you a lot of satisifaction. You can then go one step further and write a blog about it. Blogs are a good way to keep track of your ideas/thougts/stumbling blocks, etc. This is also a means to make sure that you dont repeat the same mistake twice. Suppose you encounter the same issue years later and you have no idea what you did previously, you can go back to your blog post/ community post and get the answer!
As beginners, most programmers/students are interested in short term solutions. However, when you become a pro, it is super important that you look for long-term/stable solutions.
Some things that can be kept in mind are:
Write code small piece by small piece. I've helped beginning programmers for a few years now, and the #1 problem they have is they write too big pieces of code. Try to write code in 5-line increments. Test each 5 lines for correct compiling AND correct running.
Don't worry. You'll find that you make the same mistakes less often. If you can learn from these mistakes, you will only get stronger and better. Some of these mistakes will be your best teacher.
it may not seem like it but you are getting better and better but you're moving to fast to notice. Hang in there an it will all work itself out.
Best 'o luck :)
One thing I learned is that having larger building blocks helps, as in relatively self-contained sections of code that fit together. Try to keep code chunks self-contained and with limited functionality.
Another thing I sometimes use is formal proofs, which can go pretty fast if you're practiced with them. Of course, these only work on simple things; if you've got complex code, a formal proof will be a lot more complex than the code, and you don't gain anything. It's not that code I've proved correct actually is, but that the remaining mistakes are typically big dumb ones that show up well with even limited testing.
Test-driven development is good. With luck, you'll find out about stupid mistakes immediately. I like to find mine when the logic is still fresh in my mind.
Other people can help find mistakes in code. Sometimes just explaining the code will bring out mistaken assumptions you hadn't thought of before. Heck, I had a friend who'd talk about bugs in his code with a large cardboard cutout of Captain Kirk (from the original Star Trek).
And, of course, remember that you're not alone in this. There are very few programs of any size that will go through a thorough examination that doesn't find bugs.
There has been a lot of good advice here. I don't think 'too dumb' is correct but some people are undoubtedly better at coding than others. I often get people to write small scripts during job interviews. You can tell a lot about a person's coding skills etc by this - if the code is laid out neatly, consistently, with good var and function names, with lots of comments, then I know this is going to be a good person with good attention to detail. I find that with a structured, logical approach you make less mistakes. The clearer your code, the less silly mistakes you'll make, and the easier they are to spot. This approach can be learnt, but is easier for some than others. Also, learn how to debug your code - there are simple techniques that can spot tricky problems quickly. Saying that, sometimes we all need second eyes to spot a persistent bug that we can't fix...
You should try pair programming [1] if you have the chance. Another pair of eyes too look after you would make a real difference.
[1] http://en.wikipedia.org/wiki/Pair%5FprogrammingNobody's perfect. The ratio of defects created per checkin is pretty close to 1:1 for the median developer. Experience, maturity, and improving your personal practice will help you get the better end of that ratio, but it'll be a long (never ending, in fact) hard-fought battle.
Consider: again, nobody is perfect. If you never acknowledge your own ignorance and your own fallibility then rather than retaining perfection you are instead merely missing out on opportunities to improve yourself. Only through accepting, eagerly seeking out, and remedying your own deficiencies can you possibly improve.
P.S. You could do worse, starting out, than to go through the highest voted Stack Overflow questions tagged best-practices [1].
[1] http://stackoverflow.com/questions/tagged?tagnames=best-practices&sort=votes&pagesize=30Everyone does this at first. It takes a long time to cut out certain stupid mistakes, and you can never get rid of them completely. Just think, after you spend 4 hours fixing a stupid bug, you're way more likely not to make that mistake again ;)
I think that it is normal beginning. As people mention, even very experienced programmers can stuck to long time, on debugging process.
At this point what helps me when i start to programming, is writing logs(very important to make this logs readable). on time when i start i didnt know about TDD :) .
Blaming others for errors when your code is broken is maybe even worse than making errors. But many people do that too. So making pretty sure your code works is very important. But when an error occurs, better check your code first.
One rule of thumb is that check the most obvious things first. For example maybe your code does work, but you have some parameter or setting wrong. Your module should throw an exception if possible, when input is wrong kind or not supported.
I think that defining and documenting the features of a program helps. If you find it hard to even describe what and how your program works, then there might be some hard to think of problems in some execution paths. In large systems this becomes more important, when some part of a system might have an effect to some other part, but if you are not aware of that, you might implement a new feature that breaks the first hard to notice functionality. So features should be clear and traceable.
It means you have to scale down your attention scope and span -- break things into smaller pieces and name them properly.
Don't use vague variable names or methods that will cause you to spend a few more previous seconds wondering what these variables or methods are about. Clear and concise.
I've felt the same way. Just stick in there, keep pounding away at the code and eventually it gets easier.
If you are newbie and junior coder, that is normal, if you cant find your solution at coding later, read aloud of your coding line by line and explain every lines to your self, that will make you see the error and solution, I am sure that will save your time later when you are coding.
A method I try to stick to is that when you find that you've made some stupid mistake, write a test (or just an assert), that will catch the mistake the next time you make it. Hopefully it won't happen, but if it does, you'll get a little satisfaction from knowing that you've saved yourself a couple of hours worth of debugging pains.