Boundaries with guest James Hickey
Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis.
This is episode 58, on the concept of boundaries, with guest James Hickey.
Boundaries
This week's tip is brought to you by devBetter.com.
Sponsor - devBetter Group Career Coaching for Developers
Need to level up your career? Looking for a mentor or a the support of some motivated, tech-savvy peers? devBetter is a group coaching program I started last year. We meet for weekly group Q&A sessions and have an ongoing private Slack channel the rest of the week. I offer advice, networking opportunities, coding exercises, marketing and branding tips, and occasional assignments to help members improve. Read some of the testimonials on devBetter.com and see if it sounds like it you might be a good fit.
This week we have our first returning guest, James Hickey. James was on the show earlier for episode 48 on how to accelerate your career. This week, he's back to talk about boundaries withing software systems. James is a software developer working remotely in eastern Canada. He's recently written a book about keeping your code clean called "Refactoring TypeScript" (https://leanpub.com/refactoringtypescript). He's also the author of an open-source .NET Core library called Coravel, which provides advanced capabilities to web applications. Welcome back, James!
Boundaries
Hi! I'm James Hickey.
I'm a software developer working remotely in eastern Canada.
When I started my career as a software developer I was thrust into a large codebase for a SAAS that helped automotive manufacturers perform analytics on their financial data.
The way the codebase was organized is probably familiar to most developers - especially those with a background in enterprise-y companies. The solution was organized into 3 main projects: business, DAL (data-access), and "core" (which was just a bunch of classes having no business logic full of public getters and setters).
At the end of the day, all the real business logic was mostly found within stored procedures in the database. So, all those layers didn't serve any real purpose. Business-oriented classes would just call a function from the DAL layer, and that method would call a stored procedure.
As a fresh-out-of-school developer who's trying to learn "how the pros do it", I didn't question this way