🔭 #1: Trunk-based Development, Wasting Time, and More
Are feature branches an anti-pattern? What is the biggest waste of time for developers?
Last week was a busy one, and I discovered a lot of fresh pieces of knowledge. The most significant change for me personally was that I started to create a knowledge base with Obsidian. One of the dominant themes I'm constantly thinking about for weeks is code sharing across teams and managing responsibilities. Related to that is my research on Git workflows, and that's how I discovered trunk-based development.
Furthermore, I thought about my definition of work-life balance and that we waste most of our time not by what we think of as typical time-wasting activities but when we feel most productive.
Creating a Personal Knowledge Base
Recently, I started to create a personal knowledge base using Obsidian. Obsidian shines when it comes to connecting pieces of knowledge.
I'm thinking about sharing it with others (maybe paid access?), but I'm not sure how useful it can be for people who are not me. Let me know in the comments if you're interested.
Trunk-based Development
I always believed feature branches are the best and only way to work with Git, but I'm not so sure anymore. With trunk-based development, you do not branch at all (or if you do, you only create very short-lived branches 1-24h max). That means all your commits go directly into the main branch (trunk), and everybody immediately has access to all the latest changes. There are two prerequisites to make this work:
Mature processes and teams
TDD
Resources
You Break It, You Fix It
I'm more and more convinced that teams should be responsible for fixing problems in the projects of other teams if they introduce breaking changes in a shared code library. Most people seem to disagree with me on that, yet, I think that if you're under the impression that it is not possible in your company, you should ask yourself why and maybe you discover a deeper problem with your processes.
Resources
Maintaining Shared Code and the Inversion of Responsibility Principle
What I learned from Software Engineering at Google, Swizec Teller
Work-life Balance
I think most people get it wrong when talking about work-life balance. It is not a quantitative thing: X hours of work vs. Y hours of leisure time. It's about the quality of the time spent. For example, suppose you only work 4 hours a day: if those 4 hours feel like torture, I'd still consider your work-life out of balance. Same if you can't enjoy yourself during leisure time (which probably sounds crazy to some people, but it is where I struggle the most). And sometimes, working a 10 hour day can feel really awesome.
Doing the Wrong Thing
I believe that most of our time is wasted not by slacking off but because we're doing the wrong things. Not just in development but in general (there are whole companies making tons of money which, if they didn't exist, would be a net benefit for humanity), but developers are particularly prone to solving problems that shouldn't exist in the first place. Unfortunately, I feel that some of my Open Source work falls into this category.
A clever person solves a problem. A wise person avoids it.
– Unknown
Possibly the most common error of a smart engineer is to optimize the thing that should not exist.
– Elon Musk
Hi Markus,
Thanks for the information share and handy links to additional reference info on various topics.
I had a look at Obsidian's page with your graph as a reference and to be honest, it's a bit vague to figure out what is is or can be used for explicitly:
"The human brain is non-linear: we jump from idea to idea, all the time. Your second brain should work the same.
In Obsidian, making and following connections is frictionless. Tend to your notes like a gardener; at the end of the day, sit back and marvel at your own knowledge graph. "
Yes our minds work in ways nobody understands completely yet. I like to refer to it as "Lateral-thinking vs Logical-thinking" processes being combined. (Read many of Edward de Bono's books in my high-school and early college years.)
However, what's the practical application of the idea map? How can we use it to re-suss old, forgotten ideas and concepts. My notebooks are scattered all over countries, in boxes in dusty corners of garages, others lost on failed HDDs, so Yes having my "paper-mind" saved safe and sound is a nice idea. And even then VeeAM can help take care of the rest.
Digging in deeper into the docs of Graph Views I see a ton of detailed "How", but I don't see examples of "Why or What". Practical use case examples will switch on my fool head.
Call me daft, but wouldn't a few examples of what can be done and why it should be done with Obsidian be helpful to set it's use and sales on fire? (simple, clear and yet in enough detail to reveal the use cases)
The documents are quite elaborate, yet I struggle to find the beginning of the learning path.
I scanned through to the bottom weaving through all the copy, but I'm still unsure. Next, I start assuming this strange thing is far to "clever" for me and I wanted to walk away by clicking close tab.
Wait, let me go look in their "About" section ... Oh, it's a note-taking app ...
If: It's me being stupid;
Then: Please slap me into the right direction and show me why I don't get it;
Else: Maybe my confusion can help find a clarification;
Result: More success in getting people using a helpful tool,
Help!
Why don't people say "What" something is, "Why" you need, "Where" to use it, "When" to use it, and "Who" it's suited for, before telling you "How" cool its and "How" it works?
Just my creative knee-jerk-side kicking in.
No intention of being an A$$hole here :-)
Thanks for your efforts,
Andre.