3 ms·

There are two forms of mess in my experience, none of them have to do with SPA. 1) You have the problems that different developers have different styles. So w

by koblas 8y ago

There are two forms of mess in my experience, none of them have to do with SPA. 1) You have the problems that different developers have different styles. So when you jump from one area to another in the code base you're hit with WFT this is functional/procedural/inheritiance/composition, etc. style and your first thought is "barf" they did it wrong... 2) People either have huge functions that are spaghetti or tiny little functions to avoid complexity that are one line if statements. Both of these are usually rooted in lack of a shared code culture, these are not SPA issues but team issues.

cle 8y ago
These could also partially be language and tooling issues. There are some languages that are so “powerful”, “flexible”, and unopinionated that every developer has dramatically different coding styles (JavaScript, Scala, etc.). On the other end of the spectrum are tightly prescriptive, constrained languages where everyone’s code looks the same (Go comes to mind). No doubt team culture plays a part as well, but in team settings it is important to pick tools that are designed for team settings. These tend to prioritize regularity, lack of flexibility, syntactic simplicity, static analysis, etc.
taeric 8y ago
Oddly, I would sum up both of those as bikeshedding problems. I agree it is a team issue. I know the world is sick of gardening metaphors, but I do feel like there are lessons from community gardens. (Really any community thing.) You will usually have an owner that will paint broad strokes of what the rules are. Then, a bunch of spots that contributors are touching regularly. In their contributions, the rules are much more free form. But, you don't typically have people moving rapidly between contribution zones. Which gets me to my favorite take on the answer. Solving the customer problem is not necessarily the same as solving any developer problem. If you are lucky, you can align them. However, as a developer brutal honest with self in "did this change actually provide any value to the customer" has to be constantly asked.

by koblas 8y ago

cle 8y ago

These could also partially be language and tooling issues. There are some languages that are so “powerful”, “flexible”, and unopinionated that every developer has dramatically different coding styles (JavaScript, Scala, etc.). On the other end of the spectrum are tightly prescriptive, constrained languages where everyone’s code looks the same (Go comes to mind). No doubt team culture plays a part as well, but in team settings it is important to pick tools that are designed for team settings. These tend to prioritize regularity, lack of flexibility, syntactic simplicity, static analysis, etc.

taeric 8y ago

Oddly, I would sum up both of those as bikeshedding problems. I agree it is a team issue. I know the world is sick of gardening metaphors, but I do feel like there are lessons from community gardens. (Really any community thing.) You will usually have an owner that will paint broad strokes of what the rules are. Then, a bunch of spots that contributors are touching regularly. In their contributions, the rules are much more free form. But, you don't typically have people moving rapidly between contribution zones. Which gets me to my favorite take on the answer. Solving the customer problem is not necessarily the same as solving any developer problem. If you are lucky, you can align them. However, as a developer brutal honest with self in "did this change actually provide any value to the customer" has to be constantly asked.