4 ms·

Ten low-level, generic advices. Too low level to do any good in larger picture, and too generic to be applicable in real life as-is. The only exception is not i

by dozzie 11y ago

Ten low-level, generic advices. Too low level to do any good in larger picture, and too generic to be applicable in real life as-is. The only exception is not interrupting people when they are in the middle of work. There are several high-level advices that are similarly generic: break up your program to subsystems of clearly defined interface and purpose, make the subsystems composable by not loading them with too many purposes, don't mix high-level and low-level purposes or operations in the same interface, avoid putting dependencies on other modules or services unless necessary, and know which operation belongs to which module. Those make good programmer, not minutiae about creating identifiers.

ljk 11y ago
> Ten low-level, generic advices. Too low level to do any good in larger picture, and too generic to be applicable in real life as-is. agreed, these buzzfeed-type "blogs" are getting out of hand
AnimalMuppet 11y ago
It's both/and, not either/or. If you do all that you say, but not what the article says, I'm still not impressed with you as a programmer.
50CNT 11y ago
I like to generalize it to "Understand and consistently apply the concepts and good practices of your chosen field". This requires you to find out what good practices are, understanding why they are good practices and then working on making them a habit so they reliably show up in your work. The issue I have with the article myself is that it over-promises in the title and under-delivers in the body. The rules are drawn at random from things that make good sense, with no attention to order in level, area, or importance. DRY is a pattern, not commenting code is an anti-pattern, and not interrupting co-workers is workplace etiquette. Some rules are obvious to the intermediate [DRY, no magic numbers], whilst others are confusing to the beginner [eliminating dependencies to make code easier to test]. This makes the list useful for neither. Calling this "golden rules" seems dishonest. "My rules for becoming a better programmer" would be a more accurate, albeit more boring title.
- samizdatum 11y ago
  Yeah, this article reads like someone was forced by their employer to write a blog post. If it was for self-promotion you'd think they'd put a bit more effort into it. Would be better if retitled to "10 things that just so happened to pop into my head".
FLUX-YOU 11y ago
>There are several high-level advices that are similarly generic: break up your program to subsystems of clearly defined interface and purpose, make the subsystems composable by not loading them with too many purposes, don't mix high-level and low-level purposes or operations in the same interface, avoid putting dependencies on other modules or services unless necessary, and know which operation belongs to which module. Those make good programmer, not minutiae about creating identifiers. Lot of this will happen during accretion. You can rationalize adding one low level method to a high level class because at the time because you only have one request to do. On the other hand, had you a request that warranted a whole bunch of low level stuff in your high level program, it's very easy to see the opportunity of separating those concerns. If you have good instincts for your problem space, chances are you'll foresee a lot of these needs. You might even have the concerns separated long before the requests for them come in. Instincts take time to develop. So most people end up writing sub-optimal code because it's the cost of training someone. Code reviews stop it from actually getting committed, but the team is still incurring a cost with the small chance it doesn't pay off from the person not adapting the reviewer's style. How often do you sit and count the number of purposes a class has? The number of dependencies you're adding per unit time? The amount of small things that sneak in because it's just one small change and we really want to go drinking tonight? Do you go through this ritual every time you open the source? After all, you don't just have to worry about your code, but also your co-workers'. Are they putting in the same effort as you are? Even if you do that, what are your thresholds? Can you defend for choosing a particular value? Maybe it's just inherited from someone who has a bigger name than you, which is a good guideline, but is not necessarily law. To me, it will always come down to finding like-minded people in this area, which means there are people that just don't care about the quality as long as it works. It's a people problem. Since the compiler/interpreter is happy to run terrible looking code, maybe it should have hard coded thresholds as compiler warnings decided by dice rolls!
- samizdatum 11y ago
  I find this is one of the biggest problems with object-oriented programming. The object is a terrible unit of abstraction, because it forces you to carve up your domain into rigid chunks which might map to your domain today, and fail to map to it tomorrow, and a terrible unit of reuse, because it couples methods to data, and bundles these methods together on top of that.
paulddraper 11y ago
Way to outshine it in two paragraphs.
- deleted 11y ago
  [deleted]

by dozzie 11y ago

ljk 11y ago

> Ten low-level, generic advices. Too low level to do any good in larger picture, and too generic to be applicable in real life as-is. agreed, these buzzfeed-type "blogs" are getting out of hand

AnimalMuppet 11y ago

It's both/and, not either/or. If you do all that you say, but not what the article says, I'm still not impressed with you as a programmer.

50CNT 11y ago

I like to generalize it to "Understand and consistently apply the concepts and good practices of your chosen field". This requires you to find out what good practices are, understanding why they are good practices and then working on making them a habit so they reliably show up in your work. The issue I have with the article myself is that it over-promises in the title and under-delivers in the body. The rules are drawn at random from things that make good sense, with no attention to order in level, area, or importance. DRY is a pattern, not commenting code is an anti-pattern, and not interrupting co-workers is workplace etiquette. Some rules are obvious to the intermediate [DRY, no magic numbers], whilst others are confusing to the beginner [eliminating dependencies to make code easier to test]. This makes the list useful for neither. Calling this "golden rules" seems dishonest. "My rules for becoming a better programmer" would be a more accurate, albeit more boring title.

samizdatum 11y ago
Yeah, this article reads like someone was forced by their employer to write a blog post. If it was for self-promotion you'd think they'd put a bit more effort into it. Would be better if retitled to "10 things that just so happened to pop into my head".

FLUX-YOU 11y ago

>There are several high-level advices that are similarly generic: break up your program to subsystems of clearly defined interface and purpose, make the subsystems composable by not loading them with too many purposes, don't mix high-level and low-level purposes or operations in the same interface, avoid putting dependencies on other modules or services unless necessary, and know which operation belongs to which module. Those make good programmer, not minutiae about creating identifiers. Lot of this will happen during accretion. You can rationalize adding one low level method to a high level class because at the time because you only have one request to do. On the other hand, had you a request that warranted a whole bunch of low level stuff in your high level program, it's very easy to see the opportunity of separating those concerns. If you have good instincts for your problem space, chances are you'll foresee a lot of these needs. You might even have the concerns separated long before the requests for them come in. Instincts take time to develop. So most people end up writing sub-optimal code because it's the cost of training someone. Code reviews stop it from actually getting committed, but the team is still incurring a cost with the small chance it doesn't pay off from the person not adapting the reviewer's style. How often do you sit and count the number of purposes a class has? The number of dependencies you're adding per unit time? The amount of small things that sneak in because it's just one small change and we really want to go drinking tonight? Do you go through this ritual every time you open the source? After all, you don't just have to worry about your code, but also your co-workers'. Are they putting in the same effort as you are? Even if you do that, what are your thresholds? Can you defend for choosing a particular value? Maybe it's just inherited from someone who has a bigger name than you, which is a good guideline, but is not necessarily law. To me, it will always come down to finding like-minded people in this area, which means there are people that just don't care about the quality as long as it works. It's a people problem. Since the compiler/interpreter is happy to run terrible looking code, maybe it should have hard coded thresholds as compiler warnings decided by dice rolls!

samizdatum 11y ago
I find this is one of the biggest problems with object-oriented programming. The object is a terrible unit of abstraction, because it forces you to carve up your domain into rigid chunks which might map to your domain today, and fail to map to it tomorrow, and a terrible unit of reuse, because it couples methods to data, and bundles these methods together on top of that.

paulddraper 11y ago

Way to outshine it in two paragraphs.

deleted 11y ago
[deleted]