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):
- Rich Programmer Food, on compilers
- Notes from the Mystery Machine Bus, on the political philosophy of software engineering
- The Google Platforms Rant
- Execution in the Kingdom of Nouns, on the ills of typical mid-2000s Java/OO design trends
- Bonus: I had no idea Steve Yegge has an active YouTube channel.
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.
