DogLover_

Github-actions is not created to encourage that though. It uses syntax that only works on Github. Look at their workflow-examples and you will see.

Lucky you. I hate the blurriness and to me this sounds like a "coping mechanism"

I was not precise when I said notifications. I already set it to "only mentions". My problem was that each channel will "light-up" when anyone is commenting in them. I have to mute each channel or mark all as read for the whole server to avoid this. On IRC you opt in to channels.

I used IRC for gaming around 2004 - fond memories!

I recently tried Discord to find programming communities but I just don't get it. When you join a server you are automatically subscribed to all the channels. And apparently you can't leave them, you can only 'silence' them by manually doing that for each channel. After a few days I just gave up as I could not keep up with all the notifications.

I am not the right person to ask. I assume it is easier getting into EU but I can't say for sure

How?

You can't "just move". It is quite difficult to get into the US

I agree with this. However, I see it as inevitable. Big companies want to protect their their IP/source-code.

I find the "reverse" naming so confusing. To me it makes it sound like the http request goes backwards or something like that which makes no sense. What you suggest should be the way to word it.

  Deprecated `exec` command is hell to use

Curious what makes it hell to use?

  Unfortunatelly there is still no way to run CI file locally which is major turn down

I don't think thats correct. As you mention there is `exec`. Do you know of better alternatives?

This argument as THE SOLUTION really needs to stop. As an example I mapped caps to ctrl a long time ago so this won't work without compromises.

Thanks, did not think about that!

Have to really disagree with the "comp" function example. No need to have "else" statements. The one with early returns and only "ifs" is succinct and good.

Also what is up with comparator function being used this way for most articles nowadays? If I am not mistaken "return a-b" is the much better solution and don't say that it is considered too clever :)

If you don't use early returns don't you end up with functions doing lots of state/variable mutation (within the function)? Thats what I consider the problem with big function and/or not using early returns. You then need to keep track of all those modification. I find it much easier to reason with early returns.

You can certainly over-engineer things just to avoid bigger functions. However from my experience I see that far less than complicated large functions with little care to readability.

Early returns is the best pattern I ever adapted. Because of it I rarely if ever use 'else' expressions anymore which leads to less convoluted code.

It seems we have different experiences because where I see early returns used is mostly where functions are already small.

I have the same experience as you but when I talk to peers I went to highschool with and say the same thing they seem to not have the same experience. I am not quite sure why that is. Might have something to do with how you treat highschool. If you don't take it seriously and don't do your homework then I guess highschool would be a lot less stressful.

True, but it is no different for boys these days. Not wanted by teachers and they see that girls just get better grades leaving many uninspired to pursuit greater.

If you bought an apartment in Denmark a few years ago you got quite a lot of money just because of the appreciation. To be able to even get an apartment you have to have money in the first place otherwise you won't get a loan. So OP is saying that it is expensive to be poor and cheap/easy being rich.

I would question if that approach is appropriate. It will lead to less releases with bugs but will also lead to lower velocity. Lower velocity can have the effect that in the long term the system is in a worse place than if it had more iterations of work. As many things, it depends on the company and the industry it is in.

Thats a fair point, but I did not say that there should be no communication about the work you do. We all work differently and I think it is sensible to let each employee have some form of independence of how they want to structure their own work. If the feature is a few days of work let me work on it like I prefer and then I can submit with a nice description and thought process.

Let us also not forget about all the time wasted on getting your plan validated. Or how your validated plan is completely screwed only realized after you start implementing it. Pros and cons to each solution.

Interesting! Too young to have experienced waterfall model in a workplace. Are you saying it did not exists. If so what was the agile manifest a response to?

Have to disagree. Many places try to optimize for enjoyment so they can keep their employees.

There is a time and place for everything. If you a working on a project that takes months it should be planned ahead but if it only takes a few days you might not need. Let us not forget why we got rid of waterfall model.

Agree, it depends on company and team :)

Documenting/communicating what you do is important but when it becomes a process it can really be detrimental. Every new feature won’t take the same amount of time and having to spent time writing down my approach for a task that will only take a few days will likely just limit me. That time could be spent on writing (more) tests which is also a form of documentation. If we say that 9/10 times a solution is good, the time saved not writing down the approach could accumulate to 1 rewrite. Basically for me it boils down to some of the agile values and principless:

- Individuals and interactions over processes and tools

- Working software over comprehensive documentation

- Working software is the primary measure of progress.

- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

https://agilemanifesto.org/principles.html

If you are happy with your workflow you can continue as usual. In other work-cultures people might not like your approach which is why a draft PR can be helpful. Basically what this feature does is that it avoids having to point to a branch and tell your coworker that it is WIP that you want feedback on. Usually a PR will also show the changes directly.

One of the benefits of mono-repos

In a draft PR you can add a description and annotate lines of code with comments - making it easier for your peers. A branch can be harder to find and in your case you had to manually notify that you wanted them to have look at your code, whereas with a draft PR you probably get a notification.

Someone suggested this on my team. I personally don’t like the idea because these policies often times lead to bureaucracy and then nothing getting released. It is not that I am against thinking ahead but if i have to in details explain everything I do, then more time is spent documenting than actually creating which is the part I enjoy.

I guess its subjective/individual what is considered fast-paced. I would consider it normal web-development in agile environment. There is time for design and planning but you also have to be practical and get work done. Good design is preferred but change will happen, otherwise you can end up shoehorning yourself.

We already have practices about keeping PRs small so one could argue having to focus on crafting good individual commits is not that important in the grand scope of things. Especially if those carefully crafted messages will go lost after a merge. Some PRs require heavy reviews, while others just require a quick look through. From my experience people usually look at the changes and not the commit messages (myself including).

> Another feature of multi-commit development is when you notice that e.g. a particular feature won't fit in the next release, and you take only these changes to a different branch.

If your PRs are small you could also just move the changes yourself manually. Or you could do as you say and move each 'WIP' commit if necessary.

Yes, ideally. Usually though you have to make changes because something is not working as it should or you found a better way. If you never change the interface the code often times rots. Most of the time we don’t make the correct design decisions from the start. We learn from previous understanding and that might require to do things over.