A lot of companies care about the personal development of their devs. Usually it is enough to mention to your manager that you want to learn more about backend work. Request to pick up a few stories for backend work as part of your development plan.

Redux is an antipattern in itself. I've seen projects where the combo has been applied like it's some sort of panacea for every front-end problem.

In JavaScript/TypeScript, you don't really need classes because you have closures, mapped types, and union types. These features kind of correspond to private fields, open classes, and sealed classes. But the functional style makes more mathematical sense than the object-oriented style.

Sounds like a project-specific problem.

I usually start with inventory. I spend my onboarding process looking over where the code is, pipelines, integrations, docs and third party services. Once I have these I usually have a rough idea of the state the team is in. Then I try to change something small about the work process to see what the reaction is. Depending on the team they will be open to changes or strongly against it. If I am able to change anything I usually start with getting the basics right, testing is mandatory and code coverage is checked in the CI pipelines. If this goes well, I move on to bigger things.

I argue that it comes down to cost vs value. If third party tools are unlrealiable, pricy or in some other way not a great choice for the problem being solved, then it may be worth making your own tools. However it is usually the case that senior devs let their own passion get the better of them. The cost is usually that the system becomes harder to work on for other devs. The true sign of seniority imo, is when a developer is aware of that people of different skill need to work on the code and they make an effort to design their code to be easy to work on regardless of who is doing the work. The easiest way to check if they are doing this imo, is to check if they ask other developers for feedback before they "force" everyone to use their new idea and if they are open to changing their solution if people don't agree with them.

ofc, software development is a talent industry and some people are better at it than others. Most developers struggle to write "good" code. It is almost unheard of that they know how secure their code is.

or possibly if the person in question is working for a consulting firm and need to convince the companies that are actually in need of the consultants, then it really doesn't matter what your boss or you believe and if you are not willing to adapt to the situation, your company may have difficulties finding jobs for you and that will cost them.

ofc, there are usually a few in every company. The easiest way to deal with them is to practice your social skills. To stop the impact they have you simply need to disagree with their approach, offer a simpler alternative and then ask them to showcase their solutions to more people. Finally you agree as a team on a solution. Usually the simpler option wins but if you have a whole team of these people, you mention it to your manager and then you move on with your life.

Depends on what type of game development you want to do. Various studios use different setups but if you want to get something that will be "easy" to start you off I would suggest Unit or Unreal Engine. These platforms have good support, lots of learning materials and they are used in professional projects. Though it will be very different from FE development. Web FE has little to do with game development, it is usually the backend devs who have the easiest to transition here since most of the code written is done in languages such as C++ or C#. There are ofc more but Javascript isn't really used to the same extent depending ofc on what type of games you are making. If they are browser games, that is another story.

@@FredrikChristenson Thanks I am learning Unity game engine with c# script. My main focus on mobile games. I m trying to develop 2D small and mini games in the beginning.

@@husenali-b9d lets build something, I like your thinking

In my experience the best approach is to mock the interface on your end. You can't finish the feature but you can create a simple stub and create an in memory api client that returns some mocked data. You can i.e build the entire feature on your end and when the other team is done you just need to make the call "for real". The main thing is that you know roughly what the schema will be for the other system so you can can create a faked version that will be roughly the same when they are done.

Here the key element is who you have as your PM. The wrong PM is about as useful as any administrator in IT. It is a person who can't do much more than host a meeting. The right PM is as important as the right senior. Sadly, there are a lot of development teams who lack the soft skills and business mindset needed to develop IT products in collaboration with their customers and thus they actually need a PM to manage them or they will not know what to deliver. I promote that rather than just hire people based on their role, we should hire people with the needed skillset and that very much depends on the type of project you are working on. I was the PM a while back due to that the product we where making was highly technical and my boss understood that a regular PM would not know how to manage it.

@@FredrikChristenson Awesome. That's a much more positive scenario than my previous understanding. Thanks for replying.

I have a few videos on this topic. I suggest you treat portfolio projects as a way to get interest for your CV. Most companies determine your seniority level in the personal interview. Make sure you know your tools and the most common ways people use them before you go in to the interview. Not all companies care about your portfolio but they all care if you know your tools or not.

