- 👋 Hi, I’m @MagicShel
- 📆 I have 30 years of experience
- 👀 I’m interested in Java, Spring, NodeJS, TypeScript, Angular, Python, AI
- 🌱 I’m currently learning cloud-specific concerns
- 📫 How to reach me:
- email: gforb-github@yahoo.com
- blog: https://paper.wf/magicshel
- bluesky: https://bsky.app/profile/magickshel.bsky.social
I'm a software team lead with 30 years of experience. My current technical focus is on microservices with Java / Spring. I've also dabbled in .NET, NodeJS, a lot of front-end Javascript and CSS, though I'm a much bigger fan of TypeScript. I've largely stepped away from front-end and full-stack work to focus on architecture and back-end engineering. I'm also an AI enthusiast with plenty of experience on what works and what doesn't.
I've been a contractor/consultant for most of my career. I've worked with city governments, federal government/military, hospitals, manufacturing/industrial, retail, property management, financial/banking, construction, and probably some fields I've forgotten.
I started out with Lotus (later IBM) Notes and transitioned to X-Pages (JSF) and from there to Java, which has been my primary focus for about 20 years now. I'm primarily self-taught through books, blogs, conferences, YouTube videos, and simple experimentation.
I've worked with a lot of bad code. In my early days, it was often mine. I'd write something I thought was particularly good and then turn around and find myself burdened by the limitations, and it took me years to figure out why. I had to discover SOLID principles, dependency injection / inversion of control, immutability, functional programming (specificially the concept of pure functions), separation of concerns, design patterns and unit testing. This is an area where I'm continuing to expand my knowledge and experience. I've learned the importance of expressing and understanding architectural intent to avoid getting caught in anti-patterns.
I like to create and use code that is well documented and unit-tested. Naming of things is very difficult, but also very important. There is a lot of precedent and guidance on best-practices out there for anyone who goes looking, but few do. Code should be easy to read. Things should be done in consistent patterns where possible and documented when established patterns are poorly-suited. Where readability and performance are at odds, it is important to separate / abstract that complexity so that it doesn't need to be thoroughly understood by every developer who touches the code. Instead, that complexity should be walled-off and well documented.
My goal with software is to make a product that considers the needs of all users, not just managers and analytics. That means a good UX that doesn't require unnecessary steps to navigate. I means fast response times so users aren't watching a spinner while the sevice is overloaded. And importantly, it's not just a front-end consideration.
Just like user-facing applications must be useable, so with APIs and contracts. Limit the ways complexity can be interfaced with so that it can't be misused.