Software Engineering Blogger

I have been blessed in my software engineering career with great leaders. Some of them challenged me in technical skills. Some of them challenged me in my organization and leadership skills. Some of them challenged me in both. And all of them made me a better software engineer, a better senior engineer, a better solutions architect, a better teammate, and a better leader. If you are a student, find yourself a mentor. If you are a junior software engineer, find yourself a mentor. If you are an experienced software engineer, find yourself a mentor. Remember, you write your own definition of success and you are your own critic. That may mean that you TRY to perfect every stage of your career, or that may mean that you skip some stages in your career. Remember, you are in control. That’s all I wanted to say today :) Keep geeking out. Almir

Re-factoring vs. Re-Writing? A lot of times we heard the talks about “Never be satisfied” in the context of innovation and driving your teams forward. In that context, this is totally fine, but when this mindset gets blindly used in the software engineering low level details, then you could be constantly  re-writing  code without taking the effort to truly understand it. Is this the right thing for business? Is it costly? Re-factoring  means that you took time to understand what you have, and you are improving it. On the other hand,  re-writing  does not necessarily mean that you took the time to understand the low-level details; it may mean that you went back to requirements and decided to re-write it without trying to understand the low-level details. There could be something in those details that you need to know so you don’t make the same mistake again in the process of re-writing it. At the end of the day, if you are constantly re-writing code, then there is no sense of

You may be wondering what the Daylight saving time has to do with a software engineering state of mind. When thinking about writing this article, at first I thought to start with the following joke and I am: “ Did you know that the Daylight saving time was started because a software developer coded a function that does smart timezone and configurable calculations and then this developer created a problem to solve to use the algorithm; hence, the Daylight saving time was born. ” This is a joke, but  on a more serious note , this brings me to a state of mind in software engineering that make this joke a reality to some degree. How many times did we find ourselves in situations where we learned something new in programming and we looked for ways to apply it at any cost? How many times did we see a cool new feature from a creator of a framework and we decided to use it even though that was not the right solution for the problem or maybe there was no problem to solve in the firs

Here are very simple security tips for your Windows personal computers. 1. Create a standard or limited windows user and  use this user from this point on . 2. Install Microsoft Security Essentials. You will be prompted the admin password. Turn on the firewall and run a scan. 3. Use non-native browser for your OS. You can either go with Firefox or Google Chrome. 4. For your choice of non-native OS browser, think about installing some smart Ad blockers that are fair to good advertisers and properly block intrusive advertisers. 5. Buy a packet USB drive and do a cold backup of your files to USB once a month and keep a copy of this in a house and another copy outside your house (family house or friends house or even at work). 6. Pick a secure password manager solution and use it. Never allow browser to save the passwords locally because that is not as secure as dedicated password management solutions such as: 1Password, LastPass, KeePass and others. Almir Mustafic.

Imagine a software engineering world in which you measure the value your teams deliver with almost ZERO burden on your teams in terms of spending time to enter information correctly ! If the teams are worried and constantly thinking about being measured, then we are not doing it properly. It is very possible to measure without putting a burden on your team. This is where I stand for the first item in the agile manifesto that states: “Individuals and interactions OVER processes and tools”. For me the number #1 thing is to have the team reach that point at which you look at each other and you know you have the momentum, quality and product value and it’s fun doing it. Then the number #1 thing is to ride this momentum wave as long as you can with fine-tuning adjustments from sprint to sprint and stop any influences where the first item of the agile manifesto would be jeopardized. Yes, I know that a lot of companies are regulated and you need the processes for auditing purpose

I have been at my current company long enough to get too comfortable, but is that the case? The years I have spent in my current job feel very much like 3–4 jobs. First, it is natural for a company to go through different types of leaderships roughly every 4 years. On top of that, there is the technology aspect and its changes over the years, and different types of projects I have been part of. All of these things painted a picture in my head as if I changed jobs 3–4 times, and in fact I have been with the company slightly over 12 years. What is the secret to still getting “New Employee” jitters every week even after being with the company for so long? (1) Don’t wait for your leaders to challenge you. You need to challenge yourself from week to week. (2) You need to care. (3) Appreciate what you and your team accomplished, but never be fully satisfied. Look at this from a positive angle. Look at it as an opportunity. (4) Don’t judge somebody else’s engineering efforts that

