How I Mentor Junior Software Engineers

In 2021, I happened to have chances to mentor some software engineer interns at my work. I mentored 5 interns in total and maximum 3 interns at the same time. This is a great experience to me and to be honest, I also learnt a lot while giving mentorship. So today, I’d like to share some of my ideas about mentoring junior software engineers.



1. Keep Your Mentee Group Size Small

I would admit that, at start, I was quite happy that I could mentor 3 interns at the same time. It was my first official experience practicing mentorship at work, so I was very happy that my capability was recognised by my superior. However, I found that I was too naive. More mentees means greater responsibilities and I would need to spare more time from my work to provide mentorship.

Why do I have to spend much time to mentee? Why not just assign the tasks and wait for results?

I suppose, Mentees usually are not familiar with team culture and norms when they just joined. They need guidance so that they can understand what to do and what not to do. In the beginning, they may not have any question because they would not know what to ask. Only when they actually start to work, will they find out that problems are everywhere. And because I am the mentor, I will be the first person they think of and ask for help. To let mentees be better adapt to work, I need to spend time for explanation and guidance.

I had maximum 3 interns with me at the same time, and they were doing 2 different areas of work, front end development and data warehouse development. While providing guidance to them, I had my own work to do as well. So it ended up that I had to work overtime.

Thus, keeping your mentee size small helps you mentor your mentees better, and put yourself in a more relax mode.



2. Prepare An On-boarding Guide

To minimise your time, you can prepare an on-boarding guide to explain fundamental questions. Probably you need to spend several hours to prepare it, but it’s really useful because it can be reused every time!

I did an on-boarding guide and here’s what I included in the guide:

  1. How to setup the development machine, including software needs to install and environment variables to setup. If possible, it’s better to also provide a way to verify if the software is correctly installed. There are often strange problems happening. It’s better to provide a way of verification so that the mentees can at least check own their own first.
  2. How to setup the project, including dependency installation, how to run the project and also environment variables to setup. This is definitely a must-do, otherwise, no one can work productively.
  3. Who to ask if general problems are encountered. New comers are not familiar with the team structure. When some problems happen, the mentor is the first person they think of. However, sometimes the mentor might not know much about some specific topics, and they still need to direct the problem to someone who is more familiar. So why not just specify the people map in the guide? In the guide, you can specify system module owners who is the most familiar with that module, so that your mentee can be self-driven and directly approached the person who is the most knowledgeable to that problem.
  4. List of video recordings of past technical sharing, tutorials or training. Sometimes we have internal trainings and sharing held, which can be recorded. Those trainings and sharing are often about our own projects or products. Having these links provide better opportunities to mentees to learn about the project by themselves and to mentors to save more time.
  5. FAQs for quick references on strange problems. No matter how well you prepared, there are always strange issues happening. For example, a weird error message on python project initialization can be caused by a newly created remote development machine having setup issue during the creation. These are unusual problems which happen rarely and cannot be found in the knowledge base. So it’s better to record this problem under FAQ session just in case it happens again and investigation time gets wasted.



3. Have Regular 1 on 1 Sessions

Mentors can be very busy on their own stuffs ans sometimes may omit the mentees. The best solution to this issue is to schedule repeated meetings with the mentee on a regular basis. It can be weekly or fortnightly (I do it fortnightly).

A 1 on 1 session can be short, such as 15 minutes, so that it does not create pressures to both sides.

Most importantly, 1 on 1 sessions are not meant for performance evaluation. The latter is too formal and makes people nervous. While the former is more relaxing, it can be just like chit-chatting. The purpose of 1 on 1 session is NOT to judge or evaluate, but to communicate and advise.

There are a few topics I often use during the 1 on 1 session:

  • How is it going recently? (A general question to warm up)
  • Do you encounter any problem at work?
  • Did you solve it, if so, how did you solve it? If not, how can I help so that you can solve it?
  • Does the work align with your expectation? If not, what is missing for you?

It’s important to let the mentee to speak out, so these questions are all encouraging the mentee to share their thoughts. Probably a mentor is more knowledgeable in certain fields and more experienced, but in this communication, everybody is equal on the same page. In this way, the communication can be helpful and positive, true thoughts can be shared and then real problems can be revealed and fixed.

In the end, mentors can also share about their views, including praising for what mentee have done well, suggesting areas which mentees can improve on. When speaking about improvement parts, it’s better to directly point out areas needs improvements with the focus on the fact only, and possibly provide a direction so that the mentee can know how to get improvement started.

