JS be fun!

How to recognize when you're ready for being a senior developer? Well, it can come gradually but there are some signs: You are given more and more responsibility and trust. Well remember that nobody trusted you when you were a junior dev? And they were given to you only some not very important things. As a mid developer you would usually still feel this kind of hierarchy and superiority from more senior developers. And now - when a team trusts you and gives you most important parts of software - this is a sign that other people perceive your seniority. You often mentor other people in team. As a junior dev, you are taught by others, as a mid dev, you're doing your thing, as a senior dev, you help others to be more productive. You're starting to see things in more holistic way, you can take programmer perspective but also business perspective or look from perspective of end user. You become better communicator and help other people on your team to communicate

Front-end is often overlooked. People treat it as it would be super trivial or something that is so dirty nobody wants to touch (back-end developers often have this kind of disdain for front-end). When you have such negative views of front-end dev in your team, you would have self full-filling prophecy. The truth is different - front-end in 2023 can be as professional as "real" programming. But you have to treat it seriously. Let's dive in and check if you have things below in your front-end project: people - when you need back-end code, you need back-end developer, when you need front-end, you will need a front-end developer. And you need good developers with strong skills and professional responsibility. obvious things - Git, package.json, probably bundler (e.g. Esbuild, Webpack etc.), CI/CD pipeline for deploying tests - front-end code is still a code, so you can write unit tests for many things in frontend. Though unit testing GUI maybe won't be

Software architecture needs boundaries. But what does it mean? Well. It means that when you have many things in your app - multiple classes, multiple modules etc. you don't want them to depend freely on each other: But you want something more similar to this: Notice that on both images there are 6 boxes. On the second image though we have clear boundaries of which modules can communicate with which other modules: So basically you could say that I drew aggregates and aggregates roots from DDD(Domain Driven Design), but I think this approach is not limited to DDD. You don't need to practice full blown DDD to create such boundaries in your project. You could similar approach e.g. for separating groups of React components. But what boundaries mean in React app? State - if you're lifting state up, you lift only to the boundary of subtree Props - if you make prop drilling, you limit this practice to boundary of "aggregate" Context - you limi

If you're a junior developer , don't be afraid of asking questions. How does particular module in project work? There's things that are not on the internet. And other programmers have knowledge you need to be good junior developer. But when you have your answer, write it down, so that you won't be asking the same thing twice. Remember also about internet, documentations, source code, issue tracker... sometimes you don't need to ask if you can check it yourself. But overally asking is way to go. There's many thing specific for project (e.g. requirements) that you won't predict if you don't ask If you're a regular developer , you still will need to ask questions if you don't know something, but you need to be more proactive in your communication. You shouldn't be only focused on your task, but communicate to help other people or to gain insights about project/its progress/implementation details/architecture approach etc. It's time to be m