Write more, coder inspiration, queryable coding environments

Simon Willison on writing about one's work:

A tip for writing more: expand your definition of completing a project (any project, no matter how small) to include writing a blog post (or README or similar) that explains that project

Without this you're skipping a relatively small step that unlocks a huge chunk of the value in the work that you have just completed!

This advice goes for internal company work too

I set up an internal blog at a previous employer using Confluence (because it was already available and has a good-enough blogging feature), but even something as simple as a dedicated Slack channel can work well for this purpose

And, writing more by lowering standards 😮

And as always: one big secret to writing more is to lower your standards

Published but "could have been better" is massively more valuable than something that eternally sits in your drafts

One of the biggest productivity improvements I ever made to my blogging was when I gave up on my desire to finish everything with a sparkling conclusion that ties together the whole post

Now I embrace abruptly ending when I've run out of things to say instead

Spoiler: I’m following this advice right now! 📈


Thorsten Ball collects greatest hits by Steve Yegge (who coincidentally just joined Sourcegraph):

And, on books/screencasts/blogs that have influenced him most as a programmer. A few that have influenced me too:

  • Destroy All Software
  • PeepCode Play by Play
  • Pragmatic Progammer
  • Practical Object-Oriented Design in Ruby
  • Agile Web Dev with Rails
  • Rands in Repose
  • Code Complete
  • 37signals' books


Codebase as Database: Turning the IDE Inside Out with Datalog:

I’ve been wondering: what if this codebase model was as queryable as a database is? What new questions would we ask of our codebases, and what new ways would we find to visualize them? Furthermore, what if the language semantics themselves — types, completions, errors, etc — were specified as queries, which were also introspectable?

I believe that the design of languages and programming environments should not just be the province of a small priesthood of elite developers. Everyone should be able to look under the hood of their IDE, and be free to push its boundaries: embed it in a different context, create a domain-specific language with rich editor support, fork an existing language to play with its semantics, etc.

The opacity of the IDE’s inner model — and the rules by which that inner model is updated — are barriers to this being a reality. For IDEs to be introspectable and hackable, we must first expose this model and these rules: we must turn the IDE inside out.

Sign me up for queryable, malleable IDEs. I like RubyMine and JetBrains' development products a lot. But, I often pine for the speed and low-ceremony extensibility of Sublime Text (or TextMate, back in the day). So let's through "as easily queried as a database" on the pile while we're at it. 😆

See also: Sourcegraph, language servers. (Someone in the back is yelling Lisp, the "Freebird!" of software development.) Furthermore, I wish Jetbrains' MPS was less Java-centric and more tractable.

Adam Keys @therealadam