1: Write Well-Designed Code 2: Always Maintain A Learning Mindset 3: Document What You Learn 4: Look At The Bigger Picture 5: Take Responsibility For Your Work 6: Understand The Context Of What You're Working On 7: Have Open Discussions 8: Have Side Projects *9: Follow the ArjanCodes :)*
11:57 Two things would come to mind spontaneously, GIT and Linux. GIT: For the first few years, I always copied entire project folders back and forth as a backup. But I had almost no overview of what changed when and where. Learning GIT fundamentally changed my understanding of programming and how code should be structured (to make it version well with GIT). Linux: At the end of WindowsXP I didn't switch to Windows7 but to Linux. That changed my world! It helped me a lot to understand how simple and effective software (architecture) can be.
Back when I wrote mostly python code, I loved this channel. I've almost entirely switched to Rust, but I love to come back and see language-agnostic content! A major point (related to side projects) is to follow your passion. If you're just trying to learn stuff, don't worry about "if someone will use it." If you might use it, that's good enough!!
From a career perspective, have you had any difference in opportunities? I love Rust, prefer it over Python from an aesthetic and efficiency perspective (Rust is haiku, Python is free verse!), but want $ too.
@@_computerra I got a job in Rust last year. The industry is picking it up pretty quickly, but are they picking up what you want to be doing? Currently, most of the jobs are low-level/embedded and system (e.g. AWS). However, I suspect that will change over the coming years. A very ergonomic, powerful, and safe language that doesn't have runtime restrictions is a prime candidate for growth. Especially in sandboxed environments like WASM/WASI
Would be interesting to see your view on side projects: Examples of what you and people you know choose to do as a side projects. How to allocate and manage time so that it doesn`t stretch for months and years. And some though process of how you go from an idea to choosing a stack, architecture and planning what to do first. Thanks!
You're one of my favorite channels in youtube! Definitely would recommend to others. Excellent tips, I embraced them all long ago and that helped me to be very efficient and mindful about my work. A tip I would add is "Learn from your mistakes and from others mistakes". Yeah you could be mistaken even as a senior developer - don't linger, fail, learn from it and carry on. This lead me to absolute amazing solutions.
Thank you so much for the video, it doesn't only help with how to become a senior dev, but helps with giving us (junior devs) reassurance that its always about learning and no matter how much you think you know, you should always stay humbled and never get discouraged because there is much more that you don't know.
Top quality content, Arjan. I can attest that all of the points made strengthen seniority, with "3. Document What You Learn" being a big standout because it benefits not only you, but the whole team as well.
I love it when I'm sitting at my code editor with some really hard conceptual thinking upfront and then there's this magical moment where all the pieces of code connect like a puzzle, just because I found exactly the right concepts and abstractions. Letting the coding sessions flow and guide me to brilliant solutions I didn't think of upfront as a whole is so much fun actually. For me, this demonstrates the power of XP, TDD and good design skills 😄 Keep it up Arjan! You taught me how to properly code in Python, great stuff. It's helping me a lot at my current project where I'm developing a self-driving car software 😄
I enjoy your perspective on this issue. It seems like most other TH-camrs come across way too strong on stuff like this. Like, their requirement are super steep for what it takes to be a developer. Your perspective seems much more grounded.
Really great stuff as always Arjan. As per #6, I think understanding the lifetime and scope of the software is important. Too many times, I've seen developers trying to design for the infinitely extensible and scalable solution that adds a lot of complexity, when in reality it is within one business domain and has a life of 2-5 years. While conversely, sometimes project teams define a Minimum Viable Product that trims necessary scope and quality with no roadmap beyond MVP. It's really important to understand the real world purpose and context of the software. Anyway, great video, thanks!
Thanks for this video! It didn't also give me tips for becoming a senior developer but also I learnt a lot from you in my way of becoming a content creator. Thanks again for your videos!
I've learned so much from your videos. Thanks for addressing design patterns in a way that is digestible but still gives a good thorough understanding of the concept. Feedback you can totally ignore because the opinion of some rando on the internet doesn't really matter :: 1. You asked what helps me most with learning, and I would say practice problems. In math, at the end of each lesson there are ~50 problems to solve that help the student work through the concept at increasing levels of difficulty. I would LOVE if more of the YT software tutorials gave some kind of "problem set" suggestion at the end of the video. I realize that's asking for a lot more from you, coming up with problems is sometimes more difficult than teaching the topic, but I would love it if I had some challenge problems to work though other than just following along with the code in the lesson. 2. I was not a fan of the changing viewpoint in this particular video, which seems to be a new addition. I tend to watch most YT videos at 2x, 2.5x or 3x. When the viewpoint changes too often, or is unsteady like the side shot camera, it can be really disorienting and almost nauseating. I know there is a not-insignificant percentage of other YT users who watch videos at higher speeds also, so it might be good to sometimes watch your videos at that speed and see if the transitions, camera angles, etc are more of a problem then they seem at 1x. I don't want to discourage creativity and new techniques for improving the video quality, but the steady camera with one zoom level and minimal transitions is easily my preferred video style. Thanks again for great videos. And feel free to completely ignore the feedback from one guy who doesn't know anything about making videos on youtube.
Thanks for your feedback, John, and your opinion does matter - thanks for sharing it. I’m always experimenting with ways to make the content better, and I thought it’d be cool to try a second angle to add some visual variety. I’m not giving up on it yet, but if it doesn’t work, I’ll try something else :). Regarding the challenges/problems, if you join my Discord community, there’s a channel where people share quizzes and programming challenges, so that might be interesting for you.
In my personal opinion Tip #3 changed quiet a lot in my life. I always had the problem that something popped up in my brain, but i couldnt find the snippet or the paper where it was written. Therefore I created a git repo, with Design Patterns examples and a Document where i wrote an absract about the paper i was reading. I revisit these regularly to not forget what i have studied. BTW I love your videos. I've learned so far so much from you, which I also use at my daily work! :)
Glad to hear you like the videos! I use Notion myself. I have a bunch of 'living documents' where I write down anything interesting that I come across, or ideas/viewpoints that I might want to do something with at some point.
Taking responsibility is definitely the major point. In my experience, trying to look behind your field of expertise has often helped improve my process as a whole. I try to observe what people in other computer science domains are doing and try to picture how that could improve my own implementations.
I liked the comments On Jr, Intermediate, Sr, Lead. I've recently started as a Lead and some 'soft' content for Leads would be cool. Also some attention to older devs (50's) would be interesting as this isn't very common content.
tip 3 is something that i recently noticed that I need. I work on a very large codebase and it's almost impossible to remember where my past code is in it. From now on I'll keep track of my good code (and my coworkers' good code) so that when I encounter a similar problem I can use that previously written code as reference :)
I agree with the side projects tip. I also would like to add that my team have some meetings about refactoring and teaching some tech things to each other. That has helped us a lot with Code quality improvements.
Thank you for the video. My (junior backend developer) main problem is passively reading a lot of books and watching a lot of videos without actually coding something, so a big chunk gets lost… I know this is a problem, but most of my learning is done after 10 pm, as I work a lot during the day, and sometimes I dont have the willpower to code.
A major chunk of my Android knowledge has been due me reading and understanding different projects and solving issues(code based or design based). I can affirm having a side project will increase and expand your knowledge and experience.
Personally I would add a few points: the posture of transmission in the support of juniors. The ability to take a step back. The ability to manage effort.
I do most if not all of these points, I have a comp Sci degree and i generally work on entire projects in my current company. I have so many years of programming and code developemnt. But because of my young age and experience I am automatically put under the junior tab
You know what is extended version of "Looking at your client's steps to consume your program" ? Looking at how other programmers are going to consume your code.
Hi Arjan, Great content as usuall. One thought tho ... The side camera view is little bit disturbing ... I don't have anything against different angles during a video yet this specific one doesn't work for me :( As to the topic of note apps, I highly recommend Obsidian!
I am starting fresh from uni as a junior but I'm already tring to think like a senior. One thing that made me curious is commenting code. In our company we try to avoid that however I see that each team handles it differently. From your perspective, when should I write code and when should I not?
this is a good advice to have side projects, but what to do when I don't have the ideas what to implement? In fact I have some, but it is relatively small projects, when I, as a middle-level developer, want to use in this projects more new features/software design approaches, which I learn. Where to get ideas for middle-level projects? Or maybe do you have some?
Good content, but the jumps to the side camera view are jarring. The frontal zooms are okay, though also not really needed. Your regular delivery and editing is fine! No need to add the jump cuts!
@@ArjanCodes Echoing what Roy said, the zooms and 2nd camera are decent experimentation, try play around with yourself in different positions within the frame of the single camera, deviating from centre-framed arjan might give you that dynamism you're looking for.
@@TheAsymmetrical For me, the cuts felt like an attention pulse yet at the same time made me miss a bit of the information being talked, forcing a small rewind. It may have to do with the lighting or that the timing doesn't match for the cut to be
For a full stack team that only uses Python for 20% - 30% of the components in our system, would you consider the use of basic comprehensions as being so advanced as to violate the idea of keeping implementations simple? I have gotten pushback from team members for recommending their usage over rudimentary for loops in PR reviews. And I do not mean complex nested comprehensions or anything, but rather just any comprehensions at all. Similar resistance to using APIs like dictionary setdefault, get, and boolean ternary statements for facilitating efficient handling of default values. Basically just using what I consider fundamental Python language features that streamline code and improve performance, but are not known by Python beginners. Should I not be advocating for these features when reviewing the code of more junior developers or even of fellow senior engineers who are just less experienced in Python?
All of it. Specifically for #3, I maintain a living document that contains a bunch of random ideas and thoughts. I should probably structure that a bit more though. For my company, we tend to write down outcomes of discussions and keep track of new insights, collect relevant learning material and share that so everyone benefits. I find writing down something often helps me clarify my thoughts on a particular subject.
The problem here is that it implies that you must have the mindset before you get the promotion. However, I wouldn't switch to the mindset unless I am already paid for it. As a junior or medior, why would I care about the whole organization if my job and pay doesn't reflect this type of responsibility? It's just like when middle managers complain about the "lack" of leadership of experienced people. I might be experienced in my job whatever it is, doesn't mean that I want to take on the manager's job when I am not paid nor recognized for it.
I have worked with a couple of "mid level devs" who have run circles around some "senior developers" by experience years. Anyone who thinks they should be a senior based on time in the game will be disappointed and will never truely make senior engineer or higher. Job titles are just that a title. It doesnt really mean much, especially because each company has a different idea as to what junior, mid, or senior should be.
I agree to all points but I'd add pair-programming to the "open discussion" item. I was sceptical before trying it out, but I did not only learn a lot by programming in pairs or even in groups, but we also got higher quality code in the end. Everyone has a slightly different view on the code and in some sessions we basically had multiple people each pointing out different possible issues when one of the SOLID principles had been violated and we managed to fix all of them while implementing the feature. It would have gone through a lot of review cycles otherwise and still may not have reached the same quality if it had been done by just one developer. Bonus: All of us understood the feature in the end and we were also all able to work on it. Of course it's not feasible to work with all devs on each feature for a full projects, but especially in the beginning of a project and/or with a new team I really recommend starting like this and doing several pair-programming sessions with ever mixing participants to raise and keep the knowledge of the team to the same high level.
It's a careful balance that I still have to learn a lot about. On the one hand, you have to make sure that the title is interesting enough so that viewers click to watch the video (otherwise, the content can't help them). On the other hand, if you overdo it and don't deliver on the promise that a title makes, viewers feel cheated and have a bad experience.
I'll suggest the "developer position" tonight. Let's see what my wife thinks about it. Usually she's fast asleep already when I take up that position at night.
💡 Get my FREE 7-step guide to help you consistently design great software: arjancodes.com/designguide.
1: Write Well-Designed Code
2: Always Maintain A Learning Mindset
3: Document What You Learn
4: Look At The Bigger Picture
5: Take Responsibility For Your Work
6: Understand The Context Of What You're Working On
7: Have Open Discussions
8: Have Side Projects
*9: Follow the ArjanCodes :)*
11:57 Two things would come to mind spontaneously, GIT and Linux.
GIT: For the first few years, I always copied entire project folders back and forth as a backup. But I had almost no overview of what changed when and where. Learning GIT fundamentally changed my understanding of programming and how code should be structured (to make it version well with GIT).
Linux: At the end of WindowsXP I didn't switch to Windows7 but to Linux. That changed my world! It helped me a lot to understand how simple and effective software (architecture) can be.
Back when I wrote mostly python code, I loved this channel. I've almost entirely switched to Rust, but I love to come back and see language-agnostic content! A major point (related to side projects) is to follow your passion. If you're just trying to learn stuff, don't worry about "if someone will use it." If you might use it, that's good enough!!
From a career perspective, have you had any difference in opportunities? I love Rust, prefer it over Python from an aesthetic and efficiency perspective (Rust is haiku, Python is free verse!), but want $ too.
@@_computerra I got a job in Rust last year. The industry is picking it up pretty quickly, but are they picking up what you want to be doing? Currently, most of the jobs are low-level/embedded and system (e.g. AWS). However, I suspect that will change over the coming years. A very ergonomic, powerful, and safe language that doesn't have runtime restrictions is a prime candidate for growth. Especially in sandboxed environments like WASM/WASI
Would be interesting to see your view on side projects: Examples of what you and people you know choose to do as a side projects. How to allocate and manage time so that it doesn`t stretch for months and years. And some though process of how you go from an idea to choosing a stack, architecture and planning what to do first. Thanks!
You're one of my favorite channels in youtube!
Definitely would recommend to others.
Excellent tips, I embraced them all long ago and that helped me to be very efficient and mindful about my work.
A tip I would add is "Learn from your mistakes and from others mistakes".
Yeah you could be mistaken even as a senior developer - don't linger, fail, learn from it and carry on.
This lead me to absolute amazing solutions.
Thank you so much for the video, it doesn't only help with how to become a senior dev, but helps with giving us (junior devs) reassurance that its always about learning and no matter how much you think you know, you should always stay humbled and never get discouraged because there is much more that you don't know.
Glad I could help!
Top quality content, Arjan. I can attest that all of the points made strengthen seniority, with "3. Document What You Learn" being a big standout because it benefits not only you, but the whole team as well.
Glad to know you enjoyed the content, Augusts!
I love it when I'm sitting at my code editor with some really hard conceptual thinking upfront and then there's this magical moment where all the pieces of code connect like a puzzle, just because I found exactly the right concepts and abstractions. Letting the coding sessions flow and guide me to brilliant solutions I didn't think of upfront as a whole is so much fun actually. For me, this demonstrates the power of XP, TDD and good design skills 😄
Keep it up Arjan! You taught me how to properly code in Python, great stuff. It's helping me a lot at my current project where I'm developing a self-driving car software 😄
I enjoy your perspective on this issue. It seems like most other TH-camrs come across way too strong on stuff like this. Like, their requirement are super steep for what it takes to be a developer. Your perspective seems much more grounded.
As always, love your stuff! Your whole channel is meeting me exactly at my level of needs right now... so thank you.
Glad to hear and you’re most welcome!
Really great stuff as always Arjan. As per #6, I think understanding the lifetime and scope of the software is important. Too many times, I've seen developers trying to design for the infinitely extensible and scalable solution that adds a lot of complexity, when in reality it is within one business domain and has a life of 2-5 years. While conversely, sometimes project teams define a Minimum Viable Product that trims necessary scope and quality with no roadmap beyond MVP. It's really important to understand the real world purpose and context of the software. Anyway, great video, thanks!
Thanks for this video! It didn't also give me tips for becoming a senior developer but also I learnt a lot from you in my way of becoming a content creator. Thanks again for your videos!
Thank you and happy to hear you liked the video!
Sometimes Arjan's humour takes me by surprise :D. Great Video!
Dude you are so unique compared to other TH-camrs .
Keep up the good work bro ❤️
Great tips! I really enjoyed listening and I'm looking forward to the next one!
I've learned so much from your videos. Thanks for addressing design patterns in a way that is digestible but still gives a good thorough understanding of the concept.
Feedback you can totally ignore because the opinion of some rando on the internet doesn't really matter ::
1. You asked what helps me most with learning, and I would say practice problems. In math, at the end of each lesson there are ~50 problems to solve that help the student work through the concept at increasing levels of difficulty. I would LOVE if more of the YT software tutorials gave some kind of "problem set" suggestion at the end of the video. I realize that's asking for a lot more from you, coming up with problems is sometimes more difficult than teaching the topic, but I would love it if I had some challenge problems to work though other than just following along with the code in the lesson.
2. I was not a fan of the changing viewpoint in this particular video, which seems to be a new addition. I tend to watch most YT videos at 2x, 2.5x or 3x. When the viewpoint changes too often, or is unsteady like the side shot camera, it can be really disorienting and almost nauseating. I know there is a not-insignificant percentage of other YT users who watch videos at higher speeds also, so it might be good to sometimes watch your videos at that speed and see if the transitions, camera angles, etc are more of a problem then they seem at 1x.
I don't want to discourage creativity and new techniques for improving the video quality, but the steady camera with one zoom level and minimal transitions is easily my preferred video style.
Thanks again for great videos. And feel free to completely ignore the feedback from one guy who doesn't know anything about making videos on youtube.
Thanks for your feedback, John, and your opinion does matter - thanks for sharing it. I’m always experimenting with ways to make the content better, and I thought it’d be cool to try a second angle to add some visual variety. I’m not giving up on it yet, but if it doesn’t work, I’ll try something else :). Regarding the challenges/problems, if you join my Discord community, there’s a channel where people share quizzes and programming challenges, so that might be interesting for you.
@@ArjanCodes Oh thats great to know. I dont usually use discord, but I might have to engage it if there's that kind of resource on there.
@@ArjanCodes The second angle is fine, but please talk into the camera. Seeing you talk into empty space and just the side of your face is unsettling.
I really like your videos, for I, it’s the better form to improve my English listening skills, and review about design patterns and thinks like that
In my personal opinion Tip #3 changed quiet a lot in my life. I always had the problem that something popped up in my brain, but i couldnt find the snippet or the paper where it was written. Therefore I created a git repo, with Design Patterns examples and a Document where i wrote an absract about the paper i was reading. I revisit these regularly to not forget what i have studied.
BTW I love your videos. I've learned so far so much from you, which I also use at my daily work! :)
Glad to hear you like the videos! I use Notion myself. I have a bunch of 'living documents' where I write down anything interesting that I come across, or ideas/viewpoints that I might want to do something with at some point.
Taking responsibility is definitely the major point. In my experience, trying to look behind your field of expertise has often helped improve my process as a whole. I try to observe what people in other computer science domains are doing and try to picture how that could improve my own implementations.
Thanks for the video Arjan! Amazing and informative as always.
Glad you liked it, George!
The intro was hilarious 🤣. Thanks for sharing these tips!
You’re welcome!
Amazing! I really love your videos.
What do you thing about making some videos of advanced technics for speed improvement?
I liked the comments On Jr, Intermediate, Sr, Lead. I've recently started as a Lead and some 'soft' content for Leads would be cool. Also some attention to older devs (50's) would be interesting as this isn't very common content.
So much value from the video, great and honest advices. Keep rolling to the 💯k subs. ⏳
Slowly but steadily ;).
Thank you so much for the video and valuable advices! Keep up learning always.
You got it!
Great content!! Love the point on never stop learning. Learn something everyday!
tip 3 is something that i recently noticed that I need. I work on a very large codebase and it's almost impossible to remember where my past code is in it. From now on I'll keep track of my good code (and my coworkers' good code) so that when I encounter a similar problem I can use that previously written code as reference :)
I agree with the side projects tip. I also would like to add that my team have some meetings about refactoring and teaching some tech things to each other. That has helped us a lot with Code quality improvements.
Thanks. I fee like a junior now.
How to be a Senior Developer:
1. Be a developer
2. Grow old
Isn't it a funny way to say, a senior developer is a junior that didn't quit the industry because of a lack of promotion and opportunities? :(
Fantastic video, I liked all the tips!
Thank you for the video. My (junior backend developer) main problem is passively reading a lot of books and watching a lot of videos without actually coding something, so a big chunk gets lost…
I know this is a problem, but most of my learning is done after 10 pm, as I work a lot during the day, and sometimes I dont have the willpower to code.
A major chunk of my Android knowledge has been due me reading and understanding different projects and solving issues(code based or design based). I can affirm having a side project will increase and expand your knowledge and experience.
Personally I would add a few points: the posture of transmission in the support of juniors. The ability to take a step back. The ability to manage effort.
I do most if not all of these points, I have a comp Sci degree and i generally work on entire projects in my current company. I have so many years of programming and code developemnt. But because of my young age and experience I am automatically put under the junior tab
Thanks Arjan.....some good tips there!
You’re welcome!
You know what is extended version of "Looking at your client's steps to consume your program" ? Looking at how other programmers are going to consume your code.
Hi Arjan,
Great content as usuall. One thought tho ... The side camera view is little bit disturbing ... I don't have anything against different angles during a video yet this specific one doesn't work for me :(
As to the topic of note apps, I highly recommend Obsidian!
I am starting fresh from uni as a junior but I'm already tring to think like a senior.
One thing that made me curious is commenting code.
In our company we try to avoid that however I see that each team handles it differently.
From your perspective, when should I write code and when should I not?
please make a video on someone who has software testing experience in developement role
this is a good advice to have side projects, but what to do when I don't have the ideas what to implement? In fact I have some, but it is relatively small projects, when I, as a middle-level developer, want to use in this projects more new features/software design approaches, which I learn. Where to get ideas for middle-level projects? Or maybe do you have some?
For open discussions, is there anywhere I can "practice" this skill?
Good content, but the jumps to the side camera view are jarring. The frontal zooms are okay, though also not really needed. Your regular delivery and editing is fine! No need to add the jump cuts!
Thanks for the feedback. I’m always looking for ways to improve, so this is helpful to know.
To be honest, side camera makes me re-focus in video content. Just the lighting is different from front view lighting.
I like them 😅
@@ArjanCodes Echoing what Roy said, the zooms and 2nd camera are decent experimentation, try play around with yourself in different positions within the frame of the single camera, deviating from centre-framed arjan might give you that dynamism you're looking for.
@@TheAsymmetrical For me, the cuts felt like an attention pulse yet at the same time made me miss a bit of the information being talked, forcing a small rewind. It may have to do with the lighting or that the timing doesn't match for the cut to be
Loved the intro joke!!! Hahaha
For a full stack team that only uses Python for 20% - 30% of the components in our system, would you consider the use of basic comprehensions as being so advanced as to violate the idea of keeping implementations simple? I have gotten pushback from team members for recommending their usage over rudimentary for loops in PR reviews. And I do not mean complex nested comprehensions or anything, but rather just any comprehensions at all.
Similar resistance to using APIs like dictionary setdefault, get, and boolean ternary statements for facilitating efficient handling of default values. Basically just using what I consider fundamental Python language features that streamline code and improve performance, but are not known by Python beginners. Should I not be advocating for these features when reviewing the code of more junior developers or even of fellow senior engineers who are just less experienced in Python?
Thank you so much
im curious, how much of what you're saying do you put into practice? like for #3 for example, do you document what you learn?
All of it. Specifically for #3, I maintain a living document that contains a bunch of random ideas and thoughts. I should probably structure that a bit more though. For my company, we tend to write down outcomes of discussions and keep track of new insights, collect relevant learning material and share that so everyone benefits. I find writing down something often helps me clarify my thoughts on a particular subject.
totally agree!
The problem here is that it implies that you must have the mindset before you get the promotion. However, I wouldn't switch to the mindset unless I am already paid for it. As a junior or medior, why would I care about the whole organization if my job and pay doesn't reflect this type of responsibility? It's just like when middle managers complain about the "lack" of leadership of experienced people. I might be experienced in my job whatever it is, doesn't mean that I want to take on the manager's job when I am not paid nor recognized for it.
the kamasutra joke was the best🤣🤣🤣🤣
Thanks
Why didn’t I get a notification for this video??? I am subscribed and belled!! F&@k TH-cam
Not sure... but glad you found it anyway :).
Maths and algorithms are extremely important if you want to work for FAANG!!!!
The Kama Sutra Joke got me :DDDD
I have worked with a couple of "mid level devs" who have run circles around some "senior developers" by experience years. Anyone who thinks they should be a senior based on time in the game will be disappointed and will never truely make senior engineer or higher.
Job titles are just that a title. It doesnt really mean much, especially because each company has a different idea as to what junior, mid, or senior should be.
Exactly! It's not about the number of years you're doing something, it's way more important to learn the right skills and have the right mindset.
About dependency injection, check out di
Talking about becoming a Pro and the video is 13:37 minutes long. Coincidence? I think not! 😜👍
It required meticulous planning.
disagree about the notes part. Rather, use it immediately and troubleshoot what doesnt work.
Seems like recruiters are looking for seniors when interviewing for interns!
Uncle arjan, what time is dinner?
I agree to all points but I'd add pair-programming to the "open discussion" item. I was sceptical before trying it out, but I did not only learn a lot by programming in pairs or even in groups, but we also got higher quality code in the end. Everyone has a slightly different view on the code and in some sessions we basically had multiple people each pointing out different possible issues when one of the SOLID principles had been violated and we managed to fix all of them while implementing the feature. It would have gone through a lot of review cycles otherwise and still may not have reached the same quality if it had been done by just one developer. Bonus: All of us understood the feature in the end and we were also all able to work on it.
Of course it's not feasible to work with all devs on each feature for a full projects, but especially in the beginning of a project and/or with a new team I really recommend starting like this and doing several pair-programming sessions with ever mixing participants to raise and keep the knowledge of the team to the same high level.
Titles like this one are generally way too clickbaitish and misleading but in your case I know that there are going to be some useful tips here.
It's a careful balance that I still have to learn a lot about. On the one hand, you have to make sure that the title is interesting enough so that viewers click to watch the video (otherwise, the content can't help them). On the other hand, if you overdo it and don't deliver on the promise that a title makes, viewers feel cheated and have a bad experience.
to became senior you should review pr
Are you senior developer
well... this broke my plans of hitting my superior with a mechanical keyboard. now I'm disappointed
Señor Developer ( ͡° ͜ʖ ͡°)
I'll suggest the "developer position" tonight. Let's see what my wife thinks about it. Usually she's fast asleep already when I take up that position at night.
This is a good joke "Honey do you want to try the developer position tonight?"
1:13 cringe