wrestlerman

You are right.

Hmm, why not just stick to being an indiehacker then? Or stick to being a freelancer?

To be honest, I am curious myself...

I do think that code changes take more than 5 minutes, why? As a person, who pushed the code: 1. I have to read the comments 2. Decide if they are right/it's worth a hassle 3. Sometimes you have to reach out to the author of the comment to clarify some things. 4. Change your branch 5. Change your (thinking) context 6. Apply stuff 7. Push stuff 8. Notify the person that it's done. Many times it's more than 5mins, more like 10/15mins+

I don't hate CR. Someone below explained it better than me, that different people see the code differently. And you should respect that someone wrote it that way and not try to force your way upon them.

> If you getting bit architectural change problems in your code review, you obviously didn't collaborate with the team very well... People should roughly know what your approach is before the CR even arrives at their door

I agree with it a lot. I think that would solve a lot of problems, but not necessarily the small ones.

I don't think it's wrong to get excited about new tech. But from what I have observed it's mostly that one dev that pushes for new stuff and after they get sick/leave someone else has to take care of it and many times it means a rewrite of that functionality. Also many times with new tech, you can't really tell its bad sides, because it takes some time to know if it's solid or not.

A lot of things, my experience is based on working in startups: 1. Suggesting silly changes in CR - instead of A you could have used B. So what? I used A, let's keep it that way, time is money. 2. Long discussions in CR 3. Too much thinking like a programmer. I'm not coding, because I love it(although I like it), I'm coding, because business needs it... 4. Asking for estimates, when we both know that estimates in this situation are impossible to predict. 5. Shitty written tickets. I don't know the app well enough yet, so one sentence tickets won't help me much. 6. Too much obsession over some technology. Everything has some good and bad sides, so stop selling it, especially when no one is paying you to do that. 7. Also, I dislike when you can't get a simple answer to your question, but you get funny looks that you don't know the answer yet.

Not enough information. Please provide more information... (Blinking cursor)

Tooling, that means? I haven't had an opportunity to work on a big/very-big JS project yet. But from experience based on working on small-medium size JS project, I guess console.log() and refresh is just enough.

After thinking about it, I guess readability is a huge part of it, there are lots, lots of JS packages. And it makes sense for them to be readable, so they could be easily updated by new contributors to remain valid.

Personally, I have really hard time contributing to gems, because of so much metaprogramming in them, I don't feel like spending a week to understand what is connected with what and if my changes can break it.

I am also a Ruby dev. Haven't used TypeScript in a big project yet, just played with it, but I'd say it's gonna be a standard for frontend dev soon.

Why? Writing types isn't that time-consuming... Types will tell you very easily what is expected to be passed to function. Why does it matter so much? Imo in Ruby it's not that common that service calls are deeply nested. In frontend it's opposite. Components are very nested and with all that prop passing sometimes you have search lots of files to understand what's being passed. There are proptypes yup, but if you write proptypes, why not types?

Also data on frontend mostly comes from backend, so many times there is no really good docs for data that is brought from backend. In backend you mostly access 3rd party APIs with docs or your DB, which you can easily access to see what it delivers: )

And I am not even going to mention editor plugins that show you docs with expected types. Much fewer mistakes and easier coding with external packages.

Don't want to be that guy, but imo one week is not enough to even "learn" Elixir. To be honest it depends on your previous experience, of course. But the problems is, that there a lot of books, but there are not that much code examples in the world. There are some Phoenix open sourced projects, but I didn't see that much OTP in them.

Not OP, but I've been interested in both technologies for a while. Elixir with Phoenix feels like modern RoR, so it's probably best suited for startups that want to build their products fast and want to scale easily and cheaper.

IMO Go is perfect for big companies and somewhat middle companies where they have some heavy traffic that needs to be addressed. I guess Golang is also easier to start with and craft something very fast as opposed to Elixir. (You can check multiple topics on elixirforum.com where people ask why their first-iteration code is slower than that in ruby/python.)

I can be wrong, but I haven't found any golang opinioned-matured web framework, because most of the community is okay with building from the ground up. This may suggest that golang would be preferable in complex/enterprise systems?

I'd choose Elixir for something that has to be done fast and be reliable and open for a lot of modifications that can be introduced without sweating.

My point of view is based on building some simple product in Elixir and doing research. Also, a previous company I worked for had Golang and Ruby stack.

They pay based on local rates. For me, this is a big no. I don't think they are a company worth changing your stack for.

But going back to your question, this is a hard one... Unfortunately, I guess most companies look for experience in a specific framework, not even in a language in senior roles. Probably you would have to find some company and consider pay cut/start yours with the new stack. I think smaller companies may be less picky about your stack. You could also look for team lead roles and practice new stack while leading a team. Sometimes companies let you introduce a new stack, but it has to have a good reason. If you work with django I see no reason for rails.

https://about.gitlab.com/handbook/people-operations/global-c...

I think it's because Vue is opinioned, just like Rails, therefore dev's happiness(?)&productivity is one of the main goals of these frameworks. In case of React, there are a lot of libs you can choose from, I'd probably use React in more heavy JS application - think some games or something like draw.io (don't know how to call it). To be honest, I don't have enough experience to back up my claims, so take it with a grain of salt.

Currently finishing my retrospective slack bot, it's my first product, so I am pretty excited to see what people say about it.

Also working on some startup in the cybersecurity industry. The vision we have is really cool, there is a lot of new stuff to learn for me and I feel that contributing to this project will make me a better web dev in general, but especially in understanding web security problems that big companies face. Working along with a somewhat veteran in that field feels really cool. Think when you last worked with a guy that was very passionate about the subject you worked on. Now, this is the type of my guy. A great story is about to unfold: )

Rails (I'm Ruby dev). I've been playing with Vue lately and like it a lot. You can have all component's code in one place -> html+js+css, so it's super fast and easy to keep adding code. Also, I like React, but somehow whenever I use it I feel I am writing a lot of code for simple stuff.

I am finishing my first product in Elixir. It has some rough edges like deployment, but I start to like it more than ruby&rails - the code is much more readable and imo easier to write. Surprisingly I feel a bit more productive in it than rails.

I'd say the best tool is the one you know. If you don't know any tool for your specific problems, look for the simplest and most sane solution.

While I do like some programming languages more than others, I really like this attitude. After all, it's just a tool.

Personally, I am that kind of person that likes to experiment with a lot of languages to have a bigger toolset. So when I visit some subreddit related to a new language and I look for topics that would help me decide if that language is good for what I am looking for, I always find topics with people adoring the language and there is rarely any downsides mentioned. That kind of praise is just counterproductive and I don't understand why other people don't see it that way.

I am not familiar with your situation, so the following questions you should ask her/yourself are:

1. Does she really want to learn to code, or does it come from you? 2. Can she write any code? Does she have trouble with just defenitions or coding in general? 3. Maybe JS isn't for her? Maybe show her Python or another language? What I mean is that maybe syntax is a bit confusing to her. 4. Has she tried any books? How does she learn other stuff most efficient? 5. Maybe just let her code and search for problems on the Web? Maybe you are trying to teach her too much stuff at once.

IMO give her more space and help only in the most critical errors at the moment. Let her code, code, and code. You could help her by creating some snippets or cheatsheet that she could print and use next to a keyboard.

When I was first learning Java (at college) I had trouble with understanding a lot of concepts and it took me a long time to finally grasp them. Don't think about that clickbait articles that are all over the internet about people that have learned to code in a few months. They are just clickbait articles, that's all they are. Learning to code is not easy, it takes time, for some a lot of time. If it was easy, a lot more people would be programmers and that's not the case.