In a word, 1 on 1 session is meant to align the expectations between mentors and mentees, find out the problems and solve it, on equal positions with respects.



4. Assign Tasks by Considering Difficulties

While assigning tasks to mentees, mentors need to understand the tasks too. Some tasks may be easy or small, and some tasks can be hard or big. It’s important to assign suitable tasks to mentees considering their experiences, capabilities and time.

What I did is that,

  • In the beginning, you can assign simple tasks such as logic corrections, simple unit tests, typo corrections which are easy to complete, so that the mentees can be familiar with the work flow and the code base first.
  • Gradually, when mentees gets more familiar, you can assign them some small features such as developing a small form, writing a consolidation API, or non-urgent bug fixes. For bug fixes, though mentors are more experiences who can spot out the cause and find solutions right away, mentors should not directly tell the answer to the mentees. Instead, mentors should encourage the mentees to read through the code base and understand the contexts on their own, and finally let the mentees to solve the problems own their own. In this process, advices and hints can be provided at appropriate time, since there are definitely some contexts which are very hard for mentees to figure out on their own (such as lousy logic designs in legacy systems, which nobody knows exactly how it works :x)
  • When mentees are ready, you can assign a non-urgent mid-size feature like a small project to them, so that they can start to work independently. You can provide them a rough idea, and let them try to design the feature on their own. You can then review the design and help to improve. After that, mentees can start to independently work by themselves. At this step, the mentee is already at the stage where they are capable to work independently. And I think it will be a good time for mentees to graduate 😀



Summary

These are what I learnt from the past one year experience of mentorship. To be honest, as a mentor, I am still quite newbie 🙂 Please leave your comments below to share your thoughts about mentorship so that I could also learn from you. Cheers~!

Featured image is credited to Pixabay @pixabay from pexels


Source link

Life Lessons : The Fourth Passenger

I have dropped the pen for a while but looking at the stacks of UN-shared life lessons and write ups !
I have to share this and lighten the vessel .

The fourth passenger is borne out of a whole lot of personal and virtual experiences, I really hope y’all able to get the message !

I boarded an “along” vehicle ,
Four passengers are to be at the back seat.

Though, I am very sure the back seat was originally designed to accommodate 3 passengers , but you know, prices of things have gone up!, even the drivers need to make ends meet and NURTW does not apparently care about the welfare of passengers
(if at all they ever did).
So they stuff the back seats with 4 passengers!

Well, on this particular day,
I was the third passenger,
It was barely convenient for us even before the fourth passenger joined us.

The driver drove on with the hope of getting the fourth passenger along the way.

I could not contain the thought of a fourth passenger joining us, it would be worse !

So, I decided to pay for the fourth (vacant) seat but I kept this plan to myself and stayed mute.

Keeping mute is not so nice but cunningly smart …..
You can’t blame me too,
We are all saving cost ! 😂.
No one knew my intention of paying for the fourth seat, 
We kept moving !

This is the exact plan…

I was actually waiting ….. to see if the driver would be able to make efforts to find a fourth passenger to shove to the back seat.

You know, that would determine my next line of action .
If he happens to find a fourth passenger, then,
I will reveal my intention of paying for the extra (fourth) seat 💺 ….. 😞!
And If he does not find any, I will just “throway face” and continue to enjoy the “free-spaced” ride.!

Well, …..

That’s exactly how lot of things are in life !
I have seen several life scenarios based exactly on this model!

Lotta people are waiting to see
 “if you would make it”
“If you could do it”
“If you could achieve it”

Before proffering their (long) “due” responsibilities, duties, and help ….

I have seen it played out a lot in life,
Lot of people would only step in to help you, do the right thing they needed to have done, only when they discovered you have been able to pull through without their actions and or in-actions.

Some people are denied their due benefits ’cause they were thought undeserving, or they have not made enough efforts.

Some are waiting to see if you are “worth” it, or whether you deserved it according to their own criteria before giving it to you!

As far as I was concerned ,
The driver did not worth getting paid for a passenger he has not found until he actually got one.

Lot of people won’t help you until you have made a positively resulted efforts.

That’s why your rich uncle or friend might not help you with your educational pursuit until you study hard and you graduate!
You know, that’s a point when you can actually do without their involvement!

That’s why your company won’t promote you at the due time until you work so much on yourself till they see other companies bidding for you.

In relationships,
A lot of people don’t value or rate their partners until their partners are valued by someone more than them!
It’s not like people really want to step in and assist you, they will only be forced to do so when they know you have grown to a level you can do without their so called assistance.

Psychologically, some people find it easier to help those that don’t actually need the help, than the actual needy ones !