Usually you don't build your own oauth2 server. There are several providers already. Google, Facebook, Github and so on are already available. I have a video where I made a simple one just for fun you can look at. It only has basic features and took a few hours.

It is your job to learn what tools are available to make these implementations. Find out how to setup a keycloak server to implement oidc providers and oauth providers

Depend on if we can agree on that there is an objective way to determine if someone is "good" or "bad" at anything. In sports we compete at various levels and determine skill by a number of factors but we do agree, to some extent, that some athletes perform better than others. The same can be applied to development. If you are able to produce code mostly on time, with few bugs and in accordance with what the desired results are. Then you are a solid developer for most people. Here there is another dimension that needs to be accounted for, width. In sports you can focus on a single activity but in software your job can be as wide as the whole delivery process. Knowing how "good" you are and if you are on track is imo easiest to figure out by knowing if you can do what most of us do in our job and how much of the delivery process you can handle.

I have a few videos on this topic. i.e I suggest that you work at your tech skills and learn the company system domain. The most valuable devs are usually those who can deliver and know how the system ecosystem works.

The term can be summed up by asking. Does the person performing the job meet expectations? The same is true regardless of context, I would argue. If they can't do the job in accordance with expectations we have to ask ourselves, are our expectations reasonable given that all factors we can help with have been dealt with? If a unfit person shows up to a marathon, the other runners can try their best to support them and encourage them but it is ultametely the runner who needs to be fit enough to compete at the level needed to finnish the race. Since the other runners are finishing the race we know the expecations are not unreasonable so what is left is the runners capacity. The runner is possibly able to finnish a shorter race but unless we are willing to adjust the entire context to fit that runners level we have to ask them to come back when they are fitter.

@@FredrikChristenson I'd have to disagree. It is definitely reasonable to discuss their lack of performance and how it is holding others back. However, you cannot judge them for their 'talent' because you cannot possibly judge that "all factors have been dealt with". You don't know what's going on in their lives that are impacting their peformance. It's reasonable to argue that there is only so much we can help with and that they are more of a burden than an asset. However, I'd be very careful with giving value judgement such as "they lack talent".

@@FredrikChristenson But you are completely misusing the phrase "lack of talent". Talent is a word that is referred to something that usually comes genetically, and something you are born with, but you are talking about things that can be developed and improved. There are a lot of factors that need to be considered before blatantly giving someone "lack of talent". Couple of things that need to be considered: - Missing Technical knowledge - Missing Domain Knowledge (this is very often the reason for new employees if the domain is large) - Bad habits that require correction - Missing knowledge about best practices - Missing debugging skills - Personal issues that have to be addressed, and find ways to fix them - Overloaded with tasks - Motivation issues (lacking proactivity,... etc) - Careless mindset about the job (so many underperformers fall into this one from my experience) If the candidate checks all the boxes above, then there is a possibility for improvement. As last resort you can claim that he lacks talent and it's not gifted enough for the job, but this is rarely the case, and employees are almost firing someone that does not check something from the boxes above, but most of the things above can be improved, unless that person really lacks talent to improve at those. If the "lack of talent" is usually the case for underperforming employee, then you should revise your interview process.

When we appriciate art, do we specificly credit someones "talent", or do we credit "skill"? I am open to split these terms but I would argue that when we evaluate performance the terms are ambigious as they both are needed to produce results. We can also agree that not every factor can be accounted for. However, I hope we can also agree that there is a limit for how much slack we can cut someone before we feel that they have to take some personal accountability. If we did not, criminals would all be forgiven and no child would ever fail a subject in school. Any decent person will try their best to accomodate a fellow human being but however you want to slice it, there is a point where we can no longer excuse poor performance, either because we loose our patience or because we run out of resources.

@FredrikChristenson in any field usually you can't objectively know what produced the result, whether it's talent or skill/training, usually is mix of both. Of course, you can try to figure out bad performance by helping the employee in the things he lacks. Of course, if after multiple tries, you are not able to help him to be on the right path, you can have a reason to fire him, but that does not mean that he lacks talent. He just does not fit the standard that you require in his position, and ofc, time, resources do not allow you to invest more time. But always, when it comes to that, I would revise the quality of the interview process.