5 ms·

This is exactly the attitude I try get into every developers head! Please write maintainable code using common and broadly understood methods. There is no awar

by verelo 10y ago

This is exactly the attitude I try get into every developers head! Please write maintainable code using common and broadly understood methods. There is no award for surprising me in how fancy your solution is, in fact the opposite.

klibertp 10y ago
> There is no award for surprising me in how fancy your solution is, in fact the opposite. While I can agree with "no award" part, I don't think "the opposite" should be true. How do you know you got surprised because the method was "fancy" instead of because your knowledge was lacking?
- verelo 10y ago
  While I do not go around trying to beat people with a stick when they make things I see as overly complex, I think it's good to have a conversation about it, sit down together to find the simpler solution [or accept the one that is already implemented] and hopefully reach alignment on the path forward. It's totally possible my knowledge is lacking, which is why the conversation is critical. If I just need to be educated on why something I saw as complex was the right decision, so be it, and I look forward / enjoy those opportunities. At the end of the day, I run the tech team and founded this company, while others might come and go, I need to feel ownership over the code, product and most importantly it's shortcomings. If I cannot own that openly, I cannot lead/direct others, and that is when technical teams really start to fall apart imo.
- BurningFrog 10y ago
  Doesn't matter. If your code is not understandable by most developers, it is probably worthless in practice.
  - klibertp 10y ago
    The only thing that lays further ahead on that road is the lowest common denominator, copy-pasted code and lots and lots of mediocre code monkeys. I don't want to go there, although I can understand people who would like programming to work that way.
