I use Neovim exclusively for the past 4 years or so. Before that I used WebStorm + sometimes Vim for another 6 years or so. To this day I'm thankful to my colleague and mentor, who introduced me to the basics of Vim (you know, how to quit it and all that) saying "it get's pretty handy when you need to edit something on the server"; that was probably around 14 years ago.
WebStorm was great, it was really magical how it just knows how this or that code relates to another piece of code, navigating around was a bliss. Where is that variable defined? Jump to definition, and you're there. You want to know what's that function does, even if it's somewhere in third-party libraries? No problem, jump to definition.
The fuzzy-finder for everything (literally. From file names to methods to editor's commands and variables) was also amazing.
At some point though I got a bit annoyed with the fact that it took 5 seconds to start it up (multiply that by amount of different projects you need to open), and it's general resource hungry-ness. So I started experimenting with Neovim 0.3 (at the time), and pretty quickly managed to get near-webstorm experience with gutentags, fzf and amazing vim-fugitive for all the git things I did in the command line.
And with resent native lsp & treesitter, it doesn't
I tried VSCode once, which was a fiasco -- for some reason it failed jumping to definition in a basic react project with typescript. Oh well.
Helix looks really cool, I'm playing around the idea of using it more, though I still will have to keep (Neo)vim around for vim-fugitive. Slightly concerned with how much muscle-memory re-training will needed though, then again it didn't took me too much to get to the same level of ease of use with Doom Emacs.
Speaking of which, it worked flawlessly (and has even better git tool), but still was terribly slow at times, so in the end got too annoying to work with.
So in the end it boils down to Neovim being fast, not getting in the way, and habit, I guess.
I used to do that as well. The problem here is that PR belongs to a particular service provider (GitHub, GitLab and whatnot), and thus can be easily lost if you move providers.
Or even if you simply move commits to a new repository (for instance you need to clean out some sensitive information from git history).
In that sense having as much context in commit messages themselves saves the day.
It surely loads faster than speed of light, but with all the keyboard navigation missing, it takes 20x more time to go through each email and archive/delete/reply to. Can't have everything, it seems. :/
> So I started calling people… and quickly discovered that a lot of them have a call phobia, as if human interactions were toxic.
> Not in the sense that they’d be busy and would call me later. But in the sense that they wouldn’t pick up, only to text me 5 seconds later to start the conversation. If I tried to call them back, same thing again. They don’t want to talk, they want to text.
Problem with phone calls is that they are synchronous, yet quite often things callers want to resolve can be resolved asynchronously (= via text messages & emails), but you can handle those when it's convenient.
So at least I'm glad that most of my contacts send me messages in whichever messenger is convenient. We can always agree to call each other if we feel like it will be more convenient, but then it's a much different feeling then just randomly calling.
Also personally 100% of "random calls" I got within last 3 years were telemarketers, so guess how often I answer the phone :-D
Edit: in general I agree strongly that dropping off social networks and in general reducing notifications noise to a minimum (and not only on smart phone but everywhere) does wonders, strongly recommend.
Yep, that's me. I hate phone calls. I don't see phone calls as a natural human interaction at all and they make me really uncomfortable. I never pick up my phone but am almost always available for text messages.
No issues with video call or face to face chat though, so that's not that I find human interactions toxic. But phone calls are something I hate to do. They somehow feel too intrusive and too intimate.
Thats really interesting to me as a gen x'er. Grew up largely before the internet was a thing. I'm in the complete opposite opinion. I find face chat to be intrusive and too intimate. For what could simply handled over voice, no need to see my face or surroundings.
We live largely on zoom these days, and less and less people have their cameras on and they are more like voice calls. I really don't see the difference between this and a phone call
Same. Multinational company, no one uses face / camera unless we need to. Uses up more bandwidth, and calls with China or Brazil are already flakey enough as it is.
Face chat is for friends and family; for business I don't want or need to see your face.
In comparison to calls, texts/messages also bring the tangible benefit of giving more space for one to compose and better conduct their thoughts. This is true even when the people involved are actively messaging each other — it's fine to delay a message for a few minutes whereas in a call there's constant pressure to speak to avoid awkward silence and keep the conversation flowing.
Of course people don't always capitalize fully on this but I think it's a major reason why messaging has come to be preferred over calls.
I prefer texting/chat because of the traceability, especially for work. The chat history is a type of decision log for me, and I really appreciate being able to go back and review or search for conversations.
Oh yes, also that! My colleague was rather frustrated with apartment repair crew he had to deal with. Everything was handled via phone calls, none of the construction folk kept any papertrail whatsoever on who agreed to what (obviously), as a result >70% of things agreed either were completely forgotten, or mis-implemented, or implemented weeks later than they should have.
> Problem with phone calls is that they are synchronous, yet quite often things callers want to resolve can be resolved asynchronously (= via text messages & emails), but you can handle those when it's convenient.
Very true. The OP doesn't understand phone calls interrupt people most of the time unnecessarily. I like texts and emails, because I can process them whenever it's convenient for me, not when it's convenient for the other person.
If calling on the phone is not part of your social connection with other people (and obviously, here it wasn't) then I think it makes sense.
Consider how most people communicate now a days. A call is only for long conversations. No one is expecting to receive a call without a reason, out of the blue. I could certainly imagine people texting back, confused about what their friend wanted to talk about, and whether they could answer in a quick text instead.
That's not anxiety, it's just practical. No one is expecting you to call just to say "hi", they assume there must be some sort of problem that you want to talk about in depth.
> If you don't answer the phone simply due to conversation anxiety, that is not normal and it should be worked on.
I think it should be worked on if the person in question would rather have an easier time talking on the phone. Otherwise I'm not sure I agree.
I'm autistic and phonecalls are a nightmare given ambiguous social signalling over who begins speaking and when. Thankfully at this stage in the game most people contact me via some other communication method, the only calls I get are scammers.
The problem I have with this is the implication that the only valid reason not to want to talk on the phone is "being busy". Maybe they just don't want to talk to you right now. Take the hint!
They’re not busy + can’t accept a phone call + are happy to text? This doesn’t add up at all to me!
I’m the opposite. I tend not to text. Most of my friends and family know this and call. When someone does text me, I remind them gently that I’m not willing to sit there trying to type on a tiny screen to have a mediocre conversation with them when they can just call me instead. I say it in a nicer way of course. It’s never a problem! I guess I’m just old but it looks like the default is shifting towards texting lately. No offense to the texters, but it’s just not my thing.
I'm with you in that I refuse to have a back-and-forth conversation via text.
And most of the time, I love to have a phone conversation.
But, the mental state is not always there for it. I may may be in a low mood, or emotionally exhausted, or a host of other reasons why a voice conversation would not be ideal right now. When I talk to a friend I like to be able to engage with them and give them my best. Sometimes, it's just not the time.
So in such a case I would prefer to speak to them later, perhaps the next day after a good night's sleep. It shouldn't be a big deal unless someone makes it into one.
So many people treat texts like they're synchronous, though. Haven't you ever had people send you follow-up texts half an hour after the first one to "remind" you to reply? I've found this to be really common.
Politely remind them, when you do get around to following up, that unless it's critically urgent (in which case they should call) you will only respond when you can. Which is not always immediately since you have other obligations (work or family) or may be involved in a task where you can't (commuting, when we did that sort of thing).
What I found better than calls, at least with my wife, is Zello - a walkie-talkie-over-IP-app. What seems to work for me is that the talk over it feels natural. Like you're shouting something from other room. It is synchronous and asynchronous at the same time. I respond when I can, there is no call hanging, the conversation is stretched in hours and it naturally fills gaps when we don't see each other.
Calling a person on the phone is a rude act at its core.
I think it was Stephen Fry who once said a phone call is like a person bursting into your room yelling "Talk to me now! Talk to me now! Talk to me now!" We wouldn't stand for that in any other circumstance, but when it happens through a phone it becomes socially acceptable.
At home we have a landline and I'll often call people on that. It doesn't have any way to receive text messages. It seems to me like there needs to be a universal way to indicate whether a given phone number has the ability to receive texts or not. I'm now wondering how many people I've called, who didn't pick up, tried to text me back at that number and thought I was ignoring their texts.
In the UK you can (sort of) text a landline. It's been a while since I've done it but I think the person receives it as a call and then an automated voice reads the message.
I find texting to be one of the worst forms of communication for anything other than short Q&A type communication. Maybe writing letters is a lost art form, like in the past but this was out of necessity more than anything. Emoji's don't replace hearing of a person's voice or reactions to what a person is saying.
Text is too often misconstrued and again emoj's don't solve this problem. The fact that emoji speak even exists is really odd to me, but I guess thats an "ok boomer" for me.
Agreed. Text messages are great for very short immediate ping messages, like "I'm here" when I drove to pick someone up.
But for anything that takes more than about 5 words, please send me an email instead.
My frontend date code just passes a millisecond timestamp to the JS Date object constructor to do validation, so technically any code I've written could be actively deployed until the maximum valid JS Date, which is in the year 275,760. (https://262.ecma-international.org/5.1/#sec-15.9.1.1)
Something has gone seriously wrong with human society if that ever actually happens.
> In my experience, they're always wrong. These systems can be run locally during development with a relatively small investment of effort. Typically, these systems are just ultimately not as complicated as people think they are; once the system's dependencies are actually known and understood rather than being cargo-culted or assumed, running the system, and all its dependencies, is straightforward.
Whenever I hear these statements, it always sounds like "I need to have an identical copy of this skyscraper in order for me to be able to replace one tap on floor 42."
Also good luck running a system that operates on few hundred of terabytes of for instance YouTube data locally.
Also running the whole system locally is usually a pretty good way of creating a "distributed monolith" -- yea, there might be microservices, but also a dozen of assumptions here and there that different parts of system are being deployed simultaneously (usually they are not), or that certain distant parts of a whole system share some behavior that can be changed simultaneously.
So no, you don't need to run the whole system locally. On the contrary, you need to be able to run smallest part of it (hello, microservice) locally, and that part should be responsible for one thing. APIs and frontends can easily share JSON schema to make sure they send and receive valid data, and each service can have tests against that schema, the ultimate source of truth for them.
Boom, suddenly I can develop "big system" piece by piece in isolation on my 7-year old macbook with no problems against tests / storybook / debugger.
>Whenever I hear these statements, it always sounds like "I need to have an identical copy of this skyscraper in order for me to be able to replace one tap on floor 42."
The building industry also has the problem the OP describes:
The problem as I see it is that people who go all in on unit tests tend to be dogmatic about it and suffer the above type of issue whereas the people who want, broadly speaking, to run things as realistically as possible are pretty aware of the real constraints.
Moreover modeling larger is also frequently cheaper because the real thing often comes for free while creating elaborate frequently changing unit test mocks has very high opex.
> Also good luck running a system that operates on few hundred of terabytes of for instance YouTube data locally.
Why can't that be scaled down to a few hundred megs of data running through a system, end-to-end, on the local machine?
Not being able to scale down seems like a code smell to me. Is there so much overhead in the microservices that even at idle, or very low usage, they can't even be started?
For instance PostgreSQL's performance might be very different depending on the size of data query has to operate.
Also if you deal with something like search results, it gets pretty annoying to deal with "well, I don't have enough data locally for this particular thing I develop".
Again, talking here about the "run the world and click on things" approach vs developing against tests / API schemas / whatnot.
Ive had pretty good results with scaling down real world data and using it to run tests against it.
Postgres performance will be different to prod, yes. That's all part of the realism - cost trade off. All models are wrong, some are useful.
The point is that diving headfirst into making matchstick model unit tests is dumb when you could build something to test against at reasonable cost which is a lot more representative of reality.
IMO this is an obvious point if you adopt a cost/benefit approach to development but it's often impossible to see for the dogmatists.
I think we're talking about slightly different things here.
Running service that I need to develop right now with a lot of local data (or even read-only connection to production mega-db) is one thing.
But needing to run that service with a lot of data only to be able to develop some other part of the system (that is not even related to that particular service, but "nothing works" without it) is a pretty annoying development experience.
Well then you have to do some bug hunting, but at least you'd have a fully working version of the system in miniature that you can test any hypotheses against.
To be honest, short of issuing every developer with their own production-grade environment to debug against I am not sure what exactly would satisfy this line of questioning.
Running app locally -- yes, there's nothing wrong with that.
Running 25 different apps that compose "the platform" only to be able to develop something -- sounds overkill to me.
> You don't need hundreds of terabytes to run an app with test data.
Well you could just mock the data and code, but then the according to the author:
> "Run an individual service against mocks" doesn't count. A mock will rarely behave identically to the real dependency, and the behavior of the individual service will be unrealistic. You need to run the actual system.
What matters here are the odds that the production system will behave the same way as your tests. For functional requirements (not performance), the normal situation is that if you replace your data, those odds do not decrease a lot. If you want to test performance, that changes, and you may need an environment as large as your production one.
The author is suggesting running your code (all of it) in a separate environment, that isn't prod. There is a passing acknowledgment that data exists, but nothing more about it. Very likely, he don't talk about data because bringing all of your data into another environment is indeed not viable for a lot of people, or even legal for some.
If you replace all of your data, it's still your code running there. But you must have some data, or your code won't run, and it must look like real data, or your environment will be fake again... where "look like real data" is completely problem dependent.
If your assumptions of a system fail on a single box they will fail more dramatically when they are distributed. If your system is designed such that it can't be executed on a single box then you're setting yourself up for a world of pain.
> Also running the whole system locally is usually a pretty good way of creating a "distributed monolith"
I'm not sure how you came to this conclusion. Nowhere does he mention monoliths or microservices. Even if that distinction is made it is good practice to be able to run your architecture on a single box as a goal.
Going through that exercise alone will force the designer to think about how the application scales up and down, having representative samples of data for test suites, coupling between services and so on.
The orders of complexity increase dramatically for each component running on a separate machine for the system under inspection.
Being charitable, the things you mention do have their place but they don't address many of the problems you'll face when building a complex system.
Funnily enough the same channel that made OP video also made a review on that pedal 6 weeks ago: https://www.youtube.com/watch?v=vaX6WwV_d_s