Avoid These Common Mistakes Junior Developers Make • Dave Farley • GOTO 2021

We’re so pleased to announce that we’ve teamed up with Dave Farley, author of “Continuous Delivery” and frequent GOTO Conferences speaker, for a monthly video series featuring ideas about continuous delivery, DevOps, test-driven development, BDD, software engineering and software development in general.

Dave Farley - Continuous Delivery & DevOps Pioneer, Award-winning Author, Founder & Director of Continuous Delivery Ltd.

ABSTRACT
What are the common software mistakes that junior developers make, and what should they avoid? Get advice for software engineering students and people starting out in their career from an expert.

In this episode, Dave Farley describes 8 common mistakes that junior developers often make and offers his advice on how to avoid them. Whatever your approach to software engineering and software development, whether you are practising Continuous Delivery, DevOps or something else, we think that you may find some helpful ideas in this video.

CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses

RECOMMENDED BOOKS
You can grab Dave Farley's new book 'Continuous Delivery Pipelines' here:

#GOTOxDaveFarley #Programming #JuniorDevs #JuniorDeveloper #Teams #SoftwareDevelopmentMistakes #DevOps #DaveFarley #GOTO #GOTOcon #ContinuousDelivery

DAVE'S LINKS

Looking for a unique learning experience?

SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.

[VladimirCheTV]

First mistake - not making time codes in your videos :)

[Jelvix]

It is unrealistic for anyone entering the development world to move forward without making mistakes. There are some mistakes that a lot of junior developers tend to make over and over again. The best thing you can do is recognize mistakes, accept them, and move forward.

[madmanX]

Referring to the last point: I am currently working in an organisation that does not care about software development. The software that they ship is of bad quality, there are many bugs in production, development is slow, QA and Ops are having a hard time. The problem actually is crappy code with a lot of technical debt. It’s been only about deadlines for years. Really, you just have to look at the code and you know what’s going on. Yet, the management does not listen to the developers. Developers are just exchangeable resources. When they try to adress these issues at the end of the day they damage themselves. Sure, it would be great to stand up for these things and take responsibility. But would you jeopardize your reputation or a raise if they don‘t even care? It‘s funny, because everyone is talking about optimizing processes and project management and invoicing. Nobody is talking about the software. They would rather blame QA for being too expensive instead of asking a developer what‘s going on.

[sitedel]

"Speed is all that matters" => "Reactivity is all that matters", which means react quickly to business requirements when they are created, not several weeks later when the task is assigned to your team to acknowledge them ASAP.

This mantra is also an extremely strong advice when shit happens in production code : strong reactivity is the only way to gather sufficient metrics to understand if and what bad behavior happened, why, how many use cases are concerned by this bad behavior.
Then you will know how much work is required to fix this bad behavior, and ideally deliver an hotfix before this bad behavior can cause too much harm to your users' daily workflow or to the company business.

[raulcalvo]

About the second mistake is not fair to blame the devs for asking to get proper requirements. As a software developer our productivity is measured by tasks completion. There are many positions over software developers in an organization that are meant to discover and describe next user story. Thus is logical for developers to ask for a precise description of these. There is a lot of context that is missing for a developer when sprint start that’s why the results of Business meetings should be a concise tasks specification that doesn’t have to contain any technical details

[TheRedbeardster]

Dear sir, carpenters DO NOT make chairs and cabinets - this is joiner's work :)

[tackline]

The Newton kept Apple afloat. When the money was running out, they sold off their ARM shares. Co-founding that company was a pretty good idea.