Too "careless" in programming?

Question

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?

Answer 1

This is normal - although as time goes on and you persist at your craft, you'll become more efficient.

Answer 2

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.

Answer 3

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! :)

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

• You're actually looking at a different page/form/button
• You had < instead of > or vice versa
• You forgot to recompile before you ran it

etc.

Answer 8

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.

Answer 9

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.

Answer 10

Sounds like you might want to look into Test-Driven Development - 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.

Answer 11

It 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:

• Check library calls return values, don't silently ignore errors.
• Learn how to split your code into multiple files and group it by function.
• Don't write huge, bulky functions. Split up your stuff until each and every function is reasonably small and easy to understand. If you're having difficulties understanding code 15 minutes after you wrote it, it's bad code.
• Don't intertwine unrelated code and don't copy & paste all over the place. Try to reuse code.
• Pay attention to small details, like indenting and formatting the code.
• Make interfaces sufficiently generic and don't give in to ugly hacks or quick solutions, unless you're really, really in a hurry. Let there be a little flexibility.
• Try to plan what you're about to do ahead of time. With experience, you should be able to work independently on different parts even when dependencies haven't been written yet.
• Try to mimic how professional developers write good code, especially those from the open-source world. It may seem like overkill to you, but it is probably easier to write more lines of code than chasing strange bugs.

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.

Answer 12

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.

Answer 13

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.

Answer 14

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.

Answer 15

It would be better if you gave some examples of stupid mistakes, but still I have some suggestions:

• Read Code Complete and Object Oriented Software Construction, 2nd Edition. You have more complete suggestions of (mostly) language-neutral books here, here and here.
• Do code reviews systematically.
• Use Design by Contract.
• Write some unit tests for your classes.
• By the way, write everything in classes (in OO languages).
• Keep track of your mistakes (not every mistake, but those that escape your first verification, and hence become bugs). e.g. in an Excel file. Start adding columns such as "Cause" or a long, descriptive column "Preventive actions that would have avoided the problem or spotted it much earlier". This can actually be a personal bug tracking system.
• It's useful to use a source control system.
• Learn that mistakes are part of being human. I make mistakes, you make mistakes, we make mistakes. That's why we invent processes to spot them, fix them and minimize their impact. We test, we write assumptions in code (Design by Contract), etc.
• Don't do "just enough", try to do it really well. Be as clear as you can. e.g. Your question title begins with a lowercase, which is not standard; it would be better understood if it was a full sentence; etc. Fixing this costs nothing and makes your "code" easier to understand for those who come later and read it. Code as if someone else was going to continue your work.

Answer 16

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 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

Answer 17

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.

Answer 18

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.

Answer 19

Everyone 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 ;)

Answer 20

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 :) .

Answer 21

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.

Answer 22

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.

Answer 23

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:

• Have a plan. Before you even write any code, think about what you need to do and how you're going to accomplish it. Identify the major steps in your solution and then figure out what needs to be done first.
• Start simple. Get basic things working and then add additional functionality.
• Work in small steps. Write your code in little pieces, and test each piece as you go. Don't write code for everything and then try to make it all work or you'll need Hair Club for Men in no time.
• Fix problems, not symptoms. Always identify the cause of an issue before you try to fix it. Use your debugger, comment out code, or change conditions until you know exactly where the problem originates. Don't "fix" the behavior by fudging the code where the problem manifests.

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.

Answer 24

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...

Answer 25

You should try pair programming if you have the chance. Another pair of eyes too look after you would make a real difference.

Answer 26

Nobody'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.

Answer 27

Lots 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.

Answer 28

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!

Answer 29

• 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 ! :-)

Answer 30

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".

Answer 31

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 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.

Answer 32

What 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 ;)

Answer 33

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:

1. Write Unit Test Cases
2. Proper naming convention
3. Peer review and feedback
4. Maintaining code in source control
5. Versioning
6. Think about performance from the start, instead of thinking about it in the later stages of SDLC.
7. Follow consisted coding patterns
8. DO NOT COPY PASTE CODE FROM THE NET.
9. Most important of all, be self-critical and be open to new ideas.

Answer 34

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.

Answer 35

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 :)

Answer 36

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.

Answer 37

The Software Engineering Institute has a methodology to help you become a better developer. It's Called PSP: 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.

Answer 38

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:

1. State explicitly (write down) the assumptions I have about why the code is behaving the way it is. (e.g., I know that function foo succeeds, I think it fails somewhere in function bar).
2. Test these assumptions in the most simplified way possible.

The second step also takes experience in learning how to simplify your code and inputs so that you're testing only the particular assumption.

Answer 39

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.

Answer 40

I've felt the same way. Just stick in there, keep pounding away at the code and eventually it gets easier.