Requirements negotiation for engineers

Requirements in software engineering are a living thing. As we develop the software or as the software is used in day to day business, new perspectives are revealed that require us to adjust the original requirements. As the requirements change, so does the planning of the software and this often causes friction between the stakeholders and the engineers, therefore, we must develop our coping mechanisms to accommodate this constant change to minimize this friction. Let us discuss the reasons behind the change and how can engineers do requirements negotiation.

Why do requirements change?

As the business circumstances change or new facts emerge, so do the requirements for the software. While this change of requirements is something mainly disliked, at the same time it is something that in most cases cannot be avoided or prevented. The very thing we need to do when requirements change is to get a clear understanding on all sides about the why. Why do we need to change the requirements. It is not easy to list all possible change categories, but most often you will see one of these root causes:

  • New information has emerged about a previous assumption
  • Management has decided to pivot the project direction
  • There has been a change in the market (e.g. competition, new customer requirement, etc.)
  • New legal requirement has come up

No matter the change reason, it is very important to understand the background so you know the importance of the change. When you know the why, chances are higher that you will empathize with the requestor, rather than thinking they did not do their job properly when writing them. This sets a better baseline on both sides when trying to find the best solution how to move forward.

What can we do when the requirements change?

As engineers, when we analyze a change request, we try to think it through all the perspectives that we can imagine. We think what do we need to do to implement a certain requirement, what can go wrong and how can we prevent it, what kind of quality measures we need to put in place, etc. This is a complex process with a lot of, usually unspoken, variables in it.

As an outcome of this process, we propose a solution and give a delivery estimation. Usually, this estimation is taken into calculation of the implementation timeline and is announced to stakeholders, turning it into a commitment for engineers. This is exactly where the problem arises. If the requirements change, the implementation needs to be re-planned, maybe re-worked if the work is in progress and chances of delivering on previously promised date start to decline, a fact very often dismissed by the business stakeholders. Often, change of the deadline is highly opposed and it becomes a blame game. From my experience, I have learned that:

Change of requirements is not the problem, the problem is the inadequate communication of the cost of the change

To escape this blame game, we need to do a fact based discussion laying all the cards on the table, show the viable options we have in front of us and guide the stakeholders into choosing the next step. This way we make sure that everyone is aware of the cost of the change and no one is blamed for not delivering on the promise.

The triangle of change

Before we discuss how the change of requirements can be negotiated, let us first understand the dimensions of change, which I like to call the triangle of change. When the requirements are estimated, engineers usually think of what needs to be done (the scope), the quality of the solution (automated testing) and come up with an estimation on how long will it take to implement the change. But, when the requirements change, there comes the triangle of change in play.

The triangle of change shows that one can hold at max to two of the points and has to sacrifice the third. Meaning, one can choose to:

  • Hold on to scope and quality (green vertex) -> sacrifice deadline
  • Hold on to scope and deadline (yellow vertex) -> sacrifice quality
  • Hold on to deadline and quality (blue vertex) -> sacrifice scope

Once this is understood by all parties, then the negotiation can begin.

How to negotiate the requirements

It is also often the case that change is requested while holding the expectation to the same estimation, scope and quality standards. How can engineers address this situation constructively? This is the framework that I generally use:

  1. Listen to understand the motivation behind! You need to understand, why are the requirements changing now and how pressing this is.
  2. Ask if we can de-scope something else or extend the deadline. Out of the three dimensions of the triangle, you want to avoid lowering quality at any cost (this will haunt you back), so adjusting the scope or postponing the deadline is the most desired outcome.
  3. If you should hold onto the deadline, then see all the options you have to adjust the scope. Offer the requester a couple of alternatives together with the associated cost. Make it transparent, what decision leads to what outcome. Agree together!
  4. Communicate the “new agreement” openly to all stakeholders.

To illustrate this better, I will go through two scenarios to demonstrate the use of the framework:

Scenario 1: The engineer is working on integrating an online payments provider’s checkout process into an application. This work is estimated at 10 work days. The work is in progress at about 50% and will be finished in 5 days. And… here comes the product manager with a new announcement. The CEO has negotiated a better deal with another provider and you need to integrate this new one. How would I go from here?

  1. I would first asks questions to understand what exactly does this change mean. Do we need to drop the previous integration or do we need to complete it plus add the new integration. Ideally, I would also try to understand the rationale behind. When knowing the why, it is a lot easier to accept the change positively.
  2. I would ask for some time to analyze the integration process of the new provider. I would estimate what parts of the already done work needs to be dropped and what can be reused, thus estimating how much more time I would need to complete the integration of the new provider with the same quality and same scope. I calculate the delta and explain to the product manager what is the cost of this pivot.
  3. As implementing payments’ integration is a crucial feature for the product, I go ahead and analyze quickly if we can also do a feature breakdown and see if can deliver it in chunks, meaning still hitting the initial deadline with a smaller scope and then complete the rest of the work after the first release. So I come up with two alternative paths we may walk and their associated cost and outcome.
  4. Having gathered all these facts, I would have a talk with the product manager and present them all the options we have.
    1. Adjusting the scope and go live with a minimal version
    2. Extending the deadline to accommodate the new requirements
    3. Lowering the quality (I TRY TO AVOID THIS AT ALL COST)
  5. Try to agree together on one of the options, or if we cannot, then ask for further input from other stakeholders
  6. Communicate the decision in the team transparently so everyone is a ware what is happening.

