163 karma · joined August 25, 2016
The other two are better, and (aptly) not closed. Of course you'll get inappropriate votes to close, but I hope they are correctly offset by other votes the (hopefully vast) majority of the time.
Now about this:
> how is closing the question helpful in any way?
I suppose it's to stay focused. When googling I quite often get useful SO results (& upvote those), and I'm happy not having to sift through tons of useless questions.
I avoid humor in main code, but in unit test code when you have to come up with dummy bits of test data or variable names, I love getting funky there :)
But whatever, ("Sign in" or "Log in") alongside "Register" is clear enough. "Sign in" alongside "Sign up" is confusing. Thanks Al-Khwarizmi for bringing that up... or is it bring in ? ;)
https://www.google.com/search?q="Don't+kick+a+man+when+he's+...
Credit: https://twitter.com/ObeyComputer/status/1050131788830560258
WTF does that mean?
Is it incorrect? How do you get "6!" ?
720 custom doodles seems doable, 2520 seems a bit much, so I suspect my reasoning for 7!/2 is wrong :)
Edit : oh, I see how for all closed paths all 7 permutations are the same so we can divide by 7 for closed paths, but there are still the open paths... hmmm (still pondering)
Edit 2 : aaaah, got it, I did not notice he was always closing the path himself... tss that's cheating :)
https://www.stackoverflowbusiness.com/enterprise
Edit: while interesting, this (private internal instance for your team) is not what johansch is after (separate public instance dedicated to your product, for your users)
I see what you did there. Well done.
Right, but the problem is those that do judge it in a systematically negative way.
I'm glad to see this in an article for JavaScript projects. Here are a few articles for Java projects, that go in more details (I think the concepts still mostly apply to JavaScript projects):
http://www.javapractices.com/topic/TopicAction.do?Id=205
http://www.codingthearchitecture.com/2015/03/08/package_by_c...
For now I have:
- write down everything: tasks, discussions & conclusions, etc (you said "keep a backlog of tasks")
- when interrupted while coding, insert a //TODO with a few words that will help rebuild context on resuming, maybe with a statement that does not compile to quickly get back there (if the interruption leads you to navigate away from that file/editor)
- if a few seconds are not enough, explain "I need a few minutes to write down stuff and I'll get back to you". This is always accepted without issue. Although it's difficult when the person politely waits behind you :)
- if you figure you really cannot be interrupted on the spot, make great effort to explain this as gently as possible, and offer to get back to them later: again, always accepted by peers (in my experience). If the interaction stays below a few seconds, AND I stayed agreeable & polite, I have little problem getting back in the flow. When I reply too curtly or let the slightest trace of anger show, then I fail to get back in, because my thoughts are polluted with remorse & guilt.
- over time, learn to identify in advance when you are about to enter a "really-really-no-interrupt zone", and then wear audio gear or something to signal this. And don't do it too often.
- I also noticed "recursive tasks" are a challenge. You suggest to avoid them when they are just ideas that help the previous task, but what if they are impediments that MUST be fixed? (Google "malcolm hal fixing light bulb" for hilarious illustration). For this I only have "write down everything", but it gets frustrating with the feeling I'm getting slow due to constant swapping, and could be faster if I could count on short term memory alone (and no interruptions...).
Anwyay... would love to read more about "embrace interruptions" & "optimize for re-starting".
What our tool does is allow users to organize the flow of their processing jobs on an infinite 2D layout, have some jobs run at the beginning of the flow while they organize another part to run later.
Unfortunately it's a big pile of messy code that depends too much on other "internal" systems so we can't open source it... I'd like to add "yet" because I try to gradually clean it up, simplify and make it more generic, but I'm not sure I'll see that day myself.
In the meantime... maybe Node-RED ? https://nodered.org/