The baseline message is
*TRY,
make EFFORTS ,
Help yourself ,
Build yourself *

Try your best on your own without necessarily depending on a virtual or promised help anywhere!

Lot of people would proffer lot of helps, advices , assistances when you are already up there, when you technically don’t really need their assistance and you will just wonder where were all these before you got here !

I can keep on with so many examples and (not personal) experiences ..

I was a newbie on some stuffs , 
I really needed some one to just put me through but my supposed helper (maybe sincerely)was too busy! 
But he came back looking for me to help me when he knew I have been able to get them fixed!

I needed a setup from a friend,
He didn’t give me, by the time he learnt I have made research and found an alternative and sure source of getting the same setup !
He proffered the same aid I earlier requested!

The company I worked with delayed my promotion but swept to action when they got the news of a bigger company fixing a virtual appointment meeting with me .

A lot !
Some scenarios are just too ridiculous!

If you don’t make (right) efforts to put your self up, No body will rate you !
Make (right) efforts !
Make efforts to get your fourth passenger and you would be surprised at how many were willing to pay for the fourth seat!
The fourth passenger ~ amfstacks
✍️🙏🏽


Source link

My Journey to Becoming a Google Developer Student Clubs Lead

Hello everyone, it’s Sai Ashish Konchada back after a hiatus for good. The past few months have been a rollercoaster ride, a wave of happy hormones with nervous adventures. It gives me immense pleasure to announce that I’ve been selected as the first-ever Google Developer Student Clubs Lead at my college. In this post, we will be looking into the journey from the application to the selection.



Table of Content:

1. What is Google Developer Student Clubs?

2. What are the roles and responsibilities of a lead?
i. Starting/Growing a club
ii. Host Workshops
ii. Build projects

3. How can I apply to become a Google Developer Student Club Lead at my campus?

4. The Google Developer Student Clubs Lead Application Form 2021

5. Timeline for GDSC Selection 2021 and the Interview Experience



1. What is Google Developer Student Clubs?

As per the official website, Google Developer Student Clubs are university-based community groups for students interested in Google developer technologies. Students from all undergraduate or graduate programs with an interest in growing as a developer are welcome. By joining a GDSC, students grow their knowledge in a peer-to-peer learning environment and build solutions for local businesses and their community.


Google Developer Student Clubs(GDSC) are like your college/ university clubs, powered by Google Developers. Every year, Google selects leads from across the globe who align with the vision of GDSC and want to empower their community. This year, there are around 352 leads selected across India. There are many first-time leads, as well as leads who continue the legacy initiated by the founder/former lead. It is not necessary if your college has an existing GDSC, then a lead will definitely be selected from your campus for the following year.



Who can become a Google Developer Student Club Lead?

As per the official website, these are the eligibility criteria to become a lead.

  • Have a minimum of one year left until graduation
  • Enrolled in an undergraduate or graduate program at a college or university
  • Can commit to the program for one year
  • Passionate about creating impact in the community
  • Strong technical understanding of computer programming and/or software engineering
  • Have experience with event planning or leading a team
  • Have some connection to the local developer community
  • Host an event ideally once a month, and at least every 3 months



2. What are the roles and responsibilities of a lead?

The 3 basic responsibilities of a lead include:



i. Starting/Growing a club

Google Developer Student Clubs Shree L R Tiwari College of Engineering

If you’re the first-ever lead of a GDSC, you found and set up the club. For this, you might have to talk to your respective Teacher Incharge of such programs at your college, taking permission from the respective Head of Department and Principal for the same. This varies from college to college, so get in touch with a senior or teacher for the same. Being the Technical Head of my college I already was in touch with my respective HOD and Technical Incharge. I wrote a letter to them, explaining about GDSC, its benefits, the impact it creates, and permission for the same.

Once you get the approval, you have to find a Faculty Incharge and form your Core Team. Find a faculty in charge, who actively takes the initiative for promoting such activities in your college, manages any scheduling conflicts, and provides insights about the events you conduct, suggests improvements.

Forming the core team depends on you. You have the complete freedom to choose the number of members in your team, the hierarchy, and the domains you want to have. It is recommended to have 5 people in your core team as at the end of the year, Google sends 5 members(apart from the lead) the Graduation kit consisting of goodies. However, as mentioned earlier you can have more than 5 people and choose the top 5 people working diligently towards the club activities.

