ashnur

The One Secret Trick To Becoming A Genius Programmer

Okay, the title of this post is a bit of a lie. There's no one secret trick to becoming a genius programmer - there are two, and they're more habits than tricks. Nevertheless, these kind of 'secret tricks' seem to resonate with people, so I went for this title anyway.

Every once in a while, a somewhat strange thing happens to me. I'll be helping somebody out on IRC - usually a beginner - answering a number of their questions in rapid succession, about a variety of topics. Then after a while, they call me a "genius" for being able to answer everything they're asking; either directly, or while talking about me to somebody else.

Now, I don't really agree with this "genius" characterization, and it can make me feel a bit awkward, but it shows that a lot of developers have a somewhat idealistic and nebulous notion of the "genius programmer" - the programmer that knows everything, who can do everything, who's never stumped by a problem, and of which ther

ashnur

The One Secret Trick To Becoming A Genius Programmer

Okay, the title of this post is a bit of a lie. There's no one secret trick to becoming a genius programmer - there are two, and they're more habits than tricks. Nevertheless, these kind of 'secret tricks' seem to resonate with people, so I went for this title anyway.

Every once in a while, a somewhat strange thing happens to me. I'll be helping somebody out on IRC - usually a beginner - answering a number of their questions in rapid succession, about a variety of topics. Then after a while, they call me a "genius" for being able to answer everything they're asking; either directly, or while talking about me to somebody else.

Now, I don't really agree with this "genius" characterization, and it can make me feel a bit awkward, but it shows that a lot of developers have a somewhat idealistic and nebulous notion of the "genius programmer" - the programmer that knows everything, who can do everything, who's never stumped by a problem, and of which ther

ashnur

• If "rebasing" means you're expected to do force pushes then I guess I don't understand what "rebasing" is or what you would want to do it. I think the easiest way to keep "pretty" branches in the repo is to use GitHub's "squash" option when merging a PR. There is a reason to keep the repo "pretty" -- it can make future investigations with "git blame" easier -- but developers keeping their own development branches "pretty" sounds like a total waste of time.
• That said, we haven't bothered to keep the repo "pretty" (here, or on my previous 2 jobs) and it never burned us, I think because investigating historical changes is comparatively rare, and when it happens, you're willing to put in some extra effort anyway.
• tl;dr If I have to come down on one side or the other, I'm "Don't rebase".

ashnur

type StringBool = "true"|"false";


interface AnyNumber { prev?: any, isZero: StringBool };
interface PositiveNumber { prev: any, isZero: "false" };

type IsZero<TNumber extends AnyNumber> = TNumber["isZero"];
type Next<TNumber extends AnyNumber> = { prev: TNumber, isZero: "false" };
type Prev<TNumber extends PositiveNumber> = TNumber["prev"];

ashnur

[alias]

    #  === Common Commands ===
    s        = status                # Shortcut for status
    b        = branch                # Shortcut for branch
    a        = add                   # Shortcut for add
    d        = difftool              # Shortcut for difftool
    m        = mergetool             # Shortcut for mergetool
    f        = fetch --all --prune
    po       = push origin           # Shortcut for push origin

ashnur

module.exports = function(api) {
  api.cache(true)
  const presets = ['@babel/react', ['@babel/env', { modules: false }]]

  return {
    sourceType: 'module',
    presets,
  }
}

ashnur

// https://hackernoon.com/web-components-the-react-way-8ed5b6f4f942#.5em3zpgin
const store = (() => {
  let state;
  return todos => {
    if (todos) {
      state = todos;
      render("todo-list");
    }   
    return state;
  };  

ashnur

// Helpers
const $ = (selector, parent) => (parent || document).querySelector(selector)
const $$ = (selector, parent) => (parent || document).querySelectorAll(selector)
const $$$ = (selector, cb, parent) => Array.from($$(selector, parent)).forEach(cb)
const $s = (selector, eventName, cb, parent) => {
  //we expect dom to be loaded here
  //so if we can't find the elements it means that the callbacks
  //are not expected to be invoked
  $$$(

ashnur

license: mit

ashnur

#API ##Application Programming Interface Either you write Applications, or you connect to them. For Payments, for Identification, for Storage, for Connectivity and so on and so on, you will use more things the more people you want to reach. You need to connect to already existing networks so you need to learn the languages that software use to talk to each other This language is collectively called as the Application Programming Interface

In general there will be good API and bad API, meaning the more effort it is to deal with it, the worse it is. Good API in general doesn't require too much effort from anyone.

I believe that to achieve a good API, two things has to remain true in the lifetime of the API:

• no surprises, that is, no changes and no hidden quirks that are uncovered only in practice and require workarounds