Yes it's a bit annoying if you have to edit something on the fly on a server without a GUI - but fumbling around in vim for this small amount of time is still quicker than learning all the keybindings. and why are you vimming around on the server anyway? isn't that a red flag in the first place?
I have probs spent well less than 1 day in total working in vim, in my dev career.
whereas I spend 8 hours a day in an IDE which catches 80% of my mistakes for me and offers all sorts of other features to boot.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
I'm just starting to use rails and I'm a little bit mad at myself for not doing so earlier. At least at the very outset it's hard to understand why I'd use anything else, everything just works.
I'm mad that I didn't learn it earlier too. But actually, even now I didn't, commited to django, which is kinda of a similar mindset behind the two of them. Love DHH too haha
This is true and I'm part of the problem. I've been thinking about all the suboptimal systems I've learning over the years and how it could be good to move to something more clear or consistent.
I'm not known to conform to how things are done or avoid new things. But like so many before me I have learned these old systems and we can't move past because we have so much knowledge and documentation in the old.
If someone chooses a different system, I'm not there to help, I will fall back to the system I know. I also can't make a good recommendation on what to move to.
However I am also not left behind. Docker is heavily reliant on the concepts of the past. It didn't take much for me to handle because I know bash and the supporting concepts of git.
More JavaScript Frameworks, more text editors, more language options are a good thing.
Yes, 99% of code will still be written in the most popular 5, but the next thing to break the top 5 will remix a bunch of great ideas from whatever that 1% is written in.
Microframeworks and/or libraries that cover the bare minimum of wrapping request-handling are better than massively abstracted, monolithic frameworks. You can build the same structure without the extra bloat.
I repeat this regularly at work. We have a developer who (in PL/SQL) wrote a parameter as "parameter := null" instead of "parameter default null", and the reason was that "I'm not a typist".
(actually planning to write an article on this, if I ever overcome my self-hate/shyness/etc)
Meetings are not something you should avoid or which you should hate, stupid meetings are.
A kick-off meeting is useful, a planning meeting is useful, a retrospective meeting is useful... they are literally there to explain to you how to do stuff, to help the company strategize and/or to help your company make a comfortable environment for you.
Other meetings are to be avoided/hated (and I am looking at you 3-hours long meeting on "definitions")
But the only image you give as a hater for all the meetings independently on what they are about is a very not-professional one.
I tend to agree. It's nice to have "class" syntax if classes are what you actually want... But a lot of old-school devs saw that and said, "Oh, I guess we can do real OOP in JS now..." And JS is just fundamentally not object-oriented in the way that C# or Java are. It's silly to force that paradigm on a language that does so much more...
It's also a much harder language to learn though. This matters in language adoption. If you read the story about why Go was designed like it is you will find details about Google trying to manage complexity and reduce bugs rate and improve complication time in massive C++ code bases with developers of all levels of skills
Most testing of UI components is a waste of time, especially snapshot testing.
Frontend developers should run their code in a browser to see what they built. Any teams I've been on that used automated tests for UI components inevitably have developers who get overconfident in the tests and don't even check their code in a browser, breaking things.
For a test to be valuable it should either be written before the target code, written before fixing a bug, or written for either a project or team so large that people might break things in different parts of the codebase. I haven't seen many exceptions.
I'm a programmer working at Pupilfirst with a bunch of awesome people on our open-source LMS; it makes teaching long / involved / complex courses online easier.
Keep in mind that Python hails from 1991 (actually 1989 but the first public version is 1991). I think it stood well the test of times :D
Though I can see why someone wouldn't like indentation to be syntax, but it's not that different from having gofmt indent all files the same way. It's also one less tool you have to worry about :)
React ships with context and reducer support built in, so I guess you could say that. There's also MobX which is quite common, but most projects can stick with the state management options built into React.
Actually there's a gap year where I didn't code either aand Redux was super popular back then that it was required for react jobs, well, still now but much less. And I didn't use other state management libraries either.
I'm a programmer working at Pupilfirst with a bunch of awesome people on our open-source LMS; it makes teaching long / involved / complex courses online easier.
JavaScript tooling is too complicated but I'm not even sure it's an "unpopular opinion" anymore, even tools developers are aware of that and are working every day to make it simpler (or to hide complexity away with easier abstractions)
I'm going to throw in a suggestion for ReasonML on this one. TS and Flow are great for many reasons, but ReasonML is just 100% better in every way. Compiles to JS and native, and has solid web frameworks in the ecosystem. Can't really go wrong.
It's a waste of time to learn vim.
here's my reasoning.
Yes it's a bit annoying if you have to edit something on the fly on a server without a GUI - but fumbling around in vim for this small amount of time is still quicker than learning all the keybindings. and why are you vimming around on the server anyway? isn't that a red flag in the first place?
I have probs spent well less than 1 day in total working in vim, in my dev career.
whereas I spend 8 hours a day in an IDE which catches 80% of my mistakes for me and offers all sorts of other features to boot.
That seems like a very popular opinion except among those that have learned vim.
Now I'll switch to links to respond to your comments.
Mastering Vim grammar
Igor Irianto ・ Mar 6 ・ 6 min read
visualstudiomagazine.com/articles/...
onivim.io/
I have not found learning vim a waste and still get IDE benefits.
I have learned vim enough to write part of the translated manual in french.
And I'm sorry but it would be delusional to think that vim gives IDE benefits similar to JetBrains IntelliJ IDEA :)
Right it's not a waste of time, it's fun
With the right plugins you can get most of the way there. I'll take 95% of the way there for free than 100% of the way for $150/year.
vim+plugins doesn't do 95% of a modern ide
and $150/year is like one or two hour of work for your employer, I'm pretty sure that he shouldn't care
I think you missed that I wasn't specifically talking about vim, but emulators and new IDE which provide vim's mode based editing.
Inelegant software which has a huge following and a big ecosystem is often better than objectively cleaner, better software.
The reverse is also true if the pendulum swings too far in the other direction.
I relate to this so much! Devs love to hate on Rails so much. I just can't imagine a better tool to make something with ease in a small amount of time
I'm just starting to use rails and I'm a little bit mad at myself for not doing so earlier. At least at the very outset it's hard to understand why I'd use anything else, everything just works.
I'm mad that I didn't learn it earlier too. But actually, even now I didn't, commited to django, which is kinda of a similar mindset behind the two of them. Love DHH too haha
For me, it is PHP who I love to hate. But again, many developers and organizations have achieved more using PHP.
This is true and I'm part of the problem. I've been thinking about all the suboptimal systems I've learning over the years and how it could be good to move to something more clear or consistent.
I'm not known to conform to how things are done or avoid new things. But like so many before me I have learned these old systems and we can't move past because we have so much knowledge and documentation in the old.
If someone chooses a different system, I'm not there to help, I will fall back to the system I know. I also can't make a good recommendation on what to move to.
However I am also not left behind. Docker is heavily reliant on the concepts of the past. It didn't take much for me to handle because I know bash and the supporting concepts of git.
More JavaScript Frameworks, more text editors, more language options are a good thing.
Yes, 99% of code will still be written in the most popular 5, but the next thing to break the top 5 will remix a bunch of great ideas from whatever that 1% is written in.
Microframeworks and/or libraries that cover the bare minimum of wrapping request-handling are better than massively abstracted, monolithic frameworks. You can build the same structure without the extra bloat.
That we teach to much technical/frameworks/lib stuff and don't teach enough how to think about code and how to abstract things in a general way.
People hating on language X. Nobody is forcing you to use Language X.
Google, Facebook, Netflix, and all the big tech companies are highly overrated as an employer.
It's better to write dirty, understandable code than highly abstract and incomprehensible one.
Also, sometimes it's better to repeat some code rather than refactoring a days work just for the sake of "cleanness".
I repeat this regularly at work. We have a developer who (in PL/SQL) wrote a parameter as "parameter := null" instead of "parameter default null", and the reason was that "I'm not a typist".
I would say it's almost always better to repeat code.
My unpopular opinion: Hateing Redux is so often listed as an unpopular opinion amongst React Developers that its become popular.
I'm not hating though, I really understand where it fits. Still I did like lifting state up.
In Gitflow, I think the develop branch is a waste of time.
It's better to have discrete release branches and a single master branch.
This way you can just deploy what branch you need to the dev/staging environment rather than having to merge to develop,
You might like Gitlab Flow
Yes, I think this is approximately what I was thinking of.
(actually planning to write an article on this, if I ever overcome my self-hate/shyness/etc)
Meetings are not something you should avoid or which you should hate, stupid meetings are.
A kick-off meeting is useful, a planning meeting is useful, a retrospective meeting is useful... they are literally there to explain to you how to do stuff, to help the company strategize and/or to help your company make a comfortable environment for you.
Other meetings are to be avoided/hated (and I am looking at you 3-hours long meeting on "definitions")
But the only image you give as a hater for all the meetings independently on what they are about is a very not-professional one.
Javascript is overrated and has an overly complex eco-system. It belongs in the browser.
Classes are the worst thing has ever happened to Javascript
I tend to agree. It's nice to have "class" syntax if classes are what you actually want... But a lot of old-school devs saw that and said, "Oh, I guess we can do real OOP in JS now..." And JS is just fundamentally not object-oriented in the way that C# or Java are. It's silly to force that paradigm on a language that does so much more...
That is a very popular opinion.
I dislike Golang.
go mod vendordoesn't work properly.I can never understand why Golang become popular, when Rust is so much better for developer experience...
It's also a much harder language to learn though. This matters in language adoption. If you read the story about why Go was designed like it is you will find details about Google trying to manage complexity and reduce bugs rate and improve complication time in massive C++ code bases with developers of all levels of skills
Most testing of UI components is a waste of time, especially snapshot testing.
Frontend developers should run their code in a browser to see what they built. Any teams I've been on that used automated tests for UI components inevitably have developers who get overconfident in the tests and don't even check their code in a browser, breaking things.
For a test to be valuable it should either be written before the target code, written before fixing a bug, or written for either a project or team so large that people might break things in different parts of the codebase. I haven't seen many exceptions.
The tabs/spaces debate is stupid.
(Althought I think in Phyton, whitespace matters so yeah, do tabs)
Frankly, I think it's silly for a language to force programmers to even think about indentation, because of how it affects its interpretation.
That's probably what I hated most about Python, back when I still used it.
Just let us use braces / brackets / do-end / some kind of clear indicator, and let an auto-formatter figure out the rest!
Thankfully, modern languages seem to come with a formatter built-in -
refmton ReasonML, for example.Keep in mind that Python hails from 1991 (actually 1989 but the first public version is 1991). I think it stood well the test of times :D
Though I can see why someone wouldn't like indentation to be syntax, but it's not that different from having
gofmtindent all files the same way. It's also one less tool you have to worry about :)Mmmm... I just use Black with Python and it standardises everything.
Personally I find some simple indentation rules preferable to the million different ways to position brackets and braces.
Still refusing to replace PHP with Node.js (I'm using Laravel, but still...)
Didn't alternatives to Redux start to become common about 2 years ago anyway?
React ships with context and reducer support built in, so I guess you could say that. There's also MobX which is quite common, but most projects can stick with the state management options built into React.
Actually there's a gap year where I didn't code either aand Redux was super popular back then that it was required for react jobs, well, still now but much less. And I didn't use other state management libraries either.
Working with GraphQL, using a strongly typed language (ReasonML) was something of a revelatory (positive) experience for me.
Mind expanding on why you think "you probably don't need GraphQL"?
JavaScript tooling is too complicated but I'm not even sure it's an "unpopular opinion" anymore, even tools developers are aware of that and are working every day to make it simpler (or to hide complexity away with easier abstractions)
Javascript has become worse in the past couple of iterations.
I think I can guess why you're saying this, but mind elaborating?
I'm going to throw in a suggestion for ReasonML on this one. TS and Flow are great for many reasons, but ReasonML is just 100% better in every way. Compiles to JS and native, and has solid web frameworks in the ecosystem. Can't really go wrong.
Absolutely! This has been true for me as a TypeScript developer.
Code coverage is a terrible metric, and unit tests are usually a waste of time
Is that assuming the strong-typed language compiles to Javascript? What about the cases where the target is a browser?
Hahahaha agreed!
"Good" code is not elegant or clean, and it's never DRY.
100%, unfortunately that language isn't ready yet.
It's NOT okay to be soft.
I'm actually publishing a post about it tomorrow. Stay tuned.