There are 2 widely followed approaches in forming the core team. The first one is the Interview process. You create an announcement, people apply for the respective roles, you shortlist, conduct interviews, and choose members. The other one is that if you already know the people in your college and see people fit for the role, you choose them. My suggestion is to choose people who possess not only strong technical knowledge but also the ability to deliver sessions, connect with people, solve their individual doubts, give creative ideas for the growth of the clubs. You can choose to add a set of Behavioral questions to test this aspect.

If you’re the lead of an already existing GDSC, get in touch with your former lead, understand their vision, the events they’ve conducted, how they organized and dealt with various situations, how they can collaborate with existing GDSCs and other organizations, how to approach speakers and sponsorships for events, etc. Your lead is the best person you can find to elaborate in-depth about the program.



ii. Host Workshops

Introduction to Hacktoberfest.png

After forming the core team, you can kickstart your journey with the Orientation session. You’d be provided with a timeline of events conducted by Google. You can choose to conduct those events as well as events of your own. I’ll be writing a separate blog on how to create, promote and conduct your GDSC events once you become a lead. This is one of the workshops we conducted, where we introduced students to open source, how to contribute to it, and get started with Github. You can find the recording of the workshop here.



iii. Build projects

Solution Challenge GDSC

In addition to hosting events and conducting hackathons, an integral part is the hands-on experience. GDSCs across the globe are known for creating impact among society. A GDSC should identify problems in their university or local community which could be solved via technology. One example to solving a university problem could be to build an online proctoring software, or automatic attendance system, or automation of daily tasks custom-built according to the needs of the university. Apart from these, GDSCs can host demo days, where they display the projects built by the teams of their club and also participate in the annual solution challenge. Read in-depth about this amazing global challenge here.



3. How can I apply to become a Google Developer Student Club Lead at my campus?

Become a Google Developer Student Club Lead at your campus

Applications to apply for becoming a lead, opens once every year depending on the region you belong from. You can view the timeline and apply to become a lead here.



4. The Google Developer Student Clubs Lead Application Form 2021

The Google Developer Student Clubs Lead Application Form 2021
When you apply to become a lead, it redirects you to Advocu where you fill out your application to become a lead. You’ve to fill out your basic details, share links to your work and account on Facebook, Github, LinkedIn, Medium, Qwiklabs, Stack Overflow, Twitter, Portfolio, and website link(if any). I strongly recommend you to build a strong profile on these platforms and be actively engaging, sharing your knowledge with the community.

Then comes the 3 major questions:

What is your motivation to run a Google Developer Student Club at your College?

What is your experience in leading a project or a team

What technology do you find most interesting and why? What is your experience with this technology?

My Tips:

  • Please tailor these questions according to your skills, experience, and expertise
  • Don’t take model answers or points from other applicants
  • Be real
  • Be unique
  • Always proofread and use a Grammar tool, such as Grammarly
  • Have keywords in your answers. If technology is asked, mention all the names of technologies you have working knowledge on
  • Be active in leading clubs/communities from the very beginning. Experience proves your leadership, communication, and community building skills rather than plainly stating it
  • Mention statistics where necessary. Example: In the Technical Carnival conducted in our college last year, we had a total of 600 active participants.
  • As mentioned earlier, have a strong online presence and community contribution

Apart from this, you’ve to record a 90-second video and show us why you are the right person to be a GDSC Leader at your College

Choose the best points and practice beforehand. You don’t need to have a professional mic, camera, or edit videos in order to get selected. Make sure you are perfectly audible and visible. You can also choose to display your points in a presentation but make sure you are visible in the video.



5. Timeline for GDSC Selection 2021 and the Interview Experience

I had applied to become a GDSC Lead on 20th April 2021, the deadline being 11th May, 2021. After applying, you get a mail with the subject, Thank you for applying [Developer Student Clubs Application Process – Sai Ashish Konchada]

Thank you for applying Developer Student Clubs Application Process - Sai Ashish Konchada

If you get shortlisted among the application process, you get an email with the title, Next Steps [DSC Application Process – Sai Ashish Konchada]

Next Steps DSC Application Process - Sai Ashish Konchada

I scheduled an interview call for May 18th. The interview lasted for 15 minutes. The interviewer was very friendly and created a friendly atmosphere by mentioning to treat it as a discussion rather than an interview. To the best of my memory, a few of the questions were to talk about myself, the GDSC program, my previous community experiences, my plans for GDSC. If any lead is reading this, I urge them to share their interview experience too.

On July 15, I received an email – [Google Developer Student Clubs] Congratulations!

Google Developer Student Clubs Congratulations Mail

And I got selected as the Google Developer Student Clubs Lead for my campus! As per the instructions, I acknowledged my confirmation and began laying the foundation of GDSC SLRTCE.

