John DeFalco, SR Software Engineer
June 9th, 2021

I’ve been a developer for over 25 years, working as a consultant for large and small companies. I knew quite a bit, had seen it all, and knew how to get my job done efficiently. At least that’s what I thought before I joined Strasz. The largest professional existential crisis I’ve had to face in my career was when I realized how much I didn’t know. Life kicked open the door to a vast room that I didn’t know existed. Fabulous. Imposter Syndrome, meet John. I had two options – continue along and close my eyes to reality or dust off my notebook, roll up my sleeves and start educating myself.

I’ve been a developer for over 25 years, working as a consultant for large and small companies. I knew quite a bit, had seen it all, and knew how to get my job done efficiently. At least that’s what I thought before I joined Strasz. The largest professional existential crisis I’ve had to face in my career was when I realized how much I didn’t know. Life kicked open the door to a vast room that I didn’t know existed. Fabulous. Imposter Syndrome, meet John. I had two options – continue along and close my eyes to reality or dust off my notebook, roll up my sleeves and start educating myself.

What follows are some of my thoughts and experiences over my 11+ year career at Strasz as I encountered many new concepts. I hope that in sharing these thoughts, you’ll gain insight into my own internal struggles and resistance to learning new things and the vast benefits of these technologies and techniques in enterprise software development. The overarching lesson is, opening your mind to new things and dedicating yourself to continuous learning is the only way to excel in this fast-moving industry.

One of the very first new concepts I was introduced to was eventual consistency. That’s funny. Why would I want to wait for my business data to be updated in a world of same-day shipping and fast food? No thanks – immediate consistency has never been an issue for me. Sure, it causes systems to be temporally coupled, but, OK, that isn’t going to fly. Well, customers definitely aren’t going to even consider waiting for their data to update. Oh, they will … and do. Hmmm, that’s interesting. But how can you achieve that?

We’re going to use messaging? I’ve never used it and never needed to. All these events flying around makes everything seem more complicated. Just do a RPC to System B from System A to tell it something has happened or get some data. What if System B is down or busy when I make my call? Well, how often does that happen? Oh, it does happen? And that means we can’t take a system down for maintenance, a release or any other reason? Yeah, I see the problem. More coupling, too, huh? If we adopt NServiceBus and RabbitMQ as a transport we can achieve decoupling, eventual consistency, and an event-based architecture that provides flexibility, resilience, and more. This intrigues me. What we’re really talking about are the methods in which use cases alter business data or state. So, where will all this data be stored?

In a What-SQL database?? NoSQL? Did you just make that up? You meant SQL Server, right? No?! What does schema-less mean? We won’t have to conform to a rigid table structure that frequently changes during development? Well, maybe that does sound kind of cool. But I’ve never heard of RavenDB. Who are they? Alright, I’ll take a look at it. Hmm, reads and writes seem pretty fast. And I don’t need mappers to translate persisted data to my Domain model, you say? Sign me up. Um, hold on, what’s a Domain Model?

Domain Driven Design? Here we go again. So many more things to learn – Strategic, Tactical, Event Storming, Entities, Value Objects, Aggregates. Why do we need all of these things? OK, so all of the business logic will be encapsulated into a series of objects with strict rules around consistency and concurrency. What was wrong with having logic in some classes over here, the database, some classes over there? Yeah, I see your point. That’s not very good. But the devs can still name the properties of these domain objects however we want, right? Hmm, I see how that would pose a challenge when speaking with subject matter experts. The good thing is that these rules are just dealing with the composition and content of the objects, but not how they are organized in our projects and solutions, right?

Layered Architecture? Presentation, AppService, Infrastructure, and Domain. Web and Workers up front serving requests. AppService handling use cases. Domain logic and state being manipulated. Infrastructure persisting, retrieving, interfacing, messaging. I suffer from what I like to call “functional OCD,” and this level of organization in the solution does feed into that desire for order. Sounds good! Alright, I’m winded by all of this fancy new server-side stuff, and I admit it’s all very neat. At least I have nothing new to learn in the UI.

Task-based UI? Look, the entire industry is based on CRUD. And we have lots of fields on our forms that we can easily save all at once by giving the user’s a big old save button. Well, sure, executing smaller, more discrete use cases and not submitting an entire form with 50 fields might be logical. And we can implement all of it with Javascript, TypeScript, and Angular? OK, OK, you know what? This is all very useful, organized, and cool but I’m pretty overwhelmed at this point.

Wait, you have one more thing? Good grief, go on. I don’t need to know all of it right now, but instead, we’ll learn it piece-by-piece over time? And we’ll master all of these things together, as a team? Hmmm, that’s certainly fair. OK, you’ve got yourself a deal!

This blog post is dedicated to the fantastic Development and QA teams at Strasz. They tirelessly push themselves to read, experiment, and learn. Through hard work and continuous learning, we choose to stay current with industry trends and techniques. Is it hard? I’m not going to lie; it is. But to quote the character, Jimmy Dugan, from A League of Their Own: “It’s supposed to be hard. If it wasn’t hard, everyone would do it. The hard is what makes it great.” Now get out there and start doing the work!

