kevingoslar

If the thinking was truly "slower", i.e. have less throughput, it would result in fewer insights overall, i.e. lower intelligence. This doesn't seem to be the case since the author describes equal success of these "slow thinkers" to neurotypical ways of thinking.

The problem therefore seems to be more accurately described as having the same insights as others, but they arrive later, i.e. "delayed" insights.

Delayed processing could be an effect of delayed context switching, i.e. monotropism [0]. Monotropism can be an indicator of mild autism.

[0] https://en.wikipedia.org/wiki/Monotropism

I use https://www.git-town.com/nested-feature-branches.html.

No.

Since my original post is now flagged and hidden, what I said is no longer visible and I cannot let these misinterpretations stand unaddressed. I said that not everything that appears like racism or sexism might actually have a racist or sexist background, and might actually be more a random abuse by a dark personality type which hasn't learned to use their powers in more constructive ways yet. For example, abuse as narcissistic supply.

That's not an attempt to downplay or excuse anything but an attempt to understand the underlying causes of problems better since that is a prerequisite for addressing them effectively.

It's beyond me how the statement "most men are actually nice people" could be interpreted as sexist in any way.

I'd maintain that awareness, training, and tooling are essential for achieving constructive outcomes here. Without knowing that one has dark personality traits, and thereby a particular way of experiencing the world and pleasure/reward that is different from how most people experience it, it's hard to not unintentionally develop abusive behavioral patterns. Goals develop from a world view. Improve somebody's perspective and their goals adjust.

Knowing that one deals with a dark personality makes it easier to adjust one's interactions and expectations to them and not fall for possible abuse.

Every problem can be solved with enough understanding.

That's not how dark personalities are defined. With enough training one can recognize them. Relevant video: https://youtu.be/GaeJCA4nRPI

Please note that the article merely encourages the application of some of the best practices introduced by functional programming - strong typing and more mindfulness around mutability and side effects - into all forms of programming.

Functional programming as it exists today takes these ideas to a somewhat extreme form. That has its place and value, but as experience in the real world shows, as long as it feels so mathematical, it isn't everybody's cup of tea. Hopefully, over time we find more intuitively accessible abstractions for the really useful principles that functional programming is based on.

Agreed, sorry for the paywall. Is there a better place to post such stories than Medium?

I also don't expect that a lot of the existing Java code will be rewritten in Go. But there exists a whole array of startups/unicorns today who use Go extensively. Many of them will grow into enterprises. I predict that Go will generally hold up well for them as they scale. They will feel a lot less of an urge to switch to something more mature and scalable like Java, as many companies who started out with Ruby, Scala, or PHP did.

I often see enterprises using a mix of languages and technologies (depending on how independent the different org units within it are) and some amount of Java fatigue in developers who are not retiring in less than a decade. Go is often amongst the top choices they are exploring.

In addition to the right culture, great platforms enable great ecosystems. I have found that putting everything as Markdown on a collaboration platform like Github/GitLab works really well and enables collaboration in a number of ways:

- people don't feel awkward to modify other people's content because there is a collaboration and review process in the form of pull requests

- you can assign different people to oversee different parts of the knowledge base. They make sure the organization of the knowledge base doesn't get messed up by reviewing changes of other people to it.

- you can keep others in the loop about important updates (big and small) by tagging them in pull requests

- verification can be automated via bots and CI, for example using https://github.com/originate/text-runner

Git Town started out as Git aliases written in Bash. Version 3 was many hundred lines of Bash, pushing it beyond what Bash was designed for. At some point it got ridiculous, and we got requests for Windows support, as well as better integration with the Github API. Hence the rewrite in Go.

It shows the Git commands it runs, as well as their output. So, you know exactly what Git is doing.

Hub is awesome, and orthogonal to what Git Town does. You can use both together, though.

Git Town covers a ton of edge cases. Just look at their "features" folder. If something goes wrong, Git Town allows to cleanly abort and undo what it did so far and go back to where it started.

That's a lot safer than the unholy mess that ensues when most people try to run "git reset --hard" or "git push --force" manually.

Good suggestion, will add them! Git Town uses Cucumber as living documentation: https://github.com/Originate/git-town/blob/master/features/g...

Git Town contributor here. Thanks! I love your aliases. That's exactly how Git Town started. Then people kept adding logic to cover edge cases, abort and undo operations, as well as Github and Bitbucket integration. Soon enough we ended with many hundreds of lines of Bash. Hence the recent rewrite in Go.

Git Town is a strict superset of your tools. Your "topic start" == "git hack". Your "topic pull" and "topic-push" = "git sync" (you always want to run both anyways). Your "topic-finish" = "git ship".

Want to join forces?

Git Town doesn't replace Git, nor does it try to shield you from learning how Git works. It shows the Git commands it runs for you, as well as their output. When using it, one should make sure to understand what it is doing.

The thing is, Git is awesome, but intentionally designed as a low-level and generic tool. Using it correctly for particular workflows (like Git Flow or Github Flow) requires running many Git commands for each operation, and is highly repetitive.

Good developers engineer repetition away. Great developers share what they build. Hence Git Town.

Git Town contributor here.

This tool was built to help stay sane in large high-velocity development teams. In such environments, one can easily spend an hour (or so) each day resolving merge conflicts. Feature branches go out of sync with the main development branch multiple times a day. One has to keep pulling, merging, or rebasing all open branches regularly to avoid more merge conflicts later. Those things require running many Git commands.

Git Town makes all of this quick,easy, and bulletproof. A lot of people have been using it for years and love it for that.

Apparently our documentation doesn't get this across well enough. We'll add more details.

There is a way to support both styles at the same time, and most libraries (that I'm aware of) use it. If a callback is given, call it with the result. If not, return a promise for the result. This doesn't require a rewrite of existing libraries, but merely a new minor version.

I don't see how compile-time type checking would help here. When checking out a new library, I read the documentation, or maybe it's test suite, and then use it accordingly. My tests ensure that I use it correctly, i.e. give it types it understands, give it the right data (the id of the correct user account for example), and handle the outcome correctly (i.e. display it in the right format).

JavaScript has run-time type checking, which could be used for automatic promisification, but I agree that's a slippery road, for many reasons.

Great to see that Rails still has so much momentum!

The secret to getting up early and it not feeling like torture is going to bed early. I'm getting sleepy around 9pm, and am in bed between 9 and 9.30pm. Depending on my need for sleep I naturally wake up between 5 and 5.30am. Melatonin has initially helped me get to bed early, now it happens naturally.

That's an excellent suggestion, thanks! Coming soon!

This reminds me of AppleScript. Super easy to read, very hard to write.

Git Town committer here. Our commands output the detailed Git commands when they run. In addition, we provide a summary of what each command does in its man page (see https://github.com/Originate/git-town/blob/master/documentat... for an example).

You have a good point about it being valuable to document the steps run by each command in more detail though. We'll add this, thanks for the suggestion! :)

Btw "git help ship" displays the man page for "git-ship".