When I was a young, opinionated software professional, I would have agreed with this wholeheartedly. But now that I'm nearly a couple of decades into my career, I've seen 1000 different workflows justified by "we're different, we're unique".<p>And if you ask how they're different so that they'd need a unique process to manage bugs, to manage invoices, to manage inventory, you get pretty much the same answers across the board. You hear about personalities and power structures and anecdotal preferences.<p>And sure enough, that's exactly what you see at the link:
<i>Each person’s mind works a little differently, and each person remembers and processes information a little differently.</i><p>Yes, you're unique. Just like everybody else.<p>The fact is, the great tools that have achieved widespread adoption understand the problems, and all their caveats, better than you. Picking any established tool to manage information and workflow and getting good at using it will usually yield better results.<p>The search for the <i>perfect</i> tool or the <i>perfect</i> workflow or the <i>perfect</i> process always ends up being the enemy of good.
I implement workflows for a living and it is a million times easier to adapt your process to the tool than the other way around. You will spend more effort adapting the software than the people.<p>That's for business but I think it applies to individuals as well. You're much more adaptable than software. Pick the thing closest to what you want and change how you work to fit the software.
The best experiences I've ever had is when you do a bit of both. I've mostly worked in areas where the steps in the workflow were designed to support some mandatory process steps for various compliance or legal reasons. Within a process step there's usually some give and take in the local workflow but most of the eventual users of the software are all too busy to spend lots of time learning new tools and tool workflows. So the solution?<p>1. Map these intraprocess workflows by talking to the users, find the biggest pain points for automation.<p>2. Build highly modular tools that implement those workflows and automate those pain points.<p>3. Deliver the tools into the environment and wait a bit.<p>4. Re-interview the users and find places in the workflow that are now the newest biggest pain points. Goto step 1.<p>It's a pretty simple process and not hard to do. If you do it right, over a very short period of time you deliver working tools that improve the user's day-to-day jobs and then just...continue to make it better.<p>Fairly often, after a few iterations, you end up just completely automating entire workflows and I've never had users get upset about this. It usually turns out those were boring, dull, and repetitive things they had to do and they hated spending hours of their days doing them anyways. Freeing them up from doing those things means they could move on to higher-value work that was far more interesting for them.
Note that the author specifically means <i>personal</i> (not <i>shared</i>) workflows:<p>> The Eureka moment that some of us feel when we finally find a notes app or todo system that fits our brains – that epiphany happens when the tools we use mirror the way our minds work, and how we want to move information through our lives. Good tools fit perfectly around our workflows, bad tools don’t.<p>> When we resort to having other people build tools for us, the tools they build might never quite perfectly fit our workflows, because they’re not built for our individual minds.<p>He goes on to advocate building yourself exactly what you need.
These kind of things are nice and all, and on a certain level I agree: shape your environment to do the hard work for you.<p>However, when considering overall productivity, it’s very easy to fall into the trap of yak shaving, and you’ll end up with doing a lot of work in order to be “more efficient”. This always rubs me the wrong way.<p>And it is for this reason I typically prefer some integration into a tool that I’m already using, rather than using a vast amount of tools that I need to integrate myself.<p>In the end I settled on emacs for most of my things here, and since I’ve been using it for over 20 years, the investment into learning ELisp etc pays of a lot. I much rather prefer to work with the framework that eg org-mode provides, than try to find some tool that is “just a little bit better!”<p>Yes, it may be better, but in the end it will involve a lot of work to tie everything together. I simply don’t have the time to do that.
This sounds a bit like "the computer is meant to serve the user; the user is not meant to serve the computer." It's a valid sentiment, and one I use on my peers often, especially when dealing with end-user-facing software and systems.<p>But when it comes to Software Engineering Workflows, I've learned in my decades of experience that the progenitors of a process or workflow had no idea how to do it, made the assumption that no one had done it before (or that buying a solution would be too expensive), and then just cobbled something together to get the product built and out the door. They start hiring more employees who spend an inordinate amount of time just understanding the existing workflow and soon lapse into "well, it's not my problem - it produces output, and I just need to fix bugs / add features to the product."<p>Before you know it, you're ten years in, with a couple dozen white-labeling clients, and that build system can't scale.<p>What I feel like we need is an encyclopedia of workflows. So you wanna make an app: make several decisions now, and here's the recommended design workflow, engineering workflow, testing/staging/release workflows ...<p>BRB, I think I just found a consulting idea...
Classically, that's a mistake. You end up automating an inefficient process. That's from manufacturing technology. The most cost-effective way to do something automatically at high volume may look nothing like the manual process.<p>Here's a good example. This is a machine making N95 masks.[1] It works about the same way someone would do it by hand. It's the obvious approach. It's painfully slow to watch.<p>Here's a machine making paper cups.[2] The process looks very strange. It's over 5x faster than the mask machine, and it's doing a more complicated job.<p>But this guy is talking about phone apps and stuff for people who work at desks, not automating a manufacturing line.<p>One big problem in the US is that there are not enough smart people making machines like [2]. And too many people making things like what the OP is talking about.<p>[1] <a href="https://www.youtube.com/watch?v=-I4Ew4rWrXQ" rel="nofollow">https://www.youtube.com/watch?v=-I4Ew4rWrXQ</a><p>[2] <a href="https://www.youtube.com/watch?v=x3Vx5y0Yg3Q" rel="nofollow">https://www.youtube.com/watch?v=x3Vx5y0Yg3Q</a>
I love the principle of owning your env, using the right tool for the job (which may involve acts of creation)... but this<p>"Some of my apps, like Ligature and Noct, are written in Ink, which is a language I wrote myself"<p>is both impressive (truly next-level), and also completely out of reach / impractical for the vast majority. But it is inspirational; thanks for sharing -- your other blog posts look worthwhile too...
The dichotomy between tasks and notes doesn't make any sense to me either. The distinction between short and long term things makes more sense, mentally and also technically - apps that have complex features to organize notes always load so slow that they're useless for quickly jotting down thoughts. But still I hate having my thoughts siloed into different apps. I hate having to decide what app to use to write down a specific thought, I hate having to decide which app to search. I made my own app[1], which is currently only useful for short term notes and tasks. I hope with Svelte I can add some features to make it possible to relate notes, to make it more useful for long term projects, while still keeping the app fast enough to be useful for quickly jotting down thoughts.<p>[1]: <a href="https://thinktype.app" rel="nofollow">https://thinktype.app</a>
I ran into this problem when editing videos. I automated some repetitive tasks that make life easier.<p>I have a scripts to move clips off of SD cards into a date sorted folder structure. I have three cameras and a phone, and usually want to get clips from the same date on different devices (SD cards) into one folder on my backup drive.<p>There's also a problem when you film yourself, that lots of footage is wasted without action. Yesterday I recorded a video that was 10 minutes long, but only used the middle 2 minutes. So I used a script to chop up the video, then deleted the useless parts.<p>I also use Typora (mark down editor) for planning and notes. Highly recommend it.<p>If anyone is interested:<p><a href="https://typora.io/" rel="nofollow">https://typora.io/</a><p><a href="https://github.com/andrewning/sortphotos" rel="nofollow">https://github.com/andrewning/sortphotos</a><p><a href="https://github.com/c0decracker/video-splitter/blob/master/ffmpeg-split.py" rel="nofollow">https://github.com/c0decracker/video-splitter/blob/master/ff...</a>
The headline doesn’t really reflect the post body. The author is advocating for writing your own software tools for your own personal note taking and organizational use.<p>First off, their tools are very beautiful from the screenshots, and if they work for them great! However I can only think of the time liability they are (they even wrote the language they are written in). I can only imagine how much time this person sinks into making them. If that’s what you love doing great! But for the vast majority of people that’s not reasonable. They are pretending that it’s a high productivity approach. It’s not.<p>Productivity = results / time<p>Spending a few dollars (equivalent to working for an hour lets say) and getting a high quality tool that would take you months to build yourself, is the high productivity solution. Many tools allow a high degree of customization and plugins, which allows people to really make it their own as well.
Quite impressive to build so many different tools, but I feel it's procrastination.<p>Having a super customised calendar, drawing app, todo etc is going to improve productivity by what,10%?<p>And building all these tools is many months to a year's work?<p>What if they'd used off the shelf tools and spent their time building something new vs reimplementing so many wheels?
My rule of thumb for software tools: first do something the annoying, hard, manual way. Then introduce equivalent third-party tooling once you understand how those tools work, why they help, and what problems (in the manual workflow) they are trying to solve.
I don't <i>know</i> how my mind works! I don't know what workflow is best for me! So tools made by others is how I discover what workflows are even possible.<p>> one place where my mind works differently than the tools on the market is the task/notes distinction<p>I wonder if you actually discovered this when testing Notion, which doesn't have that distinction ;)
It's super cool to see this kind of self-sufficient toolmaker mentality can still thrive in today's world of big, interconnected, and multi-disciplinary software teams. It feels like a throwback in a way, but also it highlights the power of simplicity and YAGNI. Of course the fact that the tools are personal makes the tradeoffs easier to reconcile, but even as you start to scale and generalize it's worth questioning if a simplified, less feature-rich solution can generate more leverage to your particular problem.
Nicely written. I think the "Importance of Ownership" is the prime reason for doing this, but most people wont see the benefit (until it is too late when they do lose something)
If you're working with a framework or tool, you should be as idiomatic as possible. Follow the best practices of that tool. It's not because you can't do it better, you might be able to. The reason is because when someone inherits the project from you or you need to onboard someone, all of their prior knowledge will apply to your build, and all the documentation and help forums for that tool/platform will actually apply to your project.<p>Part of this is ego I think. Many of us have landed jobs in agencies or at companies who produce commodity software using a framework or tool, and we see things about them that we feel we can do better. But if you're working with a client and they've decided on a framework, part of that decision is the implicit understanding that you will build them a platform that every developer using that framework can work on.<p>It's not unlike choosing to use Volkswagen vans for a transport business because you have a good community of Volkswagen mechanics. If they ask you for a VW, and you give them a VW that has a Ford engine and a Nissan transmission, they're going to be pretty confused and annoyed when the mechanics tell them they can't work on this and need to rebuild it.
This is excellent stuff. It fits right into the hacker ethos of hacking to serve your purposes instead of settling for tools that probably won’t just because they’re more convenient.<p>If you don’t mind me asking, how much effort did it take you to develop each tool, and did you find that as you did more tools, subsequent ones took less time to develop and/or were more capable?
This is an incredible amount of work for personal tools!
Do you ever miss features from traditional note apps, CRM, and web page builders? Does tool maintenance get in the way of your work?<p>I do agree with your argument about building tools to fit your workflows. Low code and no code tools will bring down the cost of custom tools dramatically.<p>Companies don't update their tools enough because people hate changing their workflows. I've worked with customer support teams and change in workflows is a big reason why they don't want to buy a 'better' SAAS tool. They'll lose productivity in short-term with a new product that's different.<p>(shameless plug-I started an open source project to let companies build their own self-hosted tools and workflows. <a href="https://github.com/appsmithorg/appsmith" rel="nofollow">https://github.com/appsmithorg/appsmith</a>)
There’s a balance to be struck. If you’re doing something that tens of millions of other people are also doing and someone has even half-thoughtfully built a tool to address the common workflow of those 10s of millions, I’d think long and hard before concluding that my use-case requires/justifies a different workflow.
Nothing like building new software for a client and having them slowly change every element to work like the old software, which they hired you to replace because it was terrible
In my experience, most folks aren't sophisticated enough to build their own tools. Having said that a workflow tool that has a default workflow that most users can adopt but also some flexibility that allows sophisticated users to adjust it to their needs without making it super complex to use is a win-win situation. I founded a company that solved a workflow problem for K-12 schools. Our initial launch was pushing school admin users to just adopt a single workflow. Most smaller schools were OK adopting it but as we went up market, we realized that even if they want to, it's very hard for bigger organizations to change their workflow (people, processes, bureaucracy). Slowly we started making the system a bit more flexible allowing them to tune it to their workflow needs.
I have always longed for the graphical version of the Unix philosophy: rather than running large monolithic "applications", you have a lot of single purpose GUI utilities with well defined input/output interfaces that can be chained together into workflows using a simple script.<p>For example: append some markdown text into a given text file; open a text file, tokenize and filter lines where token 1 matches user input; if the user input matches a certain pattern, route it to a given file etc.<p>I'm already doing this with bash scripts (and they work for me), but for this idea to take hold with non-technical people, we will need GUI utilities.
The thing that feels implicit, yet false, in all of this is that workflows are static. People evolve, learn, change. Teams even more so.<p>The most important process I implement with teams is retrospection and its use as a mechanism to modify process in a principled way.<p>So as you learn about your own process, your tools can either fall away and be replaced, or flex with you and stick around for longer. My guess is that flexibility is slightly better than fixity, as it'll let you live within one ecosystem for a little longer.<p>The other way of interaction is to be inspired by new tools to modify your process. This feels pretty off to me, at first, in that it means that you're moving your process do to exogenous things as opposed to endogenous learning.<p>But that sort of work can be really valuable too. It's good to learn other people's methods. It forms an impulse that can get you out of local optima. It's an important part of the learning process.
I have to say, I strongly disagree with this. As a professional software developer I've watched legions of clients fall into the trap of customizing tools to adapt to their specific sacred workflow. It always ends up being expensive (though admittedly profitable for me) and most importantly, it always ends up trapping the client in a situation where they cling to the customized tool for far longer than they should.<p>The moral of the story: Your workflow is not sacred. Even the way your brain "works" is not sacred. Learn to adapt or be prepared to die. If your workflow isn't changing or at least being tweaked from time to time, the odds favor the idea that you have grown stagnant. That's not to say that change for the sake of change is the preferred alternative however. I'm only saying that treating your workflow as sacred and hence immutable is a dangerous trap to fall into.
In my experience (I have a bit of that), tools tend to be whatever I need, at the moment, to get the job done. If it works well, I look to use that tool again; maybe finding a way to make it repeatable/scripted/generalized. Some tools have lasted a couple of years; seldom have any lasted for much longer. I can't afford to marry them. It's just a casual "friends with benefits" relationship with most tools and techniques.<p>Tech changes quickly. Not just the technology, but also the markets, customer bases/expectations, design ethos, and delivery/distribution systems.<p>So does the jargon, but I've learned not to waste too much time trying to keep up with that.<p>If I get too mired in the workflows, infrastructure and tools, tech can go whizzing past, while I'm polishing my scripts.
I agree with a lot of what's written here and applying it to CI/CD was what led me to build <a href="https://boxci.dev" rel="nofollow">https://boxci.dev</a><p>In my view your tools should come to <i>you</i> - for instance with CI, why should you have to go all-in porting your production build pipeline for a third-party platform and workflow when you have a build script that already works, and fast, and you really just need to change a couple of flags to build for production rather than dev? As the author says, you shouldn't change your workflow for the tool, the tool should help you with your workflow.
If you don't have a workflow, build your workflow around the tools you think you need. Then start the "build-refine-use tooling to aid the workflow that you came up with based on the tools that you're using that determine part of the workflow you have to best fit the tools that you use to help your work flow" dance.<p>If you already have a workflow, you're already more than familiar with that dance, and there is no advice.
Sometimes your work flow is shit and you need to change it. Imagine a carpenter telling you that his thumb hurts a lot when he uses the hammer to punch in a nail. Because he likes to keep his thumb on top of the nail. That's his work flow.<p>Would you spend effort designing a novel kind of hammer that grips the sides of the nail instead of striking the head? No. Just tell the carpenter to stop doing the stupid thing he has been doing.
What's trippy is whatever workflow you have is probably molded around tools and biases that you take for granted. In modern times, there is no workflow that exists independent of technology. I can't imagine a way to isolate a "workflow" from a toolchain. And at that rate, you might as well just sample different tools until you find harmony.
I want to agree with this author, but sadly the business world does not agree.<p>The reason Airtable, Notion, Monday, and others are so successful is because they do precisely the opposite of what the author is suggesting.<p>This is the same reason most workflow software starts out as a replacement to Excel and Spreadsheets, but people continue to resort to Excel and Spreadsheets.
The problem with "Build tools around workflows" approach is that everyone has a slightly different workflow, so you end up with tools that must be customized around workflows, which results in extra and unnecessary spendings.<p>This is great for software developers because it guarantees work, but bad for business because of unnecessary IT costs.
Dear Mesdames and Sirs, is this the Topic about a mechanistic Worldview and the mechanistical-Thinking, i have heard about ?<p>And an other kind of... diversity ?<p>In front of this screen, polarized, asking myself "Do i became too choosey ?" For what Narcissus -the protagonist is meant, to "think of oneself" is any good for, not ? P-:
Not all tools are designed the same way. This advice sounds good to hear but good luck finding the tools that can be customized to your workflow.<p>I always found that it is easier to make small changes to the workflow based on the tools and the tools will increase throughput and will justify the effort for the change.
What have you done with all these tools, so fitted to your workflows? What, other than the tools, have you made? How have these tools helped you build a better world for other people? There are new tools, now, yes, custom-made to fit your hands, but what of the rest of the world?
There classes of organizations for automation:<p>* Tiny, you just do things the Quickbooks/Excel/MS Word way<p>* Gigantic, you just do things the company's way, it can pay for customization<p>* In between, here you have the major problem
This is what I find so annoying with git.<p>You can do all kinds of crazy thinks with git, but
the price is that for many common workflows you have
annoying gotchas and or usability annoyances.
The link for "Lovecroft" goes to the wrong page, and I can't find this tool (for mailing lists). Anyone know what it is or where I can learn more?