And that’s a wrap! I hope this blog post finds an aspiring lead, answers his/her doubts, and gains insights about the Google Developer Student Clubs Program. If you’ve any queries, drop them down in the comment section below and I’ll try to answer it as soon as I can. Until the next one, cheers to learning 🥂



Did you know you can join our club too?

Google Developer Student Clubs Shree L R Tiwari College of Engineering




Source link

Tackling Technical Debt: Founding OutSystems

Recently on the Dev Interrupted Podcast, OutSystems CEO and founder Paulo Rosado joined us to chat about his path to founding the company, advice for successful leaders, and the growing threat of technical debt for businesses around the world. The conversation below has been edited and summarized for length and clarity.



Tell us about OutSystems’ founding story. What inspired you to start the company?

In February 2021, OutSystems was valued at $9.5 billion dollars – but it certainly didn’t start out that way. The idea behind OutSystems was decades in the making, and its mission stems from what I observed after moving to Silicon Valley back in the mid-nineties.

My journey in technology began when I graduated with a degree in computer engineering from Universidade Nova de Lisboa in Lisbon, Portugal and moved to the US to get my Masters in Computer Science from Stanford. Afterward, while working in Silicon Valley, I began to understand just how much of a problem technical debt was.

While working on a very large engineering team, we were faced with tackling a gigantic project in Java and I realized the issues of releasing and maintaining code sustainably. The lack of productivity in the software development process was appalling. Fixing this problem is ultimately what motivated me to found OutSystems.

Before founding OutSystems, there was a small company I founded and later sold, which focused on internet and intranet projects. It wasn’t a bad company, but we kept failing. Projects were never delivered on time or on budget.

We would think to ourselves, “We’re smart. How is this possible?” Our inclination was to blame the requirements of the project, labeling the scope as incorrect and adjust from there. However, we began to realize that the companies hiring us for these projects wanted us to make changes as we were developing in response to rapidly changing environments.

The issue we began to face was the continual accumulation of technical debt. We would reach first production and realize we had built something users didn’t want, requiring us to go back and rework the stuff we had just built.

“We came up with this realization that the problem was not that the requirements up front were wrong. The problem was that the cost of changing wrong requirements, which are a fact of life, is very high.” – on the Dev Interrupted podcast at 6:03

This phenomenon was occurring in 90% of projects at the time. Things were always over budget and always late.

Today, it’s easy to take this for granted because concepts like Agile, DevOps, CI/CD are mainstream. But at the time, you had to build software the same way you build a bridge.



Why is technical debt a challenge for companies now? How has this problem changed?

Technical debt has become a large problem for businesses, and one that only compounds with time. Tech debt doesn’t have a singular cause – it’s the accumulation of several factors.

Over the course of my career, I’ve seen first-hand the complexity brought about by the evolution of software development. For instance, we’ve seen an explosion of languages, paradigms and frameworks that can all be used to achieve a solution. Often these languages are dispersed with no connections between them, so tracking these dependencies requires a great deal of sophistication.

In addition to this, turnover within the development team is a critical problem that leads to technical debt. The moment a company loses a developer, the knowledge accrued by that developer also departs the company. The hole left behind is complex, including code, frameworks and intent behind how their systems are structured.

It’s been my experience that a lost team member can take as much as 20% to 30% of the fundamental knowledge of a system with them. Reverse engineering their work is both time-intensive and inefficient.

Companies have tried to corral this problem by investing in coding standards. While these constraints can help mitigate the loss of a valued developer, our research indicates turnover remains a significant problem.




OutSystems recently released a study on the effects of technical debt. What were its findings?

Recently, OutSystems surveyed 500 large companies around the world to examine the cost of technical debt facing businesses and uncover the challenges companies face as they confront its causes. The results from the companies surveyed were many of the same things I’ve observed throughout my career.

It’s important to note that while the causes of technical debt have largely remained the same, the pace at which technical debt occurs has grown substantially.

“And so it’s a hack, right? What we call a hack at OutSystems, they did a hack to just release the software quickly. And those hacks compound into technical debt.” – on the Dev Interrupted podcast at 27:11

The survey we conducted isolated three major causes of technical debt. They are as follows:

  1. The amount of developer frameworks. An increase in frameworks leads to an increase in technical debt.
  2. Developer erosion. Employees leaving an organization and taking legacy knowledge with them.
  3. Compromises in quality of architecture and code. Often caused by a shortsighted view that what needs to be done now is more important than long-term stability of the codebase.

