3 ms·

Yeah, a lot of software engineering schools of thought are just based on superstition, but they're all somewhere in the neighbourhood of "productive practices"

Yeah, a lot of software engineering schools of thought are just based on superstition, but they're all somewhere in the neighbourhood of "productive practices" regardless of how different they are from each other. If you do * 100% pairing, * buttloads of unit tests, * lots of microservices, * use an autoformatter, * in a Node codebase, to order-of-magnitude approximations you're probably going to be about as effective a team as if you * always code alone, * mostly write integration tests, * write a big old monolith, * mostly ignore code style (except for egregious cases), * in C. These variables do make a difference, but those differences are context-dependent and can be swamped by other factors. Use version control. Do at least some testing and some code review. Make sure engineers can actually run their code before submitting it (on their laptops or in special staging environments or whatever, it doesn't matter much.) Help coworkers when they're stuck, and ask for help when you're stuck. And try to hire Harrison Bergeron onto your team :-).

mikekchar 8y ago
When programs are simple, usually time to write code is dominated by finding the requirements. As programs become more complex, the time to write code becomes more and more dominated by understanding and working with the existing code. In code bases you have written yourself, often you remember enough about it that you can mitigate the effects of complexity. Possibly you already had a plan for how to implement some functionality. Or maybe you know how to avoid certain problems. As programs become more complex, you will find that "legacy team members" are disproportionately productive. Learning the code base becomes more important than learning the problem domain. Teams that expend effort on maintaining a status quo where the exploring the problem domain dominates the cost of development (even with new developers), will usually lag behind teams that do not. Mostly, because it is difficult to do. Some of the practices you mention can be used to help in this, but for a "legacy team member" it might not be attractive. If you have a more typical situation, knowing the code base better means you are much more productive and therefore more valuable. This secures a senior position on the team. Turnover is usually high, so most people leave before it gets to the point where even "legacy team members" become unproductive. When you go to a new shop, you can always complain about the "crappy" code and suggest a complete rewrite (at which point, you secure your senior status again). While your list does not necessarily comprise what I think of a "productive practices", I think it is incorrect to imply that "productive practices" can not have a profound impact on the outcome of a project. The productive practices that work best for each team will likely be different. It's important to pick practices that work for your team and produce code that is simple to read and extend. Not thinking about it is a good way to ensure that you will end up with a complex system.
johnsonjo 8y ago
Whoa I just read about Harrison Bergeron on wiki [0]. That was an interesting read. I'm sure the full story would help capture a lot more of Harrison's spirit and qualities [0]: https://en.wikipedia.org/wiki/Harrison_Bergeron https://en.wikipedia.org/wiki/Harrison_Bergeron

mikekchar 8y ago

When programs are simple, usually time to write code is dominated by finding the requirements. As programs become more complex, the time to write code becomes more and more dominated by understanding and working with the existing code. In code bases you have written yourself, often you remember enough about it that you can mitigate the effects of complexity. Possibly you already had a plan for how to implement some functionality. Or maybe you know how to avoid certain problems. As programs become more complex, you will find that "legacy team members" are disproportionately productive. Learning the code base becomes more important than learning the problem domain. Teams that expend effort on maintaining a status quo where the exploring the problem domain dominates the cost of development (even with new developers), will usually lag behind teams that do not. Mostly, because it is difficult to do. Some of the practices you mention can be used to help in this, but for a "legacy team member" it might not be attractive. If you have a more typical situation, knowing the code base better means you are much more productive and therefore more valuable. This secures a senior position on the team. Turnover is usually high, so most people leave before it gets to the point where even "legacy team members" become unproductive. When you go to a new shop, you can always complain about the "crappy" code and suggest a complete rewrite (at which point, you secure your senior status again). While your list does not necessarily comprise what I think of a "productive practices", I think it is incorrect to imply that "productive practices" can not have a profound impact on the outcome of a project. The productive practices that work best for each team will likely be different. It's important to pick practices that work for your team and produce code that is simple to read and extend. Not thinking about it is a good way to ensure that you will end up with a complex system.

johnsonjo 8y ago

Whoa I just read about Harrison Bergeron on wiki [0]. That was an interesting read. I'm sure the full story would help capture a lot more of Harrison's spirit and qualities [0]: https://en.wikipedia.org/wiki/Harrison_Bergeron https://en.wikipedia.org/wiki/Harrison_Bergeron