How to become a better programmer(codelathe.com)
codelathe.com
How to become a better programmer
http://www.codelathe.com/blog/index.php/2009/04/07/5-sure-fire-ways-to-become-better-at-programming/
5 comments
I agree with you. Usually when you work with great programmers, you will be exposed to great code as well.
But sometimes, I have also seen that even when exposed to great code, it might not be evident to someone that it is truly great, without the accompanying commentary by a programmer on why it is great.
But sometimes, I have also seen that even when exposed to great code, it might not be evident to someone that it is truly great, without the accompanying commentary by a programmer on why it is great.
i agree, i learn a lot from tweaking, rewriting, debugging and adapting source codes to my projects; however, reinventing the wheel (w/o seeing others' solutions) actually pushes me harder
So what if you are the only person in your location? I live in one state and all of our developers are in another.
Right now I do reporting (sql, vbscript and perl). I want to get in to database administration and C#. I am starting on my own, but there is nobody here to consult with or learn from. Am I lost?
Right now I do reporting (sql, vbscript and perl). I want to get in to database administration and C#. I am starting on my own, but there is nobody here to consult with or learn from. Am I lost?
I think the fact that you are motivated to learn by yourself counts a bit. If you have passion, you can make up for other stuff.
The other way is maybe to get into open source dev. You will interact with a lot of folks.
The other way is maybe to get into open source dev. You will interact with a lot of folks.
Also, physical location doesn't matter that much. See if you can hold code reviews, look at other people's code, talk to other respected developers in your team. That will help.
I would add...
"Work in a shop that QA's the source code by people who know what they're doing." This would be in addition to User Acceptance Testing.
The first program I submitted in a shop like this was rejected for 38 reasons. Some were shop standards, but many requirements where I thought "I knew better". I didn't. And I've been a much better programmer ever since.
"Work in a shop that QA's the source code by people who know what they're doing." This would be in addition to User Acceptance Testing.
The first program I submitted in a shop like this was rejected for 38 reasons. Some were shop standards, but many requirements where I thought "I knew better". I didn't. And I've been a much better programmer ever since.
In addition I would say, work where your code actually gets code reviewed. (is that a dying practice?) You will write better code.
This is a disaster if the senior programmers are less skilled than the junior programmers. It happens a lot in big corporations. "You have more than one return statement! Go change that."
Of course if you work in a shop like that, it's advisable to leave. And I did.
Of course if you work in a shop like that, it's advisable to leave. And I did.
One situation I was even worse; the "senior" programmers were actually juniors with nearly no experience, but who had office politics (i.e. nepotism -- one was the CTO's son) on their side.
Needless to say, the company didn't go far.
Needless to say, the company didn't go far.
I used to work where I would get skewered for misplacing the ; or about the formatting of my comments. After surviving that, I think I can survive anywhere.
You have more than one return statement! Go change that.
Yep, that's one of the 38 reasons for my original rejection. Violations of "single entry/single exit" were not promoted into production. I argued and lost. Now I'm glad I did.
Yep, that's one of the 38 reasons for my original rejection. Violations of "single entry/single exit" were not promoted into production. I argued and lost. Now I'm glad I did.
Just curious: Are you now a true believer in the "single exit always" doctrine (as well as whatever the other 37 rules were) or are you just saying that the benefits of enforcing discipline on the developers' output outweighed the disadvantages of having cargo-culted and dogmatic code standards?
I became a true believer once I got past my personal prejudices and actually made an attempt to understand "why" some rules were the way they were. I wasn't as smart as I thought. Still not.
Enforcing discipline for the sake of enforcing discipline? See military.
Enforcing discipline for the sake of enforcing discipline? See military.
Well, I would hope that if you follow the first step (work as an apprentice), it would get you in the habit of requesting code reviews, even when you've entered "the guild."
It's also worth noting that code reviews should be two-way streets--that is, more junior programmers should review more senior programmers' code, even if for nothing more than a learning experience.
It's also worth noting that code reviews should be two-way streets--that is, more junior programmers should review more senior programmers' code, even if for nothing more than a learning experience.
Code review meetings with projectors and so forth might be a dying practice (I wouldn't know), but there are tools like Code Collaborator that allow for asynchronous code reviews. CC seems to be widely used.
I agree, and I fear that it is in fact a dying practice.
code - refactor - code - refactor - sleep - code - refactor - code....
What about that practice of copy & paste good code?
copy & paste chunks of code is not necessary bad if you want to accomplish a specific task (for example, how to crop a square image, how to format date time into relative format, etc etc)
It will allow you to see if this chunk of codes work, and if it does, you can learn from it, improve it or give it back to others.
It will allow you to see if this chunk of codes work, and if it does, you can learn from it, improve it or give it back to others.
Some programmers out there can do a decent job with just copy & paste...like me :-)
I learnt a ton of stuff about programming when modifying the code of the linux kernel for an Operating Systems course. Fixing bugs in a huge code base requires inherent understanding of where things are in the code and how they are connected. And it's during that process that you gain an understanding of how to handle complex things : by making them simple.