Avoid These Common Mistakes Junior Developers Make! 

Do you have any other tips for developers at the start of their career? DROP THEM IN THE COMMENTS BELOW! 👇

*Timestamp* 1:50 1. "SW Dev is all about Coding" 3:50 2. "If only the Business would get the requirements right!" 7:08 3. "Speed is all that matters!" 9:22 4. "My Job is to Code, Not to Understand the Problem Domain!" 11:05 5. "I can't ask for Help! It shows that I don't know enough" 12:18 6. "Software Architecture is for the Experts!" 14:00 7. "Testing is someone else's job!" 15:20 8. "I would like to do a better job, but my boss won't let me!"

This video was humbling. I've been writing code professionally for 15 years and I'm guilty of some of these mistakes.

Oh, a development channel that doesn't make me cringe. I got goosebumps ... Keep up the great work

on the topic of Speed is all that matters" i always counter with "first you get good, then you get fast"

If you want to help the channel, share the video on the social networks. This man is giving you all the knowledge he has on a silver plate! Thank you very much for the video!

"There is a professional duty of care that we are all responsible for." --Couldn't agree more. Loved the "clean as you go" example.

With any career, it is important to be proactive. Don’t just sit there and only do just enough of what’s being told to do. Activate your mind, and always be curious at everything.

“Smart people ask questions, dumb people think they have all the answers.” Spot on! I was brought up on, and have successfully lived by the thesis “He knows the most who knows he knows nothing.” It’s where we all start and what enables us to learn.

14:12 _"If not, then you're dangerous, and need to take a step away from the keyboard."_ HAHAHA!

I discovered this channel only a few weeks ago, and I am stunned by the quality of the content. In my opinion, all the videos are must watch for any engineer that cares about their work regardless of seniority. Thank you for making such great content available to everyone Dave.

Awesome, sharp and clearly spoken. This is what a software craftsman distinguishes from a developer.

Randomly found this channel. Found out that, on many points, I tend to think a lot like you, despite being in this business and in the same company for roughly 7 years, meaning that I lack a lot of experience. I love this and will most likely spread this among the colleagues, some of them definitely need to hear this =) Thank you for this.

I've only watched a few of your videos, but I'm liking your content so far... In this video, for example, you have covered many topics that I have been preaching for the past decade, and It is heartening to finally find somebody else on the same wavelength. I have been working in the manufacturing business systems field for many years, and have had many of the experiences you described, and my real frustration is the fact that most organisations don't want to even acknowledge these issues, let alone change to a new way of thinking and working on I.T. projects. My company takes the much more modern approach to developing software - the main being that we do NOT think of ourselves as software developers - we are actually "Business Problem Solvers" - and computer systems are just the TOOL that we use to solve those problems. If you concentrate on actually solving the problem and improving the business, there are very different priorities. We find that if we stick to some simple principles (inspired by agile software development principles, which in turn is inspired by Lean manufacturing and Goldratt's ToC): 1. "Capabilities", not "Requirements" Concentrate on the overall "Capabilities" that the USERS need to solve the PROBLEMS - let the developers figure out the best way to deliver that capability, rather than insisting the business describe the requirement in real detail. i.e."I need to be able to take photos on a building site and automatically put them into a report template for our client" 2. Small batch sizes - develop and release capabilities in short quick chunks 3. Short feedback loops - get the developers talking to Users directly, release, test and refine a capability in as short a time as possible - preferably in hours, not days or weeks And in general, for solving business problems, the answer/system generally needs to the same simple things: 1. Make work visible 2. Be able to see any Business Operational problems quickly (and to "swarm the problem" as the famous saying goes) 3. Create communication "Protocols" between employees and teams - give the conversations common language, structure and methodology - reduces errors, confusion and waste. I think we sometimes forget that this whole industry used to be called "Information Technology" - as a society, we've concentrated so much on the Technology part, we forgotten that the actual reason that all this exists is to improve how we use and transmit INFORMATION - and this couldn't be more important than within a complex business. As software developers, we have the potential to MASSIVELY increase productivity in this country, if only manufacturing and business would adopt some of these simple approaches to using technology in their operations. They usually have a board of directors that includes representatives from HR, Health and Safety, Marketing, Sales, Manufacturing.... I have yet to meet a medium sized manufacturing business in this country that has a technology expert on their board - it's simply viewed as a "Service" like payroll or the canteen, whereas in this day and age - a real business strategy IS a technology strategy. My company has set out on a mission to change this situation by developing software that solves real business problems quickly and continuously, and finally get I.T. professionals "A Seat at the Table". James Hathaway - Technical Director at SigmaDX Ltd. Resources that insipired this post: Eli Goldratt - his entire Theory of Constraints master work. "The Phoenix Project" - by Gene Kim, Kevin Behr and George Spafford "A Seat at the Table" - Mark Schwartz "Black Box Thinking" - Matthew Syed (Better to fail fast and learn than to be paralysed by indecision) "Lean Startup" - by Eric Reis "Toyota Kata" - by Mike Rather