TROUBLESHOOTING production issues and Splunk log analysis: This skill is not something you can gain over night. It is a skill that you improve by being in tough and under pressure situations. Then over years you end up painting this whole scheme in your mind on how to approach problems. It almost becomes the second nature to you. I strongly recommend it to all software engineers. Yes, we all like to be working on new code and writing new applications, but the 10 lines of code that you write will be so much better because you were in the shoes of troubleshooting production issues and you will consider things that other developers will not. Don’t think of troubleshooting production issues as a downgrade in your career. I’d like to think of it as a necessary step in completing your software engineering skills and graduating. At the end of the day, if we write code, we should be maintaining that same code to appreciate the value of it. If that code is not stable, it is in our intere

Relationship that is based on focusing on results and then strengthening it as you taste success together after some tough times. OR Relationship that is established with relationship in mind first without focusing on results as the primary catalyst. There are leaders in both sides of the camp depending on your professional leadership style you may gravitate towards one of these a bit more. Process is the third driver in the picture and some leaders tend to gravitate towards this. Understanding or having this topic formalized is a good step forward for a leader in this fast-paced world where we need to learn every day. I recently attended a leadership workshop that formalized a lot of this. The name of the workshop was “Facilitative Leadership” and it covered much more. Thank you for reading this article. Almir Mustafic

Process is good to protect your end customers. When people say they don’t like the process, they don’t really mean that they don’t like the steps in the process, but rather they don’t like how these steps are streamlined. The process should be streamlined to encourage us to launch more often and to launch smaller increments instead of making us bundle things. When it takes a long time to get things approved, the approval process could be very centralized. What microservices may improve with natural de-centralization, a centralized process may undo in terms of agility and speed. To de-centralize the approval process, tech leaders on the floor could be ITIL certified and act as approvers; with that permission comes responsibility. The ultimate goal would be that the same number of steps would be executed in the process, but the steps would be much quicker and streamlined in a more enjoyable fashion. The end goal is to keep the end customers satisfied and to pass all the audits.

Difference between providing requirements and giving implementation details ? Here is a metaphor for this: Can you increase the power of the engine vs. can you make the car go faster? Which one of these is a true requirement coming from the overall car product manager and which one is an implementation detail? We can definitely make the car go faster by increasing the power of the engine, but it depends how much faster you want to go. For example, we can instead put some lightweight wheels on the car and it will definitely go faster because we are reducing the inertia. Or if it is about going faster on a track doing multiple laps, then adding better brakes will also make you do faster laps. So asking us to make the engine more powerful is not necessarily a requirement but rather an implementation instruction. You can now apply this in software engineering and as a software engineer please truly understand the requirements and if they are not requirements, ask for them. It

* My work accomplishments * Blogging * YouTube software engineering series Almir

AWS CodeStar service ?? AWS launched two new important services: * AWS CodeStar * AWS Cloud9 IDE After AWS Re:Invent, I spent some time setting up AWS Cloud9 service. I was a user of Cloud9 before Amazon acquired them. I really like the IDE and I was wondering how it integrates with the rest of the AWS services. Then I did some more learning and setup and here are the results: You can use  AWS CodeStar  service as an orchestrator/workflow that allows you to: (1) Code an application (different templates with different languages) using AWS Cloud9. (2) Manage the source code via AWS CodeCommit. (3) Deploy it using AWS CodeDeploy. All of this is managed through the AWS CodeStar dashboard. As part of creating a project within AWS CodeStar, I had an option to set it up with just one EC2 or with Elastic Beanstalk. For simplicity I chose the EC2 flavor and successfully deployed the “Hello World” Python Flask application using AWS CodeStar. After I deployed the initial ve

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

AMAZON WORKSPACES. I am not sure how many of you have heard of Amazon WorkSpaces. Let me give you some information and my analysis after using it for some time. What is it? It is the Amazon’s solution to desktops in the cloud. What’s the point? Well, if you want to use a basic less powerful laptop or even use a Chromebook as your daily computer, then you will not be missing the full functionality of a powerful Windows 10 machine. For example, you can use your Chromebook to connect to your Amazon WorkSpace machine and then you get the full Windows 10 experience. The point is that it gives you the experience as if your remote/workspace Windows 10 machine is really part of your Chromebook. Where it makes the most sense is using Chromebooks to connect to your Amazon WorkSpace machine as Chromebooks with Chrome OS are fast for anything you do in the browser and they are very secure; Chromebooks are also generally cheaper than other laptops. Just a thought as an alternative to buying ful

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

ARCHITECTURE DIAGRAM representing interactions of your family of microservices is one of many important things to achieve the enterprise-level microservice architecture and microservices. After going through the design and contract definitions of your APIs/microservices, your team needs to put together a single diagram that explains the interaction among microservices (owned by your team) and how these microservices interact with other teams’ microservices. This is basically the blueprint for your team’s work and this picture needs to be constantly updated as you are evolving your services. What does this give you? It gives you the big picture view and it allows you to detect good or bad patterns that you cannot see when you are deep in your code. For example, you may be able to see that you are doing too many direct API calls for something that could be done with pub/sub approach. Almir Mustafic

