I'm David Scott Bernstein, a software developer with over 40 years of experience and the author of “Beyond Legacy Code” and co-author of “Prompt Engineering for Everyone.”
This channel is where my passion for software development meets the transformative power of AI. By focusing on essential technical practices, I've guided thousands of developers towards long-term success in their careers.
Subscribe to this channel and join me on this journey of discovery into the future of software development.
Contact me directly through my website for questions or consultations, The Passionate Programmer, passprog.com/schedule-a-call/.
And if you want to dive deep into Extreme Programming practices used by senior software developer then let’s discuss bringing my Software Developer Essentials class and coaching to your organization. Contact me through my consulting company, To Be Agile at tobeagile.com/.
Dave Farly is my hero! His ideas are brilliant! I highly recommend his RU-vid Channel, @ContinuousDelivery. The ‘easy to change’ theme is recurrent and something we come upon all the time. I try to be good to my future self by doing what Kent Beck says, “Make the change easy. And then make the easy change.” It’s a philosophy that has served me (and my clients) well for many years!
I'm just starting out. Trying to learn good habits of documentation and type-hinting, as I use Python. Also, learning how to create modular, reusable code instead of case-specific code. Haven't learned unit tests, though. I really should xD For example, I had an Inventory system (I learn via RPG tasks) that I realized was just a container for data. However, I made Inventory too specific to use outside of its intended area. Subscribed! I enjoyed your talk.
"agile I think means agile software" I think you are right here. It would also be much more rational to say "look our software is going to need maintenance and change and it's not that one time produced product". But with management probably the time wasn't right and money givers simply had different ideas so the "work process" has been defined that way as a first step to establish it. And now we have "Scrum". But I think the idea and the rational is 100% correct. It means agile software.
I think it is kinda funny that software quality has went down since agile methods. I think the mindset has shifted from releasing as "good of product as possible in the time given" to "release it fast, release it first, patch it next sprint". Just look at games, old games had bugs but new games sometimes release and they don't even run sometimes. It is like there is no QA now.
Thank you. It is really a subtle (but I think an important) point. And I think that most of the original authors of the Agile Manifesto would agree (I know most of them personally). I think that for them agility means agility in software. This involves technical practices to write code that can be changed even late in development when we know more and can leverage that knowledge. For me, this is where I find the most benefit in Agile as a software developer.
I (and many others) have refuted the recent report that decrees Agile as a failure. The data is actually not in alignment with nearly every other study done on Agile. I’m not saying that Agile is THE solution. It has big challenges and I see it abused and distored all the time by managers but when done well it can be a step in the right direction for software development. I see many teams achieving a lot of success by adopting the right technical practices. Take it from a guy who did Waterfall for 15 years before Agile existed-it wasn’t fun!
Hi David, very interesting topic, you're truly passionate! It would be nice if you could give some examples to ilustrate your points better; what do you think?
Yes, I’ll work on a video with some code examples to illustrate my points but I also don’t want to exclude non-coders with videos that are too technical. I’m thinking of creating a separate playlist for advanced developers that includes code examples. Does that sound good?
Thank you for the points. I pitched them all today however management keeps pumping me with new features today instead and the build times are insane for a simple feature, let alone the testing time.
I wonder how much faster you would be if you could refactor the code that needs to be extended first. I always find that cleaning up code before adding features makes adding the feature ten times faster.
Me too. Refactoring and writing tests is part of my professional standards. Like you, I don’t ask permission to do my job. I think more developers should think like us.
Another approach is considering refactoring is just a part of the job you are paid for, just as a painter is not supposed to leave a mess after painting the ceiling. It implies preparation and clean up after the main job. Don't ask for approval, just do it in appropriate duration.
I like this way of being diplomatic to those kind of people who doesn't understand IT as a whole, but some of them they are just walls, in those terms better move on.
Yeah, unless those kind of people end up as our bosses. Then we have to educate them as to why refactoring code to make space for new features is faster and safer than trying to cram the new feature into code that can’t accommodate it.
@@ThePassionateProgrammer It's hard to educate them when they made a company from scratch, their software works on hope and prayers but thanks for the insights. I look at it again and to better grasp the mindset how to approach them
These are different videos. The video from two weeks ago is 7 strategies on how to justify refactoring to management. This covers the number one reason developers tell me they don’t refactor-because their manager won’t let them. Yesterday’s video is on when the best times to do refactoring. And in two weeks I’ll release a video on what code is most important to refactor. These are completely different videos with different strategies but all are important. Most development teams neglect refactoring code and pay a heavy price for it.
Could you take a look again? Last week, I was expecting to hear about those reasons to justify to management when to refactor, but video just mentioned the strategies. Maybe there was a mistake in the video you uploaded ( I don't want to miss that information 😀)
@@joaquinnunezgarcia9279 OMG, you are right! I’ll take down the duplicate I posted and put up a new one in under an hour. Thank you so much for spotting this!! Thank you! Thank you! Thank you!
One observation I've made, when maintaining software (particularly when project managers may not be that experienced with software development), you often get a feature request like, "I need a button here that ...". The junior developer tend to add the button to the UI, implement a click handler, and work their way in through the layers (if there are layers) to achieve the requested effect. The senior developer starts by trying to understand the business side of thing, is there a business process we need to support? This is often an XY problem, so once we understand the problem the experienced developer can ask. "Now we understand the problem, and the button that does ... is _one_ solution to the problem, but perhaps ... is a better solution to the same problem". Or even due to the knowledge of how the system works can see other parts of the system where knowledge of this business process could be taken into consideration. Much of it is about discovering useful cohesive abstractions (I don't mean it from the OOP sense as abstract classes, but just concepts that can be considered a value as a whole). As an example, I worked on a system that needed to calculate distances and weights. By introducing these as specific Distance and Unit types, implementing their corresponding arithmetic, and handling different units of measure, the Scope 2 CO2 calculation became extremely simple _and_ reflected the _actual_ formula from the standards.
Oh, I feel so inspired reading your post. YES! This is our REAL job, to figure out better ways of interacting with our systems. And yes, it is common for people to describe what they want in terms of ‘how,’ like put a button on the screen that does x. As you point out, we have to listen deeper to what the user really wants and find better ways of delivering it. This is also my exact philosophy when writing unit tests-to test behaviors rather than implementation details. This is how we bring more value to our work and insure our future in the age of AI. Thank you for your awesome insights!
I love hearing about this concept *outside* my own head. 😂 Especially 4:53 - the inherent beauty & creativity held in this field of content creation (because we are *creating* content!).
Yes, I think building software is one of the most creative acts that we can do. It engages both halves of the brain-abstract and logical. And even though the abstract side is less prescriptive, they are skills that we can develop and excel in. That’s what I love about building software!
What is excellence in software to you and how to you create it? Some of the things that have helped me create good object-oriented software has been understanding the Single Responsibility Principle and the Open-Closed Principle as well as design patterns. These are powerful distinctions but they can also be misapplied or overused so we always have to keep our purpose for using them in mind. What guidance do find helpful when building software? Share your thoughts in the comments below.
Why I like a declarative programing, because I can even end on a stage what, and never touch how. Writing tests also helps you to understand what the system should do.
It would be great if you can also share bad practices you have seen implementing scrum. Many times, devs don't see value because it is wrongly implemented
Scrum Worst Practices! It’s a great idea. I proposed a talk at the Scrum Gathering called The Seven Stages of Scrum. It was rejected. But it would make a banger video. Boy, I’ve seen a lot of abuses in the name of Scrum. There are also lots of comments on my video, Why I Quit the Scrum Alliance, from viewers on how Scrum has been abused in their organization. But many if the ideas from Scrum are valuable so I want to acknowledge that as well and recognize that like many complex activities, it can be applied poorly so that we can strive to do better.
What is you input of versioning? I use a version as xx.yy.zz.bbbb, where xx-major version, yy - minor version, zz - small the minor version improvement, bbbb - a build number, which is mostly refactoring flavor with minor improvements. Can you improve my schema?
Hi Billy Bob. Would love to hear your insight on unit testing vs integration testing vs E2E testing. Do you agree with the testing pyramid? I appreciate your knowledge. Please do a video on this ❤
Do I agree with the testing pyramid? Yes, in general. Software applications are so varied that it is hard to make rules around testing them. How we test and what we test is very different of we are building code for a pacemaker versus a social media app so there are no hard and fast rules here, IMO. However, I strongly believe that all code should be tested and I prefer to have unit tests for the behaviors I build, which I create as a result of doing test-first development. Unfortunately, there isn’t good guidance yet around doing this well and we still have some fundamentals to cover on this channel before I dive into TDD. When I have good unit tests that validate the outcomes of my APIs, they give me the freedom to refactor code later. But the way I see most devs write tests, they lock down the implementation in the test and when they go to refactor their code their tests break. This is even more so for integration and system tests so when you change implementations those tests must be rewritten. We have more opportunities to create implementation-independent tests at the unit level so that’s where I focus my testing. So, unit test can save a project or it can destroy a project by locking down implementation and preventing code changes. “The same medicine that can cure you can also kill you,” as Billy Bob would say. I hope this helps and I will make videos about this in the coming months so stay tuned.
@@ThePassionateProgrammer Awesome! Can't wait on this topic. Another great topic that would interest me is on how a mocking framework could complicate refactoring too since it knows too much of the implementation.
Yes, exactly! I’ve seen mocks lock down implementation making it difficult to refactor code. I don’t like to use mocking frameworks a lot. I prefer to create my own mocks and shunts that can abstract out implementation details. You’re right, I should do a video about this but I have a long list of videos to create and I want to try to be inclusive so non-developers get value from my channel also. Thank you for your comment and stay tuned for more.
I really liked the approach to TDD expressed in the TDD with Python book. He starts out with user stories and the tests become a fairly literal expression of the user story. It also tends to lead to a code structure where the code itself naturally aligns with the functionality you want to express. I find that when I take the time to come up with some user stories and map them to tests in this manner it really helps with creating good tests. When I don't I tend to have a lot of little tests checking some small part of the functionality which tends to become an illegible mess. With regard to mocks, I like to have an option for the mock to go either to the live API or to the mocked result. Too many times I've found a bug because a third party API has changed, or because I made an incorrect assumption about how it behaved when I was implementing the mock and the tests all pass but it breaks when exposed to real world data. Maybe there's a better approach but I find that tends to be a minimal effort for maximum reward version.
Without branches? Really? I generally don't like branches with too much work in it (big releases ones) for the reasons you've mentioned but I don't see how to work with a team of developers without branches at all. Do you let juniors and people new to a project commit code straight into the main/master branch !?
Yes, some teams commit to a staging server first as a precaution. But look at Google. Everyone always commits to trunk every day. If 60,000 can commit daily without branching then anyone can. Feature flags holds part of the answer. They are on my list of things to cover in a future video. It’s a long list.
@@ThePassionateProgrammerhow to maintain co-existing released versions (eg. Android 13 and 14, or different versions of Chrome) if you only have the trunk? are you sure they use feature flags for that? that sounds like a nightmarish amount of ifs, and simply recreating the headache associated with branch management in other form and other place
@@vibovitold I don’t know how the teams at Google handle different versions or support different hardware from the same code base because I haven’t work with them. However, you could use feature flags for that instead of branches. I am okay with branching as long as they are short-lived. Branching for experimentation is fine. We just don’t want to have many long-lived branches. We have a name for when teams create feature branches that they don’t integrate until just before release, it’s called Waterfall.
TL;DW testing individual components only makes sense for libraries to see if the details are logically sound (most common testing done today) such as having a class named MathTest What the most common testing should be is Given-When-Then output mappings for the given inputs in a class named BusinessClassTest without major concern for details before implementation
If you are testing behaviors using GWT then you are doing many things correctly. You are thinking about your component as having a single responsibility that you can easily set up, trigger, and validate. Bravo! That’s the way to build software!
On thing I'm going to try you talked about is starting simple. Then if simple doesn't work, look to design patterns. Starting with grand architecture and design patterns leaves me in coder's block, unable to write any code because I've got no clue what to do
Yes, start simple and build incrementally, that’s exactly what I’m saying. Or in Kent Beck’s words, “Do the simplest thing that could possibly work.” Once it is working it’s much easier to build upon. Big up front design is Waterfall and a waste at many levels. Incremental software construction is a core idea behind Agile. So, they did not teach you this in school? What did they teach you about code quality, software principles, acceptance testing, design patterns, and refactoring? These are what I consider to be core skills for software developers.
The only time I leave a comment is with a TODO tag where I plan to comeback and remedy the problem later and remove said comment. I think contract comments are generally fine as long they are kept up to date.. anything else should be auto generated..
The problem with code as documentation is that the code tells you what the program does, it doesn't tell you what the programmer wanted to happen. The ridiculously simple example I use is to imagine seeing the following in a piece of code: // Increment the counter counter = counter - 1; Now without comments a future developer trying to proof read or fix an error in this code has to scan back and forwards through the entire chunk of code to try and figure out what is the error while the commented version will immediately jump out as a mismatch to a reader.
If you're not completely familiar with the codebase and business logic, starting with the tests is a waste of time. Sure, you could do it, but you'll be constantly updating them during implementation.
Constant iteration incremental change can be a very positive approach. It actually happens in any code base when the program becomes big, anyway. So why try to avoid it? Our thinking should evolve along with the creation of our program, why not!
Thank you for this video. What would you say is the ratio between the time you spend specifying what to do and actually doing it? How do you test things that go to a database for example? Do you "mock" it? I'm not a big fan of that, rather build an in memory version of a DB which I guess is just a more complicated way of mocking things and I guess I'd need tests for the test implementation.
Good questions. It’s hard to answer the proportion of analysis (what) verses design (how) I do because it is ongoing and iterative. I probably spend twice as much time in analysis, talking to users, creating acceptance tests, getting feedback, etc. versus coding in the beginning of a project and that proportion reverses towards the end of a project. Regarding your second question: How to remove dependencies so that your tests test only your code is the subject of many videos and I hope to make some of them. Yes, the short answer is to ‘mock’ the database so it is out of the test but that doesn’t mean to use a mocking framework. Mocking frameworks are slow and add a level of complexity that I find distracting. Creating my own fakes and injecting them is super-easy while promoting clean code habits that make code more testable and extensible. I’m all in favor of automation but mocking is one area I prefer to do by hand. Are you familiar with techniques around dependency injection and creating ‘hand-crafted mocks’? If not then I can make a video about it.
I’m glad you are finding value on this channel. Much more to come… And thank you for suggesting the topic for last week’s video. It’s been doing really well.
I really enjoyed this video and approach. You've given the most comprehensive yet sussinct introduction to the mindset (and working theory) behind good TDD I've yet encountered. I've consumed endless content on the matter in the form of courses, articles, and videos, and nothing really motivated me to incorporate TDD into my practice like this video. Most content does a decent job of explaining the what/why and maybe the how from a technical standpoint, but I love how you provide a clear path on how to approach the mindset from a practical perspective. Thank you for the insight. I will try this approach on the project I am just starting.
I feel like this video makes a lot of sense when you already know what he's talking about, but if you haven't lived it or been in these situations enough it can be cryptic.
Yeah, I was keeping up until sometime around the half way point, I think... Vocabulary expanded suddenly... Then we were talking APIs... Method signatures.... Etc... Wish the example stayed simple or connected the dots (probably left on the cutting room floor due to the algo).
