Software developers are always using libraries developed by others. The functions of the libraries are from string processing to task queues. Have you ever considered developing your own software library? This talk is to discuss some issues related to "developing software libraries": 1. What are the benefits of developing a library? 2. What are the usual differences between library and non-library code? Have you heard of mechanism code vs policy code? 3. What are the characteristics of a good library? 4. Where can you easily find opportunities to develop libraries? How to start?

1. Create Your Library
Laurence Chen
CEO @ REPLWARE
https://replware.dev

2. About Me
● Clojure community organizer
● IT Consultant, speaker, writer
● https://leanpub.com/errors_to_innovation/ (
從錯誤到創新)
2

3. Agenda
1. Why should you consider to create
libraries?
2. Policy vs Mechanism
3. What are the properties that a good
library usually has?
4. How to start? Where to start? The end?

4. 1. Why should you consider to
create libraries?
● The key to fast development iteration, low
error rate and long-term maintainability.
● Why?
○ It reduces cognitive load and manual work for
people who use the library.
● Side effects:
○ A good way to separate the source code
repository (team works)
○ Your ego and fame (The most important thing!) 4

5. Why? language oriented diagram
5

6. Library and git repo
(code splitting)
Each library has
its own repo.
6

7. Your fame and ego
● Do not need to prepare for the white boards.
● Enjoy being a distinguished engineer.
● Have friends (actually users) all around the
world.

8. 2. Policy vs Mechanism (Non-
library vs library code)
8

9. 9

10. 3. Properties of a good library
● Provide solution for mechanism
● Documentation
○ Rationale
○ Usage example
● Tests
● Change logs
● No breaking changes after version 1.0.
10

11. 4. How to start?
Where to start?
The end?
● Build up your expertise.
● Find the incongruity.
● Make the library looks like certain part of
your programming lang. Extend your tools.

12. Build up your expertise
● Start from reading into the library you are
using now.
○ It is just one level higher than you.
○ Can you Jump to definition through your IDE
or editor?
● Choose better library.
○ Avoid the red flags. For example, huge
dependency for little benefits.
12

13. Expertise cycle
13

14. Find the incongruity
● Compare different programming language
● Focus on incongruity:
○ The existing solution is not as good as similar
thing on other domains.
○ The existing solution to the problem looks like
a work around.

15. Incongruity from comparing
programming lang
15

16. The bottleneck of a workflow
16

17. Extend your tools
● Example of extensible systems:
○ Lisp - Lisp macro
○ Java - Object & Polymorphism
○ Postgres - user defined function, user defined types
● Is your editor extensible?
○ Can you automate certain things by using your
editor’s command?
○ vim - integrate shell’s filtering command
● Is your programming language extensible?
○ Does it allow Lisp macro? (meta programming)
○ Does it provide polymorphism mechanism?
17

18. 18

19. 19

20. Conclusion
● Create your own library for productivity.
● Mechanism vs Policy
● Build up your expertise by reading into
libraries.
● From incongruity comes the innovation.
● Extend your tools.

21. Reference
● JetBrains: Language Oriented Programming:
The next programming paradigm.
● Mechanism vs Policy
https://lambdaisland.com/blog/2022-03-10-
mechanism-vs-policy
● Leveling up
https://lambdaisland.com/p/leveling-up