jimbokun 10y ago
"Please write maintainable code using common and broadly understood methods." Often times, the most common methods are the most obfuscated and unclear. Maybe this is my perspective just because I am a Java developer. Pulling in lots of poorly understood dependencies. Depending on annotations that change execution flow in complex ways that are very difficult to follow, even with a sophisticated IDE. Deploying into complex web containers. ORMs mapping method calls into who knows what SQL calls. Lots of superfluous mutable state everywhere. (I'm looking at you Spring. Although Spring Boot is a definite improvement.)
- deleted 10y ago
  [deleted]
- verelo 10y ago
  Sorry, the use of the word 'common' was a poor choice [and I'm actually not sure what would be a better choice]. I agree with you wholeheartedly. I honestly find a lot of those common methods very confusing.
- Roboprog 10y ago
  Thank you. After 30+ years of programming, I am often completely disgusted at what a bunch of magic filth JEE/Spring is. The guy(s) who made annotations in Java 1.5 deserves extreme punishment :-)
  - AstralStorm 10y ago
    Nah, annotations are great when they're used for their stated purpose, that is, annotating code. They shouldn't have been allowed to actually change runtime behavior or be used to control code generation.
lmm 10y ago
Sure, but to my mind monads are common and broadly understood, at least compared to all the alternatives for achieving the same kind of thing (e.g. AOP shudder).
- AnimalMuppet 10y ago
  Within FP, sure, monads are common and (at least should be) broadly understood. Outside of FP, though, monads are neither common nor well understood. You make these broad statements about monads as if FP was the whole programming world. It's not. It's probably less than 5% of it.
  - smaddox 10y ago
    But isn't typical high-quality OOP code essentially Monadic code? State is encapsulated in an object and transformed by method calls. Method calls can be chained, and state can be encapsulated and extracted using constructors and accessors, respectively. The basic operations are all the same. OOP is just less strict with how you can transform objects, i.e. function/method purity is not enforced.
    - catnaroek 10y ago
      > But isn't typical high-quality OOP code essentially Monadic code? Nope. > State is encapsulated in an object and transformed by method calls. Monads aren't objects (which necessarily have a runtime manifestation). Monads (as used in functional programming) are abstract type constructors (which normally don't have a runtime manifestation). > Method calls can be chained, and state can be encapsulated and extracted using constructors and accessors, respectively. Monadic bind satisfies three concrete, clearly defined algebraic laws. The use of monads in functional programming arose from the field of denotational semantics, which gives “programs” (by which functional language semanticists mean “expressions”) precise mathematical meanings in a compositional manner.
      - smaddox 10y ago
        I understand what a Monad is. My point is that high-quality OOP code typically adheres to the rules of Monads. I didn't say Monads were objects. I simply talked through the most common properties and operations of OOP code, in order to show how they are closely related to the operations on Monads. I understand that OOP code does not, in general, satisfy the constraints of Monads. Hence, why I specified high-quality OOP code, which, in contrast, typically does.
lacampbell 10y ago
What's fancy to you? What's broadly understood? Will you get upset if someone in your java codebase uses lambdas or optionals or even the ternary operator? All of the above are still considered black magic to many in our industry.
- AstralStorm 10y ago
  If a standard feature in your language of choice confuses or upsets you when it is not misused... You may have a problem. The problem is typically lack of willingness to learn.
- verelo 10y ago
  It totally depends on the situation, is it something the whole team needs to work with on a regular basis? And is it really the most optimal solution (those two questions are highly interlinked)? If that's the case then we might want to a) educate everyone else first or b) pick something we know will be less of a struggle for others to maintain. I guess there is always option c) ask the original author never to leave and be available 24/7 to answer questions, but that, obviously, isn't realistic. Edit: I answered the question poorly. Are you "writing art" or doing your job? I don't mind if the outcome is pretty, but your first priority is to do your best in your role within the organization. If the author or the code feels that is the case then generally I won't ever get upset with anything they do.
slededit 10y ago
I work on a product that was mostly C. At the time the developers loved it! Look at how clear and explicit everything is. These days however people recoil in horror when they see parts still in that old C style. The rest of the world can and will change their definition of what "common and broadly understood" means.

by verelo 10y ago

klibertp 10y ago

> There is no award for surprising me in how fancy your solution is, in fact the opposite. While I can agree with "no award" part, I don't think "the opposite" should be true. How do you know you got surprised because the method was "fancy" instead of because your knowledge was lacking?

verelo 10y ago
While I do not go around trying to beat people with a stick when they make things I see as overly complex, I think it's good to have a conversation about it, sit down together to find the simpler solution [or accept the one that is already implemented] and hopefully reach alignment on the path forward. It's totally possible my knowledge is lacking, which is why the conversation is critical. If I just need to be educated on why something I saw as complex was the right decision, so be it, and I look forward / enjoy those opportunities. At the end of the day, I run the tech team and founded this company, while others might come and go, I need to feel ownership over the code, product and most importantly it's shortcomings. If I cannot own that openly, I cannot lead/direct others, and that is when technical teams really start to fall apart imo.
BurningFrog 10y ago
Doesn't matter. If your code is not understandable by most developers, it is probably worthless in practice.
- klibertp 10y ago
  The only thing that lays further ahead on that road is the lowest common denominator, copy-pasted code and lots and lots of mediocre code monkeys. I don't want to go there, although I can understand people who would like programming to work that way.

jimbokun 10y ago

"Please write maintainable code using common and broadly understood methods." Often times, the most common methods are the most obfuscated and unclear. Maybe this is my perspective just because I am a Java developer. Pulling in lots of poorly understood dependencies. Depending on annotations that change execution flow in complex ways that are very difficult to follow, even with a sophisticated IDE. Deploying into complex web containers. ORMs mapping method calls into who knows what SQL calls. Lots of superfluous mutable state everywhere. (I'm looking at you Spring. Although Spring Boot is a definite improvement.)

deleted 10y ago
[deleted]
verelo 10y ago
Sorry, the use of the word 'common' was a poor choice [and I'm actually not sure what would be a better choice]. I agree with you wholeheartedly. I honestly find a lot of those common methods very confusing.
Roboprog 10y ago
Thank you. After 30+ years of programming, I am often completely disgusted at what a bunch of magic filth JEE/Spring is. The guy(s) who made annotations in Java 1.5 deserves extreme punishment :-)
- AstralStorm 10y ago
  Nah, annotations are great when they're used for their stated purpose, that is, annotating code. They shouldn't have been allowed to actually change runtime behavior or be used to control code generation.

lmm 10y ago

Sure, but to my mind monads are common and broadly understood, at least compared to all the alternatives for achieving the same kind of thing (e.g. AOP shudder).

AnimalMuppet 10y ago
Within FP, sure, monads are common and (at least should be) broadly understood. Outside of FP, though, monads are neither common nor well understood. You make these broad statements about monads as if FP was the whole programming world. It's not. It's probably less than 5% of it.
- smaddox 10y ago
  But isn't typical high-quality OOP code essentially Monadic code? State is encapsulated in an object and transformed by method calls. Method calls can be chained, and state can be encapsulated and extracted using constructors and accessors, respectively. The basic operations are all the same. OOP is just less strict with how you can transform objects, i.e. function/method purity is not enforced.
  - catnaroek 10y ago
    > But isn't typical high-quality OOP code essentially Monadic code? Nope. > State is encapsulated in an object and transformed by method calls. Monads aren't objects (which necessarily have a runtime manifestation). Monads (as used in functional programming) are abstract type constructors (which normally don't have a runtime manifestation). > Method calls can be chained, and state can be encapsulated and extracted using constructors and accessors, respectively. Monadic bind satisfies three concrete, clearly defined algebraic laws. The use of monads in functional programming arose from the field of denotational semantics, which gives “programs” (by which functional language semanticists mean “expressions”) precise mathematical meanings in a compositional manner.
    - smaddox 10y ago
      I understand what a Monad is. My point is that high-quality OOP code typically adheres to the rules of Monads. I didn't say Monads were objects. I simply talked through the most common properties and operations of OOP code, in order to show how they are closely related to the operations on Monads. I understand that OOP code does not, in general, satisfy the constraints of Monads. Hence, why I specified high-quality OOP code, which, in contrast, typically does.

lacampbell 10y ago

What's fancy to you? What's broadly understood? Will you get upset if someone in your java codebase uses lambdas or optionals or even the ternary operator? All of the above are still considered black magic to many in our industry.

AstralStorm 10y ago
If a standard feature in your language of choice confuses or upsets you when it is not misused... You may have a problem. The problem is typically lack of willingness to learn.
verelo 10y ago
It totally depends on the situation, is it something the whole team needs to work with on a regular basis? And is it really the most optimal solution (those two questions are highly interlinked)? If that's the case then we might want to a) educate everyone else first or b) pick something we know will be less of a struggle for others to maintain. I guess there is always option c) ask the original author never to leave and be available 24/7 to answer questions, but that, obviously, isn't realistic. Edit: I answered the question poorly. Are you "writing art" or doing your job? I don't mind if the outcome is pretty, but your first priority is to do your best in your role within the organization. If the author or the code feels that is the case then generally I won't ever get upset with anything they do.

slededit 10y ago

I work on a product that was mostly C. At the time the developers loved it! Look at how clear and explicit everything is. These days however people recoil in horror when they see parts still in that old C style. The rest of the world can and will change their definition of what "common and broadly understood" means.