In the past, companies believed they could buy their way out of this problem, but that strategy has proven ineffective. The reality is, the most successful companies must build the software they require to meet their business needs.

Simply purchasing what you need doesn’t solve your problems because even purchased systems must be cobbled together, requiring unique API’s, unique UI’s, unique portals, and unique mobile applications.




Does OutSystems play a role in helping companies cut tech debt?

The core of what we do at OutSystems is focused on tackling those three fundamental problems. We understand that technical debt amasses slowly over time, through a myriad of decisions that appear much smaller at their onset than their totality would suggest. Once these “tiny” decisions become a major problem, they inhibit investment in current operations and future innovations.

The increasing pressures of today’s fast-paced business environment often push companies toward decisions that spiral into technical debt. The good news is that by creating a development process that marries short-term deadlines with long-term strategic goals, it’s possible to “pay down” that debt.

I believe that any company is capable of whittling away technical debt with the correct tools and processes, and I founded OutSystems because companies shouldn’t have to choose between building fast and building right.

To learn more about technical debt, how to combat it, and what to expect in the future, you can download the 2021 Technical Debt Report on our website.

This article is based on an episode of Dev Interrupted. The only podcast made exclusively for dev team leaders, it features expert guests from around the world to explore strategy and day-to-day topics ranging from dev team metrics to accelerating delivery.


Source link

Developer Productivity Masterclass – interview with Leonid Blouvshtein

On December 7th we’ll host a free master class with Mykyta Protsenko, Senior Software Engineer at Netflix. Michael Wood, Field CTO, HashiCorp. Ryan Menezez, Software Engineering Manager, Meta. And Leonid Blouvshtein, CTO of Lightrun.

I got a chance to grab Leonid and make him sit down for this quick interview…



Q: Tell us a bit about yourself?

I worked in several successful startups while most of my experience is with distributed systems that require high performance. This was after I graduated from the elite 8200 intelligence unit of the IDF. I sold my first startup at the age of 22. I founded Lightrun a couple of years ago to revolutionize the way developers interact with cloud production applications.



Q: What would be the chief topics you’ll discuss in the master class?

I want to focus on the following topics:

  • Developer Productivity at Different Growth Stages.
  • The importance for the developers to embrace the DevOps culture and adopt observability in the development workflow.

In the past decade, the way we build and deploy software has changed completely. We moved from on-prem deployments to VMs in the cloud to container-based environments. With the rapid change in the ops world, companies also changed their methodologies.

A lot of ownership is moving towards the developers and developers nowadays need different tooling and processes than what they needed 5 years ago, and organizations should adopt this change.



Q: Aren’t the Problems startups run into different from the problems in major companies like Meta and Netflix?

Yes, and no.

The scale of Netflix or Meta requires a level of scale that brings with it challenges we all hope to face. But probably won’t in the short term. But there’s still a lot of common ground we can build thanks to the componentized nature of the market and shifting story of tooling.

Mistakes you make today in the core team building the MVP can bite you back when you try to scale. The technical debt we incur today can become the source of long-running problems. A small investment in doing things “right” at this stage can make a big difference in the future.



Q: What excites you about this master class?

I’m very excited about the panel we brought together. Netflix, Hashicorp, and Meta are three titans of industry. Mykyta, Ryan, and Michael have a lot of experience with high scale fast-growing systems and engineering organizations. I think the panel will provide us with a lot of insights into the different approaches, but even more interesting is the consensus we can reach.

I think through consensus we can uncover underlying truths of developing that might be less obvious.



Join Us

Thanks Leonid for this great insight. Please join us on Tuesday, December 7th for this master class to learn more.


Source link

Who am I?



WTF? Oh, Shit 💩

Yes it’s exactly which you have just read, it’s completely describe such a Shit, but why?, the question should be why is it called shit?
In this posts I will share you everything you need to known as a developer, I will tell you exactly as I have felt it without skimping anything. 😇

let important = "If you are not interested please not continue reading";
console.log(`Hey 😄, $important`);



Let me introduce it 😌

My full name is Emanuel (you can call me Manu), I was born in Uruguay but actually I’m located in Spain 🇪🇸, I suppose you think I’m older, but no 😜, at the moment I’m twenty years old, I started coding when I was 14 years old. Maybe you are asking for why I started coding at this age, the answer can be summarise in one word:
Curiosity 😙.



What will this series talk about?

It’s really important for me, I’m sure you have already heart that developer life is incredible, blah, blah blah 🤓, a lot of suppositions without any fundament, the typical phrase:

Coding will be you millionaire 💰.

