Personal computing discussed
Moderators: renee, SecretSquirrel, just brew it!
Crayon Shin Chan wrote:I'm not a poet, but I can appreciate some poetry. I've been thinking about how people appreciate beauty in all forms, but for programming I don't think there is much you can do to be a good programmer.
What is really beautiful (as in any language) are the concepts expressed through the language - so perhaps you'd find something like a haiku in a mathematician's code for HPC programs. But in most programming tasks, there's really nothing beautiful. It's boring stuff like setup this box here, setup this checkbox there, link that to that, make sure input is tolerable... so what makes a good programmer? Is it the whitespace?
JohnC wrote:Crayon Shin Chan wrote:I'm not a poet, but I can appreciate some poetry. I've been thinking about how people appreciate beauty in all forms, but for programming I don't think there is much you can do to be a good programmer.
What is really beautiful (as in any language) are the concepts expressed through the language - so perhaps you'd find something like a haiku in a mathematician's code for HPC programs. But in most programming tasks, there's really nothing beautiful. It's boring stuff like setup this box here, setup this checkbox there, link that to that, make sure input is tolerable... so what makes a good programmer? Is it the whitespace?
There is no "beauty" in programming (certainly no "timeless" beauty which can still be appreciated by many people not related to programming even after a few centuries)... As for being a "good programmer" it all comes down to being able to finish your assigned tasks during the assigned time period, that is all
JohnC wrote:There is no "beauty" in programming (certainly no "timeless" beauty which can still be appreciated by many people not related to programming even after a few centuries)... As for being a "good programmer" it all comes down to being able to finish your assigned tasks during the assigned time period, that is all
just brew it! wrote:1. Take the time and effort to understand the problem to be solved before making key architectural decisions or writing substantial amounts of code. This includes understanding the performance requirements of the application, and any constraints of the platform (hardware and software) being used. Occasionally, you may need to do a substantial amount of up-front prototyping to achieve a reasonable level of understanding; but you and your management both need to acknowledge that the prototype code may need to be thrown away, and allow for that in the schedule.
Captain Ned wrote:and it's designed to "reduce paper"
just brew it! wrote:And then you've got the utter insanity of printing out a document so you can sign the paper copy, scan it back into the computer, and e-mail it somewhere.
just brew it! wrote:IMO the best programmers do the following:
1. Take the time and effort to understand the problem to be solved before making key architectural decisions or writing substantial amounts of code. This includes understanding the performance requirements of the application, and any constraints of the platform (hardware and software) being used. Occasionally, you may need to do a substantial amount of up-front prototyping to achieve a reasonable level of understanding; but you and your management both need to acknowledge that the prototype code may need to be thrown away, and allow for that in the schedule.
2. Structure the code such that it reflects the structure of the problem being solved, and factor the code to make it modular and maintainable.
3. Refrain from using tricky or clever constructs which hurt the readability/maintainability of the code, just for the sake of being tricky or clever. OTOH if there are good reasons (significantly better performance, resource usage, etc.), then by all means go for it; but carefully document your work so that others can maintain it if you get hit by a bus tomorrow.
michael_d wrote:Personally I strive to adhere to the following:
* Ensure that previously fixed issue never comes back to me.
* Spend hours analyzing old code (not mine) before starting working on a resolution.
* Attempt to not introduce new bug(s) while fixing current one(s).
* Take time to attempt to find more unknown bugs and fix them. It bodes well with management and results in fewer issues reported by customers which leaves good impression.
michael_d wrote:I do not agree with the thesis that code has to be "maintainable", without "tricky" or "clever" constructs. It does not mean anything useful to me. It sounds like programmer designed the app for the programmer and not the end-user. Always think how your work will impact customer and their business because in the end their success is your success.
just brew it! wrote:Obfuscating the design of a non-performance-critical application just to improve performance by an insignificant amount isn't good programming; it misses the big picture. Someone else may be maintaining your code in the future; by avoiding unnecessarily tricky/clever constructs, you're making that person's job easier. By making that person's job easier, you're reducing the cost of maintaining the software, and reducing the odds that future modifications (or a port to a different OS, or a different platform...) will introduce new (and possibly subtle) bugs.
Crayon Shin Chan wrote:I'm not a poet, but I can appreciate some poetry. I've been thinking about how people appreciate beauty in all forms, but for programming I don't think there is much you can do to be a good programmer.
What is really beautiful (as in any language) are the concepts expressed through the language - so perhaps you'd find something like a haiku in a mathematician's code for HPC programs. But in most programming tasks, there's really nothing beautiful. It's boring stuff like setup this box here, setup this checkbox there, link that to that, make sure input is tolerable... so what makes a good programmer? Is it the whitespace?
Star Brood wrote:Years ago I was on a project where one developer pushed and got management approval to implement pooled reusable database connections from the app. He ran some benchmarks showing the connect speed improved from 0.1s to 0.01s and management loved it.just brew it! wrote:Obfuscating the design of a non-performance-critical application just to improve performance by an insignificant amount isn't good programming; it misses the big picture. Someone else may be maintaining your code in the future; by avoiding unnecessarily tricky/clever constructs, you're making that person's job easier. By making that person's job easier, you're reducing the cost of maintaining the software, and reducing the odds that future modifications (or a port to a different OS, or a different platform...) will introduce new (and possibly subtle) bugs.
If I have to choose someone to program with, I'd want someone like you. I've met way too many speed freaks who will spend hours gaining 0.5% efficiency in a snippet that might get used a couple times a month and only lasts a few milliseconds anyway. Speed freaking is the most unhealthy thing a programmer can get into.