Conclusion

Change is the only constant. During the development of a software, requirements change very often and getting comfortable living with the change will make your life easier as an engineer. Using the above mentioned negotiation framework can help you deal with those situations better and smoother agreement with your business stakeholders on changes and consequences with less stress and frustration.

Effective Knowledge Sharing Strategies for Software Engineering Teams

Software Engineering teams usually have a very special evolutionary dynamics. Often they start small and stay like that for a while, or better to say, until the solution gains traction and the feature requests start to overflow the team’s capacity.

It is usually this late stage when companies start adding people, but hiring takes time and the teams have to survive. Trying to cope with the load and push for the speed, usually teams start to allocate similar tasks to same people. Of course people working on the same parts of the software are faster than the rest who seldomly contribute on those areas. Speed is a factor of convenience on many perspectives, therefore usually the evolution of these knowledge siloes is tolerated, until it becomes a problem. An engineer goes on vacation, every change on their silo-part slows down, or halts altogether. Or even worse, an engineer leaves and the whole team falls in chaos as no-one knows the “black box” of the other.

In my two decades in software engineering, I have very often encountered situations of knowledge siloes, in small as well as large companies. Almost always, the intention behind was benign but at the end in one way or another it caused annoyance to everyone.

Knowledge siloes are bad for both individuals and the team. They can be fixed, but it requires a systematic approach and discipline

The role of Engineering Manager in fixing knowledge siloes

Engineering Managers (or Team Leads) are often pushed to focus on delivery as this is their primary responsibility. Very often, the pressure to deliver faster comes from multiple directions. From the desire to achieve the team targets, to business objectives and all sorts of other circumstantial requirements. However, knowledge siloes are a sort of technical debt that haunts the team (and the company) later, therefore needs to be addressed systematically.

As the responsible person for the team, Engineering Manager is also responsible to make sure to create and facilitate the culture of knowledge sharing. Engineers should have the time for knowledge sharing and it is the Engineering Manager who has to make that possible. The team should be enabled and supported to do so. Knowledge sharing should be part of the process and not a handover task, therefore it should be incorporated in the regular delivery flow of the software.

Effective Strategies for Knowledge Sharing

What are the strategies that you as an Engineering Manager can follow to effectively address the challenge of knowledge sharing? Here are some that have proven to work well:

  • Writing comprehensive documentation
  • Conducting thorough PR reviews
  • Holding team presentations for major updates

Writing Comprehensive Documentation

Writing documentation (e.g. on Confluence, Notion, etc.) could be a remedy for saving the knowledge from people’s brains onto a shareable space. Especially if you need to document large concepts such as architecture, complex business decisions etc. Documenting on such central tools also helps with organizing knowledge and long retention. The main drawback about this strategy is that after some time documentation tends to be outdated. Unless a rigorous discipline for updating is applied, this effort can go waisted very quickly. Stale documentation is not trustworthy, therefore no one will read it.

Actionable advice:

  • Document only long living concepts (e.g. high level architecture, business decisions, legal requirements, processes, etc.)
  • Book time in your planning to update the documentation. If something changed that should be updated in the documentation, this should be a written task done following the implementation of the change (do not put somewhere down into your backlog :))

Conducting Thorough PR Reviews

If done properly, I would consider the reviews as one of the most effective ways to share knowledge. It is the live documentation of what the code does. At the same time, the reviewer understands the transition from how it was to how it will be after merging. The disadvantage, if in a hurry (which often is the case) people tend to do the review superficially, not paying too much attention to understand it properly.

Actionable advice:

  • Make it a rule, every change should be PR reviewed
  • Push for small PRs. Human brains cannot cope with too many variables at the same time. It’s difficult to review a PR with 10+ files
  • Let the team feel the responsibility jointly. The reviewer is as responsible of the change as the implementer

Holding Team Presentations for Major Updates

This is one of my favorites, especially if major changes are introduced. Sometimes things cannot get documented so quickly, also not everyone can be involved on every part and every review, therefore you have knowledge leakage. Such team presentations are intended to bring everyone on the same page by presenting the latest developments and changes introduced. At the same time, giving everyone a chance to ask questions and gain more understanding. The downside of this is that it is time-expensive therefore not feasible to do too often.

Actionable advice:

  • Every major change should be followed with a team presentation
  • Even if you have no major updates, make such a presentation at least once a quarter. It serves as a refresher for the team as well as make everyone aware how much you have achieved in that quarter.

My favorite strategy for know-how sharing