All that glitters is not gold, you have to take into accounts a couple of things you aren’t known, really all of us are ignorant 🥸, we think we know everything, we think we are gifted, but no. I’m overwhelmed about the society’s ignorance. Almost people get settle with their lives, making a cyclic and eternal life. I’m here 🤨 trying to show you why you shouldn’t stop learning, how is exactly a software engineer life?

Really, let me tell you, you do not have to be agree with me 🥲, it’s only my point of view based in my experience and knowledge, this is why I have learnt in 7 years as software engineer, I will be more transparent to you than with my family 🤐.

Every Friday I will post a new story in this series talking about all this topics, I recommend you subscribing to the newsletter to get up to date with my latest post. Run this code in your mind:

let postReminder = Reminder("Shit Post 💩", "Manu will release a new post in his story", .urgently, .everyFriday);
me.setReminder(postReminder);



Finally

I’m here to help you growing in your professional career, if you regarding any question, suggestion or complain please do not hesitate in contact me. I’m very glad in helping you 🤤


Source link

What to do if you're a bottleneck

Jackson is a go-to person when it comes to MongoDB.

You have a problem — you go to Jackson. He’s an expert. Of course, you can go to anyone else – it’s a free world. You can go to Molly if you want. But you know what Molly would recommend, don’t you? She’ll tell you to ask Jackson, that overworked guy with a giant todo list.

Let’s talk about what to do if you ended up being a Jackson and need a way out.



What kind of a bottleneck are you?

There are two different kinds of overworked Jacksons: knowledge bottlenecks and expertise bottlenecks.

Knowledge bottlenecks are the ones who answer questions:

  • Who owns Payment API?
  • Which database has client emails?
  • When is our next release?

If you’re one of those, write documentation. Sorry for such trivial advice, but boring problems need boring solutions.

It’s worth writing docs even if people don’t read them. Sounds stupid, but it will serve as your second brain from where you can quickly copy answers.

Watch out for an urge to share your screen and demonstrate something. It’s always better to record a video (or a gif) and share it instead – this way, you will be able to reuse it later.

That was all about knowledge bottlenecks.

Expertise bottlenecks are trickier. They don’t just answer questions — they solve problems:

  • This program crashes for Netherlands users.
  • My DB query is slow.
  • Our photo gallery page leaks memory.

This situation is much more complicated because you need more experts to share the load. But unfortunately, there are no books or tutorials you could give to somebody and turn them into an expert – they need to build the expertise themselves. And it takes time.

But how to accelerate the process?



Limited opportunities

If someone wants to learn how to play the guitar, they need to practice playing the guitar. Likewise, if one wants to learn how to fix memory leaks, they need to fix memory leaks.

The tricky part is there are much more opportunities to play the guitar than memory leaks to fix. They don’t happen every day.

Zoom out now and look where you ended up: people call you whenever a challenging problem arises because nobody else has a similar experience. And nobody else has a similar experience because you solve all the challenging problems. A chicken and egg situation.



Growing new experts

The naive advice would be to stop doing what you’re doing so that others can practice and build necessary expertise in time. But, unfortunately, it’s overly utopian – a few companies have the luxury of accumulating unsolved problems while their best specialist sits idle and waits for new experts to emerge.

But I’m not saying it’s impossible – there is a way to grow new experts without slowing down the process. Here it is:

  1. Pick one successor to mentor. Learning opportunities are scarce resource, so resist the temptation to pick more than one.
  2. Redirect all requests to this person.
    Need help? Ping Nelson, he knows this stuff.
  3. Be available for this person.
    Answer all their questions as soon as possible, pair program or pair debug when necessary.

What to do if you're a bottleneck

It works because:

  1. The company will not slow down in critical situations – if the time is tight, the mentoree can ask you for help.
  2. You can tune your involvement depending on the circumstances to manage risks and guide the learning.
  3. This person starts earning credibility from day one, solving real problems with your invisible help.

In the beginning, be prepared to play broken telephone answering proxied questions:

What to do if you're a bottleneck

It may look like a waste of time, but it’s far from it. Yes, the future expert acts as a proxy, but they learn about the domain. Even if it’s a proxy, it’s a caching proxy:

What to do if you're a bottleneck

As their experience grows, they will start asking more complex questions:

What to do if you're a bottleneck

This is the point where you can return to your expert’s duties, which you now can split with another person:

What to do if you're a bottleneck

This is a cross-post from Resilient Systems – a newsletter about strategic software engineering.


Source link

What is The Serverless Edge?

Originally published on www.theserverlessedge.com

