Your format is good. In ten or fifteen minutes you manage to explain things clearly and calmly highlight both the advantages and disadvantages with each approach. LinkedIn “devposts” tend to be click bate designed to make people angry and/or eager to defend their javascript framework until their death.
Quite often people to push and promote unnecessary complexity are flashy middle managers who have little experience writing actual systems and think that complexity automatically mean a better system
@CodeOpinion , I've heard you express that idea before, and I'm glad to be honest. It'll keep you honest. :) But I think you have things worth saying, and I appreciate your channel. There is one thing that I wish you would do, though. I don't see a lot of references in your video descriptions to "upstream" sources. (When applicable.) I think it'd help prevent semantic diffusion if people did that more often.
Another great video Derek! Your analysis on the second case was "Sherlock Holmes" level, I couldn't see with my own eyes until you've pointed out the issues, after that it was clear as a sunny day. One idea for your videos over Linkedin, Twitter, Facebook, name your social media post is to make a Reaction series, "Reacting to SWE Hot-takes" or something like that, also theses kinds of videos can render tons of shorts ;D
I don't know of another industry where there's such a gap between what you learn in school (computer science, or some stripped-down version of it) and what you need to know to do your job. I understand why things are the way they are: software is almost infinitely malleable, and the industry is very new. We'll get there eventually, I hope. But in the meanwhile we, in the industry, should be focused (both individually and collectively) on collecting the wisdom and experience of the industry and weaving it into a unified theory of how we should be doing our jobs. Instead, what we have, to a large degree, is what you see on LinkedIn: we DDoS ourselves with "brand building" hot takes. It's a classic case of the Tragedy of the Commons.
Oh, and don't get me wrong: I think we undervalue computer science, but its relationship to software engineering is the same as physics to mechanical engineering: foundational and inadequate at the same time.
There are different computer degrees in college. For building web, mobile, windows apps and working with db's for businesses, "Computer Information Technology" or computer info sys degrees are the closest fit. Computer science is better fit for building OS, working for science and military orgs. More diehard. Beyond my capability. 😅
An academic setting just isn't a good place to learn software engineering. I think something similar to what tradesmen do where you have a few years in trades school then spend time in the industry as an apprentice would be much better
That’s a great quote by Alberto Brandolini you shared in the video, I wish I had learned the lesson about the pitfalls of design by entities earlier in my career. Thanks!
I really love the little turd piles concept. That's absolutely the point, isolate specific code and code paths related to specific actions that have the freedom to evolve independently of other specific actions. This in turn reduces coupling between the various unrelated actions. As far as the crud comment. There are many places where data entry type scenarios that happens in software applications this can be crud based activities. I'm thinking of crud as there is very little logic or rules around processing a request (maybe transaction script is more appropriate) Registering for a website and updating your profile might involve crud. Drafting a blog post is crud. Entering product details in an e-commerce scenario is crud. Most of these situations are not operating on or depend on "shared" data. Anyway, great video as always🎉🎉!🎉
Greg Young has talks about not building a big ball of mud, but instead build small balls of mud. Everything will end being a ball of mud, it is unavoidable. The diiference is, that a small ball of mud is still maintainable, or even better you can just delete it and rewrite in a sprint.
Why are people reading LinkedIn posts for recommended/best practices? Jeesh, it's like FB and news. It's social media. Use it for social stuff, and it's primary purpose of networking for job opportunities, but not as a trusted source for design best practices.
Thanks Derek! I liked the format. As always you bring us some clarification about some of these important concepts. I think that the challenge is really the process of discovering the behaviors in a new domain and not knowing if it's right or not. I have a question for you: What do you think its the main source of your knowledge about DDD and Software design in general? Is it from practice, books, articles, papers, or all of it?
Feature slice vs Domain capability. I never liked the first one unless you are building a UI. When I expose a micro-service though an API, this is singled context. No need to separate it in features.
based on the title, I was expecting a discussion about whether it's even useful to have technical discussions on LinkedIn - it just seems like entirely the wrong platform for that, for two reasons. (1) many (perhaps even most) of the people who would see your content are going to be non-technical, and therefore (2) the incentives for posting anything technical are all wrong. can you trust anyone posting anything technical on LinkedIn? are they really trying to help, or even have a serious discussion? or are they posting to profile themselves and look interesting to potential employers? these past few years, it's as though LinkedIn wants us to forget what it is - a professional network and hiring platform. now we're supposed to think it's a social media. it never really was, and the only reason they're trying to be, is because "more engagement good" for their investors. there are much more appropriate forums for technical discussions, where your future employer or your manager aren't watching to see if you look "smart". 🤨
Here's a good game. The next video I don't mention it explicitly, think about the root cause of what I'm talking about and see if it's coupling. It probably is, I'm not saying it :)
@@CodeOpinion Just started at a new company and honestly can't stop thinking about this. Everything is all about technology this, optimize that, refactor after refactor. But then I'm still like, but what depends on what and why? I wish to some day figure out the idea behind coupling lol
