The Return of Fancy Tools | Hacker News Reader

The Return of Fancy Tools

macwright.com

447 pointstypeofnandev216 comments

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.

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.

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

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

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.

I used to complain about Jira for similar reasons. Then we switched to Azure DevOps, and now I have tears in my eyes and cry "I want my simple and fast Jira back!"

> 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

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.

Actually, I’m obviously not talking about Jira but imagine some made an issue tracker in cloud mode and programmed it using microservices, the speed of each microservice would vary a lot depending on workload, time of the day, location, time since last access of the document/attachment/screen/userdata, configuration of the instance, importance of this customer (maybe I would give privileged speed to a good customer, or to one whom I’ve had problems with on other features) and it would vary so much that performance for one person would be hardly representative of another person’s experience.

That would be one legit reason for thinking about writing this clause. Because it’s really curious to think about writing that.

Not that I disagree, although I feel the problem here is that this clause then can apply to all types of softwares. And even hardwares too. Just think if tomorrow Apple says that you cannot talk about degradation in performance in iPhones (because battery capacity reduces over time or something). We both know this, like we know that a user's experience will differ from the other. A company shouldn’t be adding a clause to prevent talking about this, it sounds like a malpractice to me. (I know it’s not that serious but still…)

Anytime I see similar language, I know I do not have to look very hard to understand why someone felt it worth producing.

They might as well say it:

Will be slow, we feel that does not impact the value proposition.

Our license revenue is super necessary and this is not a race.

Ya, slow now because we need users and features now, go faster later.

If you need it to be more performant, pay us more and make the hardware investments we tell you to...

I personally would respect those more than a blanket gag attempt.

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.

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.

It's like medieval doctors and hand washing.

Fast solutions clearly exist. But somehow everybody ends up using slow Jira.

> but I don't sit there consciously waiting for it to do stuff.

100% of the time I want Jira to do stuff is when I'm interacting with it, and thus absolutely waiting for it.

I use Jira a lot. Waiting three seconds per action makes me think that interfaces based on old-timey mainframes were probably faster.

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.

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.

Second this. Even within JIRA itself the markup it accepts is inconsistent. Back ticks vs double brackets being the bane of my existence.

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.

    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

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.

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.

Or even just the wildly different text formatting syntax across tools

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

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.

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.

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.

I don't think I've ever seen integration between confluence and jira that mattered.

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)

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.

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

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.

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.

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.

I agree that anecdotes don’t negate a statistical observation. The original article isn’t a statistical observation though.

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.

At least in my own specific case, I have neurological damage that has swiss-cheesed my memory. I get that not everyone needs nor wants smart tools, but I prefer to have at least a moderate safety net.

The fact that there's such a wide range of options doesn't hurt. I'm currently using Logseq for note-taking (yeah, I actually had to look up the name. That's how bad my memory is) and it's been a considerable help there. VSCode, well, I use it with custom task setups that script as much of the manual work that I'd be likely to slip up on as possible.

Not everyone needs that sort of thing. I didn't 20 years ago.

So, yeah, I agree with what you're saying-- different tools for different needs.

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?

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.

Is this complexity warranted? I mean could not the same goals be achieved by less formality and less complexity?

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.

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"

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.

Conway's Law seems relevant here, but I don't think I've seen (or seen the desire for) it to be used aspirationally, like "we need to become the kind of company that operates with these complex tool systems).

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.

That sounds interesting, what issue tracker did you use before?

It works well for simple stuff too. You can just _not implement_ a complicated workflow.

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

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.

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.

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

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.

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?

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.

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

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.

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.

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

<waves>

I've personally gone back and forth over the years between IDEs and decent editors for programming in C, C++, and Java.

I started programming before there were IDEs, so perhaps that has some influence, but you did say "...stopped using IDEs once they started".

I like some functionality of IDEs, but most are barely "nice to have", not "must have" -- the thing I find that I miss the most is language aware navigation.

The thing that keeps bringing me back to just using a reasonably powerful editor (for me, that means either Vim or VSCode, both with zero or very, very few extensions) is the lag between new features coming to existing languages (and new languages emerging) and IDEs supporting them in a non-disruptive manner (never mind fully).

With a decent editor, web or manpage based docs, and a command line based build (which I want anyway for releases and/or CI), I'm all good, thanks.

I mean, if I were to be working someplace that required or depended upon an IDE, I'm not necessarily averse to using one again, but that might be a red flag for me regarding that workplace.

I certainly get the appeal of IDEs, and understand that some find more value in a powerful IDE than in using the latest language features.

Both ways of working are reasonable, depending upon your situation, goals and preferences -- I wish more folks would understand that.

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

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.

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

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)

I followed the author’s IDE trajectory but only because I stopped working with C#

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.

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.

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

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

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.

