a73x

+ _{high effort, low reward} + + +

Simplifying Interfaces with Function Types

In Go, you can define methods on type aliases, which means that we can define a type alias of a function, and then define methods on that function.

+ +

Example

+ +

Given the following interface

type DB interface {
+	Get(string) (string, error)
+}
+

You can fulfill it using a function type like this:

type GetFn func(string) (string, error)
+
+func (f GetFn) Get(a string) (string, error) {
+	return f(a)
+}
+

Now you can use GetFn whenever a DB is required:

func main() {
+	var storeFn DB = GetFn(func(s string) (string, error) {
+		return "bar", nil
+	})
+	fmt.Println(storeFn.Get("Foo")) // Outputs: bar
+}
+

You can try this example in this [Go Playground](https://go.dev/play/p/hyBNIMblafs

+ +

How it works

+ +

In Go, interfaces are implicitly through method sets, which means any type (including a function type) that defines the required methods satisfies the interface. By defining the Get method on the GetFn type, the compiler treats GetFn as a valid implementation of the DB interface.

+ +

This flexibility allows you to use function types as lightweight, dynamic implementations of interfaces, without the need for full struct definitions.

+ +

Application

+ +

One common use case for this pattern is testing. Instead of implementing a full mock, you can use an inline function to provide test specific behavior.

func TestHandler() {
+    mockDB := GetFn(func(key string) (string, error) {
+        if key == "foo" {
+            return "bar", nil
+        }
+        return "", fmt.Errorf("not found")
+    })
+
+    result, err := mockDB.Get("foo")
+    fmt.Println(result, err) // Outputs: bar, <nil>
+}
+

This approach is not limited to testing. It’s also useful for dependency injection, where you can pass in lightweight or context specific implementations of an interface.

+ +

This pattern is similar to how http.HandleFunc works. In the HTTP package, http.HandlerFunc is a function type that fulfills the http.Handler interface by implementing its ServeHTTP method. This allows functions to act as handlers, providing great flexibility in designing web servers.

+ + + +

a73x

+ _{high effort, low reward} + + +

You and Your Career

+
The unexamined life is not worth living
+
- Socrates (probably)
+

+ +

If you’ve not listened to You and Your Research by Richard Hamming, I highly recommend it—you can also read the transcript here. Hamming’s talk emphasises the importance of examining your career and the choices you make. Whilst the talk specifically speaks about research, it’s fairly easy to draw parallels to software engineering—you only have one life, so why not do significant work?

+ +

Hamming doesn’t define significant work, nor will I—it’s deeply personal and varies for each individual. Instead, he outlines traits he’s seen in others that have accomplished significant work.

+ +

Doing significant work often involves an element of luck, but as Hamming puts it, ‘luck favours the prepared mind’. Being in the right place at the right time will only matter if you have the knowledge or skills to execute. Creating opportunities is important but wasted if you aren’t ready to perform. Conversely, having the ability to perform but no opportunities can feel just as futile. The key lies in striking a balance—cultivating both readiness and the conditions where luck can find you.
Knowledge and productivity are like compound interest—consistent effort applied over time leads to exponential growth. In a field as vast as software, even a surface-level awareness of an idea can prove valuable when the time comes to use it, while deeper understanding builds expertise. Mastering the fundamentals is crucial; they are learned once and applied repeatedly in various contexts.
Maintain enough self-belief to persist, but enough self-awareness to recognise and adapt to mistakes. Software is more akin to an art than a science—there are no perfect solutions, only trade-offs. Success often lies in minimising the disadvantages rather than chasing absolutes.
To do important work, focus on important problems. What do you care about deeply? How can you work to address it? The answer is personal, but taking time to reflect is crucial.

+ +

These aren’t all the points Hamming raises, but some points that stuck with me; I highly recommend listening to the talk yourself so that you may draw your own conclusions.

+ +

The average career is only 80,000 hours, so spend it well.

+ + + +