[HN Gopher] The Return of Fancy Tools
___________________________________________________________________
The Return of Fancy Tools
Author : typeofnandev
Score : 418 points
Date : 2021-05-15 00:03 UTC (22 hours ago)
(HTM) web link (macwright.com)
(TXT) w3m dump (macwright.com)
| drawkbox wrote:
| Good games should be _easy to approach and difficult to master_.
|
| Good tools should be _easy to approach with the ability to
| customize and do more advanced actions, but never difficult_
|
| Good tools and products encapsulate complexity but still allow
| access to it where needed.
|
| Good tools aim to simplify complexity, not complexify simplicity.
|
| Good engineers and product people make tools that aim to
| simplify. Make it approachable to a n00b/junior but no bullshit
| for the experienced, or at least the ability to turn off the
| bullshit and lock-in. Always aim to abstract complexity into
| simplicity, that is the job.
| aflag wrote:
| I don't think good tools are necessarily easy to approach. Some
| of the best tools I know have quite a steep learning curve. A
| good tool is one that gives you power. It makes difficult and
| complicated tasks easy and simple. It may come with the cost of
| getting good with using the tool, but once you master it, you
| don't know how you lived without it.
| typeofnandev wrote:
| There's a lot of truth to this. I feel like I'm willing to
| really dig in and learn a tool if I can sense that the power
| of wielding that tool will be commensurate with the
| difficulty learning it.
| runevault wrote:
| A good tool picks an audience and builds everything with them
| in mind. You can make a tool aimed at beginners of some
| discipline with the understanding it may not satisfy power
| users, but that doesn't make it a bad one, just bad for that
| audience. Same in the other direction, tools aimed at
| optimizing power users ability to do their task may seem
| completely impossible to a beginner, and that's totally okay.
| Kinrany wrote:
| Audiences change over time. Projects need something less
| ephemeral to aim for.
| pessimizer wrote:
| A good tool is one that works, and works predictably. If it
| can just stay reasonably dependable, I'll come up with ways
| to use it to its limits.
| dejj wrote:
| Consider "affordances": a chair may be used for sitting, or
| as a weapon, or as kindling etc. Likewise, a good tool is
| made to be approachable for the beginner, and open-endedly
| extensible for the expert. They're the same material, but the
| hand movements of beginner and expert are very different.
| Analogously, consider how Simpsons episodes have 2
| affordances: to be funny for children and for adults, each
| for their own reasons.
| jiggawatts wrote:
| "Good tools aim to simplify complexity, not complexify
| simplicity."
|
| Some people don't realise that this is a goal, or that it's
| even possible.
|
| At Microsoft, this was the philosophy behind the .NET Framework
| standard library. It is simple, beautiful, and abstracts away
| reams of complex boilerplate that was necessary with C++
| programming.
|
| Now?
|
| I'm using Azure, and... oh... my god. Every internal piece of
| wiring is exposed, raw, to the end-user. Wear insulating
| gloves.
|
| You need to know their internal project code names! The
| undocumented ones are typically the most important.
|
| You need to pass secrets between two agents _running on the
| same VM_ through your workstation during deployment!
|
| Need to pass an identity around? It's broken up into individual
| fields, one of which can only have a single valid value. But
| you have to provide it using a programmatic lookup.
|
| Want Accelerated Networking? There's a convenient Boolean flag
| for it. Great. Except that it'll break deployments if the VM
| size you've selected doesn't support it. How do you know if a
| VM size supports it? Bahaha... you don't. Build a switch
| statement with 300 entries yourself. That's what the Indian
| subcontractors writing the rest of Azure's code do! It's good
| enough for them, so it should be good enough for _you_. (I wish
| I was kidding, but I have seen the code and it is literally
| this.)
|
| Ultra Disks? Switch statement.
|
| Availability Zones? Switch statement.
|
| You get the idea...
|
| I have spoken with several Azure team leads, and they just
| blink at me slowly with an utter lack of comprehension when I
| explain that this is just not good enough. That in Visual
| Studio, I can tab-complete a type and it _will_ compile. That
| 100% certainty is not comparable to 90% certainty in Azure,
| where a boolean _true_ value might need to be the string _"
| true"_ value because fuck you.
| pjmlp wrote:
| As long time developer on the Windows ecosystem I really
| don't get what happened.
|
| I fully agree with the experience, add on top of that CLI
| tools for what used to be VS wizards, code instead of GUI
| designers, killing C++/CX replaced by C++/WinRT, which after
| 4 years still doesn't have VS tooling support, 5 competing
| GUI frameworks on Windows,....
|
| Culture reboot at Microsoft went a bit too far in the wrong
| direction.
| nafey wrote:
| > That's what the Indian subcontractors writing the rest of
| Azure's code do!
|
| Important to note that the subcontract would be paid 1/10th
| of what his counterpart in Silicon Valley would be getting.
| wraptile wrote:
| I like what Douglas Engelbart said about good tools
| (paraphrasing): if you use a tool the same way on the 1st day
| you acquired it and a year later - it's not a good tool.
|
| Which I feel a lot of modern software struggles to provide.
| Sure I can onboard quickly and do _something_ but if I'm
| spending hundreds of hours I want to get better at it and
| improve my returns.
| divbzero wrote:
| > _Everything for the next few years will slowly fade in as you
| scroll. I don't know why._
|
| I don't understand why either. Does fade-in make a webpage more
| aesthetically pleasing? Or serve a functional purpose like
| improving readability or increasing conversion? To me it
| distracts from understanding the content and can even lead to
| janky rendering when implemented poorly.
| globular-toast wrote:
| Fashion trends tend to work like this:
|
| 1. Someone does new thing, it looks stupid,
|
| 2. Others realise that even though it may look stupid, it looks
| _new_ , so they copy it,
|
| 3. It's copied to the extent that if you _don 't_ do it, you
| look dated,
|
| 4. The stragglers do the thing too, and now it's not cool any
| more.
|
| We're at stage 3 now with fade-in scrolling. When Wikipedia
| does it we'll be at stage 4 and then it will be cool to do
| whatever Wikipedia were doing 10 years ago.
| terenceng2010 wrote:
| I probably won't pick CS as my undergrad study if I haven't used
| dreamweaver to create website for my classmate when I was just 12
| years old (hand-type html, css is a bit much for me that time.
| And Dw allows your to set hyperlink, an on hover event easily, js
| is hard to grasp for me that time ) .
|
| So I always think it's good to have a low barrier for people to
| get in.
| jhowison wrote:
| Google cache link:
| https://webcache.googleusercontent.com/search?q=cache:gnWsEk...
| yout2 wrote:
| Another example: Java and C++ got disrupted by Python and Ruby,
| which were considered to be much simpler to read and write, but
| now we are seeing more static typing, for example Python with
| type hints and friendlier static languages like Go/Kotlin/Swift.
| Perhaps mirrors the shift between text editors and IDEs.
| aunty_helen wrote:
| With Python you can write super simple to super complex. If you
| have a large project that benefits by type hinting, use type
| hinting.
| pjmlp wrote:
| As long as performance isn't part of the requirements, then
| it is time to rewrite it into Java and C++.
| egypturnash wrote:
| Fancy tools never left, you just stopped using them. I've been
| using Adobe Illustrator for art since before anything mentioned
| in this post even _existed_. Except Dreamweaver and Vim, if
| "neovim" counts as Vim. It is a complicated tool that has a lot
| of ways to easily make useless effects, and a lot of ways to
| easily make beautiful art.
|
| Also most of the professional writers I know don't write in Word,
| they write in Scrivener, which is essentially an IDE for prose.
| Then they export to Word and use this as a common interchange
| format with everyone down the line in the publishing workflow. It
| is a very fancy tool.
|
| And really I dunno if NeoVim counts as not "fancy", the first
| highlight on its page is a section about how extensible it is.
| It's got _two_ languages to write plugins in, with several
| screens to scroll down in the list of "plugins and applications
| that leverage the Neovim API". That is some fancy-ass shit right
| there.
| headmelted wrote:
| _Visual Studio was "disrupted" by Sublime Text and TextMate,
| which are now getting replaced by Visual Studio Code_
|
| No-one switched from VS to TextMate or Sublime except the author.
| There's virtually no overlap in workflows.
|
| I can absolutely believe people switched from either to VSC, as
| they are designed for similar workflows.
| lmeyerov wrote:
| This resonates.
|
| Another way to look at it is how we got to simple tools to
| beginwith: tech-driven industry disruptions. A wave of sw
| replacement came for tools that are mobile-friendly and support
| collaboration, like Google docs & spreadsheets, and Figma. Mobile
| & live collaboration are so important that feature-poor versions
| of older tools ate giant market share from Microsoft Office,
| which is 15% of Microsoft's revenue, and the same at Adobe and
| others.
|
| But Office, Adobe, and friends built up all those features for
| market-driven competitive reasons. Startups in new spaces get
| head starts of 2-3 years in consumer, and then maybe a couple
| more if b2b, but that's it. It doesn't last forever: capital is a
| moat, and part of that is by building a feature factory, which
| massive companies like to do. MS and Adobe went SaaS and mobile a
| few years ago, and they're actively competing here now.
| maydup-nem wrote:
| This view is forced and implicitly claims there are some actual
| trends going on with some handpicked examples, and even then
| they're quite false. Give me a break. I think this complex/simple
| notion is black-and-white kind of wrong at the root of it, just
| throw in "powerful" in there and see how well that view fairs
| then.
|
| > "I'm not writing it down to remember it later, I'm writing it
| down to remember it now." The friction of having to write, to
| structure thoughts in plain text, to remember the name of the
| person I need to reference on this page: that is the point.
|
| How about writing to forget it? For me, the point, more often
| than not, is to not have to remember what I am writing down. And
| if need be, come back to it later.
| globular-toast wrote:
| I spotted this trend a long time ago. I see it everywhere:
| software tools, clothes, cars, you name it. It's called fashion.
| I decided to opt out. I use timeless tools like emacs and bash. I
| wear timeless clothes like trousers and shirts. I drive whatever
| reliable car is available at the time. I haven't got time to keep
| up with the whims of fashion.
| jes wrote:
| _Edit code like a grandpa in neovim..._
|
| Love it!
|
| At 61 I am a grandpa, prefer GNU Emacs over vi, but still have
| fond memories of using vi on 4.2BSD systems. Long time ago!
| meierjo wrote:
| Ahhh vi. I was reading the article hoping to see mention of
| vi...
|
| Emacs was cool too, but I never got hooked - was very
| comfortable in vi land as it was the first editor I used on the
| old time terminals (green/amber CRT and a keyboard you could
| kill with). Oh the power of vi/EMACs and regular expressions
| without ever lifting a finger from the keyboard!
| jes wrote:
| Exactly. I well remember the green or amber 24x80 terminals.
| Televideo, Lear-Siegler, etc. Bundles of twisted pair cable
| for tty lines back to the machine room.
|
| Good times....
| makapuf wrote:
| But wasn't vi the Fancy Tool then?
| ontouchstart wrote:
| That is why I started to use ed. Much better than vi
| because you THINK in a buffer :-)
|
| https://en.wikipedia.org/wiki/Ed_(text_editor)
| fergie wrote:
| Me too.
|
| I think that there are more of us than we think its just that
| there are no commercial interests promoting our way of working,
| so we feel slightly unusual when in fact we are just doing the
| logical thing.
| jcelerier wrote:
| > Visual Studio was "disrupted" by Sublime Text and TextMate,
|
| no it was not. people didn't migrate from VS to Sublime, they
| migrated from notepad++ to Sublime. I have never met _anyone_ who
| stopped using IDEs once they started, except maybe for VSCode
| with a few hundred plug-ins to reconstruct an IDE piece-wise (but
| with much less "integration" between the different plug-ins)
| agumonkey wrote:
| I've seen a few that stopped IDEs, I have no stats of course
| but I've seen it mentionned in blogs just enough to comment. I
| for one stopped IDEs but I'm a peculiar dude that prefer the
| from-scratch approach (to an extent, I never wrote emacs
| myself, but at least I know who,why my java classpath is the
| way it is unlike in Eclipse)
| k__ wrote:
| I used WebStorm for years.
|
| But I stopped, because IDEs were too slow to adapt to current
| tech.
|
| Text based tools can simply move faster.
| coldtea wrote:
| > _I have never met anyone who stopped using IDEs once they
| started_
|
| Well, I, for one, used to use Eclipse and moved to Sublime. It
| also has to do with changing dev languages and trends over a
| period. 2005 might have been all about J2EE, 2015 was all about
| Node, etc.
| gregors wrote:
| Borland, Visual Studio, Eclipse, Netbeans, IntelliJ, Xcode -
| I've use quite a few IDE's. I much prefer a simplistic vim.
|
| You make a great point regarding reconstruction of IDE's piece-
| wise. Check out all the "10, 15, 20" VS code plugins you MUST
| HAVE blog posts. I don't see any difference between that and a
| tricked out Vim setup. I see them as exactly the same things.
|
| So someone leaving a tweaked out vim for a tweaked out VS Code
| or vice versa isn't the same as someone leaving an all powerful
| IDE. Those people are pursuing their perfect bespoke dev
| experience.
| noobermin wrote:
| Not to drag on the OP but I really wonder about people who are
| the subject of these articles who supposedly migrate from x to
| y to z, because at least for me I'm still using emacs like I
| did 10 years ago. The things I focus on is more about doing
| work than what tool I'm using.
|
| Do people really migrate or is this more about growth in a
| user-base? A higher rate of growth of one user-base relative to
| another user-base is not strictly due to people migrating (as
| if it's zerosum) but could be due to a tool capturing more new
| users, like junior developers and such. How often do people
| really migrate wrt tools they actually use for work?
| john-aj wrote:
| Exactly. I'd guess that a majority of VS Code users are
| relatively new to programming. Not to say that there aren't
| experienced people who have switched, especially among the
| TextMate/Sublime Text crowd, but the incredible growth in
| users? I think that's largely a result of new programmers
| choosing the same editor, not old programmers switching.
| meheleventyone wrote:
| There's also a big swing of experienced people as well IME.
| This is partly what drives adoption by new people. There's
| a connection there.
| flohofwoe wrote:
| Don't know if I'm representative, but I've been using
| Visual Studio for C++ stuff for about 20 years and switched
| to "mostly VSCode" a few years ago. I guess the reason is
| that I never used more than 2..3% of Visual Studio's
| features. Some features in VSCode are a bit too bare bones
| (especially the debugger), but somehow the user interface
| makes a lot more sense to me, and most of the times it
| feels faster and more lightweight than Visual Studio
| (Visual Studio nowadays even shows a progress bar when
| loading a project).
| noobermin wrote:
| Is that that much of a shift? VSCode probably isn't
| Visual Studio but isn't it related obviously. It would
| seem different if you migrated from Visual Studio to
| sublime or xcode or something.
| [deleted]
| zoom6628 wrote:
| The only significant scale of migration I have personally
| seen is from Visual Studio to VS Code. That was in a
| Microsoft shop moving to a browser based UI.
|
| Personally I still use vi/vim for just about everything and
| use language specific IDEs for anything only tackled
| occasionally (I'm product manager not a developer) because
| IDEs reduce friction and increase my productivity. Recently
| started using Thonny as python IDE not because I'm a noob (20
| years python coding) but it makes jumping into python code ad
| hoc effortless compared to pycharm or others. YMMV
| mytherin wrote:
| Maybe I'm the odd one out, but this describes me to a T. I
| started programming primarily using Visual Studio on Windows
| which I used for several years. It has a nice debugger, but the
| IDE in general was so painfully slow and bloated it actively
| took me out of my programming flow. I'm also in general not a
| big fan of all the clicking around that you needed to do in
| there. Configuring projects using the Visual Studio IDE was a
| terrible experience for me, and also supremely non-portable.
|
| I moved away from Windows entirely, and switched to Sublime
| Text in combination with Unix-style tools (lldb, clang-format).
| Quickly jumping around in files and searching within the
| project is fantastic, and the editor is supremely responsive. I
| have since switched to Visual Studio Code, which is slightly
| slower than Sublime Text but still fast and responsive.
| treeman79 wrote:
| Many years ago I ran vim as an IDE for several years and was
| quite happy. Eventually it got bloated and I just could not
| keep it functional without massive time investment.
| Maintaining indexes was biggest issue if I recall.
| quickthrower2 wrote:
| I treat dev tools like real life tools. Just use whatever makes
| sense, what I'm used to and what's at hand.
|
| I tried the whole vim thing and no don't like farting around
| with things like pathogen and remembering keys. I love a good
| graphicalIDE too much! I spend most of my time typing or using
| one of 4 keyboard shortcuts. Mouse is fine for everything else
| frankly. The mouse is actually a decent invention!
|
| VSCode for web. VS is great for c# projects. I use IntelliJ
| sometimes and it seems good but don't use it too much as I
| don't Java much.
|
| I don't think there is a pendulum at all, just a whole bunch of
| individual coders and teams choosing what makes sense and let's
| face it, sometimes, what is hot/cool/hipster
| altano wrote:
| A lot of the "Ruby on Rails with Textmate" crowd came from Java
| where you used full IDEs (in addition to the LAMP developers
| who were not using IDEs).
| toxik wrote:
| I used IDEs and stopped. In fact I wish IDEs would work, that's
| how I started with QBASIC and later Visual Basic. But as soon
| as you step out of playground level programming, IDEs are never
| on their happy path.
| akx wrote:
| You should really probably give Jetbrains' IDEs a try, if you
| use any of the languages they support.
|
| I find it hard to think I'd give PyCharm up for my daily
| Python and Typescript.
| toxik wrote:
| I tried PyCharm for a couple of months. It has some nice
| features, but they fall apart way too often. A sibling
| comment mentions Java, and maybe a more statically typed
| language does work better, but for Python the dynamic
| nature of the language makes "more primitive" code
| manipulation tools like PyCharm fail eventually.
| refactor_master wrote:
| It seems to be the only tool capable enough to at least
| offer _some_ degree of inline checking and autocomplete.
| Everything else I've tried seems to be perpetually early
| beta.
|
| Is there a _more_ sophisticated Python tool than PyCharm?
|
| My biggest gripe is the Mypy type-checking which only
| discovers errors minutes later.
| GeneralTspoon wrote:
| > as soon as you step out of playground level programming
|
| Uhh... pretty sure 99% of all complex JVM applications were
| written using an IDE.
|
| In fact, if you joined an experienced team at a senior level
| and weren't using IntelliJ, you'd be laughed out of there
| pretty quickly...
| jlelse wrote:
| Eclipse is still pretty popular as well.
| Slartie wrote:
| Don't forget that there's Eclipse as well, which I
| personally still prefer when dealing with Java codebases,
| although I have somewhat positive experiences using
| JetBrains IDEs in other languages, particularly Python with
| PyCharm.
|
| But generally IDEs are almost a necessity for any complex
| Java codebase. That's markedly different in other
| languages. I sometimes work on the chromium codebase (C++
| mostly) which I use either VSCode or a simple text editor
| for. When dealing with smaller scripts, whether in Python,
| Perl or Bash or whatever, I usually stick to whichever
| simple editor I happen to have accessible. The same is true
| for some small C codebases I maintain on an irregular
| basis.
|
| Generally I consider it a rule of thumb that the more
| refactoring a codebase requires to be kept in a
| maintainable state, the more you profit from an IDE. And
| the necessity for complex refactoring grows with the size
| of the codebase and the number of developers working on it
| (especially if a lot of them happen to be rather new to the
| craft).
| alpaca128 wrote:
| Because writing complex JVM applications without an IDE is
| painful. That doesn't mean IDEs provide a great experience.
|
| I mostly started with Java in various IDEs. Now I'm using
| Vim whenever I can, as it's pretty much the only powerful
| editor that doesn't work against me. IntelliJ is incredibly
| annoying, e.g. auto-formatting the line I'm still typing,
| turning my inputs into undefined behaviour. Or telling me a
| file contains an error but not showing an indicator _in
| which line_ (of >1000) that error is. But I sure am glad
| it displays 50 markers on the sidebar to tell me the
| location of every word in a comment the spellchecker didn't
| recognise. And to top it all off it switches tabs in some
| random order instead of the order that's literally
| displayed on the screen (I don't know why this trend is a
| thing, I'm not too dumb to rearrange my tabs, thank you
| very much).
|
| No, Vim isn't perfect. But it's snappy, reliable and most
| importantly doesn't try to "help" me without asking.
| olingern wrote:
| I followed the author's IDE trajectory but only because I
| stopped working with C#
| ziml77 wrote:
| I wonder if the shifts they're talking about have really been
| true migrations. There's constantly new people and companies
| entering/exiting the industry. New entrants are likely to use
| whatever is in vogue, so overall there is going to be a shift
| in what's dominant as time goes on even if no one were to
| actually switch from one tool to another.
| breakfastduck wrote:
| Must admit my comment is spurred by the first few words but my
| god Dreamweaver was _so_ good in the early 2000 's.
|
| I actually got introduced to it in ICT lessons at high school.
|
| Oh Adobe. The memory of their software is so nostalgic. Don't get
| me started, I'll be talking about macromedia shockwave next...
| snowwrestler wrote:
| Dreamweaver templates were the original static site generator.
| I used them to build a bunch of small sites in the early
| 2000's. They worked so well that the Smithsonian's Natural
| History Museum used them to run its site until _2018_ :
|
| https://mw19.mwconf.org/glami/smithsonian-national-museum-of...
|
| As recently as a couple years ago I had colleagues still using
| Dreamweaver to code up email templates (email is the Land
| Before Time of HTML rendering where tables still rule for
| layout).
|
| Dreamweaver started at Macromedia too, as did Flash and Cold
| Fusion. It's amazing the impact Macromedia had. The founders
| later went on to start Brightcove, one of the first big white
| label cloud video providers.
| johnwheeler wrote:
| I got my start on Drumbeat which later was purchased by
| macromedia. I miss my spinning 3D text gifs.
| cfn wrote:
| Indeed, I still have one backend in production built back
| then with Drumbeat. Its UI was very new and rebuilt/consulted
| with Alan Cooper of Thunder/Visual Basic/About Face fame.
| johns wrote:
| Drumbeat was incredible. VB for the web.
| breakfastduck wrote:
| No web UI component framework has matched the usability of
| VB.
|
| Why haven't we seen a true successor?
|
| Microsoft should do a native TypeScriptVB or something.
| bliteben wrote:
| I love how xcode's object -> function mapping seems
| inspired by visual basic / delphi, but actually makes no
| fucking sense when compared to those tools.
| 0xy wrote:
| My start was Microsoft FrontPage 2000, which I used for years
| even after I stopped using the GUI features for development.
|
| I skipped Dreamweaver entirely and went to straight text
| editors.
|
| Nowadays on the frontend you can more or less recreate the same
| effect with Webpack hot reloading. You get instant feedback on
| changes which makes for a supremely productive development
| experience.
| girvo wrote:
| RIP macromedia. That suite was the best $400 AUD I ever spent
| as a teenager running my own web agency in the mid to late
| 2000s!
| dawnerd wrote:
| It's how I got my professional start too. It's code editor and
| file management was pretty nice for the time.
| breakfastduck wrote:
| Basically the winning feature was that the UX was essentially
| the same as Photoshop.
|
| Slice up those PSDs and, WOW I can try coding it up myself
| and it kinda-sort looks-works the same as PS!
|
| It was the _exact_ tool Photoshop using website designers
| needed to up-skill smoothly.
| rm_-rf_slash wrote:
| Mine as well...in 2015, at a university that maintained lot
| of small-to-medium complexity websites. It did the job well
| and was easy to work with, even if I sometimes felt like was
| carving in my 1s and 0s with stone and chisel.
|
| But if I were still working there I would probably replace
| most of the sites - which were largely abstractions of forms
| and tables - with something like power apps instead.
| breakfastduck wrote:
| Still can't comprehend why we haven't had 'winforms' again
| but modern and not windows based.
|
| Power Apps is good but not great.
| bliteben wrote:
| Same reason people will spend thousands of hours working
| on libraries like pandas but won't make a better excel.
| Or something like that.
| raingros wrote:
| Well said: "[...] the names of things, their functionality, and
| how it all fits together should be things that exist in one's
| mind, not just in a computer."
| imwillofficial wrote:
| I really enjoyed this take. I hadn't thought of our tools going
| from complex to simple and back again. Insightful.
| madeofpalk wrote:
| > JIRA was replaced by GitHub issues
|
| This is absolutely... not the case.
|
| Sure, for some kinds of projects Github Issues might do, but for
| anything "real" Github's issue and project management is a
| serious regression.
|
| ---
|
| These tools are not replacing anything, but addressing broader
| and broader markets. They lower the barrier to entry and bring
| more people into the fold (perhaps at the expense at having a
| lower ceiling of functionality).
| steveklabnik wrote:
| I mean, it's all very opinionated. I think at this point I am
| borderline "I would rather have no bug tracker than Jira."
| Issues isn't perfect but it's the best I've ever used.
| greatgoat420 wrote:
| I have never used Jira, could you say more about your
| feelings towards it? Currently we use an old in-house
| solution and are thinking of shifting.
| AlotOfReading wrote:
| The biggest issue by far is how slow it is. I don't mean
| bubble sort slow, I mean deliberately engineered quantum
| bogosort. A cache-less refresh for me on a blazing fast dev
| machine takes between 3-10 minutes on a normal day, though
| it might only take 1m if the internet gods are feeling
| particularly merciful. That leads to all sorts of avoidance
| because using it for anything takes long enough to be worth
| documenting as a ticket in its own right.
|
| Compounding this issue is how many clicks even "simple"
| tasks take because of their bizarre choices. Basic
| necessities like changing ticket status can't be done
| without opening separate pages, etc.
|
| One you've actually managed to create a ticket and assign
| status, good luck finding it later. Backlogs inevitably
| evolve into infinite swamps that no one knows the full
| contents of. Not helping is the fact that the search is
| _terrible_. I often vaguely recollect some detail or test
| procedure that someone helpfully mentioned /documented in a
| ticket somewhere before closing. I successfully find maybe
| a third or less of those.
|
| Also it's highly customizable, so any skills or knowledge
| from one company don't apply to the installation at any
| other.
| greatgoat420 wrote:
| Thanks for replying, I think I get it now. We use
| SharePoint which has very similar issues.
| allset_ wrote:
| I don't like Jira that much, but this is just blatantly
| false.
|
| > A cache-less refresh for me on a blazing fast dev
| machine takes between 3-10 minutes on a normal day,
| though it might only take 1m if the internet gods are
| feeling particularly merciful
|
| I use Jira daily, it's nowhere near this bad. It's not
| fast, but pages load in about 5 seconds.
|
| > changing ticket status can't be done without opening
| separate pages
|
| You select the new state from the drop-down and set it.
| This is available through a few different routes/views.
|
| > good luck finding it later
|
| Their search looks through title and description, what
| else do you want?
|
| > Backlogs inevitably evolve into infinite swamps that no
| one knows the full contents of.
|
| If you let them, of course. If you don't close the
| tickets, what did you expect to happen?
| Kinrany wrote:
| They probably meant seconds. A website that takes seconds
| to open is unusable.
| AlotOfReading wrote:
| I wish I was mistaken, but I do literally mean minutes.
| I've measured it with a stopwatch before.
| watwut wrote:
| I don't know how you have it configured, but I have to
| say, we dont have these problems.
| AlotOfReading wrote:
| The configurations can supposedly make a huge difference.
| However, I've yet to see a company where these weren't
| serious issues and I can only speak to my experience. If
| you're lucky enough to have a decent installation I'd
| recommend buying IT a nice lunch or something. A bad Jira
| setup is truly awful.
| girvo wrote:
| Cloud JIRA itself is slow, for what it's worth. Seconds
| long RTTs -- which make using a CLI to bypass the web UI
| pointless in my experience
| Jolter wrote:
| I assume your workplace is using the cloud solution? Our
| huge-enterprise in-house install is blazing fast, as long
| as nobody misconfigures some automation tool to overload
| the database.
|
| Edit: I did have the bad luck to discover it performs
| pretty horribly if you're on a high-latency connection to
| the office. I think it makes a lot of round-trip
| requests.
| dmitriid wrote:
| Yes, JIRA Cloud is unusably slow and their "nextgen"
| rewrite only compounds problems by adding workflows no
| one asked for and by removing workflows everyone depends
| on.
|
| Properly configured on-premise installations are usually
| quite fast.
|
| > I think it makes a lot of round-trip requests.
|
| It does, and that's the main issue
| bradknowles wrote:
| Jira is very sensitive to the configuration you build for
| it, and the hardware it is running on. The full
| configuration for Jira would make an Encyclopedia look
| small. Get that wrong (as many places do), and it is hard
| to use and dead-dog slow, at the best of times. But if you
| have a real Jira wizard who can configure things correctly,
| then it can easily be the fastest and easiest way to
| organize your development and operational support tasks.
|
| I've seen both good and bad Jira configurations. And I've
| seen them run on both good and bad hardware solutions.
|
| There is a reason why Atlassian is getting rid of
| Enterprise Jira, because it's really hard to build a good
| hardware solution for running Jira properly.
|
| I submit that anyone who hates Jira probably has not seen a
| good Jira configuration. And anyone who loves Jira probably
| has seen a good configuration and doesn't understand what
| everyone else is complaining about.
|
| Jira is a real Jekyll vs. Hyde type of tool. In my
| experience, how you feel about Jira says much more about
| the type of configuration you've seen than anything else.
| yjftsjthsd-h wrote:
| On the one hand, I actually do agree with you. On the
| other hand, if nobody can use the tool right, then it's
| not the user at fault.
| greatgoat420 wrote:
| Thanks! I hadn't heard about this before!
| dmitriid wrote:
| > There is a reason why Atlassian is getting rid of
| Enterprise Jira, because it's really hard to build a good
| hardware solution for running Jira properly
|
| And they are replacing it with JIRA Cloud that cannot be
| configured at all, and is unbearably slow.
| pjerem wrote:
| > There is a reason why Atlassian is getting rid of
| Enterprise Jira, because it's really hard to build a good
| hardware solution for running Jira properly.
|
| This has been done wrong by Atlassian.
|
| I'm sometimes really jealous when I see fast self hosted
| public JIRAs and by the meantime, the instance I have to
| work everyday on atlassian cloud is both snail-slow and
| airplane-heavy.
| steveklabnik wrote:
| I agree with both of the others who replied. Jira has
| infinite knobs, and they all get turned, and you build this
| massive, complex system when what you really need is a
| textbox and some tags.
|
| I am not normally a "less features is more" kind of person.
| But with issue tracking, I am.
| nzmsv wrote:
| Even when JIRA isn't slow: it has an absolutely horrid
| implementation of search that basically gives you a bunch
| of random issues in addition to what you are looking for
| (your search term appears nowhere in them). The exact set
| will randomly change. And it'll keep insisting on being
| helpful and turning your search into "smart" query and then
| failing because it is not valid.
| thrower123 wrote:
| I desperately just want something like Trello boards in Azure
| Devops...
|
| There are boards, but they are so unwieldy. Just put all the
| work items on a board and let me drag them around and see
| everything at a glance.
|
| Everything else with the source control and build pipelines and
| wikis is so good, this weakness is glaring.
| typeofnandev wrote:
| If only it _was_ the case!
| madeofpalk wrote:
| Sliding in here with the hot take, but Jira can actually be
| pretty good! Github is _terrible_ at project management.
|
| The problem with Jira (or at least used to) is that it has so
| much complexities that let people make it overly complicated.
| [deleted]
| eyelidlessness wrote:
| I _hate_ that I agree with this but...
|
| I soured on Jira because my first experience with it was a
| horrible Rube Goldberg configuration on a self hosted
| instance.
|
| Years passed, I tried a bunch of different ways to use GH
| Issues as a primary tracking tool. It works but it's...
| blah. It's a good outward facing tool, it's not good for
| tracking internal work. Because there's no organizing
| principle.
|
| My last job forced me to use Jira again and, don't get me
| wrong! It's still bad. But given the nature of my role in
| that job I ended up setting up a new board and I was pretty
| amazed to discover that you could set up a new project with
| relatively sane defaults. And you can turn most of the
| complexity off and get _almost_ bare bones Trello.
|
| The only thing I couldn't sort out to make it habitable: I
| really wanted to disable the "sprint" concept and have a
| single board without gymnastics. I don't know if that's
| just baked in or something the company configured.
|
| In any case, that bare bones Jira setup was basically
| functionally equivalent to GitHub Projects, and
| surprisingly a better UX. Neither are great, this isn't
| praise for either. But I'm just owning my bullshit and
| admitting I was surprised that the (now year old) modern
| Jira UX surprisingly didn't torture me as much as I
| expected.
| typeofnandev wrote:
| >The problem with Jira (or at least used to) is that it has
| so much complexities that let people make it overly
| complicated.
|
| I actually really like this take, because a lot of the
| times it feels like a tool's complexity is from what it
| lets you do. I feel like if Jira was "dumber" (i.e., less
| feature "rich") it'd be so much better.
| gregmac wrote:
| I was previously a JIRA admin, and what I very quickly
| found was making the workflows the least restrictive
| possible was the most effective. JIRA itself is quite
| feature rich and that can be abused, but using it to make
| your configuration relatively "dumb" makes the actual
| user experience a lot better.
|
| I very actively pushed back on any requests to add
| additional states, but nonetheless there were several of
| them though mainly to facilitate kanban columns and way
| our dev and QA people worked together.
|
| I think the biggest thing is I ended up adding a ton of
| transitions between workflow states. Eg: "QA in progress"
| straight to "Dev in progress" was allowed, as was pretty
| much any state to "Closed" (so long as resolution was
| wontfix/invalid/etc). It took lots of time to get that
| setup properly and ensure transition states had the right
| name (so the button in the UI had a logical label), but
| it was well worth it.
|
| The only real workflow restriction we had was that to set
| an item to "closed" with status="resolved" it had to have
| a fixVersion assigned. This was a trivial thing to deal
| with day-to-day but made the list of closed tickets
| immeasurably better (eg, building release notes, or
| tracking down what versions a bug affects based on when
| the feature causing it was originally introduced).
|
| Comparatively, I've used JIRA in a massively locked-down
| state -- where there are tons of required fields, very
| prescriptive workflow that often requires 3-6 transitions
| to get from one state to another, specific roles required
| to do transitions -- and it sucks. It makes the ticket
| content and statuses _worse_ (not better) simply because
| everyone hates using it.
|
| If people aren't following the team's process (such as
| devs clicking "QA passed" without doing QA), that's a
| _people_ problem, and it isn 't going to be solved in the
| JIRA workflow editor.
| steveklabnik wrote:
| This is why I prefer Issues. The lack of features is a
| feature.
| madeofpalk wrote:
| To be clear - you have to go in and actively make Jira
| worse to make it bad. If you stick to the modern defaults
| and don't add in additional workflows you'll be fine.
|
| It's certainly an indictment of Jira and it's technical
| legacy that it lets to make it bad.
| aunty_helen wrote:
| I worked at a company that created a team of people to go
| in and actively make jira worse. Of course that's not
| what it was envisioned as, their actual job was to make
| jira fit the stakeholders requirements and buiness
| processes we had.
|
| However, sometimes your crappy 60 person company doesn't
| know what's best. If jira didn't have the ability to make
| it crap it would be a better product and people would
| update their processes or maybe just try not to smush
| existing ms CRM workflows into a tool for devs.
| dragonwriter wrote:
| > If jira didn't have the ability to make it crap
|
| Then your managers would buy a tool that did instead.
|
| > maybe just try not to smush existing ms CRM workflows
| into a tool for devs.
|
| If your employer wants a tool into which those workflows
| can be smushed and wants devs integrated into those
| flows, that's what they'll get.
|
| Blaming a tool for supporting your management's desires
| is...missing the people obviously responsible for the
| working conditions that are frustrating you.
| aunty_helen wrote:
| Jira existed as a better product before this and gained
| popularity without this functionality. I used and
| championed old jira in this business but hadn't used it
| for some time.
|
| A better realisation would have been that one tool isn't
| going to integrate everything in your business from
| developing software to dealing with customers billing.
| dragonwriter wrote:
| > A better realisation would have been that one tool
| isn't going to integrate everything in your business from
| developing software to dealing with customers billing.
|
| The trend (e.g., ERP and BMS) is definitely toward that
| in a much deeper way than broad use of JIRA alone
| represents. The "better realization" is probably more
| subtle, and involves more respect for the line workers in
| defining how their work is done and what the requirements
| are for the components of a broad enterprise-wide
| automation system that they interact with are, and
| balancing that with the information preferences at higher
| levels so that the latter are satisfied (and maybe
| compromised in some ways) in a way which preserves the
| ability of the line workers to deliver business value.
|
| But, in either case, not having that realization is
| management issue, not a tool vendor issue.
| dleslie wrote:
| I happen to agree.
|
| I miss the data analysis tools Jira had at its disposal,
| and the ability to create home pages with all sorts of
| graphs, todo lists, and so forth.
|
| Since last using Jira I've never felt nearly as aware of
| the state of a project as when I did.
| porker wrote:
| Yes, dashboards are underrated by those who haven't used
| them.
|
| The data analysis tools did cause problems at one company
| I worked at. They had a very locked down JIRA install and
| management were in thrall to the burn-down chart. If you
| got behind you were hauled over the coals.
|
| The burndown chart only considered the rate tickets were
| closed. So developers started creating extra tickets at
| the start of a project, so that when they got behind on a
| larger issue they could closed off some of the small
| tickets and the chart would stay on track.
|
| Management never spotted.
| Talanes wrote:
| For some reason, plenty of people in management don't
| seem to realize that raking people over the coals over
| individual data-points just incentives your workers to
| avoid giving up data.
| dleslie wrote:
| Ha! I was a team lead at a company where something
| similar happened. Management was obsessed with the burn
| down chart and equated total completed with productivity.
|
| So I told my team to make tasks as atomic as possible. If
| it can describe two meaningful changes then it should be
| two tasks.
|
| I actually preferred this outcome. Instead of a large
| task for a feature, we had hundreds of tiny tasks that
| culminated in a feature. It was far easier to get a
| handle on what was getting done and what was the
| impediments.
| moksly wrote:
| I'm not sure I agree, I think things like GitHub issues are
| actually replacing Jira for a lot of companies who either
| aren't yet, or not too heavily invested in the atlassian
| approach.
|
| We did a comparison program with a sister city who uses Jira
| for their entire process because it had been a good time-
| tracking system at the time, and we found that their project
| managers and developers spend around 5 hours a week on
| something that ours spend on average 35 minutes on. This is
| anecdotal and we're not exactly real "software development"
| cases as we are small helper functions in major enter
| organisations, but it does speak volumes as to why using Jira
| in our little anecdotal setting seems terrible. This doesn't
| mean our sister city will change their ways though, they won't.
| So in a sense you're right that jira isn't getting replaced at
| their place, but it does mean we won't consider it and will
| instead look to other tools.
| kwertyoowiyop wrote:
| Jira is so horrid that I actually might turn down a job offer
| from a company that used it.
| breakfastduck wrote:
| I'm lost now when it comes to project / dev / story etc
| management tools.
|
| No idea what the best option is, any recommendations for tools
| developers will _actually_ use or do you just need to do a
| custom integration with github issues?
| eyelidlessness wrote:
| - Still my preferred solution: real cards on a real board.
| Physical space limits prevent overload in a lot of ways.
|
| - Very seriously discussed prototyping a remote robotically
| operated version of a real physical board with a friend when
| the pandemic started, but we both got too busy.
|
| - Trello, with most optional things not turned on, is still
| the closest thing to a real kanban board. Do go ahead and
| enable GH integration, but don't turn on the zillion things
| that turn it into yet another Jira.
|
| - AirTable's kanban view is surprisingly good, but it's
| fundamentally a shared spreadsheet and a lot of UI/UX
| confusion comes from that because any filtering or sorting
| you do is global to others using the same view.
| [deleted]
| burlesona wrote:
| I switched from Jira to Linear and am very happy with it.
| Just the right mix of power, completeness, and customization,
| without any fussy fiddling. It's also blazing fast.
| jschwartzi wrote:
| Linear.app is way faster and tighter than JIRA, but lacks a
| lot of features that I actually really need in my job:
|
| * Advanced Roadmapping - JIRA will, given a pile of issues,
| sort them and fake-assign them to individuals on your team
| to determine how long it will take you to complete a
| project. This is way more powerful than burndown charts and
| cycles when you're planning a hardware project with a
| tightly-defined deadline. Without it I have to drop back to
| spreadsheets to provide any insight into when a project
| will be completed. It's especially important when the
| business peels engineers off the project.
|
| * Time-based estimating - JIRA lets me plug hours in for
| estimates instead of railroading me into T-shirt sizes,
| which means I can actually use the tool to give an accurate
| estimate of when we'll be done. Linear requires you to
| calibrate your expectations by running a few cycles first,
| which makes it a really bad fit for projects that have a
| defined end date.
|
| I think Linear has a lot of potential for teams that don't
| work to fixed deadlines, but for my purposes it's just a
| very fast spreadsheet.
| breakfastduck wrote:
| We're running Monday. Has to be used by approx 60-80 users
| mix of dev / old school projects & support.
|
| I'll check out Linear. Been looking at Clubhouse too.
| porker wrote:
| Linear looks like a clone of ClickUp (which we settled
| on) and I'd recommend checking it out too.
| design-material wrote:
| What's wrong with Monday?
| breakfastduck wrote:
| Honest truth - our developers don't like it.
|
| Very DIY. You can build great workflows if you put the
| effort in. Brilliant reporting, main reason we adopted.
|
| Clubhouse for example gives the agile structure (epics,
| stories etc) by default and you conform to it. Minimal
| setup effort. From a 'management' perspective I actually
| like monday, by the actual end users don't seem to like
| it.
|
| Getting a true hierarchy and relationships requires
| similar thought to setting up a SQL DB. Powerful, but I
| don't think we have the resource to really build upon and
| support stuff.
| porker wrote:
| I've never found a solution that both developers and
| management like.
|
| We tried dozens and I've put it down as an unsolved
| problem.
| prennert wrote:
| We are using clubhouse after looking at a lot of
| solutions. We all like it as it is quick, low complexity
| and does not introduce artificial barriers between the
| teams.
| danielheath wrote:
| I've long wished for a tool that (for git) what fossil has
| built in: issues stored in the repository, where developers
| can use their full range of tools to work on them locally.
|
| A few additional things would be required to make this work
| for less-technical team members, and you end up building some
| of your own workflow, but it means that E.G. you have options
| like "update the description of a ticket as part of the pull
| request that implements it".
| froh wrote:
| git-bug looks promising to me:
|
| https://github.com/MichaelMure/git-bug
| mikepurvis wrote:
| I want that too, but I think it only really works with a
| monorepo, or else you end up with having to aggregate
| issues from all over your different repos as well as
| dealing with bridging that automation so that an issue in
| repo X can be resolved by PRs in repos Y and Z.
|
| (I'm in a many-repo company that used to use the per-repo
| bugtracker built into Bitbucket and switched many years to
| Jira. Jira has its warts, but it's miles better for the
| project management level task of burning down to a
| release.)
| breakfastduck wrote:
| Worst requirement we have - old school board who want
| roadmaps, timelines or more honestly _numbers_ that
| illustrate _performance_.
|
| It's a losing battle between tool functionality and
| reporting abilities.
| Izkata wrote:
| Experimenting with distributed issue trackers in git was
| popular in the early 2010s, there were a whole bunch of
| different implementations people came up with for git. Most
| of them died out though, there were typically a few
| problems - this is what I remember offhand from
| experimenting with a whole bunch of them:
|
| * Some of them make a mess of some part of git; one of them
| put its info in separate git branches you couldn't delete
| without breaking it, to ensure changes were always
| pushed/pulled even without a special push/pull command for
| the issue tracker.
|
| * At least one of them kept their info in the repo in a
| dot-prefixed directory and auto added/committed the file as
| changes were made; this meant a single issue could be in
| different statuses depending on which branch you were on
| and there was no overarching view.
|
| * The rest effectively ran in parallel to the git repo,
| pushing and pulling their data within it but requiring
| their own commands to do so, so it was totally possible to
| clone the repo and not get the issues.
|
| * Most of them didn't have a non-repo way to track issues,
| for project managers and such. One did have a webview that
| ran from a repo, but it was up to you to figure out how to
| keep it in sync with the comments/etc devs were putting in
| their copies of the issue tracker.
|
| Sibling mentions git-bug, a few others I recalled/quickly
| found:
|
| https://github.com/aaiyer/bugseverywhere (I think this is
| one of the original ones)
|
| https://github.com/dspinellis/git-issue
|
| https://github.com/neithernut/git-dit
|
| https://github.com/google/git-appraise (I think this one is
| newest and I probably never tried it)
| morelisp wrote:
| > a single issue could be in different statuses depending
| on which branch you were on
|
| To me this is the main point of storing issues in git!
| Izkata wrote:
| Consider the "no overarching view" part: if you just
| cloned the repo, you'll see a bunch of open issues and no
| hint that they're already being worked on, because you
| have to check out each branch to see if that issue has
| updates.
| michaelmure wrote:
| It seems to be a polarizing idea. Many people can't stand
| it, but also I suspect that very few actually worked with
| something like that.
|
| In any case, I believe that it's better to build a data
| model/storage without that concept (read: don't store the
| data in the same branch as the code) to have the freedom
| to built it with less constraint and make it right. Once
| that work you can add this "branch sensitivity" concept
| on top and again make it exactly how you want it.
|
| An example of problem you get when storing the bug data
| in normal code branch: cool, you got the bugs state
| deeply stick with the code so you know exactly when a bug
| is resolved and in which branch. But now you are stuck
| with git only to deal with merge conflict, which means
| you might need to have the user fix it when it goes
| wrong. Will you push that to a non-technical person as
| well? Also, what happen when you rebase or cherry-pick?
| plorkyeran wrote:
| Jira is an amazing argument for the idea that having too many
| features is itself an anti-feature, and github issues' second
| biggest strength compared to it (behind the integration with
| github) is specifically that it doesn't try to do everything.
| cryptonector wrote:
| Or an argument for doing it right. It's got a query language
| that looks a bit like SQL, just... not SQL. It's got an ugly
| but responsive UI. It's easy to over-customize.
|
| The real problem is that it gets over-customized, and as with
| all databases, schema is forever, so after enough years of
| using it you have: ugly remnants of how you used to do things
| mixed with the ugly new things you're doing, and a devops
| team dedicated to maintaining and further over-over-
| customizing your JIRA instance.
| systemvoltage wrote:
| I equate this "swinging pendulum" to be more akin to optimization
| than just back and forth between two foci. Imagine that the
| problem space lies in a multidimensional landscape and humans are
| trying to evaluate (explore) in various directions to see which
| works the best. Usually, it sticks and its an obvious solution.
| But many things are a regression. As technologists, we should
| strive to have optics for this sort of thing - sometimes _old
| things are actually better_. We went down the wrong slope and
| need to walk back to the previous peak and try again.
|
| Those who do not understand this tend to stick people into two
| buckets and then start an unending argument streak. Recognize
| that going back is 100% foolproof by definition - hindsight is
| perfect and going forward is a toss-up. If you can evaluate and
| have a good measure for current vs. old, don't be afraid to leap
| backwards. Startups should exploit hindsight and they do.
|
| There are also stagnant local optima that we need to _really_ go
| out there to find a new peak. These we coin as revolutionary
| technologies that change history forever.
| greatgoat420 wrote:
| I think there is something with this, and the minor resurgence of
| interest in C. I think people learn about the issues with memory
| and threads in C, use some other language and come back to C with
| better appreciation for what can go wrong and better care to keep
| things safe. C is the less fancy tool. It gets out of the way as
| much as VS Code does.
| hyperpallium2 wrote:
| A tool maps user inputs to results. A programming language is
| fine-grained - complex input to desired result. A fancy tool is
| coarse-grained - simple input to result.
|
| As an industry matures, what users want to do is better known and
| methods for doing are developed, so a coarse-grained mapping
| becomes possible - on both ends.
|
| But this process can cross industries above, obsoleting entire
| roles; and below, creating new roles.
|
| A "role" is something requiring complex user input to specify a
| result.
| Animats wrote:
| Webflow is a service, not a tool. Unfortunately.
| ravenger00 wrote:
| Old man shakes fist at clouds
| plondon514 wrote:
| When I see articles like these I usually:
|
| 1. cmd+f 'linear'
|
| 2. see result
|
| 3. smile
| ZeroGravitas wrote:
| Amusingly, the last paragraph is almost the exact opposite
| conclusion I just typed on another thread, that Ctrl-P type
| interfaces in Vim is the future of programming UI.
|
| I've struggled with the notetaking issue as well and think the
| important part isn't the taking notes, but the processes around
| it. The paper/ink based note systems that work possibly do so
| because they accidentally force you to refer back to things
| repeatedly, like the virtual note taking system they use.
|
| I can certainly think of times I've written and then forgotten
| notes in ink.
| theelous3 wrote:
| > but the processes around it
|
| Couldn't agree more.
|
| I keep a notes vim open in i3's scratchpad. Mod+minus and it
| appears front and center, I make a note. I shortcut again and
| it's gone. I use one giant text file so everything is always
| searchable on hand.
|
| I never kept notes before this setup, no matter how hard I
| tried. I just made it as ridiculously easy and zero-brain-
| required as possible. I don't even like using vim, but the
| setup is just too straightforward. I've become a note making
| machine, and I love it.
| ZeroGravitas wrote:
| Sounds similar to my current setup. Partly inspired by Bullet
| Journal's paper based system, it's a per "project" (basically
| usually a git repo) notespage, that appears and disappears
| with a hotkey. It also acts as a margin to center the other
| vim buffer when I'm only working on one file.
|
| It functions mostly as a Todo, so if I'm in the middle of one
| thing and think of another thing that I want to come back to
| later, I can add it here. And when I'm thinking, what next? I
| can consult it and tick things off to feel like I'm making
| progress and remind me to break big tasks into smaller tasks.
|
| As yet incomplete parts of the process are stealing some
| ideas from Bullet Journal and having global "pages" that I
| can call up, a system for copying (not moving!) issues to
| other places (similar to the > in bullet journals). My theory
| is that digital workflows err on the side of only showing you
| what's relevant, and you need to correct for that to a degree
| to see the full benefit.
|
| I do still like "thinking" with a pen and paper though, not
| sure why, but then distilling that down into typed text.
| peterarmstrong wrote:
| The cycle also goes hand-in-hand with languages and frameworks. I
| use VSCode for Ruby on Rails editing, but I don't need to. With
| TypeScript, however, it's a huge win -- just as IDEA or Eclipse
| were essential for Java, back in the day.
| varjag wrote:
| Dialectical materialism but for tech.
| Mommasboy wrote:
| I upvoted because author shared a good personal opinion. This is
| in no way an industry dive opinion. Too much generalisation.
| systematical wrote:
| Linear looks nice. Anyone using it?
| amhenk wrote:
| I've been using it for side projects and I'm a big fan. The
| keyboard shortcuts are convenient and they make it easy to pick
| them up as you navigate around the app. I also like their
| approach to the traditional epic with projects that have their
| own set of work items/timeline. Overall I feel like it's more
| intuitive than what I use for work
| devmunchies wrote:
| i'd never heard of it. just signed up after seeing it in this
| article.
| 0xCMP wrote:
| It's basically cause of mobile. Simple tools often involve using
| files. Using plain text files too. I don't think the pendulum
| will swing back the same. Files are a bad abstraction. Databases
| via HTTP APIs are far more reliable for using between all our
| devices. Syncing files without something like Git is very painful
| and for Git to be used the user themselves need to be able to
| handle the diff themselves correctly. And they'd need to do this
| all on Mobile. It basically kills plain files for anyone except
| the most advanced users and requires very complicated apps (e.g.
| the _wonderful_ WorkingCopy on iOS). The problem yet to be solved
| for normal users is how do you take advantage of that convenience
| while still letting users own their data?
|
| There are some attempts but basically at the end of the day it'll
| require more support from the various operating systems (mainly
| mobile). There needs to be some underlying open data format which
| can be synced easily that recreates a database locally that apps
| can query directly and optionally some way to proxy those
| requests to a central service when the device can't/shouldn't
| have direct access to that database (lack of storage, lack of
| compute to run the database or app, lack of privilege's to have
| possible direct access all of the data.)
|
| If you can't solve encryption, syncing, and ability to easily use
| the same rich data between devices and operating systems you
| won't reverse the trends to move everything to these fancy tools
| which almost all end up being centralized and requiring the user
| to be online regularly even for data which only their own devices
| would ever be using.
| flohofwoe wrote:
| That's a fairly dystopian outlook. There's no (technical)
| reason mobile operating systems can't be just as open as
| desktop operating systems. The only reason why mobile platforms
| are locked down are business interests (we're lucky that IBM
| lost its iron grip over the PC platform early on, otherwise
| we'd still be stuck in the computing dark ages).
|
| (apart from that: a filesystem _is_ nothing else than a
| database, and text files are pretty much the most open data
| format imaginable, it 's not like we arrived there by
| accident).
| osmarks wrote:
| A filesystem is a hierarchical key-value database, which is
| not what many applications actually want, and plain text is
| not a data format for anything except structureless human-
| readable-only, well, plain text. While you could then put
| some textual format like JSON or ad-hoc space separated
| values or something into a text file, the tooling around text
| files may not deal with this very well. And it's slower than
| something like SQLite and lacks the aforementioned convenient
| syncing capabilities.
| ashneo76 wrote:
| Files are a great abstraction. They give you ownership, actual
| one, not the kind sold by apple or Netflix. Files give you
| freedom to share informatiin instead of being held in a
| database by some third party with different intentions than
| your freedoms. Please don't spread FUD
| 0xCMP wrote:
| For storing bytes at a path on disk? Sure, but it's low level
| abstraction. Something which only developers and sys-admins
| should be concerned with.
|
| Users would much rather work with logical items. A "photo"
| which includes metadata, photo files, photo edits, ratings,
| face/object detections, and etc. as a single "thing". A tweet
| thread. A blog post on Medium or in WordPress. A Google Doc
| or Sheet.
|
| The question is how do you provide that seamless "anywhere,
| anytime" experience while keeping that data as local to the
| device as possible? Files by themselves just can't solve
| that. There needs to be a protocol, a data format, and mobile
| OS support.
| brabel wrote:
| You're basically describing Microsoft OLE[1].
|
| There was also the open-source alternative, OpenDoc[2] that
| never got anywhere... this has been tried and just doesn't
| work.
|
| The only thing that seems to work is media-types on the
| Internet... with the browser as the universal
| viewer/processor... but as it is currently, it's hard to
| make it better than what we have.
|
| [1]
| https://en.wikipedia.org/wiki/Object_Linking_and_Embedding
|
| [2] https://en.wikipedia.org/wiki/OpenDoc
| pessimizer wrote:
| I think it was just an observation, not a recommendation. If
| we can't defend a free lifestyle from within this new, messy,
| network, then the future is proprietary and rented from the
| cloud.
| gryn wrote:
| The issues of control and whether the file abstraction is
| that good are orthogonal.
|
| I personally hold the view that it could have been better and
| that a more general notion of persistent object (not in the
| OOP sense) would've been better from a user facing pov.
|
| The filesystem is doing more than one job, holding multiple
| responsibilities and imposing a way to present data and how
| to store it.
| throwawaycuriou wrote:
| Not perpendicular, just unaligned.
| Otek wrote:
| I agree with you completely. I love orgmode and I love emacs
| but using tool like TickTick or Things3 for my todos makes it
| so much better because without any hustle I have the same
| version everywhere and with nice UI. For stuff that I don't
| need to sync, merge etc on many devices I definitely choose
| Emacs + Org. For stuff that I need on the go, updated on the
| spot - sorry, too much hustle for me
| bitexploder wrote:
| First, this is an interesting take, and I think there is some
| kernels to consider in it. However, the author is painting very
| broadly with a large brush and smudging a lot. I have been
| happily using PyCharm/IntelliJ since what feels like the dawn of
| time. It is a perfectly complex and rewarding Fancy Tool. People
| still use IDEs for C/C++ this whole time, etc. I think the author
| is taking their personal journey and experience and extrapolating
| a bit too much about trends in the industry. I found myself
| nodding along at times and then saying "What?" the next sentence.
|
| My thoughts:
|
| * JIRA, still heavily used in many, many places. Not even close
| to being replaced in them.
|
| * Evernote vs. Markdown: I have been using org mode and or plain
| text notes for over 20 years. Markdown was a welcome addition to
| the arsenal, but I tried the Evernote/Microsoft Notes back in the
| day... just went back to plaintext for notes+todo, it has worked
| forever and is good enough. Org mode is a very nice and "Fancy"
| tool on its own. But also easy to get started with.
|
| Just some examples. I don't mean to be overly critical, it is an
| interesting and fun article about the tools we use as
| technologists, but it could do with a lot better grounding all
| around.
| sverhagen wrote:
| Jira still for the complex stuff, with many teams in
| enterprises. But maybe less than it was in simple projects,
| with one-to-one relationships between issues tracking and
| repository?
| closeparen wrote:
| We undertook a migration from not-JIRA to JIRA. Our previous
| issue tracker would let us have the same task in different
| columns on multiple boards. You could do your investigation,
| post your comment, reassign to the reporter, and move it into
| your "waiting" column. Then they would move it into their "in
| progress" column, do their piece, and get back to you. A
| complex cross-org issue might show this cycle 5+ times.
|
| In JIRA it is completely impossible. A task has one project
| and one status. You're lucky to have view and comment rights
| on another team's task, forget about change-status or
| reassign. An admin can "move" an issue but then it's gone
| from your own world.
|
| The net result: the issue tracker is no longer a
| communications medium, but a paper trail for the bean-
| counters, where you laboriously log conversations and
| decisions that actually occurred by email or Slack. There
| will be a JIRA corresponding to any give issue, but reading
| the JIRA will not tell you the story anymore.
| wh33zle wrote:
| That sounds interesting, what issue tracker did you use
| before?
| chii wrote:
| There's a bias in HN that favours the simple and clean. But
| the real world is full of bureaucracies and complications due
| to legacy and/or politics or some other factors (like
| momentum).
|
| When HN users argue that certain tools (like Jira) is too
| complex, they imagine that a simpler tool following a simpler
| process would've worked. For them, may be it would, as a
| greenfield project, but not for the enterprise currently
| using Jira or is going to adopt it.
| samat wrote:
| Is this complexity warranted? I mean could not the same
| goals be achieved by less formality and less complexity?
| PeterisP wrote:
| In some cases they could and in some cases they couldn't.
| For a particular example, in fintech development a bunch
| of formal ceremonies are non-negotiable, you need to
| track, document and query who ordered, developed, built
| and tested what and why and has a change request been
| formally approved by someone who has the authority to do
| so. In other cases, the formality is optional, but it's
| still a choice the organization has made.
|
| However, in any case it's not a technical discussion
| about tools, that would be putting the cart ahead of the
| horse, it's about organizational change, which tends to
| be as slow and difficult as a rewrite of a technical
| product. If the organization chooses to have a particular
| process, then they'll switch tools if needed to support
| that process; and the fact that they could use a more
| conenient tool if they would choose less formality and
| less formality does not carry much importance, that
| choice is determined by other factors.
| DoingIsLearning wrote:
| Most Engineering teams would probably work frictionlessly
| with any simple Kanban style board.
|
| The pull force in JIRA is how much it gives PM's and
| other managers a feeling of air traffic control
| visbility. It ends up serving as a medium for less
| technical people to digest and participate in a project.
|
| The features that in my opinion keep Atlassian profitable
| is all the automatic reports and analytics features more
| so than the daily work functionality.
| p_l wrote:
| I can't defend confluence for various reasons, but JIRA?
| HELL YEAH.
|
| The problem is that JIRA is a powerful tool that is often
| misconfigured or otherwise made to suck more than it
| should.
|
| For example on one of my current projects, both JIRA and
| confluence are put behind malfunctioning SSO meaning you
| have extra annoying steps that sap your energy and will
| every time you open them. And then you have to face that
| someone made a royal mess in it and we have to deal with
| it - without access to settings to fix IT. And the final
| nail is that effectively we can't use any external
| integration, because it's all blocked, including just
| using the API on your own.
|
| Now, if I had the power of administrator there...
|
| We would have better work flow, with automation
| supporting human overrides.
|
| We could link issues with our Github Enterprise and use
| local clients (org-jira, gojira, etc) as well as a bit
| integration in MS Teams.
|
| And I would fix login so that accessing JIRA or
| Confluence didn't feel me with annoyance of "where is
| that fucking RSAID" and "goddamn fix MFA already"
| coldtea wrote:
| The post is not about what this or that place or person uses or
| "always have used".
|
| It's well understood that some people have "always used" IDEs,
| and other people have "always used" Vim/Emacs.
|
| The post is about general trends. What kinds of tools were
| trending/rising at some point, what at another at so on.
|
| In that sense, counter-examples don't negate a statistical
| observation. Only whether the trends described in it is right
| or wrong matters, not whether some or even many buck them.
| sokoloff wrote:
| I agree that anecdotes don't negate a statistical
| observation. The original article isn't a statistical
| observation though.
| jruthers wrote:
| Right. The idea that Jira has been replaced made me laugh.
|
| There's probably a crowd of people that want to move on to the
| next issue tracker flavour and that's fine but I've got work to
| do that isn't tool shuffling.
|
| I'll use the one that integrates with so many of our systems
| and, though flawed, does a great job.
| solraph wrote:
| That integration piece is key. The people who want to replace
| Atlassian tools usually focus one part of the suite (usually
| Jira or Confluence), but to replace them you all you need a
| set of tools that work together.
|
| It's not just issue tracking, but alerting, issue management
| ITSM tools, source control, CI/CD, release management,
| documentation and I don't know what else that all need talk
| to each other and provide traceability from any point to
| another. You can do the integration yourself, but it's a
| gigantic PITA, and as the number of tools rises, the number
| of integrations you need to set up is going to rise
| terrifyingly fast.
|
| I have a litany of complaints about the Atlassian suite, but
| none of the competitors have even have the services we need.
| pydry wrote:
| I don't think I've ever seen integration between confluence
| and jira that mattered.
| solraph wrote:
| The useful ones I've seen are where Confluence
| automatically indicates jira tickets that mention the
| page and confluence pages that link tickets that will
| have their status embedded.
|
| It's just those two though, it's also the git branches,
| pipelines, and release integration from jira, being able
| to see the support ticket cases and / or alerts that were
| the cause of ticket/branch/release.
|
| I'm in no way arguing that atlassian does a great job
| here, only that no one else offers that end to end
| integration. (Possible exception of phabricator mentioned
| in a sister thread)
| mtzet wrote:
| On the other hand, I find the integration between Atlassian
| tools to be pretty barebones. It feels very clear to me
| that Atlassian tools are really developed separately, with
| a separate jira task to integrate specific parts. There's
| no "coherency" to them.
|
| You are right that it's difficult to replace the entire
| Atlassian suite. The thing about Atlassian is that when
| there's if there's a box to check on a feature list,
| they've made sure to check it. If you go around the office
| asking everyone what features they want, Atlassian is going
| to check all those boxes. That's pretty hard to compete
| with.
| [deleted]
| paulryanrogers wrote:
| Second this. Even within JIRA itself the markup it
| accepts is inconsistent. Back ticks vs double brackets
| being the bane of my existence.
| hinkley wrote:
| It is infuriating the extent to which Atlassians tools
| are only slightly more integrated with each other than
| they are integrated with third party tools. If they'd
| done a better job with their acquisitions then we would
| all be complaining about how they've not done enough for
| third party tools.
|
| I kind of want a modern version of Trac. Trac is
| essentially a collection of integrations that just happen
| to have useful features.
| gknoy wrote:
| There's no "coherency" to them.
|
| It's interesting to hear you say that. With the
| integrations we have with Slack and Github, I see
| previews, summaries, etc thrown at me when I link things
| mih wrote:
| I recently had to upgrade Jira and Confluence at the
| workplace. It was clear from their configuration methods
| and how they respond to errors/failures, they are written
| by different development teams. One needs to be an admin
| to experience this, ordinary users will see no
| difference.
|
| Take for example the admin UI. When adding "Application
| Links" to link Jira and Confluence with each other, Jira
| has a nice tabbed interface allowing you to configure it
| easily, whereas in Confluence, you have to scroll down a
| long sidebar with dozens of options until you chance upon
| the required link. Had similar experiences configuring
| various other options at the filesystem level.
|
| Jira configuration was more coherent, fault tolerant and
| failed gracefully. Confluence configuration on the other
| hand was messy in comparison.
| Macha wrote:
| Or even just the wildly different text formatting syntax
| across tools
| hinkley wrote:
| As a bamboo user who is not an admin, everyone on that
| team can fuck right off.
|
| Whoever thought it was a good idea to build a CI tool on
| a concept of information hiding is a monster who should
| be banished back to whatever eldritch plane they crawled
| out of.
|
| You can't have a coherent conversation with anyone about
| the functionality of Bamboo versus other CI tools because
| _Bamboo is constantly lying to you about what is
| available_. You don't even know to ask other people for
| help with something because you don't know if Bamboo can
| do it. So people use the ugliest kludges that their
| privilege level allows to get things done, creating an
| unmaintainable mess in the process.
| zozbot234 wrote:
| > It's not just issue tracking, but alerting, issue
| management ITSM tools, source control, CI/CD, release
| management, documentation and I don't know what else that
| all need talk to each other and provide traceability from
| any point to another.
|
| Isn't Phabricator trying to do all of this? It seems to get
| quite a lot of fairly high-profile usage in both enterprise
| and community-focused/FLOSS contexts.
| solraph wrote:
| I wasn't aware of this, I'll have to check it out. Looks
| like it would especially good for companies that can't or
| won't the atlassian tax.
| licebmi__at__ wrote:
| Well, to add a counterpoint, never in my career I have
| encountered a place with a proper atlassian products
| integration. The most common integration I saw was using
| Jira and Confluence, which seems a little underwhelming to
| me. In all the places I have seen a mishmash of different
| products not really glued together and the workers had to
| navigate that mess. One of the places I've worked on had
| salesforce for customer sided issue tracking, and JIRA for
| software development tracking. Support engineers had to
| copy and paste tickets to raise defects and bugs, keeping
| track of all the interactions in both systems. Silly stuff.
| solraph wrote:
| That's my point though, the alternative is glueing all
| those tools together, and Atlassian promises (and frankly
| often falls woefully short on delivering) to give you an
| integrated out of box experience.
| coldtea wrote:
| > _Right. The idea that Jira has been replaced made me
| laugh._
|
| It shouldn't though. Jira wasn't always here, and it wont be
| here forever.
|
| And what's even more important, and is the point of the post,
| trends don't stay the same, whether a tool still maintains
| its existing userbase or even increases it.
|
| In a changing market, a tool might hold or even increase its
| userbase, but still end up with much smaller marketshare.
|
| If we add qualitative considerations too, then it's also very
| possible a tool to remain dominant even in market share, but
| still lose mindshare (and eventually be dropped by the next
| gen of developers).
|
| Tons of people and companies use Visual Basic too, but it's
| not where things are happening (or what one should study to
| get a job in 2021).
| randallsquared wrote:
| > _I 've got work to do that isn't tool shuffling._
|
| Is most of that work waiting for Jira to respond to your
| action so you can take the next action?
|
| I don't know if it's possible to have an adequately fast
| installation of Jira (since I've never seen one in a decade
| of Jira use at various places), but I do notice that people
| who have to put a lot of things into Jira seem to mostly use
| text editors or word processors to actually plan, and then
| transfer it a piece at a time into Jira once the initial
| result is done. Yesterday I was in a planning session with
| two others, and we did that planning with headings, bullet
| points, and concurrent editing by all three of us in a Google
| doc.
| rkangel wrote:
| > I don't know if it's possible to have an adequately fast
| installation of Jira
|
| That's not my experience of Jira. The cloud version is the
| best, and our current on-prem installation is perfectly
| fine. I agree that Jira isn't the snappiest tool to use,
| but I don't sit there consciously waiting for it to do
| stuff.
| michaelt wrote:
| No doubt it depends on how you use it, but I find it very
| slow.
|
| For example, I just tested following a permalink to a
| comment on a ticket. After 1.3 seconds I see the ticket -
| but it takes more than 7 seconds until I'm scrolled to
| the right comment, all the ticket details are loaded, and
| so on.
|
| And the slow-ass lazy loading means you daren't click
| something between 1.3 seconds and 7 seconds, because at
| any moment a new button or linked issue box or the
| addition of status icons next to links or something will
| reflow the page.
|
| In my experience this shitty performance is baked into
| every single interaction with Jira. You want to create an
| issue? Two seconds to show up the form. You click the
| 'epic link' dropdown on that form? A full second just to
| display a dropdown menu. Oh, and you also want to open
| the 'label' dropdown? That'll be 1.8 seconds.
|
| And all those are on Cloud Jira, at a weekend, on a <300
| ticket project, on a powerful developer workstation.
| laurent92 wrote:
| > I agree that Jira isn't the snappiest tool
|
| It is forbidden in the ToS 3.3 to "(i) publicly
| disseminate information regarding the performance of the
| Cloud Products".
|
| https://www.atlassian.com/legal/cloud-terms-of-service
| vasco wrote:
| I also confirm that in my experience the performance of
| the JIRA Cloud installation has been mostly fine. It's
| not amazingly fast but only having used JIRA cloud, even
| with loads of projects and so on, I always thought it was
| weird to read all the stories of poor performance.
| treeman79 wrote:
| Compared to something like pivotal tracker, Jira feels
| like trying to swim in glue.
|
| It just gets in the way. Individual actions are
| tolerable-ish. But it's never setup right. Constantly
| hunting for the field that is blocking story creation.
| Permission issues all over the place.
|
| Finding things is often nightmarish.
|
| Management basically doesn't care, and doesn't want to
| put effort into making it work in sane fashion. Yet freak
| out if team wants to use something else. So we do all our
| planning and story tracking in google sheets instead.
| Gravityloss wrote:
| It's like medieval doctors and hand washing.
|
| Fast solutions clearly exist. But somehow everybody ends
| up using slow Jira.
| anoncake wrote:
| Even if that clause is enforceable, you can just tell
| people about it instead. No company would try to prevent
| talk about their products' _good_ performance.
| hinkley wrote:
| I am so, so sick of Atlassian's bullshit.
|
| I remember when we used Trac on a project and it seemed so
| primitive in many ways, but as soon as I had to use something
| baroque (broke), I wanted to go back to Trac.
|
| Not to say that Trac isn't fancy, it just chose a very
| specific dimension of fancy to focus on and ignored anything
| else.
| toomanyducks wrote:
| Personally, I think there's generalizations both ways here.
| Your experience doesn't map one-to-one with the author's, and
| the author's won't map to yours. Neither of them are absolute
| when applied outside of one life. I'd judge its accuracy by how
| well it resonates _overall_ with people, and judging by its
| position on the front page and the sentiment of your last
| paragraph here, it resonates quite well.
| akagr wrote:
| Org mode is easy to get started with if you're an emacs user. I
| am one. But before I used emacs, there was no org mode in my
| life. And let's face it, while emacs and vim allow you to craft
| your flow, most people are gonna use something like VSCode.
| Emacs and Vim have not been able to escape their old school
| image, even with all their awesomeness.
|
| I'd argue that ease-of-starting also includes how visible
| something is, since you can quickly find it and find resources
| for it. Most text editors don't have org mode or have a small,
| half baked subset of it at best.
|
| A lot of amazing adjectives apply to org mode. Ease of use
| isn't it until it climbs over the emacs wall.
|
| Not trying to be combative. I'd love if more people used org.
| Would love to be educated here if something I said isn't
| accurate.
| RajuVarghese wrote:
| I agree with you. I had used micro-emacs in the 80's and
| when, about 3 years back, I heard about org mode I wanted to
| become a big boy and start using emacs. It was a bitter
| struggle and for many months I regretted that I had even
| started down this path. But now I can do the basics and it
| feels much better. I know that I will be rewarded if I
| persist.
| wyclif wrote:
| fsv, which is a clone of fsn (the file system navigator seen in
| the film Jurrasic Park) is still around and useable even though
| it's not maintained anymore:
|
| https://github.com/mcuelenaere/fsv
| imwillofficial wrote:
| Thanks for sharing!
___________________________________________________________________
(page generated 2021-05-15 23:01 UTC)