
Build tools around workflows, not workflows around tools - thesephist
https://thesephist.com/posts/tools/
======
trentnix
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".

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.

And sure enough, that's exactly what you see at the link: _Each person’s mind
works a little differently, and each person remembers and processes
information a little differently._

Yes, you're unique. Just like everybody else.

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.

The search for the _perfect_ tool or the _perfect_ workflow or the _perfect_
process always ends up being the enemy of good.

~~~
cheez
That's funny. I was the opposite. When I was younger, I would just say "lets
default to other people's solution to similar problems and move on" but as
time went by, I've become more "let's define our problems well and find
surgical solutions by others". It's a slight difference but makes a huge
difference in productivity.

Another way to say it is instead of taking someone else's blueprint, we build
our own blueprint and use pre-fabricated parts to realize the blueprint.

In the end, sometimes solutions look very similar but there is that one little
bit that gives you a competitive advantage that no one else has.

~~~
cratermoon
Years ago I analyzed the build vs. buy question and came up with a rule that I
later found to be not so original: buy for parity, build for competitive
advantage.

Most of any business is commodity stuff, typically things like HR, payroll,
logistics, finance, security. Except if your business _is_ one of those
functions. Take Amazon's logistics for example. They aren't just any online
retailer, they are the _dominant_ online retailer in large part because they
optimized the hell out of their logistics pipeline.

But if it's not your bread-and-butter, then yeah, go ahead and change your
workflow to whatever COTS software you pick requires. You'll be fine. I worked
for an insurance company, and they picked PeopleWare for their HR system and
used commodity software tools for their actuarials. I worked for a very large
shoe company they has SAP at the core of their (extremely complex) product
lifecycle management system because their real business differentiator is
their design and marketing.

That same insurance company had a customer sales pipeline tailored to a
specific market – high-end professionals like doctors, lawyers, and similar –
so they had custom software for that. That same shoe company had customized
design and bill of materials systems so they could get their shoes to market
quickly and globally.

~~~
908B64B197
I agree with your rule, but I would add something extra:

Only build if you have the talent to do so. Early on Amazon managed to attract
serious tech talent to the company. That enabled them to build. If a company
can't do that then it's better to buy no matter what.

~~~
cratermoon
> Only build if you have the talent to do so

I would certainly hope that if the function is part of what differentiates the
company competitively that they'd hire the talent. If they're trying to be the
best "X" company and nobody who works there is any good at "X", they _should_
fail. The dot-com era is littered with the graves of companies who thought
that just having an idea was enough.

~~~
tomnipotent
> nobody who works there is any good at "X", they should fail.

Except almost every software startup in the last three decades was started by
folks that were not experts in the domain they eventually became successful
in.

~~~
johnjj257
Citations needed

------
treis
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.

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.

~~~
freehunter
I work in professional services for a large IT vendor (and before that I
worked for a place that used that vendor’s products) and I can tell you we
spend a huge amount of time working with our customers to help them fit their
workflow to our tools. Because there is no way we can engineer our tools to
fit or enable every workflow.

Some companies have the skill and desire to build their own tools over our
products so they can use their pre-existing workflows, but inevitably the
abstractions start to leak and they almost always end up hiring us to train
them on how to use the tool the way it was meant to be used.

~~~
trentnix
I'm living that now a little bit. New tools and processes are discussed and
evaluated based on how easily they can be customized, perverted, and
eventually bastardized.

More frequently than you could imagine, people and organizations jump to how
they are going to implement something before they define what they want to
implement. And when the effort fails, the technology is blamed and they start
all over again.

~~~
Aeolun
A lot of organisations make the mistake that they think they can fix a garbage
process with more technology.

They end up finding that garbage in = garbage out

------
bane
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?

1\. Map these intraprocess workflows by talking to the users, find the biggest
pain points for automation.

2\. Build highly modular tools that implement those workflows and automate
those pain points.

3\. Deliver the tools into the environment and wait a bit.