All of the above mentioned strategies work well and have their benefits. At the same time, they have a common weak point: human laziness. Humans are lazy by nature (I guess this is a good thing, we need to preserve energy), therefore these practices have a tendency to degrade over time.

The documentation gets outdated as people don’t find time to update it. PR reviews start to get done fast because people start to pay less attention or are in a hurry. Tickets get written fast and in less details. If we can skip a step because we are in a hurry, then we will do it. But, there is this one thing that we cannot skip is, and it is the code that goes to production.

Therefore, my favorite long term strategy has two rules:

  • Code is the documentation
  • Everyone works on all parts of the codebase that they can

Let me get a little deeper on these two concepts.

Code is documentation

The only documentation that does not get outdated is the code that is running on production. The only exception to this would be complex business logic and agreements which can be documented somewhere else and usually they don’t change often therefore less risk of getting outdated.

The code should be written clearly and tested reasonably well. Test scenarios serve also as specifications/requirements documentation. In test cases one sees what the code should do and what should not. From them, most of the code should be explainable. If the team holds on to this principle with discipline and hones the craft of writing well tested code, the knowledge sits in the code base and not only in the brains of individuals.

This kind of documentation, will not only make it easy for people to touch most parts of the codebase, but it will also make the onboarding of new engineers a lot faster and efficient.

Everyone works on all parts of the codebase that they can

The key to spreading knowledge is the necessity for having it. Yes, we can encourage people to learn more and we can support them to do, but our brains are mostly wired to hold the information we deem as absolutely necessary, the rest tends to slip away. If people have to touch different parts of the application, their contextual memory of those parts will be fresh and it will be easier for them to jump from one part to another. Also, this will lead to a more concise implementation style across the application.

I hear you asking, but how can everyone work on every part of the application. The key is in the part “that they can”. Of course we would not expect a frontend engineer work on backend tasks and vice versa (unless you have full stack teams), but they work on all parts of the codebase that falls inside the limits of their specialization. In other words, every backend engineer work on every part of the backend codebase.

Short term vs. Long term

Your actual situation will decisively influence which strategy you will and can follow. As for everything, there is no silver bullet to this problem, but the above mentioned strategies certainly help to achieve knowledge sharing in engineering teams.

If the need is for short term, I would recommend go for quick documentations, reviews and know-how sharing sessions. If you want to play long term, I have seen that my strategy works quite well, but it requires the team to work together at least 3+ months to start seeing any tangible benefits. It requires patience and a lot of stakeholder explanations. At the beginning it will slow down the team, but long term you will go far with this.

How to deploy a rails app in under 30 mins and less than $5 per month

It’s October 2023 and we have Rails 7.1 released. The whole community is excited with the new release and countless people are awaiting to start new projects with Rails. I believe Rails has one of the best productivity oriented ecosystems. It’s not just a framework, it’s a complete ecosystem with tools, knowledge and communities supporting it.

Ruby on Rails is my default tech stack choice for my personal projects. I have some of them running online, but the usual problem is, I do not like to pay too much money for for-fun projects which do not generate any income. Previously, I was running my projects on Heroku, but with their pricing changes, I had to take them down as it became too expensive to run those projects where usually I was the only user.

With the introduction of Kamal and the great pricing of Hetzner Cloud, now there is an opportunity to actually run a rails project in under $5 per month. To make my life easier, I decided to write some automation scripts so that every time I setup a new application, I do not have to remember all the detailed steps I need to take. Let’s elaborate on this.

Typical rails setup

On my personal projects the typical setup 3 components:

  • The rails app
  • The postgresql database
  • The redis db (used for cache and background jobs)

For projects that are under development, have no significant user base or the project is at the stage of idea trying, I just need a setup that works and is easily set up. So… this is the solution I use.

Setup of the cloud VM

The VM setup of my choice is named CAX11 on Hetzner cloud. It has 2 shared vCPUs, 4 GB of RAM and 40 GB of disc space. Good enough to run all those components in one server and at the time of writing it costs less than $5 per month

Screenshot from https://www.hetzner.com/cloud, accessed on 12 Oct 2023

I wrote a terraform script which creates this server and a firewall rule to limit the open ports to ssh and http. Now I can easily provision the servers for my setups by just running this terraform script. More about it below.

Setup of deployment

With the introduction of Kamal, now we can easily have a Heroku like easy deployment process for containerized rails application. It takes care of not only rails application, but also of the necessary auxiliary infrastructure as database and redis. While playing with kamal, I realized, while it is very easy to use and makes deployment fun, I still had to spend a couple of hours to tweak the configuration details to make it work. These kind of tweaks are usually are not found in one documentation page as they are custom to your setup, but anyway I had to loose the time to google the info and make it work. So I decided to write a ruby scrip to automate this.

Here is what exactly this script does:

Phase 1: It collects input

  1. It asks for the root folder of the project
  2. Then it asks for your docker registry username
  3. Next it asks for the IP of the server, the DB and Redis (they can also all be the same IP)

