[HN Gopher] Build tools around workflows, not workflows around t...
___________________________________________________________________
Build tools around workflows, not workflows around tools
Author : thesephist
Score : 324 points
Date : 2020-08-22 14:23 UTC (8 hours ago)
(HTM) web link (thesephist.com)
(TXT) w3m dump (thesephist.com)
| glaive123 wrote:
| 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.
| stingraycharles wrote:
| 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.
| addicted wrote:
| Every second spent on developing one of these tools will more
| than pay for itself in your professional career if your
| professional career has anything to do with software
| development.
|
| The time energy and effort will make the creator more efficient
| and more effective in nearly every project they undertake going
| forward in life.
|
| Making and learning, especially if they are in areas related to
| what you do frequently (for example, as a career) almost always
| pays off in overall efficiency and productivity.
| beagle3 wrote:
| Within reason; building e.g. your own build tool rarely pays
| but sometimes does. Building your own compiler and/or IDE
| almost never does.
| EFFALO wrote:
| 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 wrote:
| 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.
| JJMcJ wrote:
| 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
| jagged-chisel wrote:
| 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...
| ehnto wrote:
| 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.
| ChrisMarshallNY wrote:
| 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.
| jungletime wrote:
| 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://github.com/andrewning/sortphotos
|
| https://github.com/c0decracker/video-splitter/blob/master/ff...
| [deleted]
| jasonhansel wrote:
| 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.
| dgudkov wrote:
| 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.
| jt2190 wrote:
| 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.
| MarcellusDrum wrote:
| For simple things, I think I agree with what he's advocating. I
| made my own todo/tasks manager application that got my own
| needs. Took me 2 days of developing, and a few edits after
| using it for a while when I discover a bug or want to edit
| something. But I think for more advanced stuff ( a proper full
| featured bug tracker for example), I don't think it's worth the
| effort.
| maire wrote:
| Yep - I started building personal tools when I realized that
| purchased tools are to benefit someone else - not me. Their
| goal is to make money for them not to make me happy.
|
| Once I realized that I automate my own processes and I am so
| much happier. I went so far as to purchase an annual $99
| developer license even though I have no intention of selling
| apps.
| Shared404 wrote:
| > 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.
| dathinab wrote:
| 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.
| wallflower wrote:
| And then there's the saying in ERP systems: "You buy SAP and then
| you change your company to fit SAP".
| treis wrote:
| 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.
| gonzo41 wrote:
| I came here to say this. And just mention that in most IT
| workflow disasters. It's usually when the company decides it
| doesn't want to bend a knee and change it's processes to fit
| the tool.
| nabilhat wrote:
| Absolutely! The majority of tools and systems in distribution
| are templates for effective workflows. For setting up your
| personal life as in this post, by all means go bespoke in your
| area of expertise or curiosity. It's certainly not the most
| effective or efficient workflow in the world, but that's not
| why you're using it, right? When performance really counts,
| always look long and hard at what the thousands-millions who've
| trod this way before have done before bushwhacking your own
| path.
|
| While hiking around Iceland, for example, one should adopt
| established tools and methods, and adapt to them. No one's
| workflow can ever grow to accommodate that level of embedded
| efficiency and safety.
|
| Real change in business requires adopting new processes. I just
| helped a small business shift from a paper driven workflow to
| electronic. Adapting their workflow to fit established tools
| was less work than doing nothing, less effort than their
| existing process; they doubled their output literally
| overnight. We'd have been fools to try to adapt a tool they'd
| never used or heard of before to look like their paperflow.
| hinkley wrote:
| I had heard this about Salesforce years ago, that companies
| generally do better by adapting to Salesforce than by adapting
| Salesforce.
|
| In the end every quirky thing you do means more on the job
| training for all new employees. If you take quirky too far,
| then you can't hire new senior talent (everyone starts as a
| noob). And it may be very uncomfortable to look at, but you
| need to think hard about who benefits by having things be this
| way. It's not the company, and probably not the team. It's a
| couple of people and likely also their manager.
| freehunter wrote:
| 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.
| luckydata wrote:
| Sure but how much you gotta change is the difference between
| a successful implementation and a failure. Good tools are
| already close to what people do.
| wtetzner wrote:
| > Good tools are already close to what people do.
|
| I'm not sure I agree. I think good tools represent the
| problem space well, and provide powerful ways of
| manipulating/interacting with it. That may or may not be
| what people are already doing.
|
| I'd say solving a problem well is orthogonal to what people
| are actually doing.
| trentnix wrote:
| 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.
| conception wrote:
| This sounds right but in my experience most people are set in
| their ways and it is very hard to rewrite the muscle memory of
| a process. Especially since it appears that most people are
| sensors (vs intuitive if you buy Myers Briggs take on
| personalities https://personalityhacker.com/develop-intuition-
| intuitive-aw...) then it requires a whole retraining of x does
| y and a does b. In my experience it is tremendously easier to
| have a computer change then a person much less a group.
| Admittedly most people when put in the position don't have a
| choice and the cost of retraining is rarely measured but
| studies on adult learners generally point out it's hard and
| doesn't go as well as we'd expect.
| cjonas wrote:
| In general, I agree with this... There are cases in which there
| is actual value in breaking "out of the box", but it's
| difficult to calculate the ROI. It also depends on the
| licensing cost of a tool and the skill of your team. Enterprise
| software can be insanely expensive, and with the modern
| framework and the right team, it might actually be
| significantly cheaper to build features yourself. I recently
| built a DocuSign replacement which also collects payment method
| for 1/2 the cost of the yearly subscription. Turns out they
| didn't need to actually collect signatures in the first place,
| but they were doing so because they modified their process to
| fit the tool...
| ta17711771 wrote:
| That's wild.
|
| 1/2 of the subscription including your time, or no?
| cjonas wrote:
| ya really the only real cost was my time. It runs on their
| existing CRM platform so no additional infrastructure
| overhead. It's just a small react app which displays a PDF
| contract, gathers TOS acceptance and collects CC via a
| Braintree drop-in. They were sending contracts via Docusign
| (10's of thousands @ $11 per envelope!), then would still
| have to separately gather payment information and update
| the CRM to process the sale.
|
| I spoke with there legal team and turns out they didn't
| really need a legally binding signature. New system does
| everything they actually needed, without any real
| reoccurring costs.
| bryanrasmussen wrote:
| When you write a tool you do it around a workflow that you have
| observed as being beneficial.
|
| When you adopt a tool you adapt your workflow to its
| limitations.
|
| on edit: obviously this is an "ideally speaking" type
| situation.
| rexpop wrote:
| > it is a million times easier to adapt your process to the
| tool than the other way around
|
| In the short term, perhaps, but at what cost in the long-run?
| We end up with channels of accepted behavior dictated,
| undemocratically, by software teams.
| floatboth wrote:
| 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 ;)
| jaylittle wrote:
| 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.
| TheRealPomax wrote:
| 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.
| bane wrote:
| 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.
| asperous wrote:
| 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.
| wdb wrote:
| Funny, this is going totally against the philosophy of SAP which
| basically means to change your workflows to the way SAP works.
| bostonvaulter2 wrote:
| SAP isn't about personal tools, whereas this whole article is
| focused on the needs of a single person, not an organization.
| trentnix wrote:
| 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.
| momokoko wrote:
| Process is a crutch for bad management. If you are constantly
| moving from process to process because they aren't working, you
| likely need to replace a significant portion of the management
| team.
|
| Almost all processes work well enough. And there is nothing
| wrong with trying to find an optimum one. But process is not
| the solution. Quality management talent is.
| contingencies wrote:
| I cultivated an extreme dislike for managers for years. Then
| I became one. Things are a whole lot different from the other
| side.
|
| You perhaps overlook a few things: (1) Managers are people
| too. They make mistakes. They should be able to recognize and
| correct them as others. Ideally quickly, transparently and
| with the insights of others. (2) Needs evolve. The right
| process for proof of concept R&D is not the right process for
| global domination with a mature product. (3) Management is
| about competing concerns. Often a decision must be made
| within a limited sphere of experience, time and resources and
| reviewed in the future. There is no 'right' decision, and it
| can be fiendishly difficult to quantify decision quality in
| many such circumstances without the benefit of hindsight. (4)
| Different people can respond _very_ differently to the same
| management, so 'bad management' is perhaps too uni-
| dimensional a notion to hold much meaning.
| momokoko wrote:
| I never said managers where bad or that I disliked them.
| Sorry you got that impression.
|
| In this case all I was referencing was that frequent
| process changes and repeated failures of process are
| typically an indication that a change needs to happen in
| management not process. No where did I state management be
| eliminated altogether. I stated that better managers need
| to be brought in to replace those that are underperforming.
| tootie wrote:
| It's more true now than it used to be. A lot of business
| software in the early days was an attempt to directly replicate
| paper business process on a screen. Enterprise software was
| sold as being low friction and not requiring users to learn
| anything new. And it was built by developers who started with a
| data model and then build screens to match.
|
| I think we've finally tipped to the point that business
| processes are designed as digital first. The current gen is
| also following much more user-centered design.
| cratermoon wrote:
| You're absolutely correct: business processes are changing
| rapidly in a way that they haven't since the assembly line
| and Taylorism. We've had decades now of users and companies
| "paving the cartpath" by replicating paper on screen and
| learning what translates, what doesn't translate, and how to
| evolve. The workflows and the tools are evolving together now
| through a feeback loop, and that's a good thing. Consider
| order fulfillment and shipping for small to medium businesses
| today compared to the era before FedEx and eCommerce.
| edgarvaldes wrote:
| Yes. Just see any ERP implementation. Its better to take as
| many defaults as possible and go live, than spend years trying
| to implement your own convoluted unique workflow.
| zmmmmm wrote:
| I think you need to distinguish here between "core business"
| where you generate your competitive advantage, and everything
| else. In your core business, were you are going to make the
| critical difference that determines why your business or
| organisation exists, shooting for the most finely tuned, unique
| solution that maximizes that advantage - or at least, enables
| capability to do that - is critical.
|
| For everything else - I agree. The more bespoke you decide to
| be the more pain you create for very little value.
| jariel wrote:
| "the great tools that have achieved widespread adoption
| understand the problems, and all their caveats, better than
| you"
|
| Tools that get widespread adoption are mostly those that move
| quickly to add every little feature every manager/exec asks for
| in order to secure the contract.
|
| Once they become incumbent, they become the standard, because
| managers are responsible for the 'big purchases'.
|
| There's tons of very accepted systems that are 'not very good'.
| agumonkey wrote:
| I also wonder if there's some twisted emotional flow in people
| to consider whatever hell they conquered as the way to go
| forever. Questioning their ways is seen as such an insult there
| must be something deeply wound in their brain.
| koonsolo wrote:
| Good explanation! These companies start out thinking they will
| make a better product than anything out there. But due to
| limited resources always end up with an ugly monstrosity that
| is hell to work with. So they end up with something more
| expensive (but that cost is hidden), and something worse than
| what's off the shelve.
|
| I always ask them "So are we the only company in the world that
| is developing software?".
|
| Tools are pretty powerful, so you build your process around
| them.
| cheez wrote:
| 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 wrote:
| 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.
| jimkleiber wrote:
| I've been thinking a lot about the buy (or rent) vs build
| problem and one factor that keeps screaming at me is: who
| do I want to maintain it?
|
| If my team or I want to maintain it, then build. If not,
| then buy/rent. I've built way too many things over the last
| few years only to realize again and again that things we
| build will need to be maintained by someone.
|
| As you say, if it's a competitive advantage, then it makes
| sense for me to fix it, update it, adapt it, etc.,
| otherwise it may be too costly to get distracted with
| maintaining it internally and easier to pay someone else to
| do that.
| 908B64B197 wrote:
| 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 wrote:
| > 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.
| 908B64B197 wrote:
| And yet it's surprising how a lot of companies simply
| won't match offers or try to play games with CoL. Or
| worst, consider engineering a cost center when it's
| central to the business.
| contingencies wrote:
| Nice one. Added to https://github.com/globalcitizen/taoup
| cheez wrote:
| You said it better than I ever could have!
| cratermoon wrote:
| I can't take credit for the phrase, only for being
| thoughtful enough in my early career to more-or-less work
| it out from first principles.
| jmole wrote:
| I'd call it "rent for parity", not "buy". If all you have
| is a license, it's effectively a rental - not a purchase.
|
| Rent for parity, buy or build for competitive advantage.
| scott_w wrote:
| In practice this isn't a problem. Take a non-software
| example:
|
| Driving instructors typically have their cars on a 3 year
| hire purchase then return instead of buying. Why? Way
| back when, my driving instructor actually bought one of
| the cars. 3 months later, the engine failed and it was
| out of warranty.
|
| Because of that, he realised that paying a monthly fee
| meant he had no surprise failures, he returned the car
| just as the clutch was burning out (learner drivers don't
| have great driving technique, weirdly enough), and had a
| fresh car every 3 years for new learners.
| masklinn wrote:
| Yeah I've never heard anyone think a driving instructor
| car was a great buy, unless you like replacing basically
| every driving component which can fail. These cars have
| it rough. Especially manual. I'm surprised a driving
| instructor (of all people) would think of doing that
| without also wanting to do a full engine and transmission
| rebuild.
| quesera wrote:
| Makes sense, but FWIW and IIRC, the terms of an ordinary
| car lease prohibit commercial use.
| gukov wrote:
| If it's for business use you should be able to expense
| it.
| cratermoon wrote:
| Shows how long I've been around. I still think of
| commercial software as something you buy and own.
| mlyle wrote:
| > 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.
|
| I'm all for doing something "different" if it gives you some
| kind of core competitive advantage.
|
| But the pain of being off the beaten path can really exceed
| small benefits you get in unexpected ways.
|
| Save real innovation and risk for the things that are core,
| unique to you, and possible sources of large competitive
| leverage. Be boring elsewhere, maybe with an occasional small
| sprinkle of something clever mixed in. Evangelize the small
| bits of cleverness, in hopes that someone else will start
| maintaining it. ;)
| cheez wrote:
| I'm not sure if I'm misreading you, you're misreading me,
| or we're on the same page :-)
|
| Ideally, I map out workflow and find tools that fit the
| workflow in the Unix philosophy. Well-defined, do one thing
| well. As opposed to monoliths that purport to do
| everything.
|
| My experience has been that doing things in this way builds
| a system that is extremely robust to significant changes.
| ta17711771 wrote:
| > 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 stagnated companies with questionable data analysis
| because they're looking at beautiful SAP or other ERP graphs
| that have been filled with incomplete data by their end users
| on awful interfaces would disagree...if they knew.
| iforgotpassword wrote:
| Agree. Interns or grads always want to throw whatever the
| most hyped tool in some domain currently is at every remotely
| fitting problem. Ansible all the things!
|
| That's not to say you should always roll your own. This is
| one of those things that's really hard to become good at:
| Decide early on whether to go with an existing solution or
| create something from scratch. (and if you go for an existing
| solution, which one?)
|
| There's many arguments for both sides, one thing often
| mentioned is that settling for some popular solution or
| framework will make it easier for others to get into your
| project, but if you bend over backwards to get three
| different tools to do what you want instead of writing a
| hundred lines of bash, you might be doing something wrong.
| cheez wrote:
| What I do is decide that I am in charge of defining the
| machine, and the tools implement the machine. The tools are
| a means to an end. If the tools don't exist to implement
| the machine, I write them. If they do exist, great.
| mcny wrote:
| > 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.
|
| I thought the same way except I was even more insane. I
| thought lets just teach everyone English and we won't
| have to do any internationalization/localization.
| 908B64B197 wrote:
| But then you lose the advantage of being the first to
| localize for a given market!
|
| But seriously, in a lot of cases, translating and
| localizing is actually the easy part of
| internationalizing a business.
| mcny wrote:
| > But seriously, in a lot of cases, translating and
| localizing is actually the easy part of
| internationalizing a business.
|
| In my defence, I was not a very travelled child. I didn't
| even know about all the different kinds of power socket
| standards around the world.
| [deleted]
| ish wrote:
| I ask clients (and myself quite frankly): what is the
| competitive advantage of doing it this way? Do you get a leg up
| on your competition? What's the opportunity cost of spending
| time and money on this instead of your core product or mission?
| Konohamaru wrote:
| How unique are people? You take a bunch of teenagers, ask them
| to non-conform, and they all come up with the same pierced,
| hair-dyed fashion. As if they're clocks ticking at the same
| rate. If you have several million clocks reading the same time
| down to the microsecond, that implies the existence of a master
| clock they were synchronized to.
| abhgh wrote:
| I agree with you, in the context of working in a corporation.
| It's not a bad thing to pick tools and structure your workflows
| around them, because sometimes such tools serve as 'mental
| anchors' for standardizing a process.
|
| The article seems to focus on personal productivity tools, for
| which the author's conclusion _might_ relatively hold to a fair
| extent.
| starfallg wrote:
| Spot on. Some things just need to be good enough. Spend effort
| on solving the problems with the biggest impact, your workflow
| and tools don't deserve that much attention unless it's
| completely not fit for purpose. Also changing your process and
| tools too often and too drastically usually makes things worse.
| People spend all their time keeping up with changes to how
| things are done as opposed to actually doing things.
| addicted wrote:
| 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 wrote:
| 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/
|
| [1] https://github.com/thesephist/torus
| m-p-3 wrote:
| It's easier to bend a workflow around existing tooling than the
| other way around depending on the size of the business.
| oneelectron wrote:
| 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.
| sokoloff wrote:
| 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.
| acutesoftware wrote:
| 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 wrote:
| (OP) Yep, ownership is definitely big for me. Maybe I've just
| been burned one time too many by a startup pivoting away...
| jinal wrote:
| 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.
| bluedino wrote:
| 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
| haihaibye wrote:
| 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 wrote:
| 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.
| chrisweekly wrote:
| 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 wrote:
| 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/
| andrewingram wrote:
| FYI, there's another language called Ink
| (https://www.inklestudios.com/ink/) which I momentarily
| confused yours with.
| tel wrote:
| 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.
| amadeuspagel wrote:
| 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
| bbbobbb wrote:
| 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..
| arey_abhishek wrote:
| 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)
| thesephist wrote:
| >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 wrote:
| Does your note taking app support embedded files and images
| in-line?
| lukeramsden wrote:
| Is Appsmith essentially a FOSS Retool? If so that's awesome and
| I may use that at some point
| arey_abhishek wrote:
| Yes! It's a FOSS replacement for Retool, Powerapps, and other
| such low code products.
| dasil003 wrote:
| 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.
| crb002 wrote:
| The humble .plan file. https://github.com/ESWAT/john-carmack-
| plan-archive
| natcombs wrote:
| 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 wrote:
| 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.
| davnicwil wrote:
| 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
|
| 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.
| rexpop wrote:
| Is this not an aspect of Ivan Illich's "Tools for Conviviality"?
___________________________________________________________________
(page generated 2020-08-22 23:00 UTC)