3 ms·

I agree with some of what the author says (building at least one prototype before carving a plan into stone is usually a great idea), but I think affordances fo

I agree with some of what the author says (building at least one prototype before carving a plan into stone is usually a great idea), but I think affordances for teamwork are missing. The author proudly reiterates how much of their development process exists only locally, with key artifacts like mocks and prototypes being inaccessible to team members. I think one of the most effective ways to increase velocity is to structure your work so that 2-3 other people can work on it with you. I feel like that would be a more productive discussion than some of the nuts and bolts stuff this article dives into (side effects or ifElses or what have you).

molteanu 2y ago
Yes, `2-3 other people can work on it with you` would be splendid. But then you have to be on the same page with your colleagues on how to go on about doing things. You know how that goes, when good ideas are then made mandatory and all the team must follow suit. Then the original motivation is kinda lost in the background and then part of the team only does the moves because "someone told me to". If you say, yes, `2-3 other people...`, let's get together and do this thing, approval or no approval, then we might be getting somewhere. As an extreme example, if I'm using Emacs, and assume it offers some advantage in the project development velocity department (ignoring any reasons as to why, for the sake of the argument) but cannot convince the other team-members to use it, should I stop using it?
- striking 2y ago
  There's a difference between working in lockstep with every single other teammate and making your work available to other people. The former is sometimes the ideal, but the latter is always achievable. I am maybe the only Emacs user in an eng org of 100 people. But my work is compatible with that of the VS Code and Vim users, of course.
- ParetoOptimal 2y ago
  Can you give some examples of why you would need to stop using emacs? I can only think of the reason of pair programming and both users editing at the same time.
  - molteanu 2y ago
    Late reply, but I've found I reason why one might need to stop using Emacs, https://www.reddit.com/r/emacs/comments/1glqfa3/my_company_doesnt_know_who_developed_emacs/ https://www.reddit.com/r/emacs/comments/1glqfa3/my_company_d...

molteanu 2y ago

Yes, `2-3 other people can work on it with you` would be splendid. But then you have to be on the same page with your colleagues on how to go on about doing things. You know how that goes, when good ideas are then made mandatory and all the team must follow suit. Then the original motivation is kinda lost in the background and then part of the team only does the moves because "someone told me to". If you say, yes, `2-3 other people...`, let's get together and do this thing, approval or no approval, then we might be getting somewhere. As an extreme example, if I'm using Emacs, and assume it offers some advantage in the project development velocity department (ignoring any reasons as to why, for the sake of the argument) but cannot convince the other team-members to use it, should I stop using it?

striking 2y ago
There's a difference between working in lockstep with every single other teammate and making your work available to other people. The former is sometimes the ideal, but the latter is always achievable. I am maybe the only Emacs user in an eng org of 100 people. But my work is compatible with that of the VS Code and Vim users, of course.
ParetoOptimal 2y ago
Can you give some examples of why you would need to stop using emacs? I can only think of the reason of pair programming and both users editing at the same time.
- molteanu 2y ago
  Late reply, but I've found I reason why one might need to stop using Emacs, https://www.reddit.com/r/emacs/comments/1glqfa3/my_company_doesnt_know_who_developed_emacs/ https://www.reddit.com/r/emacs/comments/1glqfa3/my_company_d...