Prepares the rails app

  1. It extracts the name of the rails app from database.yml
  2. it creates the kamal deployment file to setup all these components
  3. It creates/appends .env file to add two keys:
    • RAILS_MASTER_KEY – reads it from config/master.key and copies here. Itused when running rails docker container
    • POSTGRES_PASSWORD – used for postgres container
  4. Disable force_ssl so the application can be accessed using http

With the preparation, now your application is ready to be deployed using Kamal

What about previous versions of rails?

If you want to use the scripts with apps older than rails 7.1 you need to prepare them to be dockerized. The script expects to be able to dockerize the app and use the generated image for deployment. If you add a working docker file to your older rails app, the setup will work.

Where can you get the scripts?

I packaged the scripts and a readme file for each of them into one zip file and published them as a digital product. You can grab them from here: https://ariancelina.lemonsqueezy.com

You can get the scripts and use for your own project. If you like them or if you have any feedback, please write me, I’d love to hear from you.

Common interview mistakes I encounter

As a hiring manager, I have interviewed hundreds of candidates so far. The more I talk to candidates, the more I start realizing, some of the mistakes are common between candidates and I wanted to share them with you, hoping it helps you to prepare better for your next challenge.

Before I move into the list, I’d like you to remember: hiring managers do not interview people to find what they do not know! Hiring managers do the interviewing to find out what you DO know and how’s that going to fit to the needs of the team and the company. Therefore, if your actions and answers start from this point of view, you’ll have a greater chance to move ahead in your interviewing process.

Here are the 5 most common mistakes I encounter:

#1 Not being punctual

Punctuality is a highly desired characteristic in professional life. Being late to the interview already will be setting you on the wrong foot. If nothing, it will create a bad initial impression. If you see that you are not going to make it on time, try to inform the company proactively for how late you will be or ask for another slot. People will understand when you reach out, but simply being late will play against you, even if you are a very good match.

#2 Not elaborating on your experience

When the hiring manager asks you to talk about your experience, this is your chance to shine. It is your opportunity to show how well you and your skills fit into the organization and the position itself. It is your convincing pitch to show why you are the right fit for what the team needs

Do not cut it short. Do not overlook your experience, but also do not get into unnecessary details. But then, how do you answer this correctly? Do analyze the job description, try to understand the expectations from the role and what the company does. Then try to create mental connections on how does your knowledge and previous experiences benefit the company and how can you use that to contribute further in this role.

The hiring manager is not asking you to read what is visible in your CV, they are asking you to provide further details, details that are not visible in your CV, but would show that you are the right fit.

#3 Not knowing enough about the company

One of the typical interview questions is, “Why do you want to join us?”. Pay attention on how you answer this question as it often defines the fate of the interview process. Before the interview, take your time to analyze the company, what do they do? Try to find out what are their culture and core values, try to find what their mission is. If possible, also analyze the market and how do they stand. Then see, how does this fit to your own values and cultural values you live by.

Your answer must be original, as this shows how genuinely you are interested in the company. Probably, you don’t want to look like just another candidate looking for just another job.

And, if you see that what you found out about the company doesn’t interest you or does not align with your values, then better move to another company, as probably this is not going to be your next place where you thrive.

#4 Not having questions of your own

This may feel related to the mistake #2, thought this is not only about your knowledge about the company, but also about showing interest about the position, the job, the team and the challenge. The hiring manager will try to understand, what is important for you. What kind of questions you ask, what kind of values you are looking for.

Often, not your answers to the interviewer questions, but your questions will tell you apart from your competition and if you are a good cultural fit for the organization.

#5 Answering questions superficially

In a time slot of 30 or 45 minutes, it is very difficult for the interviewer to check all your knowledge, though depending on how you answer the questions it will give an indication of how well you know the topic. Answering questions with a shallow answer will often leave the impression that your knowledge is superficial or that you have not actually had that experience you are mentioning in your CV.

When you believe that a detailed answer will take too long, try offering the interviewer a summarized answer and asking them if you want to elaborate it further. If this experience/knowledge is important for them, they will follow up with more detailed questions.

Summary

Preparing for the interview with the right focus and perspective will already jump you ahead of competition. Do these to prepare:

  • Research about the company, the business and the market
  • Understand the role, the responsibilities and expectations
  • Think about how your skills and experiences can be of the benefit in this role

I hope it helps you have success in your next interview. If you found this advice helpful, please share so more people will benefit from it. Thanks!

Moving from Scrum to Kanban

In most of my 15 years in Software Development, I’ve mainly been part of development teams which were practicing Scrum methodology. Although we have always aimed to do it right, somehow the organizational culture and operations methodology influences how Scrum was implemented in these teams. Recently, in my current team we decided to actually move from Scrum to Kanban. Here is how it turned out for us.

Why did we decided to switch?

I am very passionate about Software Development process. Without working process I believe it is not possible for a team to reach their output potential. Yet, I am not religious about methodology used. While one methodology in one environment may thrive, it may kill the productivity in one another. So, why did we decided to switch? Was Scrum not good enough for us?

