Should You Return to Your Old Job? Pros and Cons

With the current state of the market in software engineering, I can understand there are people out there who cannot find a decent and stable job. I might be exaggerating, but I do believe that the “peak” of software engineering was reached in ’21. It’s all downhill from there on.

Returning to a former job can be appealing for those seeking stability, familiarity, or a role they truly enjoyed, but it’s a decision that requires careful consideration. Especially in software engineering, and in the software industry, where job hopping is considered the norm. I will try to analyze a breakdown of the pros and cons.

Pros

  1. Familiarity: You already know the team, culture, and work processes, allowing for a smoother transition.
  2. Shortened Learning Curve: Since you’re familiar with the role, you can often pick up where you left off, leading to quicker productivity.
  3. Potential Respect or Promotion: Returning employees are sometimes valued for their previous loyalty, especially if they left on good terms, which could open doors to promotions or new responsibilities.

Cons

  1. Stagnation: Returning could limit new learning and growth, as it may feel like going back instead of moving forward in your career.
  2. Possible Tensions: If you left for reasons related to culture or management, those issues might still be there.
  3. Missed New Opportunities: Going back might prevent you from exploring fresh environments or companies that could offer new perspectives, skills, or compensation.

Mr. ChatGPT, could you please…?

The above, just as you guessed, came from a single, one-liner prompt:

Write the pros and cons of returning to your old job.

While I can see the reasoning behind it, and most of the pros do make sense, my belief is that the scale tips towards the cons. As usual, I’ll try to elaborate my train of thought.

Being primarily a millennial, when it comes to the job market, I was born on the wrong side of the history. Right when I managed to make a break and by shedding tears and spilling blood, graduated from my masters, I ended up right in the big financial crisis. Businesses closing down, political unrest, and not to mention that my current job aspirations were describing a profession that, at the time, half of the people could not grasp it even.

Therefore, just as my other peers born on the cusp of the millennia, we believe that having a job is actually a blessing than a burden. So, millennial compromise usually outnumbers gen z’s pickiness, or general “high maintenance” of all the younger people joining the industry. Hence, if usually millennials are changing jobs, they do so because there are strong reasons behind them.

Familiarity

The kind of reasons, once accounted and acted upon, do not easily change. Hence, the pro argument of Familiarity is a strong con. What would be the reason of returning to the old job, if, there was a familiar strong reason for leaving? If that reason has changed, yes, it makes sense, but this leads to other…kind of arguments (essentially a different company, or position), so let’s not explore that.

Shortened Learning Curve

This argument, while seems to be a big positive one, I will try to reverse it.

Indeed, since an employee left, was familiar at the least, or was doing a very good job at best, in his/her previous post. That leads to shorter time to production and increased productivity. However, we do not fully know the reasons for leaving (whether that was compensation based, or something else), but for most of the people in the industry, a short learning curve is something they generally avoid. Not learning something new (especially with all the new tools that come up every day), is considered to be job-killing. Not to mention the challenging part. It is extremely challenging to be able to comprehend, learn and adapt in order to fix something broken. Or create something new.

Potential Respect or Promotion

I cannot think a worse argument than this. The main reason behind it is quite simple. If there was enough respect, there would have been a promotion, and the employee would not have reached the exit door. GPT, is also mentioning “loyalty” and “leaving on good terms”. Both of those things are, obviously discarded, right from when someone opens the exit door…

Concluding

Returning to a former position for me does not really make any sense. Being an advocate of change and generally positive feedback, when someone leaves his post, there surely is a larger reason that has not change for him to return. If that reason has changed, the most of the times we are talking about a different company, with different managers and different colleagues. Not the same company anymore…

To quote the big economist: “This time is different”. No — this time its not different than the previous time, at least not in the software industry.

Unveiling the Truth: Kubernetes as a Panacea or a Myth?

Kubernetes as a Panacea: Myth or Reality?

In the rapidly evolving world of technology, few tools have garnered as much attention as Kubernetes. Often hailed as a silver bullet for a multitude of IT challenges, Kubernetes is touted as a panacea for managing containerized applications. But is this perception grounded in reality, or is it merely a myth? In this blog post, we will delve into the capabilities and limitations of Kubernetes, exploring whether it truly lives up to the hype.

What is Kubernetes?

Kubernetes, often abbreviated as K8s, is an open-source platform designed to automate the deployment, scaling, and operation of application containers across clusters of hosts. Originally developed by Google, it is now maintained by the Cloud Native Computing Foundation (CNCF). Kubernetes provides a framework to run distributed systems resiliently, handling scaling and failover for applications, and providing deployment patterns and management tools.

