Hoping to become a programmer
Pages: 12
closed account (z05DSL3A)
mikeb570,
I have recommended this to others and had positive feed back, the book Code Complete [1] is worth, at the very least, getting out of a library and reading.
[1]Synopsis
Widely considered one of the best practical guides to programming, Steve McConnell s original CODE COMPLETE has been helping developers write better software for more than a decade. Now this classic book has been fully updated and revised with leading-edge practices and hundreds of new code samples illustrating the art and science of software construction. Capturing the body of knowledge available from research, academia, and everyday commercial practice, McConnell synthesizes the most effective techniques and must-know principles into clear, pragmatic guidance. No matter what your experience level, development environment, or project size, this book will inform and stimulate your thinking and help you build the highest quality code.Discover the timeless techniques and strategies that help you: Design for minimum complexity and maximum creativity Reap the benefits of collaborative development Apply defensive programming techniques to reduce and flush out errors Exploit opportunities to refactor or evolve code, and do it safely Use construction practices that are right-weight for your project Debug problems quickly and effectively Resolve critical construction issues early and correctly Build quality into the beginning, middle, and end of your project.
I have recommended this to others and had positive feed back, the book Code Complete [1] is worth, at the very least, getting out of a library and reading.
[1]Synopsis
Widely considered one of the best practical guides to programming, Steve McConnell s original CODE COMPLETE has been helping developers write better software for more than a decade. Now this classic book has been fully updated and revised with leading-edge practices and hundreds of new code samples illustrating the art and science of software construction. Capturing the body of knowledge available from research, academia, and everyday commercial practice, McConnell synthesizes the most effective techniques and must-know principles into clear, pragmatic guidance. No matter what your experience level, development environment, or project size, this book will inform and stimulate your thinking and help you build the highest quality code.Discover the timeless techniques and strategies that help you: Design for minimum complexity and maximum creativity Reap the benefits of collaborative development Apply defensive programming techniques to reduce and flush out errors Exploit opportunities to refactor or evolve code, and do it safely Use construction practices that are right-weight for your project Debug problems quickly and effectively Resolve critical construction issues early and correctly Build quality into the beginning, middle, and end of your project.
Yeah, I'm jealous of both of ye. It's worth moving to New Zealand for it. :->
@mikeb570
I'm glad you're getting so much out of this thread.
@Grey Wolf
I had to laugh. Hardware and software engineers use many of the same words but don't speak the same language, don't they? (Besides which, you can't tell an engineer anything...)
/me runs away mischievously ;->
[edit] Ack! Too slow! (Again... *sniff*)
@mikeb570
I'm glad you're getting so much out of this thread.
@Grey Wolf
I had to laugh. Hardware and software engineers use many of the same words but don't speak the same language, don't they? (Besides which, you can't tell an engineer anything...)
/me runs away mischievously ;->
[edit] Ack! Too slow! (Again... *sniff*)
Last edited on
One of the problems with methodologies is that people pick one then try to use it rigidly in all circumstances as if it will be a 'silver bullet' to resolve problems from the past.
Which just doesn't work.
Most of the different methodologies have elements that can be applied to most projects, but not all, and when you factor in legacy code maintenance the degree of 'flexibility' you have to apply increases.
I am in a similar situation to Zaita & Grey Wolf - I am currently a team of 1 on the main project I work on - which means I have a good degree of flexibility in what I do, but have to do everything (from requirements through to final documentaion). I am in the fortunate position that my manager previously worked on the project, so I can always pick his brain if I have a problem or need a second opinion on an approach - and it also means I have a manager who understands SW development:-)
If only the project wasn't locked into Modula 2, Delphi 4 and MSDE 7.0...
Just seen Grey Wolf's recomendation of Code Complete. Completely agree, should be regarded as required reading IMHO.
Steve McConnal has written a number of other books which are also worth looking at including Code Complete 2 which is I belive an updated version of the original.
Which just doesn't work.
Most of the different methodologies have elements that can be applied to most projects, but not all, and when you factor in legacy code maintenance the degree of 'flexibility' you have to apply increases.
I am in a similar situation to Zaita & Grey Wolf - I am currently a team of 1 on the main project I work on - which means I have a good degree of flexibility in what I do, but have to do everything (from requirements through to final documentaion). I am in the fortunate position that my manager previously worked on the project, so I can always pick his brain if I have a problem or need a second opinion on an approach - and it also means I have a manager who understands SW development:-)
If only the project wasn't locked into Modula 2, Delphi 4 and MSDE 7.0...
Just seen Grey Wolf's recomendation of Code Complete. Completely agree, should be regarded as required reading IMHO.
Steve McConnal has written a number of other books which are also worth looking at including Code Complete 2 which is I belive an updated version of the original.
Last edited on
I'm having a little smile at the comments about Hardware and Software engineers. I've been in the 'only softy in a hardware world' before and it does sound nice from the outside and yes, the freedom to follow the methodology that best suits is nice. I found the downside to be the uphill struggle to get them to understand and be software 'aware'; fighting questions like "why do you need subversion running on a server, can't you run it on you desktop?" and "Why can't you just fix it now and give me a copy? That's what the last guy did." After a while it just grinds you down.
On the book front I found the Scott Meyers books to be really useful when I was first starting out with C++.
On the book front I found the Scott Meyers books to be really useful when I was first starting out with C++.
Heh heh heh...
I think the best way to answer such questions is to ask something in return, like "Why can't we just move all our servers to the other end of the building for tomorrow's presentaton?" and "Why can't I use my Commodore 64 disk drive with my Windows box to load all my old games?"
:-D
I think the best way to answer such questions is to ask something in return, like "Why can't we just move all our servers to the other end of the building for tomorrow's presentaton?" and "Why can't I use my Commodore 64 disk drive with my Windows box to load all my old games?"
:-D
There is probably an enjoyable 'lounge' thread in questions like these....
like how to make a hardware engineer scream....
"Sorry, but I knocked that tube with ESD written on it and all those little IC chip things fell on to the floor, but it's OK, I picked them up and put them back, I hope you don't mind?"
like how to make a hardware engineer scream....
"Sorry, but I knocked that tube with ESD written on it and all those little IC chip things fell on to the floor, but it's OK, I picked them up and put them back, I hope you don't mind?"
Last edited on
Don't forget to add that a few looked a little mucky so you rinsed them off under the tap...
closed account (z05DSL3A)
Top Ten Things Engineering School didn't Teach You
1. There are at least 10 types of capacitors.
2. Theory tells you how a circuit works, not why it does not work.
3. Not everything works according to the specs in the databook.
4. Anything practical you learn will be obsolete before you use it, except the complex math, which you will never use.
5. Engineering is like having an 8 a.m. class and a late afternoon lab every day for the rest of your life.
6. Overtime pay? What overtime pay?
7. Managers, not engineers, rule the world.
8. Always try to fix the hardware with software.
9. If you like junk food, caffeine and all-nighters, go into software.
10. Dilbert is not a comic strip, it's a documentary.
The Dictionary: what engineers say and what they mean by it
Major Technological Breakthrough
Back to the drawing board.
Developed after years of intensive research
It was discovered by accident.
The designs are well within allowable limits
We just made it, stretching a point or two.
Test results were extremely gratifying
It works, and are we surprised!
Customer satisfaction is believed assured
We are so far behind schedule that the customer was happy to get anything at all.
Close project coordination
We should have asked someone else; or, let's spread the responsibility for this.
Project slightly behind original schedule due to unforeseen difficulties
We are working on something else.
The design will be finalized in the next reporting period
We haven't started this job yet, but we've got to say something.
A number of different approaches are being tried
We don't know where we're going, but we're moving.
Extensive effort is being applied on a fresh approach to the problem
We just hired three new guys; we'll let them kick it around for a while.
Preliminary operational tests are inconclusive
The darn thing blew up when we threw the switch.
The entire concept will have to be abandoned
The only guy who understood the thing quit.
Modifications are underway to correct certain minor difficulties
We threw the whole thing out and are starting from scratch.
Essentially complete.
Half done.
We predict...
We hope to God!
Drawing release is lagging.
Not a single drawing exists.
Risk is high, but acceptable.
100 to 1 odds, or with 10 times the budget and 10 times the manpower, we may
have a 50/50 chance.
Serious, but not insurmountables, problems.
It will take a miracle. God should be the program manager.
Not well defined.
Nobody has thought about it.
Requires further analysis and management attention.
Totally out of control.
The project is designed for high availability.
Malfunctions will be blamed on the operators mistakes.
This project has low maintenance requirements.
We wouldn't let the technicians change a light bulb, much less fool around with our baby.
The software is being developed without excessive process overhead.
The documentation will be written in clear and lucid Chinese.
The delivery is scheduled for the last quater of next year.
This leaves us plenty of time to decide who to blame for it being late.
1. There are at least 10 types of capacitors.
2. Theory tells you how a circuit works, not why it does not work.
3. Not everything works according to the specs in the databook.
4. Anything practical you learn will be obsolete before you use it, except the complex math, which you will never use.
5. Engineering is like having an 8 a.m. class and a late afternoon lab every day for the rest of your life.
6. Overtime pay? What overtime pay?
7. Managers, not engineers, rule the world.
8. Always try to fix the hardware with software.
9. If you like junk food, caffeine and all-nighters, go into software.
10. Dilbert is not a comic strip, it's a documentary.
The Dictionary: what engineers say and what they mean by it
Major Technological Breakthrough
Back to the drawing board.
Developed after years of intensive research
It was discovered by accident.
The designs are well within allowable limits
We just made it, stretching a point or two.
Test results were extremely gratifying
It works, and are we surprised!
Customer satisfaction is believed assured
We are so far behind schedule that the customer was happy to get anything at all.
Close project coordination
We should have asked someone else; or, let's spread the responsibility for this.
Project slightly behind original schedule due to unforeseen difficulties
We are working on something else.
The design will be finalized in the next reporting period
We haven't started this job yet, but we've got to say something.
A number of different approaches are being tried
We don't know where we're going, but we're moving.
Extensive effort is being applied on a fresh approach to the problem
We just hired three new guys; we'll let them kick it around for a while.
Preliminary operational tests are inconclusive
The darn thing blew up when we threw the switch.
The entire concept will have to be abandoned
The only guy who understood the thing quit.
Modifications are underway to correct certain minor difficulties
We threw the whole thing out and are starting from scratch.
Essentially complete.
Half done.
We predict...
We hope to God!
Drawing release is lagging.
Not a single drawing exists.
Risk is high, but acceptable.
100 to 1 odds, or with 10 times the budget and 10 times the manpower, we may
have a 50/50 chance.
Serious, but not insurmountables, problems.
It will take a miracle. God should be the program manager.
Not well defined.
Nobody has thought about it.
Requires further analysis and management attention.
Totally out of control.
The project is designed for high availability.
Malfunctions will be blamed on the operators mistakes.
This project has low maintenance requirements.
We wouldn't let the technicians change a light bulb, much less fool around with our baby.
The software is being developed without excessive process overhead.
The documentation will be written in clear and lucid Chinese.
The delivery is scheduled for the last quater of next year.
This leaves us plenty of time to decide who to blame for it being late.
Last edited on
LOL
@ Faldrax - I hope you used a little soap. Those chips ought to be nice and shiny when you put them back. ;-)
@ Faldrax - I hope you used a little soap. Those chips ought to be nice and shiny when you put them back. ;-)
Last edited on
Topic archived. No new replies allowed.
Pages: 12