Well, I would not say Scrum is not good. I’d rather say, in our organizational environment, it did not seem the most optimal methodology. There were certain details around Scrum that we were struggling to implement properly. While I believe that it’s OK if we id not implement it 100%, I also believe that if we are missing some core things, than something is not right.

What were we actually missing? Sprint goals! We were rarely actually meeting our Sprint goals and our burn down chart was rarely meeting the lower end. Why was this happening? Were we a lazy or a dysfunctional team? Actually completely the opposite. The team was and is very focused and very productive. It was just the environment that was not enabling us to achieve those goals.

In our department we embrace a DevOps culture. We don’t only develop solutions, we also run and maintain them. Also, in addition to modern cloud based solutions we have developed, we also have to support a legacy application which is old and with a lot of hidden details. Any time we were touching the legacy application, our estimation of tasks was completely deviating because of unknown surprises.

With all these constraints, it was often that while in the middle of the sprint, we had to change priorities because we needed to fix something in the legacy app or because we needed to attend to a customer incident. In such circumstances, we could not just tell our customers “wait until the next sprint because the current one is full”. Of course our customer centricity pushed us to react immediately and solve the problem of our customer, but often issues of this nature lead us missing the Sprint goals.

Another thing that was not working for us is estimations. Estimating software is difficult. Especially in Agile environments where you have to judge the “half specified” request and give a number. But then when you give the number, you have to live with the pressure to deliver on time. Plus, often we go ahead and plan for more than one Sprint because the backlog is always larger than one can deliver, and then you realize delays in one Sprint affect the others, but on the other side the business people expect the potential date you had given them. This was another major sign for us that Scrum is not the best methodology for our circumstances.

The transition to Kanban

We did the transition in small steps. First thing first, we had a joined workshop with the team and agreed on this transition and the steps. We also pictured how the new process will look like and how do we map existing process steps to the new one.

Of course, implementing Kanban by the book was difficult again for the same reasons. One has to adapt to the organizational requirements as well. We could for example transition to continuous deployment immediately. Technically we had all the mechanisms in place. Yet, we had to satisfy some organizational expectations. Our solution is used by customers around the world. Our account managers expect us to communicate the change to them so they can communicate to their corporate customers. We also get often their help in testing major changes, so just rolling updates without a schedule was not going to work well in our case.

What we decided was to apply Kanban and release to development and quality environments as continuously, but keep production releases on a regular schedule. So far, this is working quite well.

Initial Chaos

The first day or two when we transitioned the workflows things did not go perfect. We had some Jira ticket statuses mapped not exactly as we wanted, therefore our board got messed up. Fortunately, we were able to fix this in a day and things started to get back to normal. Also, during the first week, it happened that people were confused about the flow of the process but everyone got used to it quite fast

The joy of on-demand prioritization

One of the main benefits of Kanban is that we can re-prioritize the priority backlog as often as we need. Is there a new business requirement, a burning customer incident, or a support request, we can adjust the priority on demand without feeling the stress of missing sprint objectives. This has released especially the “friction” between the Product Manger (facing pressure from the customers) and the development lead (trying to maintain the sprint promise).

Feedback from the developers

Whenever I have to drive such a change, I like to constantly get the feedback of the team mates and adjust/pivot in necessary. So far, I’ve mainly received positive feedback from the team about Kanban.

Developers feel less under pressure when they do not see a waiting list of tickets for the sprint. While we have the same level of productivity, it now feels more like a flow rather than a milestone based sprint.

This change has also substituted ceremony meetings (prioritization, tech planning, retro and review) with on-demand fully focused meetings. This has created more productivity time for the team.

Conclusion

Again, going back to my initial statement, it’s not that Scrum is bad per se. It just was not the best methodology for our circumstances. Moving to Kanban was an opportunity for us to improve our process to something that fits our needs better. So far, it has been a very rewarding experience and we enjoy it. Of course, after some time we’ll have to revisit this as well and see if we need to move ahead to something else. Continuous improvement is what we enjoy!

Measuring the temperature of the team

We are at the time that software development is such a crucial part of the business that almost everyone is lost on the river of “feature delivery” in such a way that we even forget that we have to stop and pay attention how our teams are functioning and how is our team dynamics.

The feature requests are way more in number than we technically can achieve to address. Our user base is getting smarter and smarter every day as well as they get more tech savvy, so they know more and more what they want. This makes addressing their requests a daily challenge, but this is only one side of the story 😉

When developing software, one side of the story comes from the users and key account users, but the other side comes from the business management and the leadership. Quite often, the perspective of these two groups may not end up to be the same, leading to stressful situations.

One of my favorite “soft tools” for leading teams is having regular 1 on 1s. Even though sometimes they feel unnecessary and too obvious, I religiously follow the cycle and never miss them. But why?

