My WORST Mistakes as a Software Developer
Vložit
- čas přidán 27. 03. 2024
- Drop a database by accident? Write some horrible bug that caused all sorts of issues? Sure but that's not the one's that had the most significant impact on the code I write. The worst mistakes as a software developer are the ones that blinded my thought about how to write and design software.
🔗 EventStoreDB
eventsto.re/codeopinion
🔔 Subscribe:
/ @codeopinion
💥 Join this channel to get access to a private Discord Server and any source code in my videos.
🔥 Join via Patreon
/ codeopinion
✔️ Join via CZcams
/ @codeopinion
📝 Blog: codeopinion.com
👋 Twitter: / codeopinion
✨ LinkedIn: / dcomartin
📧 Weekly Updates: mailchi.mp/63c7a0b3ff38/codeo... - Věda a technologie
Want to learn more about software architecture and design? Join my newsletter!
mailchi.mp/63c7a0b3ff38/codeopinion
Mistake number 4: adding abstractions for abstractions sake. Usually those codebases contain lots of mappers and other conversion hoops without doing anything useful for the business.
Yup. Agreed. I've talked about that in videos explicitly about it. I was going to mention it in here but felt like I would be repeating myself a bit.
Agile, DDD, TDD, RESTful services, CI/CD, DevOps, ... the list of good, helpful concepts that are fundamentally misunderstood by many if not most people in the industry is long. I could complain about it all day but I don't have a solution ;) Thankfully, channels like yours exist that really explain some of these things.
I'll go off the rails one day about that entire list and semantic diffusion. I try and keep it together without losing it. 😂
About this 3-modes developers. I would add "don't care" developers at the same level as complain. The result is the same in both cases.
"this is fine" developers
@@georgehelyar "this is fine" implies that they at least spent a minimum time thinking whether the codebase is fine or not.
@@georgehelyar "this is fine" implies that someone at least spent a minimum amount of time to think whether the codebase is fine or not, while dont-cares just don't give a shit.
I see that in many places. They don't dig deeper. They just adopt whatever ideal solution they find under some pressure. Without understanding the pattern and its downsides. The misconceptions being spread in a handful article about it. The ideas must sink in and you need to explore in order to understand how to best apply it according to the context you are in.
I say this as someone who is working on my own projects.
What I'm looking for in a pattern is the best way to express my intent - to manage the complexity. By mapping concepts onto code in a way that is intuitive. And then iterate on it. That is an endless search since everything is changing with new tech and tools.
Working iteratively is something that is underrated, as well.
When it comes to foundational knowledge. Devs in the workplace tend not to talk about or share that knowledge. It is all surface-level. I have been in many places where Azure was fundamental. But people weren't into it. And when you are doing a task you, try to fix something according to some instructions, and you seldom have time to reflect about what really happens.
I think this creates unnecessary demand for specialization.
The first point is so spot on, and extremely relevant. The vast majority of content is produced by people with no clue what they are talking about. You channel stands on in that respect though. You clearly know what you talk about.
I think I'll share one mistake I've made in the past. The first time working with databases (relational databases), I wasn't taught how they worked. I'd seen some database code, and I expanded my knowledge by reading the documentation. As I was querying for data, I just though that by magic tricks, it would find the data I was querying for. But as we got more and more users, and each user produced more and more data, our system got slower and slower and slower. That's when I learned about indexes and execution plans :)
Absolutely, most of my failures have comes in the form of pain, just like you mentioned. Often in learning something new, really just scratching the surface without really understanding the underpinnings. "Hey everything works fine...", until it doesn't. But now you have a better idea of how relational databases work, regardless if its SQL Server, Postgres, MySQL. They all have different ways of dealing with things but at the core you get the gist of indexes and execution plans. Thanks for the comment.
I learned over time that it's best to look into the original concept first. There's too much misunderstanding, confusion, mixture etc. in secondary sources.
The second point is really good! Whenever I hear about a new framework or tool in the web space, my very first action is always to draw lines to existing technology or foundational knowledge. I want to at least have a rough idea of the moving parts. No need to know things in depth, but if I know that tech X is just Y with a new spin or abstraction on top of a specific feature, then I can have a much better mental picture of what I'm working with.
I have seen that when we teach to others in a formal way like a "career plan" we fail to force that learning of dig deeper, too many times it becomes something like, read, practice and then tell me and show me some evidence, but we don't know if they really know the "why". Good video!
"why not what" is often a motto I say.
"semantic diffusion" so much! I've heard people think that capabilities mean:
* Fine grained permissions (see posix, which carved this confusion in stone)
* Isolation, sandboxing
* Swizzling pointers to prevent memory corruption bugs (see apple Pointer Authentication Codes)
Capability systems are about how you express and exercise access, specifically, using the same concept for both. This tends to make them fine grained. It also makes it easy to give components exactly the authority they need. And while they can be used to protect memory and other hardware, statistical methods don't remotely meet the unforgability criteria. If you know, you know, I guess.
Excellent video! All those are recognizable
Great video
CQRS - Command and Query Responsibility Segregation becomes a way how to write code. But technically it just separation of reads and writes to db. Useful when you have master - slaves db architecture. I like what people call CQRS (DDD, Mediatr, commands and queries) - it makes code more readable, testable and maintainable. But It has nothing to do with what really CQRS is. Especially when you write and read only from 1 db instance, using same repositories and calling it CQRS.
An often missed concept in CQRS: The things needed to change the state of the system are often wildly different from the things needed to respond to questions (aka queries) about the state of the system. Models are only one aspect of "things" in both contexts.
I guess "semantic diffusion" is when people implement some term, but then tie it to that implementation. For example, thinking of DDD as only being possible within OOP when it is actually possible in all programming paradigms.
Confusion for sure or misinterpretation. I'd say the better example of Semantic diffusion is REST.
I wish I'd changed companies when I was stuck like that.
Thank god none of them was "making context King" 😅
Derek why do you say your CQRS diagram is incorrect? Could you tell me what's wrong with it?
He literally explains it... It's conflating multiple concepts together.
CQRS is just about separating the query (read) model from the command (write) model.
Queries and Commands can still use the same database and CQRS doesn't imply you HAVE to use events to synchronize data. Both of which are in the diagram he shows.
And documentation! Read and write!
Don't forget MVC
I thought you were gonna showcase actual mess ups like executing a wrong delete on a database, or doing something that actually costed your company some significant money or dev hours to fix.
This video does have useful information, but to be honest it does not deliver on the title.
Sorry it didn't meet the expectation. Although, I'm not really sure what the title could be other than what it is. It's is MY mistakes and what I think are the worst I've made. I can def make a video about some brutal technical ones but they pale in comparison to the overall impact and not by any means what I think are my worst.
We know the resources, scope and deadline... but we're 'agile'.
Are you a mind reader? 👀
Maybe?