Being a rock star programmer
-
I think it can certainly help to study good code written by others, especially good code written by someone who's "better" than you. But understanding the code and the whys and wherefores is of vital importance too. Is it the only tip you need. No I don't think so. Lots of practice and lots of learning from your own mistakes and those of others is equally important. I mean, how did the first "expert" programmer get that way? Certainly not by reading someone else's expert code. ---sig---
Might I suggest that the universe was always the size of the cosmos. It is just that at one point the cosmos was the size of a marble. -- Colin Angus Mackay Silence is the voice of complicity PS. If you don't understand my sarcasm -- go to hell!Agreed: well put. I learnt a lot from working in an environment where I had to produce rapid solutions to problems under pressure. You sink or swim pretty quickly. www.merrens.com
www.bkmrx.com You can ignore relatives but the neighbours live next door -
The best way to improve is to study code that is better than your own. Read good code written by experts, in a variety of programming languages. Study it until you understand how it works and what makes it good. That's it.
The One Tip That Rules Them All[^] The IronMonkey claims that the one tip to being a better programmer is the above. To read good code. Anyone care to agree or disagree? (And you can skip his waffle at the begining of the post.) regards, Paul Watson Ireland Feed Henry! K(arl) wrote: oh, and BTW, CHRISTIAN ISN'T A PARADOX, HE IS A TASMANIAN!
adapted from toxcct:
while (!enough)
sprintf 0 || 1
doI agree. Way back in my first programming class one of the first things they told us was, "You will only get better at programming by studying and writing good code." Note they did say WRITING good code as well, not just STUDYING it. Back then there were professors telling us what was "good code" and now it's more of a judgement call but I think it's still relevant. I still try to read some type of reference book every now and then to make sure I'm still up on new techniques. ------------------------------------- Do not do what has already been done. Absolute power corrupts absolutely.. but it ROCKS absolutely, too.
-
The best way to improve is to study code that is better than your own. Read good code written by experts, in a variety of programming languages. Study it until you understand how it works and what makes it good. That's it.
The One Tip That Rules Them All[^] The IronMonkey claims that the one tip to being a better programmer is the above. To read good code. Anyone care to agree or disagree? (And you can skip his waffle at the begining of the post.) regards, Paul Watson Ireland Feed Henry! K(arl) wrote: oh, and BTW, CHRISTIAN ISN'T A PARADOX, HE IS A TASMANIAN!
adapted from toxcct:
while (!enough)
sprintf 0 || 1
doUnderstanding how other's code works by reading is great, but until you've screwed up trying to implement it, you still won't really grok it. One of my professors always had the acronym, ABP, on his board. Always Be Programming he'd say ad nauseum. I rolled my eyes at the time, but it was good advice. BW
If you're not part of the solution, you're part of the precipitate.
-- Steven Wright -
Surely your testing system is not working well if you can't test your refactoring? I know pretty quickly when some code I refactored has broken the existing logic thanks to tests. (Obviously performance testing is a whole different ball game.) regards, Paul Watson Ireland Feed Henry! K(arl) wrote: oh, and BTW, CHRISTIAN ISN'T A PARADOX, HE IS A TASMANIAN!
adapted from toxcct:
while (!enough)
sprintf 0 || 1
doThis mainly comes down to load tests (100%, for 24 hours a day, for 2 weeks) e.g. memory leaks. Its the reproduction of the fault that is the pain, see potential problem, fix, rerun test and wait a week to see if it worked. At the minute we've had 2 customer faults reported in 2 months which was unheard of last year (or ever). It's stable & performant so STAY AWAY. We spent a full year getting to this stage so we're not going to muck it up now. Sure, things can be done differently, better but is it worth the possible fallout from a customer (think big CDMA/UMTS mobile network providers) if a fault does slip through (and they do). Imp. 'Out of Office Auto Reply' The email server is unable to verify your server connection and is unable to deliver this mesage. Please restart your computer and try sending again. '(The beauty of this is that when you return, you can see how many in-du-viduals did this over and over).
-
Understanding how other's code works by reading is great, but until you've screwed up trying to implement it, you still won't really grok it. One of my professors always had the acronym, ABP, on his board. Always Be Programming he'd say ad nauseum. I rolled my eyes at the time, but it was good advice. BW
If you're not part of the solution, you're part of the precipitate.
-- Steven Wrightbrianwelsch wrote:
ABP
Is that like ABC on Glengarry Glen Ross? ;P ------------------------------------- Do not do what has already been done. Absolute power corrupts absolutely.. but it ROCKS absolutely, too.
-
This mainly comes down to load tests (100%, for 24 hours a day, for 2 weeks) e.g. memory leaks. Its the reproduction of the fault that is the pain, see potential problem, fix, rerun test and wait a week to see if it worked. At the minute we've had 2 customer faults reported in 2 months which was unheard of last year (or ever). It's stable & performant so STAY AWAY. We spent a full year getting to this stage so we're not going to muck it up now. Sure, things can be done differently, better but is it worth the possible fallout from a customer (think big CDMA/UMTS mobile network providers) if a fault does slip through (and they do). Imp. 'Out of Office Auto Reply' The email server is unable to verify your server connection and is unable to deliver this mesage. Please restart your computer and try sending again. '(The beauty of this is that when you return, you can see how many in-du-viduals did this over and over).
Was the code that works your first draft or have you rehashed it a few times? And the code as it is now, are you happy with it in other terms apart from "it works"? regards, Paul Watson Ireland Feed Henry! K(arl) wrote: oh, and BTW, CHRISTIAN ISN'T A PARADOX, HE IS A TASMANIAN!
adapted from toxcct:
while (!enough)
sprintf 0 || 1
do -
brianwelsch wrote:
ABP
Is that like ABC on Glengarry Glen Ross? ;P ------------------------------------- Do not do what has already been done. Absolute power corrupts absolutely.. but it ROCKS absolutely, too.
Nicholas Wigant wrote:
Glengarry Glen Ross
Don't think I've ever seen that movie. Helluva a cast, though. I might have to check that out this weekend. BW
If you're not part of the solution, you're part of the precipitate.
-- Steven Wright -
Nicholas Wigant wrote:
Glengarry Glen Ross
Don't think I've ever seen that movie. Helluva a cast, though. I might have to check that out this weekend. BW
If you're not part of the solution, you're part of the precipitate.
-- Steven WrightABC, Always Be Closing... ------------------------------------- Do not do what has already been done. Absolute power corrupts absolutely.. but it ROCKS absolutely, too.
-
Was the code that works your first draft or have you rehashed it a few times? And the code as it is now, are you happy with it in other terms apart from "it works"? regards, Paul Watson Ireland Feed Henry! K(arl) wrote: oh, and BTW, CHRISTIAN ISN'T A PARADOX, HE IS A TASMANIAN!
adapted from toxcct:
while (!enough)
sprintf 0 || 1
doGet this (sorta shows were I'm comming from) > 10 years ago a prototype was done. > Mgt gave the project the go ahead > The prototype was used as the base implementation :confused: (this is where all the problems stem from) All this was done in another unit of our company, at the time were were application using these services. Last year we transfered this service over here (we now 'own' it), fixed all outstanding bugs, changed a few things for better performance and left it at that. It works so I'm happy (mgt not bugging us, no news is good news) the code is a mess, complete shit, completely over engineered, a nightmare to trace through, maintenance is a pain in the ass. This is why we are rewriting the application. Prototyped it, searious code reduction, performance increase, got the go ahead and currently implementing The prototype is only being used as a reference for the methodoligy behind the use cases and nothing else. Imp. 'Out of Office Auto Reply' The email server is unable to verify your server connection and is unable to deliver this mesage. Please restart your computer and try sending again. '(The beauty of this is that when you return, you can see how many in-du-viduals did this over and over).
-
The best way to improve is to study code that is better than your own. Read good code written by experts, in a variety of programming languages. Study it until you understand how it works and what makes it good. That's it.
The One Tip That Rules Them All[^] The IronMonkey claims that the one tip to being a better programmer is the above. To read good code. Anyone care to agree or disagree? (And you can skip his waffle at the begining of the post.) regards, Paul Watson Ireland Feed Henry! K(arl) wrote: oh, and BTW, CHRISTIAN ISN'T A PARADOX, HE IS A TASMANIAN!
adapted from toxcct:
while (!enough)
sprintf 0 || 1
doReading good code of guru's has certainly been a boon to me. I would add the qualification though, that it has served me best when I have spent some time working in the problem domain for a period of time myself. Once I have some experience trying to tackle a problem, seeing truly elegant, efficient solutions really helps boost me to a new level. My two cents... Dan Remember kids, we're trained professionals.
Don't try this at home! -
ABC, Always Be Closing... ------------------------------------- Do not do what has already been done. Absolute power corrupts absolutely.. but it ROCKS absolutely, too.
Sounds like a financial saying. regards, Paul Watson Ireland Feed Henry! K(arl) wrote: oh, and BTW, CHRISTIAN ISN'T A PARADOX, HE IS A TASMANIAN!
adapted from toxcct:
while (!enough)
sprintf 0 || 1
do -
Reading good code of guru's has certainly been a boon to me. I would add the qualification though, that it has served me best when I have spent some time working in the problem domain for a period of time myself. Once I have some experience trying to tackle a problem, seeing truly elegant, efficient solutions really helps boost me to a new level. My two cents... Dan Remember kids, we're trained professionals.
Don't try this at home!I absolutely agree that you have to be in the problem domain to get the most benefit. Once you can map the code you are reading to a mental concept it falls into place. regards, Paul Watson Ireland Feed Henry! K(arl) wrote: oh, and BTW, CHRISTIAN ISN'T A PARADOX, HE IS A TASMANIAN!
adapted from toxcct:
while (!enough)
sprintf 0 || 1
do -
ABC, Always Be Closing... ------------------------------------- Do not do what has already been done. Absolute power corrupts absolutely.. but it ROCKS absolutely, too.
NBC = Nothing But Crap ABC = Anything But Cool CBS = Constantly Broadcasting Shit (I just made that one up) Jeremy Falcon
-
Sounds like a financial saying. regards, Paul Watson Ireland Feed Henry! K(arl) wrote: oh, and BTW, CHRISTIAN ISN'T A PARADOX, HE IS A TASMANIAN!
adapted from toxcct:
while (!enough)
sprintf 0 || 1
doSales saying. Closing the deal. ------------------------------------- Do not do what has already been done. Absolute power corrupts absolutely.. but it ROCKS absolutely, too.
-
The best way to improve is to study code that is better than your own. Read good code written by experts, in a variety of programming languages. Study it until you understand how it works and what makes it good. That's it.
The One Tip That Rules Them All[^] The IronMonkey claims that the one tip to being a better programmer is the above. To read good code. Anyone care to agree or disagree? (And you can skip his waffle at the begining of the post.) regards, Paul Watson Ireland Feed Henry! K(arl) wrote: oh, and BTW, CHRISTIAN ISN'T A PARADOX, HE IS A TASMANIAN!
adapted from toxcct:
while (!enough)
sprintf 0 || 1
doI would add that to be a better programmer would be to write better code than your last project... My Programming Library /* You are not expected to understand this */
-
Write an article and submit it on CP :-D
C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg
:laugh::laugh::laugh: My Programming Library /* You are not expected to understand this */
-
ihoecken wrote:
But there is more than reading code.
If you re-read the original post, you will see that it does not say that reading code is the ONLY way. It says that reading code is the best way.
Yes I read it. But when it says "reading code is the best way" then I think I just have to read good code, analyse it and then start it for myself. But there is more to do. You can easy learn programming without reading good code, but you the most can't easy learn programming just with reading good code. So, I say: this isn't the best way! Greetings, Ingo ------------------------------ PROST Roleplaying Game War doesn't determine who's right. War determines who's left.
-
The best way to improve is to study code that is better than your own. Read good code written by experts, in a variety of programming languages. Study it until you understand how it works and what makes it good. That's it.
The One Tip That Rules Them All[^] The IronMonkey claims that the one tip to being a better programmer is the above. To read good code. Anyone care to agree or disagree? (And you can skip his waffle at the begining of the post.) regards, Paul Watson Ireland Feed Henry! K(arl) wrote: oh, and BTW, CHRISTIAN ISN'T A PARADOX, HE IS A TASMANIAN!
adapted from toxcct:
while (!enough)
sprintf 0 || 1
doDo what I did today: I managed to have a C++ destructor recursively call itself. This Is A Bad Thing. :sigh:
Software Zen:
delete this; -
The best way to improve is to study code that is better than your own. Read good code written by experts, in a variety of programming languages. Study it until you understand how it works and what makes it good. That's it.
The One Tip That Rules Them All[^] The IronMonkey claims that the one tip to being a better programmer is the above. To read good code. Anyone care to agree or disagree? (And you can skip his waffle at the begining of the post.) regards, Paul Watson Ireland Feed Henry! K(arl) wrote: oh, and BTW, CHRISTIAN ISN'T A PARADOX, HE IS A TASMANIAN!
adapted from toxcct:
while (!enough)
sprintf 0 || 1
doWhat are we talking about, coding, programming or software engineering? And what are they? And how do you measure them? Coding: The act of writing code. What is good and bad code? Good layout? Efficient use of stack or heap regarding variable declaration? Good choice of variable and function names so the code reads well? Or speed? Refining an algorithm to perfection? Developing good, logical algorithm? Or is it writing maintenable code? Programming: Is it the same as coding? Is it understanding the platform? Software engineering: Designing the architecture? Modularising the code into logical, reusable chunks? All well and good, but if the customer doesnt like it it is all wasted efort. Getting the product out on time at the right quality and the right price is the only criteria. Nunc est bibendum
-
Do what I did today: I managed to have a C++ destructor recursively call itself. This Is A Bad Thing. :sigh:
Software Zen:
delete this;Quite appropriate to your sig then. Trying to think of an instance, already destructed, that is meant to call it's own destructor... regards, Paul Watson Ireland Feed Henry! K(arl) wrote: oh, and BTW, CHRISTIAN ISN'T A PARADOX, HE IS A TASMANIAN!
adapted from toxcct:
while (!enough)
sprintf 0 || 1
do