The reason is, for me these 1 on 1s are just like thermometers for fever. They tell me how my teammates feel, as well as answer the questions like is anything bothering them, is there anything that can be improved? These kind of questions may sound very basic and too simple, but they are amazing to identify the small-to-grow problems at their infancy phase and address them before they grow to the scale that pushes employees to leave the company.

I’m in the IT industry for ~15 years now, and if I can name one universal rule that I could identify between all the people groups I have been working together with, it’s that people don’t tell that they will leave. They just get fed up and start looking for another opportunity before they start giving you open feedback that something is going WRONG. So, what can we as leaders/managers do to prevent the situation to come to this point. In my opinion, we should on a regular basis measure the “temperature” of the team. How is the team dynamics? How do the individuals feel? Has the performance had any variations recently? These are the questions that we need to ask ourselves regularly and be wary in any of the changes, as any change to the answers to these questions is an alarm in itself that we should address as soon as possible before it is too late.

The other VERY VERY IMPORTANT topic to discuss in these meetings is, what do the team mates want to learn and further advance their skills! Continuous learning is extremely important for performing teams and the leader has to make sure they understands who wants to learn what, so one can match the daily business priorities to the interests of the team members, so they can grow personally and professionally while solving the most crucial business challenges. We must create WIN/WIN situations for our colleagues so everyone feels happy and benefits from the daily work we do!

As the saying goes, “people leave managers and not jobs”, it is our ultimate responsibility to realize if a team member is unhappy and going to leave before they make their unhappiness official, because when they do, it’s already too late!

Supporting the professional growth of the team

As an Engineering Manager I take the personal and professional growth of my direct reports very seriously. It is one of my core duties to make sure that, in my capacity, I have enabled them to learn continuously and advance their professional and soft skills. In this blog post I will share with you my formula how I support the professional growth of the team.

Understand who wants what

Every person is unique. Just admitting that defines the level of attention required to individualize the learning and growth experience. What exactly do I mean by that? Let us suppose you have a team member who is very much into data solutions. But, in their daily job, you constantly assign them frontend tasks. Maybe they will do the job, but I’m sure they will not operate at their optimal level if they don’t like frontend development.

With every one of my team members I do regular monthly (sometimes more often) 1:1 meetings. These meetings usually are for me to listen and them to talk. They are for me to understand what excites them, what bothers them, what makes them tick. I take notes and with every meeting I review my notes to check for deviations or changes. I also use these meetings to understand what interests them to understand them better personally and their professional interests.

Understanding the industry and market trends

I think it is of utmost importance for an Engineering Manager to be well acquainted with the trends in the industry and the market. In our vibrant industry, it is at the same time very difficult for us to be able to catch everything what is happening around us. Everyday we have a new framework coming up, a new cloud service, a new programming language update, and keeping up is a real challenge, so we do need to be able to filter critically the information that will be important for our future.

What has worked for me so far is to organise and classify information digestion. I use Twitter and LinkeIn to follow people behind the technologies of interest. I also follow the companies and communities behind the technologies that are in my and my teams area of interest.

This way I can keep myself up to date with what is in trend, what is being pushed and developed from big companies, therefore worth to invest time in.

Finding synergies with our company projects

Of course just knowing what are the trends and what the team members want to learn does not lead us anywhere. We have to match these two to create growth. So, how can we make these two ends meet?

We are lucky that the part of business we work in is very vibrant. We have more projects and backlog that we can manage to complete. In this backlog I constantly look to find opportunities where we can solve our business problems with innovative cutting edge solutions. I try to create opportunities where our important business goals are achieved by team mates implementing solutions with the latest technologies they enjoy. This way, a growth opportunity for the developers is created as well as our company benefits from innovative and up to date technical solutions. Win-win situation 🙂

Enabling the team to jump on these opportunities

Of course, when adopting a new technology, being a new version of a language, of a framework, or a new tool, this would mean that the team has to spend time learning it. Therefore, I as a manager have to critically evaluate these opportunities to see if this makes sense. If that new thing we want to adopt help us move faster, safer or further in our work. It should make sense from the business perspective and it should make sense from the professional growth perspective as well. When these two ends meet, I seize these opportunities.

Conclusion

As managers we should help our colleagues to be very attractive for the market, but also should create an environment that the employees would not like to leave.

As employees, we always have to think from the perspective that we are hired to solve the business problems and bring value to the company. But also we have to keep in mind that without continuous learning and improvement our value bringing capabilities diminish by time.

As the famous quote goes:

CFO asks CEO: “What happens if we invest in developing our people and then they leave us?” CEO: “ What happens if we don’t, and they stay?”

Are Azure Certifications Valuable?

It has been years since I stopped taking certification exams and lately I decided to get back to that adventure. In September 2020 I passed exams to be recognised as Microsoft Certified Azure Solutions Architect Expert.

Arian Celina - Certified Azure Solutions Architect Expert

Before and after passing the exam, I asked myself the question which I have seen many people ask as well; Are Azure Certifications valuable? I believe the question is applicable not only for Azure Certifications, but in general for any industry certification. Are they valued by the community and employers? Do they make a difference in your career? I have also written about this topic in the past, and yet it seems the same questions are still coming up. Let me share my updated opinion with you.

