During the past weeks I have spent about 2 hours per week on mentorship sessions with various developers from the Devz Community. I am really thankful for everyone that chose me among all the mentors, and I took notes on most of the questions.
I immediately found frequently asked questions for all the topics that I listed, so I decided to write a blog post with them. In the future I plan to update this post with more questions as they come.
I Feel I Am Programming Less And Less [As A Tech Lead], Is This Normal?
Yes. Technical leaders are moving to a path where you are no longer just producing software i.e. an individual contributor. This is probably the most asked question regarding transition from senior developers to tech leads.
What's important here is a bit of time management skills. I suggest having a balanced schedule allowing new tech leads to still program while considering the other skills required. Here is an ideal example:
- 30% of your time could be spent on the mentorship of your team members,
- 30% could be spent on meetings/product development,
- 30% could be spent on coding,
- 10% can be spent on growing your own skills.
What Skills Do I Need to Be A Tech Lead?
I think there are fundamentally 4 skills that you need to develop:
- Leadership skills, being technical or non-technical,
- System Design and Architecture skills and,
- Developer skills, which you may already have.
- Time management skills to balance your time spent on these.
I Want To Keep Coding But Grow My Career. Is There A Way To Do That?
I think this entirely depends on your organization. If the only path for growth to happen is go into management, probably it will conflict with this particular interest of yours.
I have experienced this myself and usually Tech Leader positions conflict with time spent programming. If your particular organization has technical paths (such as Principal Engineer) you can try to move into that direction, but most companies do not have such paths.
You can always trailblaze the path by communicating clearly with your managers the pursuit of such goal. Some companies can accommodate you but others have different priorities thus they will conflict with yours.
As An Architect, Should I Still Develop Software?
Yes. Undoubtedly you don't want to become the proverbial Ivory Tower Architect. If you detach from programming completely, most probably your solutions will also be detached from the code teams produce and thus it becomes counterproductive because developers will be forced to retrofit your solution instead of fit it more organically.
What Coding Tasks An Architect Should Focus On?
In my experience, the best architects I have worked with usually spend time on proofs of concepts and foundational technology. I have worked with architects that usually pair program with developers to unravel solutions that can fit the actual working code instead of coming up with solutions that may or may not fit the current architecture.
I think this approach has the best results overall because it proofs that your architecture guidelines and implementations fit into the software other teams are developing.
How Can I Know If My Architecture Is Successful?
Fitness Functions can be used to measure architecture goals. They also can be used to drive evolution to certain parts of the overall system once you know what to aim to.
An example of this is a fitness function that returns either the time, or the number of commits between your production code and the latest commit in your development environments. This function will let you know if you are properly applying Continuous Delivery.
Another example is Dependency drift fitness function. It allows you to understand the Drift between microservices regarding libraries and dependencies which can be interpreted as an indicator of stagnation/ossification of services.
What's The Point Of Microservices?
This is a tough question, but I usually focus on these points that work well with the evolution analogy:
- Microservices are about change independence. As an example of a evolutionary architecture, microservices allow evolution on different parts of your system quickly. Some services will be very stable once they reach a certain point but others need to often change to accommodate business needs. Again, some parts of the organism evolve while others remain stable.
- Faster time to market. Following from the previous point, once you know that the microservice architecture style allows for faster change and independence you are able to quickly prototype new ideas because you can start new business lines from scratch quickly, with the right tools (spanish).
- Making innovation cheaper. As a side effect of the previous point, microservices enable to quickly prototype new ideas because you can start new business lines from scratch quickly with the right tools.
Do You Think We Are Ready To Adopt Microservices?
Microservices are not a free meal. Conway's law is an important concern if you plan to adopt this architecture style. This is because there is a social/organizational component to every software architecture style and having organizations simply jump into microservices without the proper mindset can be problematic.
If you use Conway's law to your favor, service-based architectures can help move faster, but without organizational perspective it usually works against the adoption.
What Are The Most Common Questions You Are Asked During Interviews?
After quite a bit of interviews I have seen common questions and follow-ups:
- What is DevOps? The interviewer wants to know if you "get DevOps". Focus on why DevOps is more of a practice and cultural mindset instead of titles.
What is SRE? Software Reliability Engineering is kind of defined as:
One could view DevOps as a generalization of several core SRE principles to a wider range of organizations, management structures, and personnel. One could equivalently view SRE as a specific implementation of DevOps with some idiosyncratic extensions.
- What's the difference between DevOps and SREs? Per the previous question, but paraphrasing here, I think of SRE as an implementation of DevOps practices done by Google.
- Can you describe/document a pipeline to deliver code from scratch? This is a lengthy question that may deserve its own post! it gets asked often.
- What are SLAs and SLOs?
I Want To Transition To A "DevOps"/SRE Position. What Should I Study?
Most "DevOps" positions are really infrastructure positions. Most SRE positions are SysAdmin positions. Having said this, if you target infrastructure positions you should focus on:
- Learn how to work with a specific Cloud Provider. This implies learning how to manage and architect infrastructure on a specific provider. AWS has around 30% of the market share as of the time of this post, so it maximizes your opportunity to land a job. This implies Infrastructure as Code practices and tools to help you provision and manage such infrastructure.
- Learn tools and practices regarding Continuous Integration and Continuous Delivery. Most interviews in the infrastructure space ask you to design a pipeline to deliver services. The goal would be to be able to design pipelines using Jenkins pipelines, Github actions, Gitlab pipelines. I recommend watching Ken Mugrage talk about modern CI/CD practices, then learn a specific tool.
- Learn about Observability tools and practices. A good rule of thumb is to use tools from the Cloud Native Computing Foundation Observability And Analysis landscape. Most interviews, in my experience, will ask you to configure not only instrumentation but also alerts and dashboards for services and infrastructure.
If you are targeting sysadmin positions, they probably will overlap with the previous points but also require the following:
- Networking fundamentals and Software Defined Networking.
- Operating System maintenance and provisioning (package management, configuration).
- Container/VM Orchestration Tools (Kubernetes is the most popular nowadays).