Practice your TDD with a FREE hands-on tutorial where you can work along with me using an excellent practice tool. Sign up for your test driven development tutorial HERE ➡ courses.cd.training/courses/tdd-tutorial
Pairing is a great suggestion. Dave included an "Impostor Syndrome" graphic in his Tweet about this post. I think the best way to address IS is to pair with someone who has less experience than you do. I've often found that I realize I know more than I thought I knew when when I am explaining it to someone else. The act of explaining, mentoring, presenting, etc. reframes your mind about the topic. It in these moments that I feel like I know the content, or I can more easily identify the holes in my knowledge.
Yes, people who don't pair often think that the learning always flows from the more experienced person to the less, but this is never really the case. Everyone learns. I like pairing with less experienced people, more experienced people and equally experienced people. None of us know everything, and explaining our ideas to others often helps us to understand them better too.
@@ContinuousDelivery For me, pair programming works for around 1 hour. After that, I get exhausted not to mention that the constant chatting is very distractive and cumbersome. I prefer the concept of Pair Revision, where a junior develops small tasks and the senior then reviews the code side by side with him, asking questions, pointing issues and explaining how to do things properly when needed. Juniors are also expected to learn by themselves, to have critical thinking and to ask questions when in doubt. I highly incentivize seniors to make sure it is okay to make mistakes and it is more than okay to ask questions when in doubt. Seniors are expected to be able to calmly teach also.
Excellent! Only one thing to add: read lots of code. You can learn piles from both good and bad code and you will get some insight into what it means for code to be readable.
I find it is not that uncommon to find organizations that do this all wrong. Either they expect full ability to produce a working solution to a problem from a junior. (Had experience when someone in first grade IT college was given full freedom to implement critical piece of infrastructure) Or they hire seniors and then proceed to feed them pre-solved problems, hindering their ability to actually fit the solution to the problem. These kind of organization are more common than we might think.
@@petropzqi It depends if you mean for 'senior' 1) A developer over 40yo ...... or ....2) (may or not include people in the 1) developers with seniority, experience, and working principles of design, with a good history of successful software production.
Sadly I agree, it is all too common for orgs to get this wrong. The best orgs invest in their people and help them to learn and develop their skills, it is in everyone's interest. I have heard bad orgs say "but if we teach them, people will leave for better jobs", my answer is to make your org a better place to work then. This isn't just about paying more, motivation is more interesting and more complex than that. Watch this from Dan Pink: www.ted.com/talks/dan_pink_the_puzzle_of_motivation?language=en
They are (scarily) highly common. I believe that today's startups are actually incentivized to follow bad practices because investors want their quick profit. Quality is optional and taking shortcuts is okay.
If I have to pick one advice for novice developers is this: to study other people's code, specially of good, mature, and open source software, like Spring framework, or Hibernate, or even smaller libraries as the Apache Commons ones. This will not only give an idea of what the design principles are, but it will also cultivate the one's own 'softpedia' of existing software out there in order to avoid reinventing some wheels. Thanks for sharing your wisdom!
I am a young professional, working in software since 4 years. Only within the last 1.5 year it came clear to me how I could improve in my career. Learning code architecture, better design and most importantly the social skills that one would need when working with co-located teams. I wonder since then why this is not part of any bachelor's or even master's degree to some extend. For example code review practices are so important but nobody teaches you a good practice. This is something I clearly miss in the educational structure. Only now I am able to look for valuable resources to find my way to improve on the same. Big part is this UA-cam channel, thanks for the content!
Your insights have helped me so much. I was horribly stuck on a problem, so I tried something silly. It didn't work but it gave me insight to the problem. As soon as I realized this I thought "Ah, that's what Dave's talking about when he says to think experimentally. I just did an experiment." Thanks Dave!
For me, personally, my intermittent development experience has been a problem. One of the most difficult projects I worked on was enhancement to an existing, very large, Perl 4 automation for log monitoring in a heterogenous environment. I believe reading code is a skill by itself, and an important one, but your advice in this video is most excellent. I bought Modern Software Engineering to add to my Kindle collection, and am still reading it.
I feel like I'm in such dysfunctional team right now.. We are implementing pixel perfect design, with every little detail specified by a customer. And when they do not give concrete requirements on something the whole process falls apart. It is hard to describe everything what is wrong with this project. I'm trying to be good engineer and write good and clean code, fix potential problems even outside scope of my ticket, make code base more DRY etc. But it is almost impossible in this project. It is a bit paradoxical, because despite this micro management in almost every detail, there is no clear vision of anything and there is no technical leadership and clear architecture goal. Even though around 50% are seniors or team leads. It is one big spaghetti. I feel dumb and powerless. I feel both like a junior not knowing what to do and like senior wanting to take charge in place of the missing leadership. But at the end of the day I don't think it is worth the effort to try to fix it if I'm just a mid level, and I don't think I have proper skills anyway.
I've got the experience as you do. The problem lies with management since there's no main goal, vision or strategy, which means they don't want to invest and take responsibility for it. I've tried so hard to address/fix the issues but no one is listening or caring about it. I'm just a mid level dev on paper but had my own business for a while before this. I can recognise a business/ management problem from a mile away. If it gets under your skin just move on, that's exactly what I've done.
As someone who learnt alone and has been working open source Was i ever a junior with this definition 😂😂 Edit: it's a joke, i had a period of time i copied code from the internet Like full crappy login systems
My two cents. Avoid - no matter of seniority - tutorials with 'screaming' titles in a style of: "THIS STACK WILL BE OBSOLETE in 2023!!11", "YOU MUST KNOW THIS in 2023". These pseudo tutorials only boost anxiety. Focus on yourself, reach out to valuable tutors that don't care about shining.
Practice your TDD with a FREE hands-on tutorial where you can work along with me using an excellent practice tool. Sign up for your test driven development tutorial HERE ➡ courses.cd.training/courses/tdd-tutorial
This is what people need to get away from to avoid the “imposter” mentality.
Pairing is a great suggestion. Dave included an "Impostor Syndrome" graphic in his Tweet about this post.
I think the best way to address IS is to pair with someone who has less experience than you do. I've often found that I realize I know more than I thought I knew when when I am explaining it to someone else. The act of explaining, mentoring, presenting, etc. reframes your mind about the topic. It in these moments that I feel like I know the content, or I can more easily identify the holes in my knowledge.
Yes, people who don't pair often think that the learning always flows from the more experienced person to the less, but this is never really the case. Everyone learns. I like pairing with less experienced people, more experienced people and equally experienced people. None of us know everything, and explaining our ideas to others often helps us to understand them better too.
@@ContinuousDelivery For me, pair programming works for around 1 hour. After that, I get exhausted not to mention that the constant chatting is very distractive and cumbersome.
I prefer the concept of Pair Revision, where a junior develops small tasks and the senior then reviews the code side by side with him, asking questions, pointing issues and explaining how to do things properly when needed. Juniors are also expected to learn by themselves, to have critical thinking and to ask questions when in doubt. I highly incentivize seniors to make sure it is okay to make mistakes and it is more than okay to ask questions when in doubt. Seniors are expected to be able to calmly teach also.
Excellent! Only one thing to add: read lots of code. You can learn piles from both good and bad code and you will get some insight into what it means for code to be readable.
Another skill to learn there too - unpicking other people's code 🙂
@@Solaar_Punk Not to mention fixing other people's code.
This one going directly to my "best" Playlist. There are more good suggestions in this video then I have got in my whole career. 9yr as a developer
Glad you found it helpful!
I find it is not that uncommon to find organizations that do this all wrong. Either they expect full ability to produce a working solution to a problem from a junior. (Had experience when someone in first grade IT college was given full freedom to implement critical piece of infrastructure) Or they hire seniors and then proceed to feed them pre-solved problems, hindering their ability to actually fit the solution to the problem.
These kind of organization are more common than we might think.
yup
Or the "senior" developers have it all wrong and are on a to high chair to admit they don't have all the answers.
@@petropzqi It depends if you mean for 'senior' 1) A developer over 40yo ...... or ....2) (may or not include people in the 1) developers with seniority, experience, and working principles of design, with a good history of successful software production.
Sadly I agree, it is all too common for orgs to get this wrong. The best orgs invest in their people and help them to learn and develop their skills, it is in everyone's interest. I have heard bad orgs say "but if we teach them, people will leave for better jobs", my answer is to make your org a better place to work then. This isn't just about paying more, motivation is more interesting and more complex than that. Watch this from Dan Pink: www.ted.com/talks/dan_pink_the_puzzle_of_motivation?language=en
They are (scarily) highly common. I believe that today's startups are actually incentivized to follow bad practices because investors want their quick profit. Quality is optional and taking shortcuts is okay.
If I have to pick one advice for novice developers is this: to study other people's code, specially of good, mature, and open source software, like Spring framework, or Hibernate, or even smaller libraries as the Apache Commons ones. This will not only give an idea of what the design principles are, but it will also cultivate the one's own 'softpedia' of existing software out there in order to avoid reinventing some wheels. Thanks for sharing your wisdom!
Appreciate the information. These videos have great eye candy. Well done to the editing team.
This was awesome. Thank you so much for taking the time to make this!
-A junior developer
You're welcome!
I am a young professional, working in software since 4 years. Only within the last 1.5 year it came clear to me how I could improve in my career. Learning code architecture, better design and most importantly the social skills that one would need when working with co-located teams. I wonder since then why this is not part of any bachelor's or even master's degree to some extend. For example code review practices are so important but nobody teaches you a good practice. This is something I clearly miss in the educational structure. Only now I am able to look for valuable resources to find my way to improve on the same. Big part is this UA-cam channel, thanks for the content!
Your insights have helped me so much. I was horribly stuck on a problem, so I tried something silly. It didn't work but it gave me insight to the problem. As soon as I realized this I thought "Ah, that's what Dave's talking about when he says to think experimentally. I just did an experiment." Thanks Dave!
Fantastic. Love all the advice and perspective you provide. I can sense all the experience that went into this quality content.
I just start my first JS developer job and thank you for sharing !
For me, personally, my intermittent development experience has been a problem. One of the most difficult projects I worked on was enhancement to an existing, very large, Perl 4 automation for log monitoring in a heterogenous environment. I believe reading code is a skill by itself, and an important one, but your advice in this video is most excellent. I bought Modern Software Engineering to add to my Kindle collection, and am still reading it.
Pearls of wisdom from an O.G. Software engineer. I enjoyed every bit of this.
Amazing content again. Thanks 🙏
Very important video, thx
Thanks, a very useful talk.
I feel like I'm in such dysfunctional team right now..
We are implementing pixel perfect design, with every little detail specified by a customer. And when they do not give concrete requirements on something the whole process falls apart. It is hard to describe everything what is wrong with this project.
I'm trying to be good engineer and write good and clean code, fix potential problems even outside scope of my ticket, make code base more DRY etc. But it is almost impossible in this project. It is a bit paradoxical, because despite this micro management in almost every detail, there is no clear vision of anything and there is no technical leadership and clear architecture goal. Even though around 50% are seniors or team leads. It is one big spaghetti. I feel dumb and powerless. I feel both like a junior not knowing what to do and like senior wanting to take charge in place of the missing leadership. But at the end of the day I don't think it is worth the effort to try to fix it if I'm just a mid level, and I don't think I have proper skills anyway.
I've got the experience as you do. The problem lies with management since there's no main goal, vision or strategy, which means they don't want to invest and take responsibility for it. I've tried so hard to address/fix the issues but no one is listening or caring about it. I'm just a mid level dev on paper but had my own business for a while before this. I can recognise a business/ management problem from a mile away. If it gets under your skin just move on, that's exactly what I've done.
Animated background - no Conway's game of life? :-p
your description of dysfunctional organization applies to 90% of Indian IT :D
One minute into it and I am already clicking like.
Are only high qualified people necessary for software development? Of course you need them, but you also need people who make the code cleaner.
As someone who learnt alone and has been working open source
Was i ever a junior with this definition 😂😂
Edit: it's a joke, i had a period of time i copied code from the internet
Like full crappy login systems
I just love the T-shirt
Dave has a great taste for t-shirts. Loved the Alien one from previous videos 😄
👍!
I am 19 and I just started my career, but I have over 6 years of software development, i was never a junior lol
Press X to doubt
My two cents. Avoid - no matter of seniority - tutorials with 'screaming' titles in a style of: "THIS STACK WILL BE OBSOLETE in 2023!!11", "YOU MUST KNOW THIS in 2023".
These pseudo tutorials only boost anxiety. Focus on yourself, reach out to valuable tutors that don't care about shining.
1st