The Promises of Kubernetes

  1. Scalability: One of the most significant promises of Kubernetes is its ability to scale applications seamlessly. It can automatically adjust the number of running containers based on the current load, ensuring that applications remain responsive and efficient under varying demands.
  2. Resilience: Kubernetes offers robust mechanisms for managing the lifecycle of applications. It ensures that your applications are always running in the desired state, automatically restarting containers that fail or are unresponsive.
  3. Portability: Kubernetes abstracts away the underlying infrastructure, making it possible to run your applications on any cloud provider or on-premises environment. This portability is a key advantage for businesses looking to avoid vendor lock-in.
  4. Efficiency: By optimizing the use of resources through its scheduling capabilities, Kubernetes can lead to more efficient utilization of hardware, reducing costs and improving performance.
  5. Automation: Kubernetes automates many aspects of application management, including deployment, scaling, and operations, freeing up developers and IT staff to focus on more strategic tasks.

The Reality Check

While the promises of Kubernetes are compelling, it’s essential to recognize that it is not a magic solution that will solve all problems effortlessly. There are several considerations and challenges that organizations must be aware of:

  1. Complexity: Kubernetes has a steep learning curve. Its powerful features come with a complexity that can be overwhelming for teams new to container orchestration. Proper training and expertise are required to harness its full potential.
  2. Resource Intensive: Running a Kubernetes cluster can be resource-intensive. The control plane components and various add-ons needed for a production environment can consume significant CPU and memory, which may not be ideal for small-scale applications.
  3. Operational Overhead: Despite its automation capabilities, Kubernetes still requires significant operational oversight. Maintaining, updating, and securing a Kubernetes cluster involves ongoing effort and vigilance.
  4. Security: Kubernetes security is complex and multi-faceted. Misconfigurations can lead to vulnerabilities, and securing a cluster requires a thorough understanding of Kubernetes security best practices and continuous monitoring.
  5. Integration and Compatibility: Integrating Kubernetes with existing systems and workflows can be challenging. Not all applications are designed to run in a containerized environment, and some may require substantial refactoring to be compatible with Kubernetes.
  6. Database Migrations: One of the notable limitations of Kubernetes is its inability to manage complex database migrations effectively. While Kubernetes excels at managing stateless applications, handling stateful components like databases and their intricate migration processes can be cumbersome. Database migrations often require precise sequencing, careful coordination, and rollback mechanisms that go beyond the orchestration capabilities of Kubernetes. These tasks often necessitate external tools and manual oversight, underscoring that Kubernetes is not a comprehensive solution for every aspect of application deployment and maintenance.

Use Istio

Attending recently a potential candidate meeting, the candidate was asked to “provide a system solution that would solve the most common issue found in a live-update system: uptime“. The requirements were simple. You have a system that is broken into two parts:

  • Backend.
  • Database.

Using k8s what would be the ideal setup you would choose so that you can update your Backend code, while also doing a database migration?

For example, say the backend code is compatible with the db code at major version X, what happens if you upgrade to the major version Y, and you need all your users to be serviced with 0 (literally 0), downtime?

The candidate, responded, after thinking a bit, that you need, in the between to deploy a backwards compatible version, so as to give a chance to the migration to take place.

This was unacceptable of course according to the interviewer. The answer from the interviewer was to : Use Istio.

What does this Istio thing:

  1. Traffic Management: Imagine you have a bunch of tiny services (like small programs) that need to talk to each other to make a larger application work, much like how team members need to communicate to complete a project. Istio acts as the “traffic controller,” making sure these messages go to the right place, in the right order, and without getting lost. It can also control how much traffic goes to each service, balance the load, and handle failures gracefully.
  2. Security: Istio makes sure that communication between services is secure. It’s like locking all the doors and windows in a building to ensure that only authorized people can enter. Istio automatically encrypts the data being sent between services and checks that each service is who it claims to be (authentication). It also enforces rules about who can talk to whom (authorization).
  3. Observability: Istio helps you keep an eye on what’s happening inside your application. It’s like having a surveillance system that monitors traffic, performance, errors, and other important metrics. Istio provides insights into how services are interacting, which can help you quickly identify and fix issues.
  4. Policy Enforcement: It ensures that certain rules are followed. For example, it can enforce limits on how much data one service can send to another or ensure that certain services are only accessible under specific conditions. It’s like having company policies to ensure everything runs smoothly and safely.

Ok, so my guess is that the interviewer had read the above bullet points and thought:

Hmmm, smart traffic management looks like can be used so that we can route traffic from the database while running a migration in a way that it would never stop servicing at all!

Well, that was correct. Except that the database is a central place that gathers all application traffic and requires a central semaphore to perform write applications. This main’s semaphore’s task is to allow or not allow one agent writing or non writing. That means, when you are running your migration and you are changing the columns of a table, the RDBMS needs to have exclusive access to that table in order to recreate it, and no one else is allowed to write there. No matter how smart you will route the pod logic and traffic, the end bottleneck would be the database.