Eclipse is still pretty popular as well.

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.

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.

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.

What do you mean with "they fall apart way too often"?

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

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.

I got my start on Drumbeat which later was purchased by macromedia. I miss my spinning 3D text gifs.

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.

Interesting. I remember Alan Cooper. He wore a beret type hat.

Drumbeat was incredible. VB for the web.

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.

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.

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!

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.

It's how I got my professional start too. It's code editor and file management was pretty nice for the time.

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.

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.

Still can't comprehend why we haven't had 'winforms' again but modern and not windows based.

Power Apps is good but not great.

Same reason people will spend thousands of hours working on libraries like pandas but won't make a better excel. Or something like that.

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.

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.

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.

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.

Audiences change over time. Projects need something less ephemeral to aim for.

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.

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.

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

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.

> Every internal piece of wiring is exposed, raw, to the end-user. Wear insulating gloves.

I'm stealing this one. Hope you don't mind.

Imitation is the sincerest form of flattery.

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

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.

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.

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.

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

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.

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.

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.

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!

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.

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!

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

But wasn't vi the Fancy Tool then?

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)

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

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.

Jira is so horrid that I actually might turn down a job offer from a company that used it.

I work on a large open source commercially funded project, where we more or less have to use Github Issues in one way or another, because that's where community report issues, and I find it very difficult to plan projects on Github.

Github Issues/Projects falls down in a bunch of small and minor UI issues. It's things like being able to have a seperate list of "these are issues for our project, and these are the ones we've prioritised/organised/committed to" (having a backlog) or just easier filtering and sorting.

What I think Jira is really good at is having a backlog, and a project board, and being able to drag things between. It's such a simple set of features I used from Jira that I find valuable but is missing in Github Issues.

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.

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.

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.

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?

They probably meant seconds. A website that takes seconds to open is unusable.

I wish I was mistaken, but I do literally mean minutes. I've measured it with a stopwatch before.

Your internet or Jira server is at fault. I've worked in some places that had really dystopian Jira installations, but never seen stuff quite that bad.

Better tell your Jira admin that something is terribly borked with your company's install, then.

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.

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

I don't know how you have it configured, but I have to say, we dont have these problems.

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.

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

Thanks for replying, I think I get it now. We use SharePoint which has very similar issues.

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.

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

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.

The GP's point was precisely that some can use the tool right.

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

Thanks! I hadn't heard about this before!

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.

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.

Maybe the thing to do is what Slack did with IRC and slap a (better, as the case may be) GUI on rt or Trac.

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.

Github issues work well for simple needs and for issues that don't cross the boundaries of a single repo/don't refer to non-code activities. If even one of those is violated, you're much better off with Jira.

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?

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

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)

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

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?

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.

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

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.

git-bug looks promising to me:

https://github.com/MichaelMure/git-bug

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

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.

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.

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.

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.

Linear looks like a clone of ClickUp (which we settled on) and I'd recommend checking it out too.

What's wrong with Monday?

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.

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.

If only it _was_ the case!

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.

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.

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

FWIW: We have sprints in JIRA at work -- but at my previous job we didn't. I doubt they've been added to the product in the couple of years since I left my previous employment, so I'll guess it was configured not to use sprints there, and still could be now.

We must have missed each other on passing trains. My experience was that sprints are not just built in but required. I set up my last project with a catch all “active” sprint that never ends, and a catch-all “later” sprint that also doesn’t end for stuff that’s not being actively worked on or considered.

Hm... Maybe that's what we had at my old job too, then. Perhaps someone had set all that up before the rest of us in the team ever got to see it, so we never noticed.

Has the "Sprint" link always been on the bottom of the rightmost column?

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

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.

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.

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.

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

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.

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

Sure, but that still sounds like it was your management that should have had this realisation -- but didn't. That's a fault with your management, not the tool.

This is why I prefer Issues. The lack of features is a feature.

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.

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.

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.

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.

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.

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.

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.

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

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.

Not perpendicular, just unaligned.

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.

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

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.

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

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

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.

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.

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.

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.

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

Thanks for sharing!

Google cache link: https://webcache.googleusercontent.com/search?q=cache:gnWsEk...

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.

Dialectical materialism but for tech.

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.

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

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.

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.

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.

With Python you can write super simple to super complex. If you have a large project that benefits by type hinting, use type hinting.

As long as performance isn't part of the requirements, then it is time to rewrite it into Java and C++.

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.

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

When I see articles like these I usually:

1. cmd+f 'linear'

2. see result

3. smile

Linear looks nice. Anyone using it?

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

i'd never heard of it. just signed up after seeing it in this article.

I really enjoyed this take. I hadn't thought of our tools going from complex to simple and back again. Insightful.

Webflow is a service, not a tool. Unfortunately.

Reply on news.ycombinator.com