I use a single app, Bear. It's a nice notes app (think Evernote but with a really refined UI).
My main goal is to have everything in one place: My journal entries, minutes from meetings at my job, project plans and working notes, book/article/film summaries, quotes, reflections. (Bear has both a Mac and iOS app which means I can note things down from anywhere.)
This enables a few things. Search across all my information from one search box. A strong incentive to take good notes because I know I'll be able to find them and reference them later. A 15 year chronicle of the things I've done.
The older blog posts I've written aren't in Bear. This is kind of dumb because they're some of the deepest and most hard-won knowledge I have. Long term, I want to move them into Bear. More recently, I started a new blog that I publish from Bear. This feels much better.
As for learning, I have a few processes that relate to recording:
1. Highlighting useful/interesting passages in books and writing notes in the margins with my thoughts on the material. For really good books, I'll pull out the highlighted passages and notes and organize them into a summary of the book in a note in Bear.
2. I have a note for each skill I'm working on (e.g. designing software architecture, estimating time frames, getting buy-in on an idea). As I practice it I'll write down things I've figured out or reflections on my application of the skill or relevant notes from books/articles.
3. I'll sometimes reference my notes about books/articles as I'm working. E.g. For some reason I've referenced the note that contains a summary of an article I read about the React lifecycle like a zillion times.
Airtable | San Francisco, CA or Mountain View, CA | Onsite | Software Engineer, Product Engineer, Data Engineer, Data Scientist, SRE, Mobile Engineer
[COVID-19: The whole company is currently working remotely. Employees can be fully remote until at least the end of 2020.]
Airtable's mission is to expand human productivity by letting everyone create tools to run their work. Our current product includes a real-time collaborative database and a rich set of UI components for building tools using this database. Airtable is like a toolkit of building blocks that people repurpose to create their own applications.
I work at Airtable as a Product Engineer. I think that creating software will be the dominant form of expression of the 21st Century. I work at Airtable because most people in the world can't program, which leaves them disenfranchised from this medium, and I care a lot about changing that. A huge number of non-programmers use Airtable every day to build the tools they need to do their work.
We're hiring software engineers for web (JavaScript + TypeScript, Node, React), iOS (Objective-C, Swift), and Android, as well as data engineering, data science, SRE, and many other roles.
We're a team with diverse backgrounds. We work in small teams, with end-to-end ownership of projects.
I had a different experience to kabdib: customization made me able to actually use emacs productively.
I joined a company where most of the devs used emacs, so I kind of needed to adopt it too. I started with very little config and it was very hard. Because many operations were different to the GUI editors I'd used before, I had to waste 20% of my brain power to consciously do things that should be unconscious (save, cut, paste etc). This made it much harder to program!
The first step was updating the config to make emacs more similar to my old editor. For example: make it so pasting text when text is selected replaces the selection. Turn off branching undo. Install a plugin that gave me an autocomplete list of every file in my current project. Make it so that if I copy text in emacs, it appears on the OS-wide clipboard. I'm sure your list of things will be different.
Another important step was getting my emacs theme to look nice. This really made me love the program a lot more. It's silly, but there we are.
The third important step was finding things that emacs does better than other editors. For me, a big one was having a terminal inside my editor (lots of editors do this now, but back then it was rare).
The danger with a natural language-like programming language is that it gives the impression . This is impossible.
I want the advantages of a natural language-like syntax (easy to read, not scary) without the disadvantages (the impression that the computer will understand whatever you type). To do this, I intentionally made the syntax only support one grammatical form of each type of statement.
Most of the stuff I have learnt from the experiences of young children using Isla comes from second hand reports from parents. I have also tested it on non-programmer adults.
There are some definite mistakes in the language.
It uses named nouns, yet in real world, we usually refer to things with adjectives and types. We say "pass me the red apple", not "that apple is called Jimmy, now pass me Jimmy".
People get confused about the difference between strings and variables.
To define a function, you make a list and add built in functions to it. This is awkward.
I feel that Ruby, Python and BASIC are too complicated for five year olds.
My aim with Isla was to make a language that avoids as much programming jargon as possible, and assumes no prior familiarity with programming. This is why I made it natural-language-like and omitted punctuation from the syntax as far as possible.
1. No principles at all. I know little about education. Since the time I started Isla, and since the time I joined Hacker School as a facilitator, I have been learning as much as I can.
2. It is not tied to any models.
3. I am aiming the language at children who are just learning to read and write. So, children between 5 and 8.
4. I don't know enough, yet, to know if Isla is better than LOGO or Alice.
I'm a student in the current batch of Hacker School. I wrote a testimonial that is not up on the internet, yet, so I thought I'd reproduce it here. Hope you guys find it helpful.
tl;dr: go.
There are eight elements of Hacker School.
First, it is unusually supportive and safe. You can ask a question to clarify something you feel you ought to know, because you will get a gentle, illuminating answer. You can write a piece of code that you worry is shitty, then shape it into something beautiful with a fellow Hacker Schooler. You are isolated from all the people whose opinion might matter to you: your friends, your family, potential employers, the internet. In short, there are no negative consequences to showing your weaknesses.
Second, it is structured. If you feel awkward in social situations, you find that you always have a place. When you program on Hacker School days, there is always a desk to sit at. At the social gatherings, you discover that everyone at Hacker School is kind and inclusive. No one is ever left standing on their own.
Third, Hacker School is an uncontrollable situation. You are guided towards the things that it is important for you to work on. This invisible hand is the aggregate of the projects that other people are working on, the fellow students who walk up and offer to work with you on your project, the subjects covered in the Hacker School library, the languages your fellow students discuss at lunch, the juicy problem your deskmates are wrestling with, and the gentle guidance of the faculty. This invisible hand plainly shows you what you have been avoiding learning, what you thought was too hard, what you didn't know you needed to know, what you didn't know interested you.
Fourth, it is a place where programming is the most important thing in the world. Imagine Florence in the fifteenth century, except, instead of painting, everyone is inventing how to program, and instead of being surrounded by Donatello and Ghiberti and Botticelli and Raphael, you are working with the startlingly sharp programmers who no one has heard of, yet. The fact that it is socially acceptable to think about programming and talk about programming and work on programming means that programming is uppermost in your mind. Which means that you get better at it very fast. (This element was copped from Paul Graham's essay on aesthetic taste: paulgraham.com/taste.html)
Fifth, there are almost no constraints on what you work on. Your project doesn't have to make money, doesn't have to build your portfolio of open source code, doesn't have to be useful, doesn't have to appeal to some particular community, doesn't have to be cool, doesn't have result in something commensurate with the effort you put in. There is one constraint: work at the edge of your programming capabilities. Which is to say: work on something that makes you a better programmer.
Sixth, there are people who are better than you and people who are worse than you. Even if you are the most inexperienced programmer in the whole of Hacker School, you certainly know more than others about a particular operating system. Even if you are the most experienced programmer, you certainly know less than others about a particular language.
Seventh, you get to talk to and work with people who have truly brilliant minds. Some are fellow students at Hacker School. Some are drafted in as speakers or co-hackers. All are your peers.
Eighth, and most importantly, Hacker School is an expression of the faculty: Sonali, Nick, Dave, Alan and Tom. They are the people you'd want teaching you because they explain things clearly and they know a lot. They are the people you'd want to be friends with because they are nurturing and fun and funny. They are the people you'd want to have with you if you got into trouble because they would impose themselves on the situation and start fixing it. In short, they examine their environment and make it better.
And:
Having David Nolen explain the ClojureScript compiler was one of the intellectual highlights of my life.
The hours at Hacker School feel precious.
This is the fastest period of learning in my life.
Hi everyone. I'm Mary and I am making Isla. It's exciting to see the language posted to HN, and great to see so much discussion.
I agree with the people who say that a programming language that apes natural language can be frustrating. Inevitably, it cannot support even a fraction of the constructions that a human brain can parse. What made me try a natural language approach is the following (contentious) ideas:
* Children find it hard to type punctuation. Natural language can be parsed without punctuation.
* Someone new to programming probably knows nothing of conditionals, loops, logical operators and functions. So, a language that codifies these concepts as jargon in the form of keywords is going to be alien.
* If you ruthlessly constrain the features of a natural language-like programming language, it's possible that you can keep the advantage of human readability and dodge the disadvantage of the "uncanny valley", as `antihero` succinctly put it. In Isla, the only expressions are instantiations, assignments (with support for objects), `if this then that` style rules (maybe), and invocation of built in functions.
* The joy of programming is in building something. To get children interested in programming, the language they use needs an application. Children love telling stories, so why not make the application a story-telling environment? This gels nicely with the sparse feature set of the language: writing a story is mostly a matter of data definition.
This is the first programming language I have ever made. All these ideas are theories. Isla is just my first shot in the dark.
* Principles: https://www.amazon.com/Principles-Life-Work-Ray-Dalio/dp/150...
* The Effective Engineer: https://www.amazon.com/Effective-Engineer-Engineering-Dispro...
* High Output Management: https://www.amazon.com/High-Output-Management-Andrew-Grove/d...