Is This Why You’re Bad At Programming?

Подписаться 202 тыс.

Просмотров 84 тыс.

50% 1

What are the bad programming habits that make bad software? What are the common excuses that programmers make for writing software that is worse than it needs to be? What are the common software developer mistakes that people make?
In this episode, Dave Farley describes the common excuses that developers make for doing a worse job and describes his software engineering approach to how we can debunk mythology and lazy thinking in software. So if you are a junior software developer or any software developer who strives to do a great job, take a look and see if you have any of these bad habits, and listen to Dave’s advice on how best to avoid them, or maybe show where Dave is wrong.
-------------------------------------------------------------------------------------
Further Reading:
Dave's Blog Post on Pair Programming ➡️ www.davefarley.net/?p=214
‘The Case for Collaborative Programming’ Nosek 1998 ➡️ bit.ly/1J6LrAP
‘Strengthening The Case for Pair Programming’ Williams, Kessler, Cunningham & Jeffries 2000 ➡️ collaboration.csc.ncsu.edu/lau...
‘Pair Programming is about Business Continuity‘ Dave Hounslow ➡️ bit.ly/1Pk0JFW
-------------------------------------------------------------------------------------
📚 BOOKS:
📖 Dave’s NEW BOOK "Modern Software Engineering" is now available on
Amazon ➡️ amzn.to/3DwdwT3
In this book, Dave brings together his ideas and proven techniques to describe a durable, coherent and foundational approach to effective software development, for programmers, managers and technical leads, at all levels of experience.
📖 "Continuous Delivery Pipelines" by Dave Farley
paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble
➡️ amzn.to/2WxRYmx
NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.
-------------------------------------------------------------------------------------
Also from Dave:
🎓 CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses
➡️ bit.ly/DFTraining
📧 JOIN CD MAIL LIST 📧
Keep up to date with the latest discussions, free "How To..." guides, events and online courses. ➡️ bit.ly/MailListCD
-------------------------------------------------------------------------------------
CHANNEL SPONSORS:
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
Harness helps engineers and developers simplify and scale CI/CD, Feature Flags and Cloud Cost Management with an AI-powered platform for software delivery. ➡️ bit.ly/3Cfx3qI
Octopus are the makers of Octopus Deploy the single place for your team to manage releases, automate deployments, and automate the runbooks that keep your software operating. ➡️ octopus.com/
SpecFlow Behavior Driven Development for .NET SpecFlow helps teams bind automation to feature files and share the resulting examples as Living Documentation across the team and stakeholders. ➡️ go.specflow.org/dave_farley

Опубликовано:

2 ноя 2021

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 403

@gilgamecha 2 года назад

Very interesting that there is now data to show quality and delivery speed are synergistic not antagonistic. I am often telling my team "we need to deliver this fast, so we can't afford to do anything shoddy, otherwise we WILL be late". I guess bitter experience has taught me that the only way to hit a hard deadline is to do things right. Sacrifice quality for haste, and your product will be both late AND crap.

@tombackhouse9121 2 года назад

I am not a professional programmer, and CI/CD is outside the bounds of my experience. I will say, that having been trying to get my head around TDD recently, I was immensely frustrated initially at having to stop and scratch my head over how to test something when my brain was already automatically working out implementation details. However, having tried to stick with it, I'm repeatedly struck by how many bugs are caught immediately and corrected effortlessly when a unit test unexpectedly fails, and how quickly I wind up back in the debugging quagmire when I succumb to the temptation to forego the tests and 'just get this feature working quickly'. This has become one of my favourite channels very quickly.

@gullijons9135 2 года назад

While I generally agree with most of your videos there's always one question that comes up in my head; Where on earth do you people find these teams where everyone wants to learn and be better? I keep running into teams that during interviews talk vividly about how they have CI/CD, automated tests and all those fancy things, they even show examples and whatnot and then once I start working all of a sudden none of that is important and the only thing that matters is getting the next minor feature out ASAP and the quicker you can shitfix it the better.

@porky1118 2 года назад

I agree about your opinion of feature branching, but not in all cases.

@redwrath5 2 года назад

Great video again Dave. Always happy when i see a new video and I can send it to my freinds and coworkers.

@rickharold7884 2 года назад

All great points I agree with. Getting an organization to implement that in the culture is always a challenge. That’s the fun .Thanks!

@dauchande 2 года назад

"It's not somebody else's responsibility to give us permission to do a good job". I think you need to do a video just on this idea. Robert Martin has discussed this quite a bit with the notion of professionalism and being responsible for the code we write no matter what management asks. As professionals, we need to get better at pushing back.

@zpinacz 2 года назад

Thans for this compilation of great arguments on why quality is always the win! Love the channel and definately gonna get the mentioned book.

@after_alec 2 года назад

Okay this shirt takes the CAKE

@celavek2008 2 года назад

I love the channel and the content and I am extremely grateful for the knowledge. Thank you! I also appreciate your awesome T-shirts :) ! The one in this video is wicked cool. Would be interested to know where do you source them from - I spent an entire evening searching for the exact "Pinky and The Brain" t-shirt you had some videos ago :), couldn't find it(I got a different one though).

@jonathanaspeling9535 2 года назад

Needed to hear this to scoop some motivation to continue pursuing automated testing in the builds I contribute too: "The impact of designing for testability on the quality of our code is profound...testable code is more modular, more cohesive, has better separation of concerns, it also hides information better and is loosely coupled. All properties of high quality code" - D Farley

@harag9 2 года назад

Excellent talk, thank you. I watched your pair programming a month or so ago, and talked my team leader into trying it out at work as we have various members with different skill set, just like to say, that we have now adopted this method after a trial period as it really worked for us. I can't recommend it enough now. Again thanks!

@rubensrfonseca 2 года назад

Great talk, data is what separates opinions and reality. Loved the t-shirt!

@sarahwbs 2 года назад

PR reviews arent about not trusting the dev, they should be about having a second set of eyes to catch something the dev might have missed (no matter how experienced and trustworthy they are), and about giving other devs the opportunity to see parts of the code they haven't worked on before. Pair programming just isn't realistic for most teams most of the time.

@thekingofallblogs 2 года назад

I agree with most of the things said here. But one thing that CI proponents never seem to acknowledge is that it is difficult to impossible to coordinate all the different features and tasks into a release schedule. Features can span multiple iterations. Some claim that all code can be released every day to production, but in the real world that is ridiculous. If you do ci you have to wait until everything is a state to be released, and that is unacceptable in a lot of cases.

@christianm4906 2 года назад

This man is a truly good influencer in software development. He really knows what is talking about. Not like other influencers in youtube that give bad advise to beginners.

@puckpovier1559 2 года назад

Thank you for being clearly and giving evidence.

@miklov 2 года назад

I think it is good to not only look for evidence that supports your claim but also in opposition. It helps develop ones gut feeling but also makes it harder to miss some obvious benefit or problem one didn't think of.

@mikemegalodon2114 2 года назад

Thanks for your awesome content 👏

@ijacek 2 года назад

I understand your strong opinions against feature branching but you should mention, that it works only when the implementation can be done within a day (and it's clear how the solution looks like). There are features that can take a week or longer to implement and that's not because the feature wasn't broken to smaller parts but because it's hard to find out how the algorithm should work in the first place. It happens to me quite often that I have to use try-error approach to find the way out and sometimes I even have to give up... What are you thoughts about that?