|
supernorb wrote: I have learned programming for 2 years,
I've been programming professionally for 27 years and learn something new almost every day. The day I stop learning will be when it's probably time for me to hang it up. My advice to you is just keep at it. In time, you'll notice yourself making fewer mistakes - at least not the common ones. I'm glad you love programming despite the difficulties you've encountered. I've never met a really good developer who doesn't absolutely love what they do.
Good luck! 
/ravi
|
|
|
|
|
supernorb wrote: The reason is I always make a lot of errors and bugs when programming and spend too much time searching and debugging before realizing those bugs are not too complex even some are very simple
Welcome to the world of programming - I still make errors after almost 30 years of programming(and I hasten to add everyone else I know who has been programming as long does too).
In fact finding an error is good - because when you find an error in code, and fix it, it means that you have one less unknown error in your code(I genuinely mean this and hope I am not coming across in some pop psychology BS manner here...).
supernorb wrote: I really love programming but that seems not to be enough.
It is enough because it will give you the determination and patience to keep with it - I consider programming to be more of an art form than a cold mechanical instruction building toolkit.
My advice - don't give up, keep going
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Coming here is a good first step.
One of the best things you can do is find someone to work with who can be a mentor to you. Ask them questions. When you don't understand the answers, and you won't a lot of the time, ask more questions. Compare the code your mentor writes to what you write. Figure out why it's different. If you think you have a better solution to a problem, ask them about it.
When something doesn't work, figure out why and remember it. When something works well, figure out why and remember it as well.
There are two qualities I associate with good programmers: perseverence and attention to detail.
Perseverence means you keep at a problem until it's solved. It also means knowing when and how to ask for help when you are well and truly stuck.
I've known some smart people, working as programmers, who were awful at it for one simple reason: they didn't pay attention. In our business, a single misplaced comma can mean the difference between a project that works, and one that is a miserable failure. Attention to details means keeping your code cleaned up. If you start down a bad path and change your mind, don't just comment the stuff out. Remove it and clean things up before you continue. Initialize your variables. Keep your comments up to date. Always assume a complete stranger will be the next person to read your code, and comment it accordingly.
Trust me, there's nothing stranger than the person you'll be a year from now.
Software Zen: delete this;
|
|
|
|
|
Gary R. Wheeler wrote: Always assume a complete stranger will be the next person to read your code, and comment it accordingly.
/ravi
|
|
|
|
|
supernorb wrote: If some one looks and feels my own application
Perhaps you are trying too hard. Go for something simpler, like Polish programming. In, out, repeat as necessary. Very simple. Two methods and a loop.
Marc
|
|
|
|
|
supernorb wrote: I always make a lot of errors and bugs when programming and spend too much time searching and debugging
At one level or another what you describe is what "experienced" developers do all day. Make mistakes and fix them, repeat until you have a usable product.
With that in mind the keys to becoming a good programmer are:
1. Learn from your mistakes so you don't keeping making the same mistakes over and over
2. Learn the best ways to debug so you can find and fix your mistakes
3. Learn how to tell if you're progressing on a problem, or need help
4. Learn how to use google effectively to find others who have been stuck in the same place you are and how they got past that point.
5. Learn how to phrase a programming question in a way that more experienced programmers can understand the problem so they can help you. (both online and in person)
Notice the common theme in that list?
I know I was a fairly horrible programmer when I was 2 years into my career, and I would guess most people here were too.
|
|
|
|
|
Dear friend,
I believe it is all about your style and habits. its always better to make the whole system make error proof before implementing through testing. The main thing is your system design & your methods to develop it. Priliminary stages you have to go through lot of searching & corrections. still as you will become experienced it will become less. No one can start developing softwares with 100% knowledge about working tools.
Sujith Kumar
Sujith Kumar K
00965-65030329
|
|
|
|
|
My first programming job was 1 1/2 years long before I moved to another company. About 3 years later my first boss asked me to do one more system for him. When I returned, on a part time basis, I looked over what I had done in that first 1 1/2 years. A couple of the things I had done were brilliant, but most of my previous work was only adequate at best. Was was really the best part of going back and seeing my old work was realizing that I had learned enough in the three years after I left that I could tell what was "brilliant" and what wasn't. This will happen for you too as you continue in this business. And secondly, I have always been "slow" in EVERYTHING I do. When I was still in college, I worked as a carpenter. I was the slowest one in the shop, but when something out of the normal needed to be done, the boss always put me on it because, in his words, he knew I would do it best. I still love this field of work, and I've been at it, including my time in classes during college, for 41 years. You have the right attitude in "I'll never give up!" I'm really glad to have you in our field of endeavor.
|
|
|
|
|
Sure you can. And don't think that being a good programmer means you will never have errors. Even the best still run into issues where they forget to declare a variable or even just forget a ; at the end of a line or a } at the end of a method or a ) after a call.
Two years isn't that long and it is best to get some real world programming in (make your own applications at home that you could benefit from using on a daily or weekly basis). I am making a movie DB and i know that others before me have one that i could buy or even get for free.. but I like working on it on the side as it gives me something to do and a feeling of accomplishment.
|
|
|
|
|
The fact that you're enjoying it is going to go a LONG way in helping you to persevere through the learning curves you will inevitably climb.
Let programming always be fun. If it stops being fun then you're taking it too seriously. I've been at this for over 35 years and I still get a kick out of writing simple applications to automate things I need automated. BTW ... you don't have to always be working on something "big". I'm at a phase in my career where most of my work is maintenance on a system I've developed over 13 years, so I'm not real busy in my main job at the moment. So, to keep my skills sharp I develop software for my own use.
Also: don't let the state of the technology intimidate you into thinking you have to be able to duplicate some of the more sophisticated applications you might be seeing. Super-sophisticated applications are the results of large team efforts. Allow yourself to enjoy developing relatively simple things that you can assemble over time into more complex works. You will amaze yourself at what you piece together over the years. It's even OK to "re-invent" the wheel as a programmer if you want to. I'm constantly adding functionality to my libraries that is either missing in the frameworks or isn't implemented the way I like it. 
I'm glad to see the encouragement the rest of the group is giving you here. They're right. Stick with it, keep having fun and keep learning.
-Max 
|
|
|
|
|
You seem to be very determined to be better. That'd help. My advice: before you write any program think about the underlying algorithm thoroughly. If needed, use paper and pencil to try out your algorithm on some specific examples related to the problem.
The more effective your algorithm is and the more you understand what your code does , the less time you'd spend debugging....
|
|
|
|
|
|
Quit making the same mistakes, over and over. Just think about it while you are doing it. Ask yourself, "am I making a dumb mistake?", and if a little voice inside your head says, "Yes!", then don't do it. Other than that, you're way, way ahead of the curve. You have placed your ego in exactly the right spot, that being well behind you and out of the way, so all you have to do from this moment forward is STOP making the same mistakes over and over!! LOL!! .... been there, done that!!
|
|
|
|
|
Nearly, i have the same experience in programming. I have the same problem in the very beginning stage. What i have done is, when ever i have encountered a problem / bug i just note down that reason for the problem/bug and simple solution in a simple text file, or in a flash card for more visual attraction. On the next time before i started to implement/design an application i have just open those saved files to have a quick look on my previous mistakes. In this way, my bugs are reduced in a very short time.
|
|
|
|
|
Hi,
you told, you will never give up which is very good.
Here small home work is required: sit at home some peaceful place and start thinking what mistakes you did and how you over come it.
By this homework next time automatically it will reduce your mistakes and have patience
Practice it, it will definitely help you
Thanks and regards,
Ajay K N
|
|
|
|
|
You are in a bad situation, if you don't have a mentor. You should look for one - but be very careful, it's easy to learn programming the bad way.
Other than that, my advice is to learn two things: how to design apps so that errors are difficult to introduce, and how to debug effectively. If you write programs so that introducing bugs is difficult, you'll have less bugs to debug. If you know how to debug effectively, you'll spend less time doing so.
While I can't help you directly, I think it's useful to read a few books. One which is IMO essential, but not so popular among programmers: Why Programs Fail. This should, to some extent, compensate for you not having somebody to _teach_ you debugging - which is an essential skill, IMO. Code Complete is a basic book, but very useful for beginners - your two years experience still qualify as "beginner", IMO. In the same category, but a tiny bit smarter, is IMO Writing Solid Code. You should go on with Riel's OO design heuristics (I liked the first edition more), the GoF's design patterns - here you can choose, as there are newer books covering more patterns, but that book has an extremely useful introductory section, from which you'll understand why patterns are useful and how you should use them. Once you have read an understood that part of the book, you can drop it, and start looking up patterns on the web. Another essential book, IMO, is Fowler's Refactoring - again, not necessarily for the refactorings themselves, since most decent IDEs these days have built in support for many refactorings, which you can easily combine to produce the more complex ones, but because of the code smells section.
And of course, you should get a solid foundation in algorithms and data structures. MIT's Open Courseware is a good starting point, you can also learn a lot simply by reading the articles on this topic from Wikipedia. There's also an older book, Structure and Interpretation of Computer Programs, used as a textbook at MIT, which, while apparently not so useful for people using more mainstream languages, is very good reading for a better understanding of programming, thus indirectly helping you getting a better understanding of the algorithms and data structures.
|
|
|
|
|
So ... I've got about 24 years experience as a developer ... like you perhaps, I was isolated from other developers early in my career so I had to learn how to be a developer because they just don't teach you the real skills you'll need in college.
Its going to be ~5 years into your career before you start becoming a good developer. Practice does make perfect, so don't worry that it takes you a long to time to complete your work. Just make sure that it is of the highest quality you can make it.
Now some practical and specific advice:
In the early days of my career, these are the things I did:
1) I learnt to copy type to RSA and Pitmans 1 standard (30 wpm). Trust me, it makes a huge difference when you can rattle out your code as fast as you can think it. BTW, generating documentation was what drove me to learn how to type properly. I was having to write design documents and user guides and the company copy typists were hopeless!
2) I read "Structured Design" by Yourdon and Constantine. A very informative book that will introduce some very important concepts. You will want to supplement this with more modern books on object orientated design e.g. Head First Design Patterns and Head First Object Oriented Design.
3) I was meticulous with my design process. I spent a long time making sure I did Specifications, Input/Output charts, Process Charts, P-Code and P-Code dry runs before I even started coding. The process helped me think through the problems and issues so that when I did code, it was more of a typing exercise. I found following the process dramatically reduced the errors I was producing. Over time you'll gain confidence and know when you'll need to go through the design process and when you can work on the fly i.e. from your accumulated experience.
4) I found it easier to break up a large task into a sequence of smaller tasks which would later integrate or join together. I would try to organize each smaller task into a one week work unit where I would be designing Mon-Wed, Coding on Wed/Thu and Testing on Thu/Fri. Then once all my parts where ready, I would spend a week integrating them testing and debugging until it all worked. Does the method sound familiar? Agile was a long way off at the start of my career, but what I was doing back then is strangely similar.
So now after all these years I'll give you some practical tips:
1) If your doing things correctly roughly speaking the time you spend on designing, implementing and testing is 30%/20%/40% with the odd 10% on sundry activities. It is important to understand that testing time is roughly double implementation time. Incidently design and testing time are first to get squeezed on software projects, but implementation time is the rock that can't be moved. The code has to be written or there is no system and now you have a good measure as to why many software projects fail.
2) When debugging, whether in a debugger or using some sort of logging/tracing (to file or console) the important things are: Function entry points and the values of the input parameters, function exit points and the values of return parameters, the initial state of variables and when variables change value. When creating debugging output - tracing - this is your minimum detail required to help you track down and detect faults. As you hone in on the problem you may put more tracing in to further clarify execution paths and looping.
3) To understand how unfamiliar software works, first understand how the data is structured before you try to understand the algorithms that operate on the data.
4) The hardest thing to do will be to get two programs to talk to each other properly. Correctly defining and testing your interfaces (the boundaries between parts of a system, sub-system, program or whatever) are paramount. Never ever skip this part of your design.
5) The best and IMHO the only objective measure of software quality will be the faults database. Every project will have one and could be an elaborate online database like JIRA, or a simple spreadsheet. A faults database can be called many things: Issues, Bugs, Faults, Errors etc Sometimes change requests and feature enhancements are included. Sometimes not, but for the purpose of this discussion it is all the same. Lots of faults and change requests pending on your software = low quality. Few = better quality. None = quality, but I'd be surprise to see a project with no pending faults or CRs. So, always strive to keep your open faults at an absolute minimum.
Hope this helps.
|
|
|
|
|
But it's a holiday, and we have a spammer in Q/A and programming forums that needs to be reported so that his account gets auto-removed.
http://www.codeproject.com/script/Membership/View.aspx?mid=8515735[^]
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
Reported his account & also all messages by him.
|
|
|
|
|
Ditto, but given the holidays (and the assumed lack of CP staff in attendance), we need people that normally don't get the opportunity to help out.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
A few more and... bye bye
|
|
|
|
|
Reported as spammer 
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
|
|
Here's an addition to your attempts at making all of your 5-a-day alcoholic. Recipe[^].
If I remember, I might have a go at this next year.
Henry Minute
Do not read medical books! You could die of a misprint. - Mark Twain
Girl: (staring) "Why do you need an icy cucumber?"
“I want to report a fraud. The government is lying to us all.”
I wouldn't let CG touch my Abacus!
When you're wrestling a gorilla, you don't stop when you're tired, you stop when the gorilla is.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
