I’m a programmer, but I’m not quite sure how to effectively apply the Zettelkasten method in my work
Hello. I am Korean.
Therefore, the text I am currently writing has been completed using a translation tool. I kindly ask for your understanding.
First of all, I am a programmer.
I am currently trying to build a PKM (Personal Knowledge Management) system using the Zettelkasten method. Although I understand most of the core concepts, I still struggle to grasp how to apply it effectively from a programmer’s perspective.
Previously, I used Tiago Forte’s PARA method to take notes, and I was fascinated by the idea of writing documents in a style similar to Wikipedia.
However, I realized that I was not gaining as much as I expected from that approach. In my pursuit to become a better developer, I began looking for a new method—and eventually returned to the Zettelkasten approach, which I had tried before but failed to stick with. Now, I’m giving it another serious attempt.
The following is one of my PARA-style documents:
---
title: "@RequestMapping"
date: 2025-02-20
author: Joung Dong Hee
tags:
- Spring
- SpringMVC
- Annotation
- RequestMapping
aliases:
- "@RequestMapping"
type: Technical Summary
created: 2025-02-20
---
# @RequestMapping
The `@RequestMapping` annotation maps a client-requested URL to a method. It is registered in the `HandlerMapping` to be invoked by the `DispatcherServlet` during the application's execution.
## Basic Usage
```java
@RequestMapping(value = "/test", method = RequestMethod.GET)
public void test() {
// Request handling logic
}
```
- **value**: Specifies the URL path. Multiple paths can be set: `value = {"/test", "/test1"}`
- **method**: Specifies the HTTP method (`GET`, `POST`, `PUT`, `DELETE`, `PATCH`)
- If omitted, all HTTP methods are allowed
---
## Annotation Evolution
Previously, it was common to use `@RequestMapping(method = RequestMethod.GET)`, but annotations like `@GetMapping`, `@PostMapping`, etc., were introduced for simplicity.
### Example: Internal structure of @GetMapping
```java
@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@RequestMapping(method = RequestMethod.GET)
public @interface GetMapping {
}
```
- `@Target({ElementType.METHOD})`: Usable only at method level
- In contrast, `@RequestMapping` can be used at both class and method levels (`@Target({ElementType.TYPE, ElementType.METHOD})`)
---
## Advanced Attributes: `consumes`, `produces`
`@RequestMapping` can specify the media types for request and response.
```java
@RequestMapping(
value = "/json",
method = RequestMethod.POST,
consumes = "application/json",
produces = "application/json"
)
public ResponseEntity<User> postJson(@RequestBody User user) {
return ResponseEntity.ok(user);
}
```
- **consumes**: Specifies the Content-Type of the request body
- **produces**: Specifies the Content-Type of the response body
---
## URI Path Variables: @PathVariable
Use `@PathVariable` to handle dynamic URLs.
```java
@RequestMapping(value = "/user/{id}", method = RequestMethod.GET)
public String getUser(@PathVariable("id") Long id) {
return "User ID: " + id;
}
```
- A request to `/user/3` maps `id = 3`
---
## Spring MVC Request Flow Overview
```plaintext
Request → DispatcherServlet
→ HandlerMapping → Search for handler based on @RequestMapping
→ HandlerAdapter → Execute method
→ ViewResolver or handle with @ResponseBody
```
Within this flow, `@RequestMapping` registers the URL and method with `HandlerMapping`, allowing the appropriate handler to be invoked during a request.
---
## Additional Annotations
### @RequestParam
```java
@RequestMapping(value = "/greet", method = RequestMethod.GET)
public String greet(@RequestParam String name) {
return "Hello, " + name;
}
```
- A request to `/greet?name=John` returns "Hello, John"
### @RequestBody / @ResponseBody
```java
@RequestMapping(value = "/user", method = RequestMethod.POST)
@ResponseBody
public User createUser(@RequestBody User user) {
return user; // Returned as JSON
}
```
- `@RequestBody`: Converts the request body to an object
- `@ResponseBody`: Converts the object to an HTTP response body (usually JSON)
---
## Class-Level @RequestMapping
```java
@RequestMapping("/api")
public class ApiController {
@RequestMapping("/test")
public void test() {
// Handles /api/test
}
}
```
- You can specify a common base URL at the class level
---
Can set a common base URL at the class level
If you have any examples or references of how you structure your notes, I would be extremely grateful to learn from them.
Edit @ctietze: Changes formatting of the sample note for the forum
Howdy, Stranger!
Comments
@JoungDongHee Welcome to the forum! I tweaked the formatting a bit so that the extent of your note is visible and distinguishable from your prose.
Your note looks like a comprehensive overview that can help as a personal documentation. So that can be useful! I do have notes like that, too.
And you need to start somewhere, so documenting the 'facts' of your craft (what subsets of APIs like
@RequestMappingannotations in Java look like) can be a starting point to collect foundational knowledge. After all, if you know Java, there's no point in pretending that you need to start from Java 101, "Hello World", and build up from first principles. It makes more sense to start at a point that is beneficial to you now.When I imagine you do this for a while, you'll probably have more notes on Java @-annotations. So I can imagine that you will end up grouping these, because they are similar. That would be curating the information you collect.
But even later on your journey, collecting all the annotations that you know may turn out to be of little use in your day-to-day work, because you never ask yourself the question: "which annotations do I know, and which should I pick today?", like you would ask yourself which pair of jeans to wear today
Or maybe I'm wrong, and the list of all @-annotations in Java in your Zettelkasten can become useful as you write a note about how and why to create these annotations as a library author, with plenty of real-world examples to link to. That is not mere curation of info anymore, that's creating something new. A tutorial (for yourself, for co-workers, ...), backed by examples you collected over the years, which you can contrast and compare, extracting best practices (short names that compose well) and annoying practices (annotations everywhere, and the order they are being applied getting confusing, ...). That could be your personal opinion, or maybe just curating the sentiment of the community. Either way, it's an intellectual effort!
I believe that then, you will look back at the note from today, see the middle part like this:
## Advanced Attributes: `consumes`, `produces` `@RequestMapping` can specify the media types for request and response. ```java @RequestMapping( value = "/json", method = RequestMethod.POST, consumes = "application/json", produces = "application/json" ) public ResponseEntity<User> postJson(@RequestBody User user) { return ResponseEntity.ok(user); } ``` - **consumes**: Specifies the Content-Type of the request body - **produces**: Specifies the Content-Type of the response body... and think something like: this captures the "What" (
consumesandproducesparameters) and the "How" (e.g. where they go, with an example), but you could write more about the "Why". The motivation to look at this will be the problem that the audience (future you) will want to solve. "Dang, how do I specify to download a file/produce a JSON API response again?", for whichproduceswill be relevant; or "I need to process a client app request with JSON payload, how do I do that again?"I find myself writing many "how to", or procedural/process notes when it comes to programming. Like cooking recipes. "This is how to make banana pancakes", or "This is how to accept JSON payload in my Java API backend with RequestMapping". It's the same
Behind these procedures, you can look for motivations, the Why, which is either stakeholder-led (or think: user stories; "as a customer, I want seamless access to my data on all devices", so you implement an upload endpoint, and the lingua franca of data exchange is JSON, so how do you accept that, etc.) or the motivation itself is problem-oriented and process-like, like issues/tickets in your project management often are ("Add HTTP POST API endpoint to accept JSON upload from the client" could be a ticket, and a problem statement that is your motivation as a coder).
Author at Zettelkasten.de • https://christiantietze.de/
I'm a part-time intermediate Python coder. Here's how I apply it in my ZK. My case may be too simplistic for an advanced coder like you, but I'll share anyway.
In the #coding tag, I have
This is a perennial question without a clear answer. Each coder has their tolerance for the pain of note-taking and the need to find things they've seen before. Some of this is simply a way to organize references. The main benefit I gain from it is that writing the note encourages me to think about the problem in a different way, which reinforces my learning.
Will Simpson
My peak cognition is behind me. One day soon, I will read my last book, write my last note, eat my last meal, and kiss my sweetie for the last time.
kestrelcreek.com
I'm a computer engineer and consultant. :-)
It's a very big question.
Developing requires a lot of learning and reflections, Zettelkasten is a real effective tool to address these two requirements, so the use of such learning and thinking system is for me natural in context of software development.
Zettelkasten is not just a method of taking notes: it is a system for building active knowledge. And that is exactly what is needed in software development.
Development is much broader than simply "coding": it is a continuous repetition of encounter a problem, ask yourself how to solve it, explore the literature searching solutions and ispirations, develop a solution from knowledge and thought, and connect the solution found to a network of other instances of the same type, transform everything into acquired experience.
And Zettelkasten worklow can be mapped to every step of this path.
I don't know your level or knowledge, but the best example I can provide you is the the catalog of object oriented design patterns.
It was almost certainly not developed with a zettelkasten, but it is very easy to imagine that something like this could be developed with a zettelkasten.
One idea (and not not the only possible idea) of having a "development zettelkasten" is building things like this in an emergent way, day after day, bringing instances of our daily problems, questions, answers and solutions and abstracting and decontextualizing higher-level concepts, and making a network of all of this stuff.
I've made this process in the last two years many times, in the context of web site accessibility and Spring Development, for example. Yes, learning a framework in an emergent way developing knowledge from daily instances of problems to solve and questions to answer is effective for me, and creates a very tailored learning.
You can model into zettelkasten your brilliant solutions or your bad choices made today and the conseguent reflections about them, so they are available next year when you meet a similar circumstance.
And there is still place for snippets of code and refererence, of course. Having a Zettelkasten doesn't mean that all notes requires to be reflections, ideas, thoughts, concepts and so on. All you feel it will be valuable and useful for your tasks at a later time than this can be stored into a note (but better if annotated with your considerations and connected into a network).
I only suggest you to don't just disassemble and reassemble a book about Spring into notes, just cutting and pasting pieces of the book into notes, and stopping the work here. The real value of Zettelkasten emerge when you express your brain work (thinking) about these pieces close to these pieces, or starting from these pieces, or connecting these pieces with others in a way that the original source doesn't provide.
Just for a practical example, in my little network of spring zettels I haven't captured the full syntax of the @async annotation.
I've captured what is, it's purpose, a simple fragment of code and a link to a couple of articles, but most important thing I've written my considerations about and I've connected the async zettel to the train of thought that I've developed solving the problem"how to manage the requirement of low response time of Shopify API?".
The most relevant part for my future myself is not the exact syntax of the construct, but the path starting from a problem to the solution I've made in my working session.
Low response time Shopify API requirement -> generalization to low response time requirement API -> one possible solution no blocking response --> async mechanism in Spring provides no blocking response --> Pro and Cons considerations. Four or five notes in total.
Next year, new task similar to this, I can reuse the same path starting from the generalization, or writing another solution If there is one better.
Other similar thing.