Software Engineering Blogger

OWNING your sandbox. As software engineers we all like to work on latest technology and coding new applications. People generally don’t like spending a lot of time maintaining the code. However, in the world of microservices the owners of each microservice are very well known and defined unlike in the world of monolithic applications. That means that you own it in the true sense. You own the code. You own the QA environment. You own the Stage environment. You own the production environment and all the errors that come along with it :) On positive note, you have a lot to be proud of and you can turn it into opportunities :) You own something that is contributing your company’s customers and what you do responsibly affects the lives of many people in a positive way. Almir Mustafic

10,000 foot level view in technology: How useful is it? What can be done at this level? If the 30,000 foot level is the CTO level, then consider the 10,000 foot level as the level that software engineering managers and directors operate at. To achieve the success at 10,000 foot level, you as a software engineering manager need to dive deep into technical details, help the team lay the foundation from BOTH organizational and technical side. It is the little moves that get the team to this level. Once the team’s applications and results at that level, then you as a manager have ability to perform the high level analysis and troubleshooting without necessarily being in code on daily or weekly basis. Therefore, your ability to troubleshoot technical issues at the 10,000 foot level is a testament to the great work of your team. Go TEAM !! Almir Mustafic

Doing software development from bottom up when you need to or is this a norm? If somebody asked you to first build the wheels for the car before having the car at all, what would you do? First, I would question if I need to design/build 4 lug or 5 lug wheels. Then I would need to predict or ask about some details to figure out the proper offset and width for the wheels so they don’t stick outside the fenders. Now how does this car analogy apply to software engineering? First, you need to know and define the API contract. Then you would probably build a stub or mocked version of your API and you would put yourself in the shoes of the client trying to use it in cases that you can predict. Depending on the performance requirements, you may end up adding caching and other improvements. This approach is actually not that uncommon. This is actually how you would approach your team to team and microservice to microservice dependencies regardless of how well you know your consumer; it i...

SERVICE NAMES, BOUNDARIES (domain lines) and API DEFINITIONS/STANDARDS are some of many important things to achieve the enterprise-level microservice architecture and microservices. Names mean things. So you first need to properly name your services and that’s the names that you would use when talking to your teammates and clients of your services/APIs. I have a separate article on how you go about defining what a microservice is. That's titled "Micro in Microservices" on my site almirsCorner .com. Essentially, you need define the purpose and boundaries of your service. Then you get into API routes and properly defining them for each service. The goal is to keep the routes RESTful and if you run into the situation when they are not, then it should trigger you to revisit the purpose and boundaries of that given microservice. Maybe that service needs to be split into smaller services. Thank you for reading this. Almir Mustafic