I really dont know how until know I find this channel.... I have been looking at videos about programming since about a year now, trying to learn by myself and doing some minor projects, and until now I find this gem.... Thank you alot for all the info and all the information!! hope your channel gets as much as you which for it!

I think actively evolving communication skills is vital. Its all about language, text, discussion and understanding the requirements and problems. A precise, meaningful and structured communication is so important.

This channel is underrated! Thanks for sharing that much of good content. Coding in itself is "easy", thinking, designing, debugging, launching a software is at an another level.

Great video, such important topics that are not discussed enough. Thank you!

Wow! So much value in a 20 min video! I would need to re watch it again and again to truly understand the ideas completely. Thanks a lot for sharing your experience!

Excellent advice. Gets better as it goes on.

I didn't firmly grasp the concept of the finding solutions to the problem until my senior dev made me solve a problem without writing a single line of code. Basically using UML diagrams and logic to think through what was actually going on, it was a very useful exercise. Side note, I can't wait to get my copy of the continuous delivery book!

I used to work with computational physics (fluid dynamics), and a recurring problem I found in the community was that they were very focused on marginal improvements in speed or accuracy, but not as much on the physics - for example, always running against simple test cases or making unrealistic modelling assumptions. Also, not very much focus on UX or documentation and making their tools accessible to a wider audience.

Than you for sharing your invaluable knowledge and experience!

Your channel has helped me greatly! Thank you for sharing your knowledge!

This has been extremely helpful, thank you for this.

Awesome content, thanks. IMHO, you can strike "junior" because some of these mistakes (especially the last) I can see long time professionals do as well (who might think of themselves as seniors)

Thanks for a great talk!

Great video! Thank you so much. Hope that you continue making videos!

11:39 Beautifully stated, and a great piece of advice.

Love your videos, titles sound like the titles from thousands of other clickbiat videos, but you actually give deep thoughtful and instructional answers/solutions!

So much knowledge, thank you

I am a new dev in my first year and this is the best video! I've seen many of these mistakes made by myself and others.

This is kind of what is called "staying in the problem-space before going to the solution-space". Focus on the problem, the underlying assumptions, the whom and why, not the what or how. One of the biggest problems with us programmers is that we tend to jump directly to the solution-space. Some business person starts talking about a problem and 15 seconds later our brains have stopped listening to the problem and is instead filled with arrows, boxes, patterns and whatever technology we know. Five minutes later we don't even remember what the problem was, just that we get to write a bunch of code using nodejs, k8s, docker and NoSQL (because I don't have NoSQL on my resumé yet). What if the correct solution is to remove a feature, delete 10,000 lines of code and add a new step to an existing process/feature? Code is not an asset. Every line of code is a cost, a liability. It has to be built, tested, maintained, deployed, configured and operated. Programmers and code do not exist for the sake of their own existence even if we like to believe that we are. We are not getting paid to do our hobby, sitting in a corner with our headphones on, listening to "programmer focus synthwave mixes". Sorry.

I've found that changing the question is a great way to find a solution that works. Never start by asking a customer what they are looking for, start with, could you describe the problem, or show me what problem you are running into. Not only will they willingly give you more information, everyone likes to complain, but you might be able to fix it in a way that gives them more value for less work. If not you can always follow up with, "and what do you envision the solution looking like." if you are talking to management, or "what can we do to fix it for you." if you are talking to a lower-level employee.