Kubernetes: Panacea or Powerful Tool?

Kubernetes is undoubtedly a powerful tool that can transform how organizations deploy and manage applications. It offers unparalleled capabilities for scalability, resilience, and efficiency. However, it’s not a one-size-fits-all solution. The notion of Kubernetes as a panacea is a myth if taken to mean that it can solve all IT problems without effort or expertise.

The reality is that Kubernetes can provide immense benefits when used appropriately and with the right level of investment in knowledge and resources. Organizations should approach Kubernetes with a clear understanding of its strengths and limitations, ensuring they have the necessary skills and infrastructure in place to leverage its full potential.

In conclusion, Kubernetes is not a magical cure-all, but it is a powerful tool that, when used correctly, can significantly enhance the agility, reliability, and scalability of modern applications. By setting realistic expectations and preparing adequately, organizations can avoid the pitfalls and maximize the advantages of adopting Kubernetes.


ChatGPT and Basic Calculus

Being a Computer Science master’s graduate, I had also being taught courses about Artificial Intelligence. Back then though, those were pretty basic. In ’08, all that was described as AI, was merely some algorithms that were designed to solve or calculate a specific set of problems.

Most common problem I can remember from back then was to write an algorithm that solves Euler’s 8 queens problem, or an algorithm for a permutation of the common puzzle of Hanoi Tower.

The theory behind the AI, was fairly simple. Algorithms and Data Structures, and actually it stopped there! No statistics, nothing fancy from a mathematical point. I can still remember BFS and DFS, but those were thoroughly taught at a separate lesson, called “Algorithms and Data Structures”.

Another aspect that was taught at that lesson, was how to use A* in a graph diagram, or a tree diagram, in order to reduce the possible branches in a potential “Artificial Intelligence” solution employed in an application. But frankly, the use of todays tools needed to create a serious AI application, weren’t the subject of that course.

“Pattern Recognition” was the most similar course that seems to be related to todays AI applications. This course was indeed a more “control theory” oriented course that was the grand-father of todays pattern recognition. Regression and discrete mathematics were the basic subjects of this course. Not probabilistic theory. Not even statistics. Now, after 15 years it has changed radically.

Last night, I decided to ask a very basic calculus question, the kind that 17 year old students are being taught. The subject was limits, and given some mathematical function, to calculate the limit of that function while the values approach the infinite.

A trip to Infinity

To Infinity and beyond!

A small parenthesis here. I have watched the documentary from Netflix, called “A trip to Infinity“, which was amazing! The stories explained in that documentary were very well presented. The “Infinite Hotel”, with infinite many rooms, which always has a room available, and the manager who visits all the rooms just in 1 minute. The Japanese Godzilla story was also very good. Later, physics are also involved and that abstract mathematical concept, called infinity is being applied to our real world universe. Definitely recommended, and I have to say I was very impressed with the work they did!

However, this is something that unfortunately cannot be easily represented in the limited space of a LLM AI application such as ChatGPT. I think in general the Calculus quizzes cannot be answered that well via that model. The reason, is, that it requires a huge amount of data (one would argue infinite?) to actually grasp the concept of something that big as infinity. Even at the very first lessons of my masters, we were taught that a computing machine cannot grasp the concept of infinity.

As simple as doing a division by zero, will raise an exception or make any program crass (I’ll write a blog post sometime why this in PHP created a few hundred thousand dollars losses, once in a blue moon), ChatGPT also crashed when I tried repeatedly to request it to calculate the simple limit:

This is what it replied with:

The calculation of this limit is being done by approximation, a strange technique, but valid from a more practical view, nonetheless.

When I “devised” the above quiz, I had in mind this:

L’Hôpital’s rule

The above rule merely says the following:

If after calculating separately the limits of the numerator and the denominator you reach to a paradox like:

or :

and if we assume the denominator to be a function that is continuous and differentiable, and the same happens to the numerator as well, then the above limit gets transformed to:

Interesting…

Therefore, I saw the response and I quizzically asked:

Completely wrong, but partly also right?

And there you have it. ChatGTP completely flunked the response. The function for the limit calculation changed radically into a sinusoidal function (who knows why? some neuron had different weights and thats the first thing that connected with the question?).

Luckily the response was the same, and correct still, at 0.

I decided to give it another chance:

ChatGPT acknowledges the defect

Again, even though it acknowledged the defect, and it made it even worse! Now it calculated it to 2/3, which is completely wrong.

That’s where I decided to stop playing with ChatGPT and Basic Calculus. I believe it is actually very well written, but, when it involves abstract thinking, we have a long – long way to go…

Conclusion

If you are a calculus student and you want to cheat your homework with ChatGPT, do think it twice. You might get a correct answer result (after all there are a few stuff we can’t calculate with calculatory methods), but the proof of that answer would be mathematically incorrect!