Microservice Architecture, but NOT microservice mindset? We are on the same team! Let's say we as a company decide to implement the microservice architecture and we also decide to split the teams into domains for each team to own a domain (group of microservices). You may be a member of team A and I may be a member of team B and we are all on the same ship. There is a water leak in your area of the ship, but my side of the ship looks good.  What do we do? Let's help out each other because we are all members/passengers on the same ship. We are all going to the same destination :) Microservice teams were created to pave domain boundaries at the architectural level, but it does not mean that we should create boundaries among members of different domain team members. Yes, the API contracts are definitions for how our services communicate, but for the sake of final destination, we need to tear down those boundaries when it comes to approaching each other for help and proacti

Python-like or C-like as the language to introduce programming to students in high school and university? The question is: Do you introduce programming concepts to high-school/university students using languages that handle memory and other things for you or do you start introducing all of these concepts in languages like C that require you to understand all aspects. I will tell you what worked for me. I was introduced to programming in grade 10 using Basic programming language. There was a version called Better Basic and also Quick Basic. Then in grade 11 we learned procedural programming in a programming language called Turing (not Turing machine but a Pascal-like language developed by University of Toronto for teaching purposes). Then a year later, I started getting interested in C and C++. As you can see, I eased into the languages that introduced me to NULL exceptions and memory leaks :) With this approach I was not overwhelmed and this set up the foundation for a fun journey

Language of software engineers and skills of scrum-masters? All software developers speak the same language and that is pseudo-code :) However, there are still communication issues among software engineers specifically with other teams. That's where the role of great scrum-masters fits in. That great scrum-master does not necessarily need to be technical but he/she needs to have the skills of hearing roadblocks that engineers communicate in their technical language. I said "hearing" and hearing is not the same as listening. Listening is just a pre-requisite for hearing. Once you hear it, now you need to know how to action it and mobilize the right people. Coaching comes along with all of this, but that is a separate topic because it is also a responsibility of the tech manager. These skills separate great scrum-masters from others. Almir Mustafic P.S. Disclaimer: On any given day, I wear a hat of a solutions architect, engineer, scrum-master and tech manager.

Introducing bugs in your software applications? If you are a software engineer and you introduce a bug in your application, it might not be that bad. Let me explain. The best bug you can introduce by accident is the one that fixes/heals an existing more serious problem and introduces a minor problem :) It is all about incremental improvements :) Almir Mustafic

NoSQL? If you are developing your applications for real-time interactions using NoSQL, you still need to pay attention to your data structure even though your database does not enforce it. Your model classes in your choice of programming language are your contract because that NoSQL data has to eventually end up into some form of relational database when you decide to report on it. Almir Mustafic

Authenticity - Step back and think about what makes projects successful; it is not all metrics looking good; it is about intangibles that you can't measure. It is the authenticity of certain individuals, their approaches, and how they let their energy radiate within the team. Recognizing their authenticity is the key to success. Almir Mustafic

Programming is an act of giving a machine some instructions so it can perform things repeatedly. Software engineering is an act of programming and everything else that goes along with it in order to deliver enterprise software to production. Within software engineering, the more time you spend coding your applications and less worrying about DevOps things and processes, the better for you. Make sure you are heading in the right direction. In conclusion, if the act of software engineering was close to the act of programming, then you basically reached that ultimate point in developers’ eyes. Wasn’t the original goal of cloud computing to abstract things for developers so you can ideally only focus on writing code? Almir Mustafic

Software Engineering — Building layers of the cake instead of slices of the cake. In software development you could go into separate rooms and build slices of a cake and combine it all into a single cake hoping to have a good cake. The following alternative is better. Build layers of the cake and that will naturally lead itself to early integrations, early visibility to software functionality from the product management and the end user point of view. Isn’t this what agility is all about? Almir Mustafic

Design for Plan A or Plan A+B? Should you design your system with defensive Plan-B mindset or should you keep it simple thinking optimistically? I don’t think the answer is yes or no. I am talking about the case where you prefer plan A, but the confidence level is not there yet. I think you can design it clean and simple with with hooks in your code so you can harness or feature toggle the plan B functionality. If plan A is chosen then all you need to do is clean up the hooks for the harness or feature toggle that was not needed. Nothing to lose, but you need to have the discipline to clean the unnecessary code when the dust settles down. Thank you for reading. Almir Mustafic