Thank you for making this video. I'm making a career change into web development and these are helpful points. Fortunately, I've always been a very curious person and love learning things and asking questions. I'm hoping that will help me here. Have a good one!

This is good stuff. The business will never get the requirements right alone. A good engineer will work with the business to define the problem and the potential solutions. Writing code, incrementally, allows us to test with the business the best solutions. We are not two teams. Keep up the good works, subscribed!

such a good speaker - love this!

Great information! Thank you so much for sharing.

Very pertinent Especially, the last one

Thank you for this list. It's branded as for juniors but lots of seniors can learn from it as well, including myself.

Thanks for this insightful guidance 👍

Thank you so much!

"We shouldn't be asking other people permission to do a decent job." Nice one!, I'll remember that forever.

Excelent content. Thank you!

Invaluable advice. I did nearly all of those mistakes in the beginning :D

This is an outstanding video even by your already high standards. I'm glad I've got something to link junior people to when I hear this stuff.

This was extremely reassuring for me as a senior dev.

First video I've seen from CD and subscribed at the end. I'm brand new to software dev but not new to the cybersecurity industry or general life/work principles and this video was spot on. 👌

I must listen to this, tons of knowledges and wisdoms

Fantastic advice.. thank you

I have a Master of Science in Software Engineering and I honestly wish I could go back and replace my coursework with nothing but the videos on this channel since it honestly would have had a more powerful impact than the standard curriculum.

To extend the carpenter metaphor, it's common to see younger people arguing about what amounts to whether cutting the wood or fastening it together is more important, when any experienced professional knows the important thing - and the thing you'll spend the most time doing - is MEASURING the wood. In software development, people will argue incessantly about whether it's more important to design the code or to write the code, when the experienced professional knows that while both of those are critical... you'd better spend most of your time TESTING the code.

love your videos man. keep them coming please!

this video is a great insight, I'm guilty of writing before thinking and later having to refactor it.

Excellent, excellent way of saying what the value of developers is in context of "the business not getting the requirements right". It shifted my perspective on things, and I will be sending this video to friends of mine just for that segment.

All your points are 100 % spot on. Believing the client will provide a substantial and useable blue print for the new application is particularly bad. You have to take time to understand their business and take time to come up with the best solutions, which might differ significantly from what they think they need.

Love the chef analogy at 15:45

I love this kind of videos, please never stop it from coming

I felt the need to give you a standing ovation for some of those points and the way you said them, especially the second one!

Thank you!

Great insights! Thanks

An Addition to the "ask for help" advice: Ask different people the same question, even if you think you understood it well after the first answer. You will most likely get to learn another point of view on that same topic and understand it even better. Same applies for online research, always have a look at different sources. Also dont worry about wasting peoples time, you might even do them an indirect favor! Explaining stuff is imo one of the best theory practices one can have, even if its just refreshing already familiar topics.

Some great insight there. Especially #2.

Recently discovered your channel and I'm very impressed with the advice. I'm a hobbyist dev looking to go pro as a full stack web dev. I never really used to write tests but have recently tried out a basic tdd approach and it was really interesting and helped me think about the problems I was trying to solve.

I've been a developer for 3 years and this is still somewhat insightful. Thanks sir 🙏

I’m so glad I found this video!

Thanks for the video =)

He is absolutely correct about these issues. Someone needs to the employers this as from most of my experience employers are the ones that push a lot of these problems. You can see these examples in job descriptions and if you ever worked in the industry for awhile you would notice they tell you today but expected it to be done last month.

Watching this video feel so great that I can watch it again whenever I need to and it will always sound reasonable to me. Kudos Dave. 👍👏

Love this. As somebody that has been doing this 25+ years, this is pure gold.

Great video, thank you! I'm two months into my first software engineering role and luckily haven't fallen into most of these traps... a few might be borderline though hah

This is Gold, thank you :)

thank you!

God, I love your channel :) Seeing a seasoned veteran continue to work and engage in my industry gives me so much hope for my future

