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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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)
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.
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.
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?
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
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 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
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.
But I stopped, because IDEs were too slow to adapt to current tech.
Text based tools can simply move faster.
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...
I find it hard to think I'd give PyCharm up for my daily Python and Typescript.
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...
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 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.
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.
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.
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.
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.
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.
I'm stealing this one. Hope you don't mind.
Important to note that the subcontract would be paid 1/10th of what his counterpart in Silicon Valley would be getting.
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.
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.
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.
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.
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.
> “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.
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.
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!
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.
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!
Good times....
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).
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.
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.
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.
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?
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".
- 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.
The problem with Jira (or at least used to) is that it has so much complexities that let people make it overly complicated.
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.
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.
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.
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.
(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).
So I always think it's good to have a low barrier for people to get in.
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.
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.
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.
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.
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.
1. cmd+f 'linear'
2. see result
3. smile
