1. Code As Communication 2. BE CAUTIOUS of Frameworks 3. CODE IS DESIGN 4. QUALITY OVER FEATURES 5. Software Development is a Social Activity 6. AVOID CODE OWNERSHIP 7. Work in small steps
8. Work scientifically: Write a hypothesis - e.g. as an automated test. Then prove this hypothesis right or wrong. Then (this is important!) meditate about "Does my hypothesis suck?" - Repeat.
@@pinguwien i work more creatively and prefer to write the solution and then the tests second. I learn what to test while writing the solution, and don't have to guess and then iterate.
@@ytlongbeach have you tried the alternative to understand its benefits? I juggle between both, but I know that when I'm "just" writing the solution it feels that I don't fully understand the problem, even if I write a test after it. Then I know that my skill for writing tests first is not sharp enough yet. I still want to find a way to do that exploration through tests and not through solutioning, I'm sure I've read something like that from Bob Martin. BTW, any tips on that, Dave?
Working in small steps is my favorite on this list. It’s so hard to see the value in the moment, but when you look back on hours of work done and zero time spent debugging, to me that’s a very special feeling.
1. Good programmers spend time and effort in making their code clear. 2. Frameworks are not the core of our skills as professional software developers. Treat frameworks with a degree of care. 3. Design is the choices we make everyday when we write good code. 4. It is the shapes of the solutions that we create what really matters much more than the technologies we choose to implement those shapes. 5. Software development is a social activity. Good developers are also good comunicators: they can express an idea clearly, they can describe complex ideas to other people clearly. Collaborate with people. 6. Great developers are free with their ideas and usually open to having them criticized. 7. Make progress in small steps.
One that might be missing is having an eagerness to learn. That is learn about the problem your users are facing and why it matters to them, but also to learn about new technology and softskills like how to give good feedback. One could say that this skill is incorporated in other items you mentioned, but I thought it’d be worth mentioning more explicitly.
The article requested at 12:33 appears to be the below Published: December 1996 Social patterns in productive software development organizations Brendan G. Cain, James O. Coplien & Neil B. Harrison Annals of Software Engineering
Let’s not also forget that great programmers don’t have to know everything, but they have developed an ability and grit to dig into the problem, understand why something doesn’t work and come up with a solution while learning about this new topic on the way. Many programmers don’t become great because when they face a hard problem they either look for someone to solve it for them, look for a framework or even worse some kind of workaround. In the end they avoid tackling hard staff and never improve their skills. I think it’s not so much about knowing some language or framework but more about the aptitude. We always have to solve new problems, otherwise we would be just copy pasting code and calling it done. To come up with a great solution you need to not only to think how to make it work but also how it might fail. In the end every team hopefully has at least one person who can always figure out the answer even if he never faced that problem yet. Even greater programmers will communicate their process and decisions to the team to keep the information flow at the right level, be realistic with stakeholders and help others learn.
Part of solving problems in reality is using an existing solution or working around the problem. The first thing to do when encountering a hard problem is to find out if someone else has already solved it. Doing it yourself might serve as an interesting challenge, but not everyone has unlimited time and money to do it instead of spending time on solving something else. Probably something that is not hard programming, but more important to the outcome.
Liked for shirt. Now it's time to watch what will undoubtedly be a clever combination of stuff I've known for 35 years plus some insights I haven't considered. I always enjoy your videos, Dave. Your approach codifies and helps me enhance my own and I like that.
Hello, Dave. Thanks for the thoughtful video(s). It gave me a lot to think about in how I approach software development. At 6:38 you mentioned that you prefer lightweight frameworks that don't impose their design/architecture too much on the developer. Would you mind sharing a few examples of which kinds of these frameworks you tend to use? I'd like to explore them and try them out to get a feel for them. Thanks again!
I'm not Dave, but I have similar views so here it goes Light frameworks is just his personal preference, it doesn't mean that you cannot do the same thing with any framework. It's a matter of how you structure your journey, but either way, the goal is the same: to be in full control of your architecture and design at all times. The way you do this is by using only things you truly understand from your framework. If the framework is bigger, then you have to restrain yourself from using more features from it right at the beginning. With lightweight frameworks, you can move more freely. That being said, staying in control with any framework is rather an easy, mechanical task, once you get the hang of it. Most frameworks provide tutorials and templates on how to structure your projects with it. DON'T DO THAT! Instead, get a working example first until you learn a little bit of the framework, then remove it and start from scratch. Then do the directory layout for what will be a hexagonal architecture. It's like this: src/Domain/ src/Plugin/Ui/ Then do everything you can to contain the framework in that directory, and all your domain in Domain. Easy cheesy really. Make sure the domain is free of any libraries or frameworks. When necessary, introduce pure fabrications in the Domain as interfaces, and invert dependencies. Mechanical, simple, agile. You just use the framework as a (yet another) library.
This is the only point that I wasn't totally sold on. One example might be React vs Angular. React is less opinionated while Angular pushes it's way of doing things on you. But the flip side is that React doesn't provide nearly as many features. So what often happens is React teams spend more time researching JS libraries to prop up what React is missing. One might argue the complexity added through maintaining this outweighs the benefits of a less opinionated framework. I'm also not sure if a framework's updates forces your app to change. If there is a breaking change, don't update. And if something fundamental changes (like browser API becomes radically different) then you would have had to update your app in any case. There's a lot of wisdom in being cautious of frameworks, but like he said, the power of frameworks is often how they limit us, not how much freedom they provide
@@caleb5688 I think this more relatable to backend software which implements calculations or business rules, calculating taxes or hr rules for example, it makes more sense to isolate this business logic away from your framework parts, for example backend frameworks can give you several ways to access database , and those ways can differ based on framework, so, if the database access code was baked inside the business logic, things will get ugly if you need to change the framework, and you can't just reuse those business rules without taking the framework along with it. But for frontend and even some types of backend application I think it is mainly "wiring and routing" the data, which is mainly done by the framework, so, there is usually little to be isolated.
I think this is a good rule of thumb : if a framework forces you to extend/inherit its classes too much, is a red flag. Instead, if the framework asks you to implement interfaces is a good sign. Sometimes is hard to tell, because it could be that Implementing interfaces is what the framework really needs, but it also provide some base classes you can inherits for convenience. I think the first time I realized this was when I compared hibernate with a active record library.
On point 2 (Be cautious of frameworks), I find a great way of dealing with this is an application library model, rather than build your application within a framework, you just have simple calls to your actual implementation which is somewhere else. Yes the framework is still in control and at the top of the application, but that top is small and probably fairly trivial and replaceable. Although often times frameworks are meta-programming eager and even moving **my** code behind a function call will break the framework. Anything that prevents me from breaking up **my** code how I like gets a hard no from me.
One skill I've grown fond of (in the field of "coding as communication") is the ability of "thinking stupidly". If you can step back from the code, you have just written and can look at it, as if you knew nothing about the project (or were fast forwarded two months), you can discover parts of the code, you and everyone else would have big trouble to understand later on.
Thanks for listing these valuable skills in a succint way Dave. I think the ability to translate deep, abstract or ambiguous technical details to non-technical folks (as something easy to comprehend) is a super important skill. I've seen some developers do it by bringing simple examples and mixing with wit/jokes to make non-tech folks more engaged and they grasped it. That could be an extension/part of to the skills "code as communication" and "software development is a social activity" .
When people start to think about techs instead of design - is spot on. Most, even (pseudo-)professional people value frameworks and tech knowledge more than understanding and analysing the logic first.
"Programming as a social activity". This is so true. For example, after you've been working some time with microservices and especially if you can explore the landscape, as you cross urbanized areas, wild jungles, derelict, abandoned neighborhoods, both brutish and elegant forms of order, war zones, factories and playgrounds - in fact the absolute opposite of a clock's internals - and learn about (or mostly recognize) the inhabitants communities, it's hard not to end up looking at your job as a form of anthropology or sociology. You get a live reminder about the inherent violence of Nature, even if, just as in physical landscapes, sometimes in the middle of nowhere, you find a flower. It's interesting to observe that we conceive these virtual worlds in the image of the societies we live in, not necessarily as the one we would like to be a part of. This makes us more slaves than masters I guess. In any case, I.T. is no form of escapism !
Thanks Dave for leading these types of discussions and hopefully, us in a good direction. I ordered your book as well and can't wait for it to arrive. I've got 30 years in the business, my next chapter is coding/dev and will be the way I go out. I've danced around it, did some dev about 15 years ago before getting snagged on a completely unrelated paradigm (wish I stayed then). However, I know fundamentally learning syntax and language is but a small part of the job. I see it as an iceberg, with the choice of language being the part above the water... Great channel, incredible lessons. Thank you for sharing.
Little did I know this video hit literally at home for me, as an author of an Open Source framework for chatbots called Pyttman. Amazing how you made excellent points as to how locking in users isn’t the real goal with creating a pattern and constraints, but becomes a side effect of offering APIs which fails fast. I’m currently working on offering lighter options for situations where leveraging the Django-like pattern isn’t necessary or desired by the developer. This video just made me realize how important that is.
Thx for the book, going to read it. One of those rare cases, where the video is made not just to promote a book, but a genuine video on the topic and a genuine reference to the book, because it matters. Got to read Robert C. Martin books the same way.
Very useful! I liked the argument that design is part of the every day's work, also about thinking in terms of shapes. Dave, you are adorable in this t-short! Thanks a lot!
I think it is worth mentioning that one argument FOR frameworks is that they do impose certain limitations on what team members my try to do. We are all naturally curious and often try to bend the rules of what is possible. I've seen some really scary stuff written by others and myself. Like everything we do, there are no clear cut answers. There are tradeoffs. Personally, I would rather use a mature framework, however I agree that we should start layering our code so that sections of it can be transplanted, whole sale, into the next framework, when the time comes.
I'm also in favour of programming languages that put restrictions on the programmer. I've almost never needed the ultimate flexibility that some programming languages offer, but in my experience code can certainly benefit from forcing everyone into picking from very limited ways to do something. When we use frameworks we do try to have a layer that deals with the framework, but ultimately we view frameworks as a time and money saver now and if some future time should come when we need to change frameworks we'll deal with it then. The one thing I have experienced though is frameworks that impose such a burden to use that they end up costing more to use than just writing everything yourself. Unfortunately sometimes this is only discovered once it has been in use for a while.
Key points: Communication: The speaker emphasizes that coding is about communicating with other people rather than just computers. The readability of code is important as it saves time and money in the long run. Good programmers spend time making their code clear and communicative. Frameworks: The speaker cautions against relying too heavily on frameworks, as they can be ephemeral and may require significant rewriting if the framework changes or if the developer decides to switch to a different one. It's better to use frameworks that ask less of your code and allow you to retain full control over the programming model and structure of your code. Design: Good design is fundamental to coding and the choices we make when designing our systems help us compartmentalize problems and manage complexity. The speaker emphasizes the importance of focusing on the information we are dealing with and how we choose to apply organizing principles to the code we write. Quality over Features: The speaker emphasizes the importance of quality over features and the practicality of retaining the ability to make effective and efficient changes over the long term. He recommends adopting incremental approaches like continuous delivery and agile development to prioritize change after the first release. Communication in Software Development: The best software developers are good communicators and can express complex ideas clearly to others. If someone struggles to express their ideas clearly in conversation or diagrams, they may also struggle to write good code. Collaboration: The speaker emphasizes the value of teaching others and learning from their experiences, as well as collaborating with others on tasks and bouncing ideas off of them. He advises against becoming too attached to one's own ideas and being open to criticism. Small Steps and Test-Driven Development: Great programmers are able to hold complex ideas in their heads and make progress in small steps. The speaker discusses the importance of working in small steps and using test-driven development to make small changes and refactor code. Continuous Learning and Refinement: The speaker emphasizes the importance of continually exploring and refining solutions. He invites readers to share their own suggestions in the comments.
Hej Dave, Really enjoy your videos, thanks a lot for all the great content. Incase you run out of ideas on what to talk about: Recently I opened small pull request to apache kafka and I was really suprised to see so many flaky tests in the code base. I guess it is only natural that integration tests are hard to get right when testing a distributed system like kafka. With so many contributors it might not be possible for the gate keepers to spot every flaky tests in a pull requests. How could such a large open source project avoid such issues with minimal overhead?
About "Avoid ownership": In a recent job interview I was asked "You've been talking a lot about what *we* did so far. But what exactly did *you* do?" To me code is a team work.
Hello, Dave. Another great video! Thank you so much for sharing your thoughts. What you think about learning algorithms and data structures? Many big tech companies demand that in their interviews. I always criticized this way of evaluating a developer, because it reduces our capacities into one skill that seems to be less important compared to what you mentioned in this video. I'd be really amazed to hear your opinion!!
That method of interviewing reflects the fact that no-one has figured out a good way to interview programmers. Because it provides a fairly simplistic black and white measure it is attractive to companies. The problem with it isn't only that it doesn't reflect the work programmers really do, but that it is quite simple to game. Everyone I know spends some time practising and studying before they go to interviews. They're all good programmers, but such studying even allows people who can barely programme to get through a technical interview. A far better method I have encountered occasionally is one where the interviewer gives a problem to solve and then you work together to come up with a solution. I have even experienced an interview in which I had no idea how to solve the problem they posed, so the interviewer wrote out a possible solution. Then we talked about. I asked questions about why they had done certain things and started having ideas about other options. That's how real programming works in a team
I've often said that the main difference between a good programmer and a great programmer is that a good programmer will think of a way to code a solution to the problem and do that, while a great programmer will think of ten ways to code a solution to the problem and choose the one that best fits the needs of the task (which includes weighing criteria such as readability, efficiency, maintainability, etc.) Think beyond your first idea. Also, when interviewing programmers, my favorite question is a casual, "how did you get into programming as a career?" The people who give some form of the answer "I just f***ing love to program" have always been the greatest programmers, with the best appreciation for the art and science of quality coding.
Brilliant. I think you've possibly missed "growth mindset". The best I've seen are constantly learning and apply the TDD try, test, repeat methodology to many aspects of their career/craft.
For me, the "framework skepticism" is probably the number 1 indicator of mature developer expertise. For a reason that I still do not understand, many otherwise talented developers get attached to a particular framework and/or language and end up equating "high quality" with "high level of framework adherence". According to this view, the more a piece of code "uses the framework", the better it is. At the same time, this view considers that most problems: bugs, lack of quality, bad code, etc. arise from an inability to "use the framework to its 100% potential". Developers operating in this frame of mind often make the mistake of bending their code design to the constraints of the framework which is precisely the wrong thing to do. Ultimately, the goal of any software development project is to solve a business problem, and not to "program in a framework", so it really should be the other way around: elevate the business problem to the forefront, and use frameworks, libraries and tools to support the central design, but keep them at the edges of the system. This is why the "ports and adapters" (or hexagonal) architecture is so good: it puts the business problem at the centre and pushes away the frameworks, database access libraries and all other external concerns at the edges. Thus, a very simple test to figure out if a developer is mature is to ask them if they like the hexagonal architecture. If they answer "yes", then you're most likely dealing with a pro.
I have been guilty of complaining about bespoke solutions to problems that have a standard solution within a framework. There's some benefit to following conventions and to utilize the tools that you already bought into when choosing a framework. I like the points about portability and keeping as much of the code as possible platform agnostic, but that comes with some added responsibility to make sure the solution works well within the framework and that it is either obvious or well documented. Doing things your own way may be the better choice, but I think that it necessarily leads to a higher risk for bugs simply because you opt out of using a solution that is already being tested by countless people. What I'm saying is it needs to be paired with a quality mindset.
Planning for change in your code is the highest goal if you ask me. There are many ways to achieve this. Replaceability techniques e.g. factory method right through to data driven systems. Teasing out change cases from your users is key. If they are unsure, look to the past for pointers about cyclic behaviour in their business
Your first point, Code as Communication, is also my number one priority! If I can make the code readable enough, then I can reduce the need for comments. A pet hate of mine is variable/function/class/etc. names that have been abbreviated to the point of incomprehensibility. Maybe shortening names saved on bytes in the very old days, but it's pointless now! Stop being lazy and type out names using whole words! Another one for me is to write for legibility and maintainability, rather than speed. I'd often see a solution on Stack Overflow they thought was better because it was faster. I didn't care if my macros took 3 minutes to run instead of 2, they still saved someone a whole afternoon of work.
I agree, I've seen in the past loads of pointless commends in code e.g. //refresh the window.... Code line follows is "window.refresh();" -- Why the comment? the code tells you exactly what it's doing.
Good content Dave as always. 'Code is design', do you mean always follow domain driven design when coding? I believe this will also eliminate clutter and make your design almost mimick a functional programming architecture of some sort
That isn’t what I really meant, but it is true of my own code. What I really meant was coding is much more than syntax, it is about the structures that we create that help us to understand whats going on, and find our way around. In a similar way to the fact that writing is more than only spelling words correctly. Good developers are always thinking about how they organise their code, what goes where.
@@bra5081 exactly that bro, I perceived that Dave was talking about DDD since i think when you use it you eliminate writing what is called spaghetti code. Your code is clear in terms of naming variables and functions and also its purpose, I think a DDD approach assists in this regard. Perhaps my high level understanding of this concept is different from other ppl🙂
@@bra5081 I can give my answer to that. DDD aims to model the problem and so makes you think about separating the core behaviour of your system (its essential complexity) from the stuff that is necessary because it runs on a computer (its accidental complexity) so the code that is to do with order processing or flying your spaceship only focuses on that and the code that stores stuff in files or displays stuff on screens only does that. So each is less "cluttered" with other things that aren't its real focus. I talk about these ideas in more3 detail in my new book in the chapters on Modularity and Cohesion, including some code examples.
Dave, many projects end their life because they get outdated in terms of technology, legacy in terms of understanding of the code (one of the reasons is lack of gut tests). Do you have a video or do you plan a video to teach us how to keep the software relevant from a technical perspective (why not even from a business) in order to keep attracting programmers to work on it?
The point made at about 11:35 is a really interesting one that I never thought about, it's like a good time investment to go for quality because all the time its live one day will be time where it's benefiting from the quality that was put into it initially
I just barely stumbled upon your channel. Maybe it's confirmation bias but I like what your saying 😉. I'm going to recommend your book for my team to go through together.
Heavy-handed frameworks... the bane of my development life. The "Inversion of Control" (if I may use the term) by such Frameworks seems to cause more problems than it solves: 1. Getting started - requires (IMO) an unreasonable amount of pre-requisite knowledge about the Framework's "magic" ... 2. "Magic" - way too many things just happen by "magic", usually in a way that's non-standard to typical programming - until they break and then ... 3. Debugging & testing - usually Slow, and difficult to navigate and fix because ... 4. Configuration instead of code, and mysterious framework control - Flow of control is often required in obscure XML or YML or other configurations instead of code, where it could have been more easily navigated using IDE tools, debugged, understood, compile-time checked, etc.... Maybe I'm wrong about some of these points; and maybe all the costs, added up, are still out-weighed by the benefits - I certainly don't have data to prove it either way - but it sure doesn't feel like it a lot of the time.
Enjoying these videos immensely, and to be honest, coveting your t-shirts, are they single source or just from web surfing in your down time? **Re the social aspects of coding** : I think we all need to appreciate better that *_'Normal is a distribution'_* (from a poster at a University campus). Ultimately you have to find your tribe and being in the tails of neurological function distribution doesn't mean you're alone there. Probably marks you for having something unique to contribute in the right sort of team; you just have to go looking even if like me just playing on the wing, you'll get there.
Thank you for the "causious of frameworks"! I struggle with projects trapped in structure, having depencies down to the last bit of code. Enhancing, restructuring or migration is really hard. It's also extremely expensive in the long run. And uses Log4J! 🤣
Thanks, it is a tricky line to walk for UA-camrs, we get more views if we choose click-baity thumbnails and titles, but maybe send the wrong message to people looking for serious content. For an educational channel, like this one, we have to "play the YT game" to some extent, assuming that we want people to see our content, but we also don't want to be misleading. We try to walk the line between these two, and are willing to accept a certain level of compromise on how "click-baity" our titles are, as long as they accurately represent the content of the episode, but also we try to make sure that the content is interesting and useful, and never only sensational.
The approach to frameworks sounds like Hexagonal Architecture (or Clean A.). Working in small steps is huge, and I need to do better at that. Most of the rest is Agile manifesto stuff.
I would question you a little about “code ownership”. Not advocating disallowing others to touch code. But just that in many teams I feel there should actually be more emphasis on responsibility and perhaps a kind of ‘custodianship’ of code. It goes hand-in-hand with treating software as an investment. People will probably care more about that which they are invested in and where they have “skin in the game”.
I agree, but I think it functions best at the level of teams rather than individuals. The kind of "code-ownership" that I think is wrong is what I describe people who think their code is precious and won't change it themselves and won't allow others to change it. Great programmers, in my experience, treat code as "our best guess so far" and if anyone comes up with a better idea are pleased to change the code to reflect it.
Definitely not. It makes lots of assumptions and limitations on what and how you can do. It’s also based on magic rather than solid principles. My friend has to work with it and he keeps bringing these shortcomings to me every time. To really understand why Spring is so bad see how Functional Programming solves problems with well understood, decoupled and flexible patterns and compare to how spring bakes in some magical limited inflexible features. Cheers
Thanks Dave, very helpful! I have been working with Drupal based solutions, open-source and flexible, but I think the learning curve is steep, at least to me.
I like to be involved in the framework, but not committed to it. I think this is one area where Hexagonal Architecture/Ports&Adapters shines. I featured it in a presentation queued to Vendor Lock In here: ua-cam.com/video/aayl6FysZ_U/v-deo.html
1. Code As Communication
2. BE CAUTIOUS of Frameworks
3. CODE IS DESIGN
4. QUALITY OVER FEATURES
5. Software Development is a Social Activity
6. AVOID CODE OWNERSHIP
7. Work in small steps
cheer up
Bump
8. Work scientifically: Write a hypothesis - e.g. as an automated test. Then prove this hypothesis right or wrong. Then (this is important!) meditate about "Does my hypothesis suck?" - Repeat.
@@pinguwien i work more creatively and prefer to write the solution and then the tests second. I learn what to test while writing the solution, and don't have to guess and then iterate.
@@ytlongbeach have you tried the alternative to understand its benefits?
I juggle between both, but I know that when I'm "just" writing the solution it feels that I don't fully understand the problem, even if I write a test after it. Then I know that my skill for writing tests first is not sharp enough yet.
I still want to find a way to do that exploration through tests and not through solutioning, I'm sure I've read something like that from Bob Martin.
BTW, any tips on that, Dave?
Working in small steps is my favorite on this list. It’s so hard to see the value in the moment, but when you look back on hours of work done and zero time spent debugging, to me that’s a very special feeling.
1. Good programmers spend time and effort in making their code clear.
2. Frameworks are not the core of our skills as professional software developers. Treat frameworks with a degree of care.
3. Design is the choices we make everyday when we write good code.
4. It is the shapes of the solutions that we create what really matters much more than the technologies we choose to implement those shapes.
5. Software development is a social activity. Good developers are also good comunicators: they can express an idea clearly, they can describe complex ideas to other people clearly. Collaborate with people.
6. Great developers are free with their ideas and usually open to having them criticized.
7. Make progress in small steps.
I gifted myself your new book for Christmas, hope it arrives before the holidays. Really thx for sharing your knowledge.
One that might be missing is having an eagerness to learn. That is learn about the problem your users are facing and why it matters to them, but also to learn about new technology and softskills like how to give good feedback.
One could say that this skill is incorporated in other items you mentioned, but I thought it’d be worth mentioning more explicitly.
On a sidenote: I see a lot of nice typography and pretty animation work on the newer videos - good job on the design! Looks very good, keep it up!
Thank you very much!
And Dave's t-shirts are always awesome!
❤️
The article requested at 12:33 appears to be the below
Published: December 1996
Social patterns in productive software development organizations
Brendan G. Cain, James O. Coplien & Neil B. Harrison
Annals of Software Engineering
Thank you.
Let’s not also forget that great programmers don’t have to know everything, but they have developed an ability and grit to dig into the problem, understand why something doesn’t work and come up with a solution while learning about this new topic on the way. Many programmers don’t become great because when they face a hard problem they either look for someone to solve it for them, look for a framework or even worse some kind of workaround. In the end they avoid tackling hard staff and never improve their skills. I think it’s not so much about knowing some language or framework but more about the aptitude. We always have to solve new problems, otherwise we would be just copy pasting code and calling it done. To come up with a great solution you need to not only to think how to make it work but also how it might fail. In the end every team hopefully has at least one person who can always figure out the answer even if he never faced that problem yet. Even greater programmers will communicate their process and decisions to the team to keep the information flow at the right level, be realistic with stakeholders and help others learn.
Part of solving problems in reality is using an existing solution or working around the problem. The first thing to do when encountering a hard problem is to find out if someone else has already solved it. Doing it yourself might serve as an interesting challenge, but not everyone has unlimited time and money to do it instead of spending time on solving something else. Probably something that is not hard programming, but more important to the outcome.
Liked for shirt. Now it's time to watch what will undoubtedly be a clever combination of stuff I've known for 35 years plus some insights I haven't considered.
I always enjoy your videos, Dave. Your approach codifies and helps me enhance my own and I like that.
Hello, Dave. Thanks for the thoughtful video(s). It gave me a lot to think about in how I approach software development.
At 6:38 you mentioned that you prefer lightweight frameworks that don't impose their design/architecture too much on the developer. Would you mind sharing a few examples of which kinds of these frameworks you tend to use? I'd like to explore them and try them out to get a feel for them.
Thanks again!
I thought the exact same thing at that point of the video!
I'm not Dave, but I have similar views so here it goes
Light frameworks is just his personal preference, it doesn't mean that you cannot do the same thing with any framework.
It's a matter of how you structure your journey, but either way, the goal is the same: to be in full control of your architecture and design at all times.
The way you do this is by using only things you truly understand from your framework. If the framework is bigger, then you have to restrain yourself from using more features from it right at the beginning.
With lightweight frameworks, you can move more freely.
That being said, staying in control with any framework is rather an easy, mechanical task, once you get the hang of it.
Most frameworks provide tutorials and templates on how to structure your projects with it. DON'T DO THAT!
Instead, get a working example first until you learn a little bit of the framework, then remove it and start from scratch.
Then do the directory layout for what will be a hexagonal architecture. It's like this:
src/Domain/
src/Plugin/Ui/
Then do everything you can to contain the framework in that directory, and all your domain in Domain.
Easy cheesy really. Make sure the domain is free of any libraries or frameworks. When necessary, introduce pure fabrications in the Domain as interfaces, and invert dependencies.
Mechanical, simple, agile.
You just use the framework as a (yet another) library.
This is the only point that I wasn't totally sold on. One example might be React vs Angular. React is less opinionated while Angular pushes it's way of doing things on you. But the flip side is that React doesn't provide nearly as many features. So what often happens is React teams spend more time researching JS libraries to prop up what React is missing. One might argue the complexity added through maintaining this outweighs the benefits of a less opinionated framework. I'm also not sure if a framework's updates forces your app to change. If there is a breaking change, don't update. And if something fundamental changes (like browser API becomes radically different) then you would have had to update your app in any case.
There's a lot of wisdom in being cautious of frameworks, but like he said, the power of frameworks is often how they limit us, not how much freedom they provide
@@caleb5688
I think this more relatable to backend software which implements calculations or business rules, calculating taxes or hr rules for example, it makes more sense to isolate this business logic away from your framework parts, for example backend frameworks can give you several ways to access database , and those ways can differ based on framework, so, if the database access code was baked inside the business logic, things will get ugly if you need to change the framework, and you can't just reuse those business rules without taking the framework along with it.
But for frontend and even some types of backend application I think it is mainly "wiring and routing" the data, which is mainly done by the framework, so, there is usually little to be isolated.
I think this is a good rule of thumb : if a framework forces you to extend/inherit its classes too much, is a red flag.
Instead, if the framework asks you to implement interfaces is a good sign.
Sometimes is hard to tell, because it could be that Implementing interfaces is what the framework really needs, but it also provide some base classes you can inherits for convenience.
I think the first time I realized this was when I compared hibernate with a active record library.
On point 2 (Be cautious of frameworks), I find a great way of dealing with this is an application library model, rather than build your application within a framework, you just have simple calls to your actual implementation which is somewhere else. Yes the framework is still in control and at the top of the application, but that top is small and probably fairly trivial and replaceable.
Although often times frameworks are meta-programming eager and even moving **my** code behind a function call will break the framework. Anything that prevents me from breaking up **my** code how I like gets a hard no from me.
One skill I've grown fond of (in the field of "coding as communication") is the ability of "thinking stupidly".
If you can step back from the code, you have just written and can look at it, as if you knew nothing about the project (or were fast forwarded two months), you can discover parts of the code, you and everyone else would have big trouble to understand later on.
I'm very good at thinking stupidly. Maybe too good. ;)
Thanks for listing these valuable skills in a succint way Dave. I think the ability to translate deep, abstract or ambiguous technical details to non-technical folks (as something easy to comprehend) is a super important skill. I've seen some developers do it by bringing simple examples and mixing with wit/jokes to make non-tech folks more engaged and they grasped it. That could be an extension/part of to the skills "code as communication" and "software development is a social activity" .
When people start to think about techs instead of design - is spot on. Most, even (pseudo-)professional people value frameworks and tech knowledge more than understanding and analysing the logic first.
I finished your book, and just received the book you wrote with Jez. It i filled with the anecdotes and details I was hoping for.
"Programming as a social activity". This is so true. For example, after you've been working some time with microservices and especially if you can explore the landscape, as you cross urbanized areas, wild jungles, derelict, abandoned neighborhoods, both brutish and elegant forms of order, war zones, factories and playgrounds - in fact the absolute opposite of a clock's internals - and learn about (or mostly recognize) the inhabitants communities, it's hard not to end up looking at your job as a form of anthropology or sociology. You get a live reminder about the inherent violence of Nature, even if, just as in physical landscapes, sometimes in the middle of nowhere, you find a flower.
It's interesting to observe that we conceive these virtual worlds in the image of the societies we live in, not necessarily as the one we would like to be a part of. This makes us more slaves than masters I guess. In any case, I.T. is no form of escapism !
Thanks Dave for leading these types of discussions and hopefully, us in a good direction. I ordered your book as well and can't wait for it to arrive. I've got 30 years in the business, my next chapter is coding/dev and will be the way I go out. I've danced around it, did some dev about 15 years ago before getting snagged on a completely unrelated paradigm (wish I stayed then). However, I know fundamentally learning syntax and language is but a small part of the job. I see it as an iceberg, with the choice of language being the part above the water... Great channel, incredible lessons. Thank you for sharing.
YAATS - we love acronyms
Yet Another Amazing T-Shirt
Little did I know this video hit literally at home for me, as an author of an Open Source framework for chatbots called Pyttman.
Amazing how you made excellent points as to how locking in users isn’t the real goal with creating a pattern and constraints, but becomes a side effect of offering APIs which fails fast.
I’m currently working on offering lighter options for situations where leveraging the Django-like pattern isn’t necessary or desired by the developer. This video just made me realize how important that is.
Thanks, glad you found it helpful.
Thx for the book, going to read it.
One of those rare cases, where the video is made not just to promote a book, but a genuine video on the topic and a genuine reference to the book, because it matters.
Got to read Robert C. Martin books the same way.
Very useful! I liked the argument that design is part of the every day's work, also about thinking in terms of shapes. Dave, you are adorable in this t-short! Thanks a lot!
I think it is worth mentioning that one argument FOR frameworks is that they do impose certain limitations on what team members my try to do. We are all naturally curious and often try to bend the rules of what is possible. I've seen some really scary stuff written by others and myself.
Like everything we do, there are no clear cut answers. There are tradeoffs.
Personally, I would rather use a mature framework, however I agree that we should start layering our code so that sections of it can be transplanted, whole sale, into the next framework, when the time comes.
I'm also in favour of programming languages that put restrictions on the programmer. I've almost never needed the ultimate flexibility that some programming languages offer, but in my experience code can certainly benefit from forcing everyone into picking from very limited ways to do something.
When we use frameworks we do try to have a layer that deals with the framework, but ultimately we view frameworks as a time and money saver now and if some future time should come when we need to change frameworks we'll deal with it then.
The one thing I have experienced though is frameworks that impose such a burden to use that they end up costing more to use than just writing everything yourself. Unfortunately sometimes this is only discovered once it has been in use for a while.
Key points:
Communication: The speaker emphasizes that coding is about communicating with other people rather than just computers. The readability of code is important as it saves time and money in the long run. Good programmers spend time making their code clear and communicative.
Frameworks: The speaker cautions against relying too heavily on frameworks, as they can be ephemeral and may require significant rewriting if the framework changes or if the developer decides to switch to a different one. It's better to use frameworks that ask less of your code and allow you to retain full control over the programming model and structure of your code.
Design: Good design is fundamental to coding and the choices we make when designing our systems help us compartmentalize problems and manage complexity. The speaker emphasizes the importance of focusing on the information we are dealing with and how we choose to apply organizing principles to the code we write.
Quality over Features: The speaker emphasizes the importance of quality over features and the practicality of retaining the ability to make effective and efficient changes over the long term. He recommends adopting incremental approaches like continuous delivery and agile development to prioritize change after the first release.
Communication in Software Development: The best software developers are good communicators and can express complex ideas clearly to others. If someone struggles to express their ideas clearly in conversation or diagrams, they may also struggle to write good code.
Collaboration: The speaker emphasizes the value of teaching others and learning from their experiences, as well as collaborating with others on tasks and bouncing ideas off of them. He advises against becoming too attached to one's own ideas and being open to criticism.
Small Steps and Test-Driven Development: Great programmers are able to hold complex ideas in their heads and make progress in small steps. The speaker discusses the importance of working in small steps and using test-driven development to make small changes and refactor code.
Continuous Learning and Refinement: The speaker emphasizes the importance of continually exploring and refining solutions. He invites readers to share their own suggestions in the comments.
Hej Dave,
Really enjoy your videos, thanks a lot for all the great content.
Incase you run out of ideas on what to talk about: Recently I opened small pull request to apache kafka and I was really suprised to see so many flaky tests in the code base.
I guess it is only natural that integration tests are hard to get right when testing a distributed system like kafka.
With so many contributors it might not be possible for the gate keepers to spot every flaky tests in a pull requests.
How could such a large open source project avoid such issues with minimal overhead?
10:59 Dave: "Wave your hands around". Italian Me: "That will-a be easy-a"
About "Avoid ownership":
In a recent job interview I was asked "You've been talking a lot about what *we* did so far. But what exactly did *you* do?"
To me code is a team work.
Hello, Dave. Another great video! Thank you so much for sharing your thoughts.
What you think about learning algorithms and data structures? Many big tech companies demand that in their interviews.
I always criticized this way of evaluating a developer, because it reduces our capacities into one skill that seems to be less important compared to what you mentioned in this video.
I'd be really amazed to hear your opinion!!
That method of interviewing reflects the fact that no-one has figured out a good way to interview programmers. Because it provides a fairly simplistic black and white measure it is attractive to companies. The problem with it isn't only that it doesn't reflect the work programmers really do, but that it is quite simple to game. Everyone I know spends some time practising and studying before they go to interviews. They're all good programmers, but such studying even allows people who can barely programme to get through a technical interview.
A far better method I have encountered occasionally is one where the interviewer gives a problem to solve and then you work together to come up with a solution. I have even experienced an interview in which I had no idea how to solve the problem they posed, so the interviewer wrote out a possible solution. Then we talked about. I asked questions about why they had done certain things and started having ideas about other options. That's how real programming works in a team
I've often said that the main difference between a good programmer and a great programmer is that a good programmer will think of a way to code a solution to the problem and do that, while a great programmer will think of ten ways to code a solution to the problem and choose the one that best fits the needs of the task (which includes weighing criteria such as readability, efficiency, maintainability, etc.) Think beyond your first idea.
Also, when interviewing programmers, my favorite question is a casual, "how did you get into programming as a career?" The people who give some form of the answer "I just f***ing love to program" have always been the greatest programmers, with the best appreciation for the art and science of quality coding.
Brilliant. I think you've possibly missed "growth mindset". The best I've seen are constantly learning and apply the TDD try, test, repeat methodology to many aspects of their career/craft.
That term has become an annoying cliché.
This is the channel that I recommend the most to my junior fellows. Thank you very much for the great work, Dave!
Thanks for sharing my content!
For me, the "framework skepticism" is probably the number 1 indicator of mature developer expertise.
For a reason that I still do not understand, many otherwise talented developers get attached to a particular framework and/or language and end up equating "high quality" with "high level of framework adherence".
According to this view, the more a piece of code "uses the framework", the better it is. At the same time, this view considers that most problems: bugs, lack of quality, bad code, etc. arise from an inability to "use the framework to its 100% potential". Developers operating in this frame of mind often make the mistake of bending their code design to the constraints of the framework which is precisely the wrong thing to do. Ultimately, the goal of any software development project is to solve a business problem, and not to "program in a framework", so it really should be the other way around: elevate the business problem to the forefront, and use frameworks, libraries and tools to support the central design, but keep them at the edges of the system.
This is why the "ports and adapters" (or hexagonal) architecture is so good: it puts the business problem at the centre and pushes away the frameworks, database access libraries and all other external concerns at the edges. Thus, a very simple test to figure out if a developer is mature is to ask them if they like the hexagonal architecture. If they answer "yes", then you're most likely dealing with a pro.
💯😎
I have been guilty of complaining about bespoke solutions to problems that have a standard solution within a framework. There's some benefit to following conventions and to utilize the tools that you already bought into when choosing a framework. I like the points about portability and keeping as much of the code as possible platform agnostic, but that comes with some added responsibility to make sure the solution works well within the framework and that it is either obvious or well documented. Doing things your own way may be the better choice, but I think that it necessarily leads to a higher risk for bugs simply because you opt out of using a solution that is already being tested by countless people. What I'm saying is it needs to be paired with a quality mindset.
Gonna share this one far and wide. Thanks, as always, Dave
Awesome, thank you!
Planning for change in your code is the highest goal if you ask me. There are many ways to achieve this. Replaceability techniques e.g. factory method right through to data driven systems. Teasing out change cases from your users is key. If they are unsure, look to the past for pointers about cyclic behaviour in their business
Love your t-shirts
Yeah Dave you're going to have to start sharing where you're buying these lol
@@justice7ca245 I'd be broke if he opened up a store of the shirts he wears.
Awesome! Good way to close out the week! Appreciate all the thoughts shared
this resonates with me. it makes me even more interested in your new book. i'm not sure whether i should wait for some reviews
Your first point, Code as Communication, is also my number one priority!
If I can make the code readable enough, then I can reduce the need for comments.
A pet hate of mine is variable/function/class/etc. names that have been abbreviated to the point of incomprehensibility. Maybe shortening names saved on bytes in the very old days, but it's pointless now! Stop being lazy and type out names using whole words!
Another one for me is to write for legibility and maintainability, rather than speed. I'd often see a solution on Stack Overflow they thought was better because it was faster. I didn't care if my macros took 3 minutes to run instead of 2, they still saved someone a whole afternoon of work.
I agree, I've seen in the past loads of pointless commends in code e.g. //refresh the window.... Code line follows is "window.refresh();" -- Why the comment? the code tells you exactly what it's doing.
Dude! Cool shirt!!!!
Content is awesome as always!
Good content Dave as always. 'Code is design', do you mean always follow domain driven design when coding? I believe this will also eliminate clutter and make your design almost mimick a functional programming architecture of some sort
That isn’t what I really meant, but it is true of my own code. What I really meant was coding is much more than syntax, it is about the structures that we create that help us to understand whats going on, and find our way around. In a similar way to the fact that writing is more than only spelling words correctly. Good developers are always thinking about how they organise their code, what goes where.
@@ContinuousDelivery thanks for clarifying. 🙂👌🏽
What do you mean by DDD eliminates clutter?
@@bra5081 exactly that bro, I perceived that Dave was talking about DDD since i think when you use it you eliminate writing what is called spaghetti code. Your code is clear in terms of naming variables and functions and also its purpose, I think a DDD approach assists in this regard. Perhaps my high level understanding of this concept is different from other ppl🙂
@@bra5081 I can give my answer to that. DDD aims to model the problem and so makes you think about separating the core behaviour of your system (its essential complexity) from the stuff that is necessary because it runs on a computer (its accidental complexity) so the code that is to do with order processing or flying your spaceship only focuses on that and the code that stores stuff in files or displays stuff on screens only does that. So each is less "cluttered" with other things that aren't its real focus. I talk about these ideas in more3 detail in my new book in the chapters on Modularity and Cohesion, including some code examples.
Dave, many projects end their life because they get outdated in terms of technology, legacy in terms of understanding of the code (one of the reasons is lack of gut tests). Do you have a video or do you plan a video to teach us how to keep the software relevant from a technical perspective (why not even from a business) in order to keep attracting programmers to work on it?
The point made at about 11:35 is a really interesting one that I never thought about, it's like a good time investment to go for quality because all the time its live one day will be time where it's benefiting from the quality that was put into it initially
Truly great points! Every great developer I've known attends at least some, if not all, of those points.
Great video (and t-shirt!!) as always
that's a ligthing video , thank you. Also The t-shirt is awesome. how can we also have it ? Thanks.
"...unless you're doing something weird with quantum computers..." lmao Nice line. Quantum computers are, indeed, weird.
Yes, the ideas certainly scramble my brains.
Thanks for your videos!
This one resonated very well.
I just barely stumbled upon your channel. Maybe it's confirmation bias but I like what your saying 😉. I'm going to recommend your book for my team to go through together.
Heavy-handed frameworks... the bane of my development life.
The "Inversion of Control" (if I may use the term) by such Frameworks seems to cause more problems than it solves:
1. Getting started - requires (IMO) an unreasonable amount of pre-requisite knowledge about the Framework's "magic" ...
2. "Magic" - way too many things just happen by "magic", usually in a way that's non-standard to typical programming - until they break and then ...
3. Debugging & testing - usually Slow, and difficult to navigate and fix because ...
4. Configuration instead of code, and mysterious framework control - Flow of control is often required in obscure XML or YML or other configurations instead of code, where it could have been more easily navigated using IDE tools, debugged, understood, compile-time checked, etc....
Maybe I'm wrong about some of these points; and maybe all the costs, added up, are still out-weighed by the benefits - I certainly don't have data to prove it either way - but it sure doesn't feel like it a lot of the time.
Thanks for teaching us the Jedi ways, master Dave!
btw, I must admit that I'm jealous of your T-shirts :D
This is gold Thank you. I am learning to be one.
Pair coding is great, problem is when colleagues’ attention is always drifting away.
Dave, where do you buy your t-shirts?
Well done Dave! Very solid advice.
Enjoying these videos immensely, and to be honest, coveting your t-shirts, are they single source or just from web surfing in your down time?
**Re the social aspects of coding** : I think we all need to appreciate better that *_'Normal is a distribution'_* (from a poster at a University campus). Ultimately you have to find your tribe and being in the tails of neurological function distribution doesn't mean you're alone there. Probably marks you for having something unique to contribute in the right sort of team; you just have to go looking even if like me just playing on the wing, you'll get there.
Uncle Bob said that we should avoid frameworks in the heart of our software. This resonates with what Dave said about frameworks.
@Continuous Delivery: Please add chapters for easier sharing
You need to have a t-shirt store I would buy all of them!
I think it was a google study regarding 'best developers are good communicators'.
"Avoid Code Ownership" - now THAT is a great slogan to wear on a t-shirt!
Thank you for the "causious of frameworks"! I struggle with projects trapped in structure, having depencies down to the last bit of code. Enhancing, restructuring or migration is really hard.
It's also extremely expensive in the long run.
And uses Log4J! 🤣
Great information, but the background is both distracting and causes motion sickness to those of us who have a sensory input sensitivities.
Excellent video. Very well put. Thank you.
I love these lectures - I'm learning so much from you.
Glad you like them!
One thing that scares me most in any project is the lone developer - even if that developer is me.
Brilliant ! I ordering you newest book today.
Hope you enjoy it!
14:46 - Currently I'm a lone -"genius"- individual -"hacking"- programming away in a darken room
Nice to hear a positive video title
Thanks, it is a tricky line to walk for UA-camrs, we get more views if we choose click-baity thumbnails and titles, but maybe send the wrong message to people looking for serious content.
For an educational channel, like this one, we have to "play the YT game" to some extent, assuming that we want people to see our content, but we also don't want to be misleading. We try to walk the line between these two, and are willing to accept a certain level of compromise on how "click-baity" our titles are, as long as they accurately represent the content of the episode, but also we try to make sure that the content is interesting and useful, and never only sensational.
The approach to frameworks sounds like Hexagonal Architecture (or Clean A.). Working in small steps is huge, and I need to do better at that. Most of the rest is Agile manifesto stuff.
Yes, hex architecture is a good take on this.
I would question you a little about “code ownership”. Not advocating disallowing others to touch code. But just that in many teams I feel there should actually be more emphasis on responsibility and perhaps a kind of ‘custodianship’ of code. It goes hand-in-hand with treating software as an investment. People will probably care more about that which they are invested in and where they have “skin in the game”.
I agree, but I think it functions best at the level of teams rather than individuals. The kind of "code-ownership" that I think is wrong is what I describe people who think their code is precious and won't change it themselves and won't allow others to change it. Great programmers, in my experience, treat code as "our best guess so far" and if anyone comes up with a better idea are pleased to change the code to reflect it.
@@ContinuousDelivery You’re absolutely right, thanks.
This video convinced me to buy your book.
Thank you!
You are the best code mentor!
Am in love with your t shirt :)
That tee shirt is awesome!
Excellent advice.
As much as I am a fan of the Aliens and AvP universe, that T-Shirt scares me.
We are always racing to learn shiny, new expiring assets…
Hello Mr Dave Farley, please bring back the old gingle.
Code As Communication: I say, write code as a story of the system
I wonder if you think that the Spring framework fits into his definition of what a good framework would be.
Definitely not. It makes lots of assumptions and limitations on what and how you can do. It’s also based on magic rather than solid principles. My friend has to work with it and he keeps bringing these shortcomings to me every time. To really understand why Spring is so bad see how Functional Programming solves problems with well understood, decoupled and flexible patterns and compare to how spring bakes in some magical limited inflexible features. Cheers
This is so true.
So so helpful. thank you!
wow 😮. an absolutely incredible video.
is the kindle version of Modern Software Engineering readable on iOS ?
Yes.
Thanks Dave, very helpful!
I have been working with Drupal based solutions, open-source and flexible, but I think the learning curve is steep, at least to me.
Glad it was helpful!
Where could I practice coding with others?
Sir, if possible, please put timestamps in your videos.
4:03 be cautious of frameworks
Another great Tshirt
Nice shirt!
Mouseless is a good one too.
Cool shirt.
This video should have a timestamped breakdown of the 7 steps as part of its main comments and not left to a viewer to do :(
And that is how a GREAT Developer looks in his 30s
Fantastic video
Thanks! 😃
Cool stuff
... and I love that shirt.
How can we measure code readability?
Let your colleague from another project read it.
Wtf’s per minute
Nice advice. I open sourced my latest project to attract constructive criticism.
14:10 always happen to me 😆😆
I like to be involved in the framework, but not committed to it. I think this is one area where Hexagonal Architecture/Ports&Adapters shines. I featured it in a presentation queued to Vendor Lock In here: ua-cam.com/video/aayl6FysZ_U/v-deo.html