This (all of this) is great advice. Not only for junior devs; this is what every day at the office should start with, or have these printed on a wall.

This feels more like a critique of development teams and or the management rather than junior devs.

I started programming in 1970. I think these suggestions aren't just for beginners. This is the best you tube presentation on programming I have seen.

Finally common sense in software development. Kudos!

Perfect!! AMEN

Great channel and great video. The beauty is that the narrator is actually talking in terms of principles - much of what he describes can actually be applied across the wider business.

Eeeeh this can be broadly applied outside of software development. Great stuff

8:00 I love that you would say that, as when I think fast and am awake I type fast and make big changes on the fly all working, but when my brain is chilling I'm gonna have a really long time typing one word, like a cold engine unable to warm up.

Thanks!

Thank you for your wisdom. What a treat. It's amazing how much of what you are saying applies to life in general.

8:00 about the fast typing: personally, I gain greater insight into the code by simply attempting a solution and then improving on it, rather than by, say, pseudocoding and trying to get at the answer by non-coding means. It's sometimes hard to oversee the nature of the problem without actually looking at some code that forms part of the solution, even if it's a suboptimal solution. I agree with most of what you say here but for me, working fast and typing fast are integral to my ability to focus and concentrate

Appreciate your insights!

So many good points to think over for me as a junior dev. I alway find it difficult to ask questions, not because I don't know the questions to ask but mostly because to not be seen as annoying. Combining this to the point of taking the ownership, I will try not to feel intimidated for asking the questions.

As a CS student, I found your points to be very enlightening and useful. Many thanks !!

You just changed the foundation of my beliefs on requirements... Thanks! My job is a lot harder than I thought!

The man seems to be so competent and his speaking is so credible that I adore to listen to him even though I have nothing to do with IT 😂

I really love the way, how this valuable information is presented. I believe I can learn a lot from this channel.

just a note about knowing the problem domain, I do optimize, debug and improve lot of system without really knowing the domain at all, because I concentrate first on refactoring/cleaning the support material, libs etc. So many code are badly written, a lot of time optimization is ENORMOUS by reworking the inner algorithm (like changing a bubble sort to a quick sort improvement) one of my last dramatic change was rewritting a SQL query that was written by an Oracle DBA, with all kind of obscure command and attribute proprietary to Oracle, I just clean it back to the originale intents, write the proper query, with trigger and precalculated value so the 12 hours report dropped down to 15min ... without any specialized oracle commands, my query work on any SGBD with minimal syntax adjustment! Combine this to the KISS principle, and optimization and easy maintenance is usually the results. But I guess you need to be a bit more experienced before attempting that, too many employer got burn by eager junior to 'rewrite stuff' .. but if we didn't reinvent the wheel, we'd still be on wood wheel... With experience you start 'smelling' the poor code that would gain a lot by refactoring/redesigning...

About your last topic, addressing issues with management it is relatively a lot easier for a someone senior or someone with other options. People don't choose to not write tests or not to estimate right. These things could just so happen to be there. This is a lot more sensible topic, and I don't believe standing up works often, specially for Juniors and smaller companies. Of course this is often used as an excuse to not take ownership of a task, but lots of places do have a crappy work environment and won't let you do a better job indeed.

Great video! I am guilty of some of these. Really humbled me a few times. I used to ask a lot of questions then around my 3rd or 4th year an engineer said he always knew how little people know by the questions they ask(which is true) but so what?... I am so over the ego BS, I just want to write robust, clean, solid software.

This is the must for everyone starting a software engineering careers and repeat the watching for couples years to remind self..

A very good talk.

Great content

that's Amazing video!

Hi! Love your content! Could I suggest you add time stamps to the description to add book marks on the RU-vid videos? For instance: 0:00 - intro, 1:48 - mistake 1: SW dev is all about coding, 3:47 - mistake 2: If only the business would get the requirements right etc... This is helpful so that viewers can jump to a specific point quickly in your video especially in a video with a list of items. I love the refactoring series. It's actually quite satisfying trying to make code cleaner and concise.

I really enjoyed this video, thank you. I think you share the same love for software development as I do. Subscribed.