From the motivational perspective, it is very important to clarify the answer to those questions so we know why we are putting all that effort to learn and prepare for the exams. I also think these questions should be rephrased with a reversed perspective. Before we modify question, let us first discuss about the value itself.

What is the value and who defines it? Who can tell if a certification is valuable? I think think there is no single source of truth for that. From experience, I have encountered employers and peers who value a certified professional more than someone who is not certified. I have also seen opposite. As someone who have interviewed more than 100 candidates so far, I can say both can be right and wrong.

I have met certified candidates who have not been able to defend their title with knowledge. So I have met people who were not certified on a topic but were more knowledgeable than their certified peers. I have also met certified people who were subject matter experts and knew their topic in detail, kind of detail that we do not easily learn by randomly playing with the technology.

When I reflect on my late Azure certification journey but also on my previous certifications for .NET and Java, what I remember is that while preparing for the exams I have often learned hidden details about the topics which I have not encountered during the daily work. Those hidden details then later have quite often have saved me time or effort and enabled me to bring better solutions into life. This in itself is a value for me.

Considering this, the revised question I think we need to ask ourselves would be:

What do we gain from this certification?


In my opinion, we should not get certified so other people value us more because we hold that title. We should do certifications to learn better the technology we like. Of course one can do that without taking the exams and without getting certified. It’s just that taking the exams pushes you to follow a certain curricula which is reviewed by experts and that often gives more structure to the learning.

I have been using Azure for years and have quite some experience deploying and running web applications on various forms of workloads, containerised and non-containerised. Yet, when I took the late exams for Azure Cloud Solutions Architect Expert certification, I learned a lot about some not so familiar topics to me, like migrations of Virtual Machines from on-premise datacenter to Azure, about backing up Virtual Machines, or about Express Routes. Taking those exams pushed me to learn more about those topics which probably I would not in my daily work.

As a conclusion, in my opinion industry certifications are valuable as they push us to get better at that topic and this inherently will make us a more valuable contributor to our team, company and community. When we do that, whether the certification is valued by our potential future employers plays a smaller role in answering this question.

Kubernetes basic questions answered

when getting started with Kubernetes, it can be a daunting task at first to get a grasp of the basic concepts which will allow you to move forward with it. I would like to try to answer some basic questions about Kubernetes, some of which I was having in my mind when I first started to learn and work with Kubernetes.

If you do not have any understanding of containers and containerised applications, it becomes even harder to realise where in the big picture does Kubernetes fit.

Explaining what containers are is out of the scope of this article. If you feel like you still need clarity in understanding what containers are and how do they help, I suggest to find that out first before moving forward. If you feel comfortable with containers, then off we go.

What is Kubernetes?

Kubernetes is a container orchestrator. And what would that be? Well, when we containerise an application, we package the application and its environment in an image, but we still need somehow to run it. We can execute a docker run command and run a docker container, but then when we have an update or a new image, we would manually need to kill the running container and run the new one. And what happens when the container crashes because of e.g. unhealthy state? Who would take care of restarting the container? This is where Kubernetes fits into the big picture.

Kubernetes orchestrates the lifecycle of a container. It can deploy containers together with their dependencies, restart them if they crash, update them if the image version changes, create new instances of the image without downtime, etc. Most of these can be fairly easily automated with the help of Kubernetes.

What is a Pod?

Well, in the previous paragraph I made a false statement. Kubernetes doesn’t actually focus a lot directly on the containers. Kubernetes works on a one level higher abstraction concept called Pods. Pods can be thought of as mini virtual machines which can run multiple containers inside. Usually, Docker is used as a container engine, but this can be configured differently if needed.

Ideally, a pod would run a main container (e.g. one application or a service), and it can run other side containers which would serve the main container. The reason behind this is that, if one of the containers signals to be unhealthy, Kubernetes will kill the whole Pod and try to create a new one. Therefore, it’s a good practice to have one main service running in a Pod, and if that service is not healthy, then the Pod is instatiated by the orchestration scheduler.

What applications can I run on Kubernetes?

Anything that can be containerised. Kubernetes supports stateless as well as stateful applications. Although, from experience I can say, running stateless applications is easier. That’s because managing the state requires more management work from our side.

Personally, I try to push stateful software outside Kubernetes and use them from PaaS providers. One example of such a scenario is the Database. This leaves me more room to focus on running the in-house developed applications and less attention on dependencies.

What is kubectl?

Kubectl is a CLI tool to query and manage kubernetes. Kubernetes has several types of resources. Those resources can be Pods, Services, Deployments, ConfigMaps, etc. Kubectl allows us easily to find information about those resource as well as change them. One example would be to read the deployment configuration of a pod, another would be scaling up a deployment.

One can get most (if not all) of these using a UI, but come on, who needs a UI nowadays ☺️.