4\. Re-interview the users and find places in the workflow that are now the
newest biggest pain points. Goto step 1.

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.

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.

------
jt2190
Note that the author specifically means _personal_ (not _shared_ ) workflows:

> 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.

> 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.

He goes on to advocate building yourself exactly what you need.

~~~
Shared404
> He goes on to advocate building yourself exactly what you need.

This is what I've started doing. I needed a site generator, was too lazy to
learn an existing one, and built something that would just do what I wanted,
and no more.

It's actually quite a nice experience knowing a tool inside and out,
literally.

~~~
jlevers
I totally support this strategy, as I think it's a great way to learn new
things, but...I think that's not what most people would call lazy :)

~~~
Shared404
I dunno. < 60 lines of a language I enjoy vs learning how to
configure/install/write for a program I don't know. Honestly the former sounds
like less of a pain.

------
stingraycharles
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.

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.

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.

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!”

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.

~~~
EFFALO
I felt that that the author was more concerned about ownership than short-term
productivity or efficiency.

With ownership a different kind of productivity is evoked: knowing how (and
why) every part goes together the way it does. This could lead to a flow state
when managed effectively.

I do agree that these exercises could lead into the realm of yak shaving, but
in this context we're talking about making personal tools vs tools for others
to use. I think there's a big distinction between these two approaches.

~~~
thesephist
OP here -- I think you captured a lot of what I wanted to express. A lot of my
DIY-ing is definitely about ownership: owning (1) my data completely,
including how it's stored and backed up and (2) the future of these tools, so
a SaaS provider can't suddenly decide next year that I'm no longer in their
target market / most profitable customer segment.

Agree on the distinction between building for myself vs. others. There are a
hundred things I'd have done differently, were I building for someone else.

------
Animats
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.

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.

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.

But this guy is talking about phone apps and stuff for people who work at
desks, not automating a manufacturing line.

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.

