Skip to main content

Healthy To Learn Something Outside Your Box

When you have a problem to solve, what is the most typical way to approach it?
Everybody is different, but most of us try to stay within our comfort zone because that’s what makes us feel more stable or more secure. We have one tool and we try to solve all the problems with that tool. When it comes to providing software solutions, you have to step a bit out of that comfort zone in order to innovate and in order to provide flexibility for someone else to innovate.
I started my career in Unix/C++ software engineering world years ago. Then I switched to a Microsoft shop at the end of 90s. I’ve been in the Microsoft world ever since, but I’ve shown a bit of interest in other technologies that are from the open-source community. In last few years I started digging deeper into Python, Node.js, and recently back in Java area. I have not been doing this because I am unhappy with what Microsoft had to offer, but I am rather doing it because I want to explore and find out how the open-source community has solved problems and what solutions/options are in the open-source world. This expanded my horizon a lot. It could mean that I will stay more in the open-source world or it could mean that I would take the concepts I learned and take them back into the Microsoft-shop and apply them in such a way to keep things simple and proper at the same time (.NET Core is now open source and that's a great move from Microsoft). Regardless, it is a win-win for me.
What are you doing to step out of your box? Try to dedicate only 1 hour per day and don’t worry about your progress. Check back in 30 days and you will see amazing results.
Thank you for reading this article. You can also check out my personal site: almirsCorner.com
Almir Mustafic



Labels:

Comments

Post a Comment

Popular posts from this blog

Brand New programming language and one solution OR …

Brand New programming language and one solution OR Two existing programming languages, one solution for EACH? I understand that there is no right or wrong. It all depends on your software architecture, team structure, team skills and other factors, but I still want to explain the scenario as it may look familiar to some. Let me explain. Let’s assume that you have microservices and common libraries in two major programming languages. You have some teams who are experts in one and some teams experts in the other programming language. Now you need to come up with a solution for a scenario that all teams will need to leverage. Let’s assume that your cloud platform has an off-the-shelf approach for this but it is supported by a 3rd programming language that your teams do not have much experience in. What is the right thing for your organization and not just from the technical point of view? A) Do you embrace what your cloud platform gives you off the shelf and implement thi...
Post a Comment
Read more

Programming / Software Engineering  — Think Paper, Paper, then Code

Most of the software engineering problems are solved in what I call the high-level brainstorming sessions. We basically walk into a meeting room and white-board our thoughts and come up with solutions. When things start falling apart, you better believe this happens in the last stretch of projects and it does work.  Now the issue is that we as programmers do NOT do the similar type of exercise before a line of code is written ? I typically see developers get requirements in the form of a document or a user story or in the form of walk-by requirements. The next thing I see on developers’ screens is code editors or IDEs. Is that the right thing to do? You may say that you are advanced enough and that you like to dive into coding right away, but this happens even to the best of us. We fall into this trap and rarely step back and review our habits. We have to go back to fundamentals. What did we do in school?  Professors taught us to write down our thoughts and to show what...
Post a Comment
Read more

Owning and improving what you have is a sign of maturity in software engineering — Is it?

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, t...
Post a Comment
Read more