Reading Time: 4 minutes

Serverless computing has become a term for how we build software. It is more than the compute; it is a mindset. A DataDog survey in 2020 stated that 50% of AWS users had serverless components, and container users are flocking to Lambda – one of the AWS Serverless Services.

Many experts and leaders are still not convinced that Serverless will lead to the Future of Work and Emerging Technology. People don’t make the connection. What part does it play in the Future of Work and the 4th Industrial Revolution? We will explore this to help you learn in our blog content and case studies.

We believe serverless is a gateway into many new ways of working – a technology-led, low friction, and high-value future.

Why serverless?
It represents the cutting edge of how we build business and web applications. Every business needs software, it needs it fast, and it must be cheap. Imagine if you could combine that with the ability to create a fast feedback flow and have an unlimited selection of tech to use? This is what Serverless means for business leaders. Unfortunately, the serverless term is quite technical and low-level.

We want to change that. We want to support the leading edge of software development to create business capability and performance. No immense complexity security problems or large data centers. Just give it to me straight, quickly and don’t make me spend loads of money on code.

Many think of Serverless as a new method of compute, which is incorrect. It is not comparable to containers. The first Serverless service in AWS was S3 – the Simple Storage Service. The definition of Serverless gets quite opinionated, so it’s explored further in this article by Ben Kehoe.

How is it linked to the Future of work?
Software is eating the World – a famous quote from Andersson in 2011. Digital is not just a channel; it’s a new mindset and will continue to redefine our workplaces into the ’20s and the ’30s. Unthinkable new business capability can be co-created with the Serverless mindset. This leads to different ways of working, collaboration patterns, the ability to reimagine work and reinvent how we deliver value to our customers. There are new business models that are generating millions of dollars, and textbooks cannot keep up.

Scale down to scale up
Technical Change for this future has already happened. Organizational change is still behind – people move slower than technology. This is fact and not criticism. The days of having 300 people in a massive programme of work are fading out. It’s wasteful (many people are in coordination roles) and slow. Imagine you could shrink down to a single, cross-functional team that included everyone required to create the vision, discover, decide, build and deliver? Serverless gives you the ability to develop software with minimal hand-offs, so you can scale down to scale up.

Technology of tomorrow
We are living in fascinating times. Artificial Intelligence has never been more accessible and powerful. We can achieve results now that we didn’t dream of a year ago. IoT and the sensor revolution expands weekly, touching every industry. Connectivity and networks invent every few years as standards evolve. Interfaces with computers created in the 1960s are finally starting to see a revolution. It has taken us around 50 years to get voice to a state that it feels natural. Quantum compute, capable of incredible speeds, is supposedly around the corner. What does this mind-boggling list have in common? Only ten years ago, if you wanted to bring in one of these capabilities into your business, the first step was to request and write a substantial cheque and wait several months. Today a student at college can integrate any of these technologies with her Serverless application in minutes, and the cost is minimal.

Yes, you can use serverless to build a webpage and process payments for your business. You can also think of software as a series of events and start introducing exciting new technology into your business. An IoT use case? Need to process lots of data? Need a Voice Assistant? Need to connect many disparate systems? Serverless can make all of this a lot easier.

The Serverless Edge
The Serverless Edge title implies that we will keep on the leading edge of business. We will:

  • focus on business
  • explain how the latest technology is evolving and join the
    dots for you
  • make predictions about the Future of Work and how new
    technology will change the game, and
  • comment on the ever-complex challenges of running efficient
    engineering functions.

Serverless brings all this together as it’s a mindset, a serverless edge mindset that encourages Simplicity, Speed, Innovation, Value and the Customer. We understand the details, but we are not going to focus on Functions, Cloud Configurations or Containers – these are critical, but other sites are more comprehensive. We will retain a Serverless mindset and focus on Business Value.

The Serverless Edge will stay ahead and give you insights into the Serverless Mindset, the Future of Work for business and engineers and the impact of new technology. We will look at all of this through the lens of business value and (hopefully) use plain English.


Source link

TechLead or DevLead ? – DEV Community

Hi,

Sometimes i read post about techlead but often oriented to the technical stuff, best practice etc. I think that Leading role can be separate in 2, the tech for one et and well “dev” for the other. In fact, i think the other is more about soft skill. Because being a great developer tech-wise doesn’t not necessarily means that you can teach, give some advice with the right word.
I think that Leading demands skill like Patience, Empathy, because you need to deal with different personnalities, and it’s not always easy.

What do you think? Do you make that difference, or see that Leading is like 2 jobs in one ?


Source link