[1]
[https://www.youtube.com/watch?v=-I4Ew4rWrXQ](https://www.youtube.com/watch?v=-I4Ew4rWrXQ)

[2]
[https://www.youtube.com/watch?v=x3Vx5y0Yg3Q](https://www.youtube.com/watch?v=x3Vx5y0Yg3Q)

------
jagged-chisel
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.

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."

Before you know it, you're ten years in, with a couple dozen white-labeling
clients, and that build system can't scale.

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 ...

BRB, I think I just found a consulting idea...

------
chrisweekly
I love the principle of owning your env, using the right tool for the job
(which may involve acts of creation)... but this

"Some of my apps, like Ligature and Noct, are written in Ink, which is a
language I wrote myself"

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...

~~~
thesephist
I actually believe fairly strongly that it's not out of most people's reach!
I've written before [0] about my process for learning how to build a (simple)
language, and the resources that helped me do it / how I approached it.
Certainly one of my favorite projects, both intellectually and from a returns
perspective.

There are so many great resources for building a toy language by yourself (my
impl of Ink is a few thousand lines of pretty simple Go code) and it's never
been easier. I really think most people overestimate how intellectually
intractable it is. Building a production language? Yes, a lot of work. But a
toy language for you to use / learn with? surprisingly doable.

[0] [https://thesephist.com/posts/pl/](https://thesephist.com/posts/pl/)

~~~
andrewingram
FYI, there's another language called Ink
([https://www.inklestudios.com/ink/](https://www.inklestudios.com/ink/)) which
I momentarily confused yours with.

------
amadeuspagel
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.

[1]: [https://thinktype.app](https://thinktype.app)

~~~
bbbobbb
I love this. Very creative way of handling the search and persistence with the
fulltext search to have it easily work as a todo (or any other "tag") app. I
wouldn't use it in a browser with local storage only but it actually makes me
want to copy these ergonomics for my personal use with some sort of syncing..

~~~
amadeuspagel
Thanks, working on sync.

------
jungletime
I ran into this problem when editing videos. I automated some repetitive tasks
that make life easier.

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.

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.

I also use Typora (mark down editor) for planning and notes. Highly recommend
it.

If anyone is interested:

[https://typora.io/](https://typora.io/)

[https://github.com/andrewning/sortphotos](https://github.com/andrewning/sortphotos)

[https://github.com/c0decracker/video-
splitter/blob/master/ff...](https://github.com/c0decracker/video-
splitter/blob/master/ffmpeg-split.py)

~~~
nurgasemetey
I also use Typora. Very good editor for every daily notes

[https://imgur.com/HEV00M6](https://imgur.com/HEV00M6)

------
asperous
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.

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.

Productivity = results / time

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.

------
haihaibye
Quite impressive to build so many different tools, but I feel it's
procrastination.

Having a super customised calendar, drawing app, todo etc is going to improve
productivity by what,10%?

And building all these tools is many months to a year's work?

What if they'd used off the shelf tools and spent their time building
something new vs reimplementing so many wheels?

~~~
thesephist
OP here -- that's definitely a valid argument. If the only reason to do this
were raw productivity gains in my work, it /might/ be overkill. I also find it
personally satisfying to build and run / talk about DIY tools (and I'm young,
I have lots of free time), and there've been lots of extra side-benefits to
making a habit of it.

For what it's worth -- it doesn't take me much time to build these tools. Most
are an afternoon project / a weekend project. So that also makes this more
reasonable for me.

EDIT: I'm also no stranger to off the shelf tools -- I've shopped around my
fair share of todo lists and notes apps :) Just haven't found any that worked
the way I liked exactly and allowed me to own my data the way I wanted to.

~~~
haihaibye
There are so many todo list apps, maybe the problem isn't building 1 true todo
list app but rather a way for everyone to build their own todo list app.

------
jasonhansel
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.

------
floatboth
I don't _know_ 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.

> one place where my mind works differently than the tools on the market is
> the task/notes distinction

I wonder if you actually discovered this when testing Notion, which doesn't
have that distinction ;)

------
dasil003
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.

------
acutesoftware
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)

~~~
thesephist
(OP) Yep, ownership is definitely big for me. Maybe I've just been burned one
time too many by a startup pivoting away...

------
ehnto
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.

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.

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.

------
addicted
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.

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?

~~~
thesephist
My answer your second question actually feeds into the first --

These days developing each tool is 50% taking pieces of tools / libraries I've
built before and integrating them together. I've implemented a data store, a
form UI, a websocket server, etc. each a few times so as I built up a
collection of things I can borrow from other past projects, new projects take
less time (or, I have more bandwidth to tackle more complicated projects, new
a new tool if need be, etc).

I have another blog that goes into my side-project workflows[0] but in gist, I
try to make a "usable MVP" for each project within a single chunk of time --
usually a weekend. And from there I try to dogfood it and add changes that I
need to keep using it.

All this is helped by the fact that, at least with these tools I use, I try to
keep a really simple stack. Go or Node.js server running on a single VPS,
light frontend using my own framework [1]

[0] [https://thesephist.com/posts/how-i-side-
project/](https://thesephist.com/posts/how-i-side-project/)

[1] [https://github.com/thesephist/torus](https://github.com/thesephist/torus)

------
arey_abhishek
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?

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.

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.

(shameless plug-I started an open source project to let companies build their
own self-hosted tools and workflows.
[https://github.com/appsmithorg/appsmith](https://github.com/appsmithorg/appsmith))

~~~
thesephist
>Do you ever miss features from traditional note apps, CRM, and web page
builders?

Very rarely, and if I do I build them in. But my needs are pretty low -- I'm
ok with plain markdown/text for storing most data, or nicely formatted tables.
I've found that super-rich document formats with embedded this-and-that don't
actually add a lot of value for me (but of course this might be Stockholm
syndrome speaking, I suppose).

>Does tool maintenance get in the way of your work?

No, and this is a big consideration for anything I build. I try to design /
deploy apps so they require minimum maintenance. Static Go binaries + going
slim on frontend dependencies both help with this. The only real "maintenance"
I have to do is periodically reboot my Linux box and upgrade the Ubuntu
version to the next LTS every few years. All my binaries are deployed as auto-
restarting systemd services on an small VPS -- not depending on more
serverless-style platforms helps keep maintenance needs low too, I find
(though there are disadvantages, it doesn't really apply for one dude running
a dozen web apps on a single server).

~~~
bostonvaulter2
Does your note taking app support embedded files and images in-line?

------
sokoloff
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.

------
bluedino
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

------
jinal
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.

------
hliyan
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.

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.

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.

------
jaylittle
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.

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.

------
tel
The thing that feels implicit, yet false, in all of this is that workflows are
static. People evolve, learn, change. Teams even more so.

The most important process I implement with teams is retrospection and its use
as a mechanism to modify process in a principled way.

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.

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.

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.

------
ChrisMarshallNY
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.

Tech changes quickly. Not just the technology, but also the markets, customer
bases/expectations, design ethos, and delivery/distribution systems.

So does the jargon, but I've learned not to waste too much time trying to keep
up with that.

If I get too mired in the workflows, infrastructure and tools, tech can go
whizzing past, while I'm polishing my scripts.

------
davnicwil
I agree with a lot of what's written here and applying it to CI/CD was what
led me to build [https://boxci.dev](https://boxci.dev)

In my view your tools should come to _you_ \- 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.

------
crb002
The humble .plan file. [https://github.com/ESWAT/john-carmack-plan-
archive](https://github.com/ESWAT/john-carmack-plan-archive)

------
shivenigma
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.

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.

------
perryizgr8
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.

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.

------
TheRealPomax
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.

If you already have a workflow, you're already more than familiar with that
dance, and there is no advice.

------
oneelectron
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.

------
nsoonhui
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.

This is great for software developers because it guarantees work, but bad for
business because of unnecessary IT costs.

------
glaive123
I want to agree with this author, but sadly the business world does not agree.

The reason Airtable, Notion, Monday, and others are so successful is because
they do precisely the opposite of what the author is suggesting.

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.

------
V-Beerland
Dear Mesdames and Sirs, is this the Topic about a mechanistic Worldview and
the mechanistical-Thinking, i have heard about ?

And an other kind of... diversity ?

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-:

------
jtth
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?

------
JJMcJ
There classes of organizations for automation:

* Tiny, you just do things the Quickbooks/Excel/MS Word way

* Gigantic, you just do things the company's way, it can pay for customization

* In between, here you have the major problem

------
dathinab
This is what I find so annoying with git.

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.

------
natcombs
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?

~~~
thesephist
Hey natcombs, OP here :) Just fixed up the link so it should point to
github.com/thesephist/lovecroft which is the correct link! Thanks for pointing
it out.

------
dgudkov
The author spent 1700 hours to build these tools. At the rate of $100/hr the
estimated cost of development would be $170,000. Sounds a lot to me.

~~~
minimuffins
If we're just thinking about it in terms of pure money optimization, that
makes sense. Why spend 170,000 dollars when you could spend...nothing.

But it also seems the author actually enjoys building these tools. So it
doesn't actually cost him anything. The work itself is a reward instead of a
cost.

I can't say spending 1700 hours making my own tools is what I really want for
myself, but I guess different people are different (I'd hate to find out
exactly how many hours I've spent editing ~/.emacs though, tbh...)

------
wdb
Funny, this is going totally against the philosophy of SAP which basically
means to change your workflows to the way SAP works.

~~~
bostonvaulter2
SAP isn't about personal tools, whereas this whole article is focused on the
needs of a single person, not an organization.

------
m-p-3
It's easier to bend a workflow around existing tooling than the other way
around depending on the size of the business.

------
wallflower
And then there’s the saying in ERP systems: “You buy SAP and then you change
your company to fit SAP”.

------
rexpop
Is this not an aspect of Ivan Illich's "Tools for Conviviality"?

