The best programmer is the one who can solve the problem effectively and efficiently without even touching the keyboard. You don't have to be "good". You have to solve the right problem efficiently. Find the right problem and be the solution. If you need to write a program, make an easy one. Easy to use and easy to maintain. You'll get what that means after a few years of maintaining. Nobody ever cares if you're a "g…
What you describe is application and systems architecture and requires domain knowledge. Excellent programming requires the ability to create a functional blueprint in whatever way/shape/form is decided and do so without undue time and cost.
How do I know if I'm good at programming?
131–140 of 153 posts
Re: How do I know if I'm good at programming?
#132There are 2 types of “good” programmers, who both think the other type is useless. The first is the “rockstar” developer type who is great at prototyping, hitting deadlines no matter what and delivering functionality, albeit full of bugs. They will write 80% of the code and will drive the support team up the wall by breaking the build, causing customer issues in production, security holes and basically seriously degr…
I don't know if I agree. I have friends that can smash out amazing code in very little time. Looking through some repositories of programs I like, some of them were prototyped in very little time, but with a surprisingly excellent first revision. I had the pleasure to work with Zed Shaw quite some time ago, and even though his code might not be perfect, he writes a lot better code than the vast majority, in a lot les…
Re: How do I know if I'm good at programming?
#133There are 2 types of “good” programmers, who both think the other type is useless. The first is the “rockstar” developer type who is great at prototyping, hitting deadlines no matter what and delivering functionality, albeit full of bugs. They will write 80% of the code and will drive the support team up the wall by breaking the build, causing customer issues in production, security holes and basically seriously degr…
Re: How do I know if I'm good at programming?
#134Re: How do I know if I'm good at programming?
#135There are 2 types of “good” programmers, who both think the other type is useless. The first is the “rockstar” developer type who is great at prototyping, hitting deadlines no matter what and delivering functionality, albeit full of bugs. They will write 80% of the code and will drive the support team up the wall by breaking the build, causing customer issues in production, security holes and basically seriously degr…
All the founders of Autodesk were of the second type. Most were mainframe OS maintenance programmers who fixed kernel bugs in assembler. A big issue for AutoCAD was "don't lose the user's work". Customers were not forgiving of that. New features were less important. Autodesk is still around, market cap around $26 billion. They're still selling expensive software that works, and have been profitable for over 30 years.
3d apps especially seem to suffer from bloat, which then leads to competitors getting the leg up and the original dying off; then repeat for the competitors.
Re: How do I know if I'm good at programming?
#136A good programmer doesn’t exist in nature.
Now a good team is something that takes a couple of years of hard, honest work with stellar management. A rarity.
Re: How do I know if I'm good at programming?
#137Earlier quoted context omitted.
What you describe is application and systems architecture and requires domain knowledge. Excellent programming requires the ability to create a functional blueprint in whatever way/shape/form is decided and do so without undue time and cost.
Maybe programming is to system architecture as tactics is to strategy. Which would probably mean management is to system architecture as logistics is to strategy?
Re: How do I know if I'm good at programming?
#138There are 2 types of “good” programmers, who both think the other type is useless. The first is the “rockstar” developer type who is great at prototyping, hitting deadlines no matter what and delivering functionality, albeit full of bugs. They will write 80% of the code and will drive the support team up the wall by breaking the build, causing customer issues in production, security holes and basically seriously degr…
Full of bugs (non working) functionality that constantly causes customer issues is not considered "rockstar". It might appear that way up front, but the lasting reputation will be from the success (or not) of the final product, including whatever post-deadline work is done.
Re: How do I know if I'm good at programming?
#139Earlier quoted context omitted.
"More readable code almost always means less efficient code." Can you give examples? I'm not sold that the "low hanging fruit" of readability improvement (empty lines to break up "paragraphs", breaking up unintelligible one-liners into several lines, etc.) degrades performance. My intuition is that the compiler/interpreter ends up producing almost identical runtime code and therefore similar performance. Unless you m…
Take the following code, which I had occasion to write this morning: foreach (var item in items) { if (items.Where(item2 => item.Upc == item2.Upc).Count() != 1) { item.Duplicate = true; } } This is the most readable and straightforward code I could come up with for the task; it's also not particularly efficient, since it does at least twice as many comparisons as necessary (more if there are actually duplicate items)…
Note that this was conceived in just a few minutes of reading your code, deciphering syntax only remotely familiar, and figuring out what was it supposed to do, all with cold start (I haven't written much today yet). Something went wrong with your thought process.
Re: How do I know if I'm good at programming?
#140There are 2 types of “good” programmers, who both think the other type is useless. The first is the “rockstar” developer type who is great at prototyping, hitting deadlines no matter what and delivering functionality, albeit full of bugs. They will write 80% of the code and will drive the support team up the wall by breaking the build, causing customer issues in production, security holes and basically seriously degr…