Five coding hats
A new blog post
I just published a new blog post — it’s called Five coding hats:
Early in my career, I was convinced there was “good code” and “bad code”. That you could look at something and — without knowing anything about the context — pass judgement on it.
These days, my views are much more nuanced. I try to adapt my style to the situation. The code I write, and the process I use, depends a lot more on what the goals are. Am I trying to bang together a quick prototype to learn something? Or am I fixing a bug that might affect hundreds of thousands of users? My approach would be completely different in those two scenarios.
Years ago, I read Edward De Bono’s Six Thinking Hats, which describes a framework for problem solving and creative thinking. The idea is that you can “put on a hat” to deliberately adopt a specific mode of thinking. It’s a bit corny but (imo) there’s a useful idea there.
Maybe this applies to different styles of programming, too? What “coding hats” do I use?
Another post!
I also wrote a post back in November and forgot to send an email about it! It's called One way to do applied research:
In some of the communities I hang around in1, there’s a fondness for the kind of industrial research that happened at places like PARC and Bell Labs. Things like Smalltalk, Mesa/Cedar, and Plan 9 not only introduced new ideas but demonstrated them in practical, working systems.
If you want to actually do research like this, how should you go about it?
Recent TILs
(TILs are short posts about things I've recently learned.)
- Getting started with Zig
- Lightweight multitenancy for server-side JS
- Why silicon wafers are round
- Scripting GMail with Python
- Longer V8 stack traces
- Debugging shaders
- Shader performance profiling on macOS
✌️,
Pat