John DeFalco, SR Software Engineer
June 9th, 2021

I’ve been a developer for over 25 years, working as a consultant for large and small companies. I knew quite a bit, had seen it all, and knew how to get my job done efficiently. At least that’s what I thought before I joined Strasz. The largest professional existential crisis I’ve had to face in my career was when I realized how much I didn’t know. Life kicked open the door to a vast room that I didn’t know existed. Fabulous. Imposter Syndrome, meet John. I had two options – continue along and close my eyes to reality or dust off my notebook, roll up my sleeves and start educating myself.

I’ve been a developer for over 25 years, working as a consultant for large and small companies. I knew quite a bit, had seen it all, and knew how to get my job done efficiently. At least that’s what I thought before I joined Strasz. The largest professional existential crisis I’ve had to face in my career was when I realized how much I didn’t know. Life kicked open the door to a vast room that I didn’t know existed. Fabulous. Imposter Syndrome, meet John. I had two options – continue along and close my eyes to reality or dust off my notebook, roll up my sleeves and start educating myself.

What follows are some of my thoughts and experiences over my 11+ year career at Strasz as I encountered many new concepts. I hope that in sharing these thoughts, you’ll gain insight into my own internal struggles and resistance to learning new things and the vast benefits of these technologies and techniques in enterprise software development. The overarching lesson is, opening your mind to new things and dedicating yourself to continuous learning is the only way to excel in this fast-moving industry.

One of the very first new concepts I was introduced to was eventual consistency. That’s funny. Why would I want to wait for my business data to be updated in a world of same-day shipping and fast food? No thanks – immediate consistency has never been an issue for me. Sure, it causes systems to be temporally coupled, but, OK, that isn’t going to fly. Well, customers definitely aren’t going to even consider waiting for their data to update. Oh, they will … and do. Hmmm, that’s interesting. But how can you achieve that?

We’re going to use messaging? I’ve never used it and never needed to. All these events flying around makes everything seem more complicated. Just do a RPC to System B from System A to tell it something has happened or get some data. What if System B is down or busy when I make my call? Well, how often does that happen? Oh, it does happen? And that means we can’t take a system down for maintenance, a release or any other reason? Yeah, I see the problem. More coupling, too, huh? If we adopt NServiceBus and RabbitMQ as a transport we can achieve decoupling, eventual consistency, and an event-based architecture that provides flexibility, resilience, and more. This intrigues me. What we’re really talking about are the methods in which use cases alter business data or state. So, where will all this data be stored?

In a What-SQL database?? NoSQL? Did you just make that up? You meant SQL Server, right? No?! What does schema-less mean? We won’t have to conform to a rigid table structure that frequently changes during development? Well, maybe that does sound kind of cool. But I’ve never heard of RavenDB. Who are they? Alright, I’ll take a look at it. Hmm, reads and writes seem pretty fast. And I don’t need mappers to translate persisted data to my Domain model, you say? Sign me up. Um, hold on, what’s a Domain Model?

Domain Driven Design? Here we go again. So many more things to learn – Strategic, Tactical, Event Storming, Entities, Value Objects, Aggregates. Why do we need all of these things? OK, so all of the business logic will be encapsulated into a series of objects with strict rules around consistency and concurrency. What was wrong with having logic in some classes over here, the database, some classes over there? Yeah, I see your point. That’s not very good. But the devs can still name the properties of these domain objects however we want, right? Hmm, I see how that would pose a challenge when speaking with subject matter experts. The good thing is that these rules are just dealing with the composition and content of the objects, but not how they are organized in our projects and solutions, right?

Layered Architecture? Presentation, AppService, Infrastructure, and Domain. Web and Workers up front serving requests. AppService handling use cases. Domain logic and state being manipulated. Infrastructure persisting, retrieving, interfacing, messaging. I suffer from what I like to call “functional OCD,” and this level of organization in the solution does feed into that desire for order. Sounds good! Alright, I’m winded by all of this fancy new server-side stuff, and I admit it’s all very neat. At least I have nothing new to learn in the UI.

Task-based UI? Look, the entire industry is based on CRUD. And we have lots of fields on our forms that we can easily save all at once by giving the user’s a big old save button. Well, sure, executing smaller, more discrete use cases and not submitting an entire form with 50 fields might be logical. And we can implement all of it with Javascript, TypeScript, and Angular? OK, OK, you know what? This is all very useful, organized, and cool but I’m pretty overwhelmed at this point.

Wait, you have one more thing? Good grief, go on. I don’t need to know all of it right now, but instead, we’ll learn it piece-by-piece over time? And we’ll master all of these things together, as a team? Hmmm, that’s certainly fair. OK, you’ve got yourself a deal!

This blog post is dedicated to the fantastic Development and QA teams at Strasz. They tirelessly push themselves to read, experiment, and learn. Through hard work and continuous learning, we choose to stay current with industry trends and techniques. Is it hard? I’m not going to lie; it is. But to quote the character, Jimmy Dugan, from A League of Their Own: “It’s supposed to be hard. If it wasn’t hard, everyone would do it. The hard is what makes it great.” Now get out there and start doing the work!