I want to have a Kubernetes cluster, what are my options?

Starting from the most obvious option, you can get some bare metal servers and install your own Kubernetes cluster. Though, I would strongly not recommend this until you really know what you are doing. Kubernetes is a very complex system. It has several components and a good configuration would require several servers. Only keeping a safe, available and up to date configuration would be a challenge, let alone taking care of more complex topics like the security of the cluster.

Unless you are constrained here, I would strongly recommend you start with one of the cloud providers that provide Kubernetes as a service. It is offered by many providers, amongst them Azure, AWS, and DigitalOcean.

The cloud providers abstract away the management of the cluster itself and give you freedom to focus on actually building your application infrastructure.

When is Kubernetes good for me?

If you have only one or two applications running, you are better off without it. Kubernetes offers great functionality to orchestrate containers, but it also comes with an administration overhead. If you are not building many (3+) different applications or micro services that you deploy frequently (several times per month), in my opinion it would not be a good option.

Kubernetes is a great helper in an environment of multiple micro services where continuous delivery is the process. It is an overkill to run 2-3 applications which get deployed a couple of times per month. You get my point.

Start small and adjust as you grow!

Conclusion

Kubernetes is one of our time’s coolest tools. It has enabled many business solutions scale flexibly and shine. But at the same time, it can be a complex beast. Take it with a grain of salt and prepare well before adopting. Equipped with knowledge, it will take your DevOps processes and with it your possibility to reacting to changes to a whole new level.

My language learning framework

The most important lesson that I have learned in my career of almost 15 years in software development is that programming languages are just tools to solve real life or business problems. About 5 years ago I was doing full time .NET, then I jumped to Java for about two years, then I switched to Ruby and Rails, and just recently I started using Kotlin to create two microservices (don’t ask me why, the business needed it ;)).

Because of this, there is no point whatsoever to be bound to a language/platform religiously. The languages are tools but it’s the core knowledge of computer science and software development practices that prevail.

These changes have been inspired by different rationales, sometimes influenced by the employer and sometimes by the economic conditions of the runtime environment. E.g. hosting a Java web application during 2006 was way more expensive than a PHP application, therefore, I used PHP as a primary language for my web facing pet projects. So during my career so far, I have used Java, .NET, PHP and Ruby as my core languages and also have implemented small solutions using Kotlin, Javascript, and Python.

To adapt to this changing environment of ours I have noticed I had created a framework, which I call my language learning framework. The framework itself is not about the language per se, but about the whole ecosystem around that language. It came as a result of identifying unchanging things around any language ecosystem. E.g. no matter the type of language, there is a way to deal with strings, numbers or arrays. Or the language has some sort of collections.

With almost every language that I have used, I have had the need to also learn a framework to develop web applications, a framework to do testing, and other common things around the application. So out of this experience, here I share with you my language learning framework. It lists the things I try to learn or pay attention to when I start learning a new language.

I. Language
1. Runtime & ecosystem (general knowledge)
2. Syntax
3. Data types (if there are types)
4. Main constructs
4.1. packages/modules, classes and methods/functions
4.2. loops & conditioning
4.3. arrays
5. Core libraries
5.1. String manipulations
5.2. collections (lists, arrays, maps, sets)
5.3. math (rounding, sqrt, pow, PI)
5.4. important packages/gems/etc. and any language/platform specific library
II. Frameworks
1. Application development (evaluate popular ones and pick one)
2. Testing (unit & integration)
3. Main design patterns and in that language
III. Toolset & Other
1. IDE platform specifics
2. CI/CD
3. Deployment (does the docker & Kubernetes work or is there anything platform specific)
4. Community
5. important learning resources

Some of these items on the list are dead clear so you just follow it, but some of them are hard, like choosing which framework to use. How do you choose which framework to pick. Well, in those cases, I use different inputs to make my decision but most often it is an educated guess. What I consider is, I ask my colleagues/friends if they have experience with any of the ones I am considering and get their opinions. I also evaluate possible blog posts about them and also try to measure the popularity by checking the number of contributors, how often does a major version gets released, how many job openings I find requiring that framework, and based on all these inputs I narrow my list to two options. Then I try both of them with a certain simple scenario and I try to evaluate how easily I could implement that scenario and get a feeling of both and then decide. Out of all the factors I consider, how much I like it and how many job vacancies are there requiring that framework are two criteria that weigh most with me. The pleasure to work with is very important for me, but also having an opportunity to use it (have an employer/business which actually uses the framework) is also important in my opinion.

One important thing is, when I try to jump on a new language, I try to do all these steps in a relatively short period, potentially with max 2-3 months, and then try to repeat it at least 2 times with 2-3 sample projects. In this way I make it possible for my brain to remember it, otherwise, if it takes too long to go through the list, I forget things in between and the end result is not satisfactory.

This is not a definitive list and doesn’t include everything we need to learn to be productive in one language/platform, but it certainly serves as a good starting point for me when I want to jump into a new language.

Do you have a different approach? Share with us!