I've taught basic and intermediate programming to students and co-workers, and one recurring behavior is that people often forget the debugger is there to help. Be careful with endless trials and errors when troubleshooting bugs in your code, but instead take some time, debug it and understand the flow it's taking and where are the gaps.
Is programming a job or a career for you?
It will take a while for you to figure this out, but will help you realize where do you want/need to put your focus on. If you really enjoy and want to improve your programming skills, do not rely solely on what your job has to offer you challenge-wise. Study and practice on your own, keep reading about what are the current trends and why, and if you're up to, build some side projects.
Refactor always
On the first few years of your career, you will often join teams that are rebuilding something, often a redesign of an old, legacy system. Your new system is cool and shiny, and everyone loves it. After a while, in exchange of productivity, people might start taking shortcuts to deliver things faster; New members might be assigned tasks which they have no idea where to start and will deliver code outside your standards; Also, if you have plenty of unit tests, which are there to help, you might be intimidated when you think about refactoring something that's there for a while, and heavily tested: if you refactor that, you'll have to review/rewrite so many tests! After a while - usually after the team changed so much it has no faces from the original team, they realize that - ta-da! - they got a new legacy system, and the cycle repeats. To an extent, much of this could've been avoided if the team was committed to quality and were not afraid of refactoring code. Well-written, flexible and secure code can accommodate design changes and be submitted to new business needs.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Debug your code
I've taught basic and intermediate programming to students and co-workers, and one recurring behavior is that people often forget the debugger is there to help. Be careful with endless trials and errors when troubleshooting bugs in your code, but instead take some time, debug it and understand the flow it's taking and where are the gaps.
Is programming a job or a career for you?
It will take a while for you to figure this out, but will help you realize where do you want/need to put your focus on. If you really enjoy and want to improve your programming skills, do not rely solely on what your job has to offer you challenge-wise. Study and practice on your own, keep reading about what are the current trends and why, and if you're up to, build some side projects.
Refactor always
On the first few years of your career, you will often join teams that are rebuilding something, often a redesign of an old, legacy system. Your new system is cool and shiny, and everyone loves it. After a while, in exchange of productivity, people might start taking shortcuts to deliver things faster; New members might be assigned tasks which they have no idea where to start and will deliver code outside your standards; Also, if you have plenty of unit tests, which are there to help, you might be intimidated when you think about refactoring something that's there for a while, and heavily tested: if you refactor that, you'll have to review/rewrite so many tests! After a while - usually after the team changed so much it has no faces from the original team, they realize that - ta-da! - they got a new legacy system, and the cycle repeats. To an extent, much of this could've been avoided if the team was committed to quality and were not afraid of refactoring code. Well-written, flexible and secure code can accommodate design changes and be submitted to new business needs.