Posted by: lrrp | October 28, 2021

9 Habits I Wish I Had as a Junior Developer

Have you ever sat down and taken an inventory of your habits? Habits are what make us who we are.

Good habits help you to become who you want to be. Bad habits will slowly turn you into someone you don’t want to be.
After more than 20 years as a software developer, I’ve grown some habits that I’m proud of and some that I’d rather get rid of.

Most of the time, I wasn’t aware of my habits, but looking back, it’s pretty clear to me which habits were helping me grow and which were hindering me. This drove me to take an inventory and write about good developer habits to maybe inspire you to do the same.

If you’re starting as a developer, have a look at the habits outlined below and ask yourself if they would help you become who you want to be. Be conscious of your habits and actively nurture them to become a great software developer.

Volunteer for Things You Don’t Know

At the start of your career, you don’t know a lot. You come into that new project and feel like an impostor because they’re paying you money even though you don’t understand half of the acronyms, technologies, and frameworks they’re throwing around in each meeting.

And you only faintly know the other half because you googled them.

Replace “At the start of your career” with “At the start of any new project”, and you have a pretty good summary of a software development career. Every new project, we start over. There are new people to meet, new requirements to understand, and new frameworks to learn. Every single time.

This is why it’s important to learn new stuff. If you just keep doing the things you know, you’ll never be confident about starting a new project. There will always be the fear of the unknown. If you make it a habit to volunteer for tasks you don’t know anything about, you will constantly learn new things.

If the build needs fixing and you’ve never worked with the build system, get on it! You’ll learn about build management. If there’s a bug in the JavaScript frontend and you’ve only worked on the Java backend so far, fix it! You’ll learn new Javascript idioms.

Doing stuff you’re not confident about doing is a great way to grow. Be sure to manage other people’s expectations towards you, though. Don’t pretend you’re an ace. Tell them you haven’t done it before but you would like to learn.

Ask to Pair Up
If you’re stuck and can’t get started with a task because you’re unfamiliar with the context, ask someone with experience in the topic to pair up with you.

A pairing session is a great way to kick off the work on a task. Discuss the requirements with your partner until you have an understanding of what is expected. Then, discuss the solution.

What’s the context? Which codebase(s) do you have to touch? What are the explicit and implicit conventions in the codebase?

But you can make pairing even further. Instead of just pairing up to kick off a task, schedule more time with your partner. After kicking off the topic, start working on it together. You drive, your partner gives advice, then the other way around.

This way, you even get to learn how your partner thinks and solves problems. You can only profit from it! Even if it’s just a new IDE shortcut you learned.

A note on working from home: due to working from home, I struggled with things that would not have been a problem before. I hesitated to ask teammates to pair up with me. What was a simple tap on a teammate’s shoulder in the office became a high barrier when working remotely and communicating with video conferencing software.

If that is a problem in your team, talk about it with your teammates (in a retro, for example) and it will be much easier afterward. Turns out it’s just a habit to re-learn.

Ask to Pair Up

If you’re stuck and can’t get started with a task because you’re unfamiliar with the context, ask someone with experience in the topic to pair up with you. A pairing session is a great way to kick off the work on a task. Discuss the requirements with your partner until you have an understanding of what is expected. Then, discuss the solution.

What’s the context? Which codebase(s) do you have to touch? What are the explicit and implicit conventions in the codebase?

But you can take pairing even further. Instead of just pairing up to kick off a task, schedule more time with your partner. After kicking off the topic, start working on it together. You drive, your partner gives advice, then the other way around. This way, you even get to learn how your partner thinks and solves problems. You can only profit from it! Even if it’s just a new IDE shortcut you learned.

A note on working from home: due to working from home, I struggled with things that would not have been a problem before. I hesitated to ask teammates to pair up with me. What was a simple tap on a teammate’s shoulder in the office became a high barrier when working remotely and communicating with video conferencing software. If that is a problem in your team, talk about it with your teammates (in a retro, for example) and it will be much easier afterward. Turns out it’s just a habit to re-learn.

Talk about What You’re Doing (and What You’re Not Doing)

I don’t remember how often I have eagerly taken on a task, thinking I’d be done within a day, but I end up still working on it a week later. It gets better with experience, but I still find myself making too optimistic estimations. There are just too many reasons to make an optimistic estimation:

the pressure to deliver this new feature quickly because the deadline is looming,
the pressure to look good among peers,
things just not working as I expect them to (this is the one that’s most commonly throwing me off, even with years of experience),
and a lot more .

Chances are that most of your estimations end up being too optimistic. What can you do about that?

You can manage expectations along the way.

Continuously talk about what you’re doing and what is holding you up. With “continuously” I don’t mean that you should provide a status update to the whole team every 15 minutes. But make sure the relevant people know where you stand at the start or the end of the day, at least.

So, if your manager / team / project manager / product manager / stakeholder expects results from you, give them a quick update every day: “This is what I’ve been doing. This is the next step. This is a problem I’m facing. These are the options.”

This will let everyone know of your progress. No one will blame you if you’re hitting a wall, as long as you kept them in the loop.

This will make discussions of the type “Why did that take so long?” a thing of the past. As an added benefit, the status update will trigger discussions that can help solve problems. In the best case, this status update is ritualized in the team. It’s commonly called “daily standup” where every team member quickly updates the rest of the team about their progress and problems.

But even if you have a daily ritual like that, take a couple of minutes to think if anyone should be updated that is not part of the daily ritual. Should they be included? Or should they be updated through some other mechanism?

Make it a habit to regularly update the people that have an interest in the results of your work.

Write a Blog

I’m probably not the first person you’ve heard saying this, but I’ll say it nevertheless: write a blog!

It doesn’t even have to be public. It can be a couple of pages in a company wiki or a collection of GitHub repositories with example code and a couple of lines of explanatory text.

Why?

Because writing with the intention to teach others (even if it’s just future you) is a great way of learning and growing.

Write about how you solved a gnarly problem. Write about how to use that new and shiny framework you always wanted to try. Or write a journal of what you did each week (this will also help with the “talking about what you’re doing” habit because you can look up what you’ve been doing).

I have started a blog a couple of times. It’s hard to keep the motivation up in the beginning, because no one will read your blog posts. It feels strange to write into a void. So I stopped. Then, I started my current blog 3 years ago, writing without an audience for half a year. I noticed only then that my robots.txt file didn’t allow search engines to index my blog!

So I changed my robots.txt file and people actually started to read my stuff. Not many, but it gave me the motivation to continue. So, I pulled through, tuned my writing skills along the way, and grew my blog to > 200,000 page views a month.

All because I started writing about frameworks I wanted to learn and problems I had solved so that I could look my articles up again when I needed them. Not because I wanted to create a big audience. Blogging is a chore at first but can grow to be very rewarding if you stick to it. If you do it with the intention of learning and teaching, you will not only learn a lot, but other people will notice your blog eventually and it will open a whole world of opportunities.

Have a Notebook and a System

I’ve only recently grown to be a big fan of notebooks. Not a computer notebook, but a real, paper notebook. I take it (and a pen!) wherever I go, so I can take notes about whatever strikes me as important at any time.I take notes when I listen to a talk, or when I’m waiting for the bus, thinking about what I could make for dinner this week.

I also use the notebook to maintain lists: books I want to read, frameworks I want to try out, features I want to add to my side projects. Most importantly, I use it to take notes while reading books, because that conserves the learnings from the book.

I’m writing down everything that weighs on my mind. If I don’t write it down, it will keep my mind busy, sometimes to the extent that I’m getting anxious and have trouble sleeping. The reason I’m getting anxious without my notebook is that I don’t trust my memory. If you have a great memory and can recall everything that you have thought about a week ago, you probably don’t need a notebook. If your memory is as patchy as mine, though, it will make a world of a difference to your peace of mind.

To build trust in your notebook, you need a system. You need to convince your mind that whatever you put into the notebook will not be lost. Create an index on the first couple of pages of the notebook to make the information retrievable. Then, make it a habit to review your notes regularly and process them.

To process the notes I’m taking while reading a book, for instance, I review the notes whenever I’m done with the book and write a book review on my blog. Almost no one reads these reviews, but the process of writing the review makes the things I learned stick so much better.

Keep Notes about Your Wins
Having a notebook can also help with the next habit: documenting your achievements.

As I said, my memory is patchy at the best of times. I can usually remember what I had for lunch yesterday, but if I’m deep in focus and spending brain power on some gnarly problem, the halftime of my memory goes down considerably.

That’s why I like to document my achievements at the end of the day. It’s usually not big achievements, but small wins – like having beaten a bug, or having finished one of the many steps towards adding a new feature to the software I’m working on. I also document personal wins like having stuck to my morning workout routine.

I just create a list of bullet points each evening in my notebook, but it’ll also work with a digital medium like a spreadsheet or whatever you’re most comfortable with – as long as you stick with it. Over time, the achievements aggregate. You might want to mark the ones that are most important to you so you can easily find them later.

Then, on an occasion like a performance review, you go through that list, find the achievements that are relevant to that occasion, and list them out to prepare. Performance reviews always work out better when you’re prepared. Having a list of your achievements also helps in everyday situations to talk about what you’ve been doing (see habit “Talk about what you’re doing”).

Have a Time Slot for Important Tasks

At the end of the day, I often feel I haven’t accomplished anything. While it helps to document your wins or even just the things you did, you still need to actually do those things. It happens quickly that you go from meeting to meeting and suddenly the day is over. After a meeting, you want to continue the task you started before the meeting, but just when you’ve warmed up, the next meeting starts. And after that meeting, you have to start over, because you lost the context.

Context switching is killing productivity.

If there’s one thing I learned to be productive, it’s having a dedicated time slot for things you want to get done. If you don’t have a pre-planned time slot for a task, chances are slim that you will get started on it. It will be eaten up by everyday work or other planned work.

There isn’t a single way to implement a time management habit, and, to be honest, I’m hopping from one productivity method to the next every couple of months. But the core is always the same: block some time in your day for the things you want to get done most. I block an hour in the morning, before work, to write articles for my blog (or for other blogs, like this one). Most days, I also block an hour in the evening, when the kids are in bed, to work on any side project I might have.

Currently, I have a Trello board with one column for every day of the week where I put the tasks I want to do in the morning and the evening. Once a week, I update that board with the things I want to do in the next week, so I don’t have to waste my precious blocked time thinking about what to do next.

I have a very similar Trello board for my software developer job. Every morning, I think of the things I want to do and put them into the column for the day. I also block at least 2 hours of focus time in my calendar every day, so that my co-workers don’t try to schedule any meetings at that time. That’s when I get through my list of tasks.

It doesn’t really matter how you manage your time, but it’s important to do it and to make it a habit. Otherwise, your days will be eaten up by things that are not important to you.

When Stuck, Take a Break

As software developers, we tend to get stuck a lot. And boy, does it piss me off when I’m stuck and don’t see a way out. It’s such obvious advice to take a break when you’re stuck, but it’s so hard to do. “I’m so close to solving the problem, I can’t take a break now!”

Also, taking a break now would mean I would have to warm up to the topic again later. Why should I deliberately switch contexts when context switching is the number one source of wasted time? When you’re stuck, you’re not thinking straight. You’re thinking about how stupid it is to be stuck with this problem, how easily your teammates would probably solve it, and why they always get the easy tasks. But you’re not thinking about how to solve the problem.

Take a break and work on something else for a time. Or even better, try again the next day. Getting some distance to the problem will allow you to see solutions you were blind to before. If you haven’t tried this before, you won’t believe how often a problem is “just solved” the next morning. Mostly because you see a path to a solution that you haven’t seen before.

Now, it’s easy to say to take a break, but how do you identify that you’re currently in “stuck mode” and then persuade yourself to quit working on the problem for a time?

I’m honestly not very good at this myself, because I usually WANT THIS DUMB TASK OUT OF THE WAY so I can show that I’ve achieved something! But what I found that helps me is to divide my day into 30-minute slices and have a quick recap after each of those slices. This technique is called the Pomodoro technique based on those tomato-shaped kitchen timers.

After each Pomodoro unit, I’m asking myself if I’m still working in a “solution mode”, or if I’m stuck and should work on something else for a while. A nice benefit of the Pomodoro technique is that you can use the end of a unit as a trigger for other habits.

I use it as a trigger to stand up from my chair to stretch my muscles and drink some water, for example. This is sometimes called “habit stacking”, because you’re stacking one habit on top of another, and it’s very effective. If you want to read more on habits, I can warmly recommend the book “Atomic Habits” by James Clear.

Don’t Chase Silver Bullets

I wrote a book on a specific architectural style and I regularly get emails saying “I love that architecture style and I want to apply it to all of my projects! How can I do that?”.

Can you guess my answer to that question?

There is no single architectural style that applies to all problems out there.

You build a plain CRUD API when it’s a small project. You build a more sophisticated Hexagonal Architecture if you have a complex domain model. And you apply any of a hundred different styles when you’re building microservices in a specific context.

Similarly, there is no single framework you should use for every single project. And there is no single best programming language or coding style.

Don’t fall for silver bullets. They don’t exist.

Having an opinion is good if it’s backed with good arguments. “This is the best architecture style” or “I’ve always done it like this” are not good arguments and people will see through them.

Just imagine you have a developer on your team that has an opinion on everything and always wants to do things their way, “because it’s the best way”. You would get tired of that very quickly. Don’t be that person.

Build Those Habits!

Wow, this article got longer than I expected. I hope it provided some inspiration on what to think about when growing your software developer career. I certainly haven’t mastered all of those habits, but I’m trying to get a bit better every day.

Pick the habit that resonates most with you and try to consciously apply it in your everyday work.

And how not to be one

Meet Bob

Bob is an extremely ambitious and overachieving developer.

He works hard, refines his coding skills on a daily basis, and always finishes a project on or ahead of time — eager to get started on his next project. You can look at his code and immediately intuit that he’s a master at designing and architecting beautifully written code. He loves everything his job has to offer and because of that, he shows up every single day with an energy that allows him to pound out value like a machine. He feels on top of the world.

Bob is the quintessential programmer that many of us yearn to become. Surely, no one is more deserving of promotion than him? So, Bob was promoted to technical lead, a position that management thought that he’d be even more valuable in. Rightfully so. But this also meant that he’d write less code and instead would have to focus more on managing the direction of the project as a whole.

In other words, he’d have to do less of what he loved as a trade-off to do more of what he didn’t know how to do — managing others.

He lacked the ability to direct others, empathize with their schedules and knowledge, break tasks down for other people to succeed, and strategize for success. He expected everyone else on his team to be as good as he was as a programmer so he didn’t spend the time necessary to invest in their development — mostly because he couldn’t relate to their needs.

As the months went on, he proved to be less than capable of performing well in his new position. He had reached a brand new level of incompetence. His better nature and lack of managerial skills through his previous job led him to fail at what he did. This incompetence led his team’s productivity to plummet and their organization to crumble.

The Peter Principle

Bob’s situation is a all-too-familiar reality that many of us may recognize. I don’t know about you, but I’ve known a multitude of senior developers and technical leads who are absolute terrible at doing what their job requires— leading.

The sad thing is, these poor fellows were probably brilliant earlier in their careers. They have been pushed into a position they weren’t well equipped to thrive in.

This phenomenon is known as The Peter Principle:

In a hierarchy, every employee tends to rise to his level of incompetence. […] You will see that in every hierarchy the cream rises until it sours.

Although Laurence J. Peter wrote this bestselling idea as satire, it has proved to be unequivocally true — the idea that a person will be promoted again and again until they eventually reach their level of incompetence. For a developer, this can be mid-level, senior, lead, director, or all the way up to CTO.

As developers, it’s common to think that if you perform well and are constantly refining your coding skills, you’ll be promoted into a more prestigious position — one that bears far more responsibility and allows you to flex your merit and learned abilities. And that’s true — you most likely will be promoted. That’s the way things are.

People are generally promoted based on their performance in their current position, not because they hold the skillset necessary to fill the next position. It is merely assumed that they are more capable because of their past performance. Who knows, they probably are more capable.

Unfortunately, their capacity to do great things in the past doesn’t necessarily translate to their ability to accomplish great things in positions they fill in the future. For that, their promotion can serve to be a very poor investment in regards to the success of future projects. It’s a gamble, not a certainty.

That being said, in all likelihood, you’d probably be pretty awful as a manager. That’s not to hurt your feelings and undercut your abilities, but it’s because you’re so focused on your current job that you won’t be prepared for what the future holds.

Your own ambition is, paradoxically, a key that unlocks your own mediocrity.

You have the skills that make you great as a developer. You might even have the skills that make you a formidable team player. But you lack the skills that would make you great as a leader, architect, or coordinator. Programming alone doesn’t particularly develop those leadership-type attributes.

It’s for this reason that so many incompetent people hold positions above us. This is why once brilliant people do horrible things. This is why certain projects go wrong under specific leadership. And no, it’s not the team who’s at fault — it’s the leader of the pack who failed to create an environment and organized structure for the team to succeed.

But it doesn’t have to be this way. You can’t transform the way your organization handles promotions, but you do have control over yourself and your own perception. You can harness your own unique ability to think and act.

Creative Incompetence: The Key to Being Good

Imposter syndrome is often seen as a bad thing. Of course, possessing the state of mind that you’re less competent than your job demands can cripple you. It could cause you to undersell yourself. When you deeply believe that you’re not capable, that often manifests as reality.

But there’s another way of viewing such a mode of thought — a psychological avenue that you can use to avoid falling victim to The Peter Principle. The adoption of “creative incompetence.”

Creative incompetence is similar to imposter syndrome in that you see yourself as incompetent. Except, you foster this mindset in an intentional way. When you intentionally view yourself as incompetent, you might ask yourself questions about how you might be able to alleviate such incompetence.

You prepare a strategy. You learn more than just what your job immediately demands of you. You refine your soft skills. You do what it takes to become more than a mere programmer. You take action to become someone dynamic enough to fill in future leadership positions within the realm of development that isn’t tied specifically to programming.

Remember, there’s far more to development than programming. In order to maintain yourself as a powerful asset in the long run, you have to prepare now. So, verse yourself not only in programming but in management, strategy, game theory, business philosophy, communication, and whatever else it is that will allow you to lead better.

You want to hit the ground running. If you think that because you succeeded in a past position, that you’ll succeed in a future position, you’re in for a rude awakening.

“If you think you know everything; you know nothing. If you think you know nothing; you know something.”

— Jayce O’Neil

So, be creatively incompetent. Believe that you know nothing. See yourself as incompetent.

Adopt this mindset as a means to better prepare yourself and motivate you to learn beyond what your craft currently demands of you and the future positions that you’ll need to fill. Be the developer in an idealized sense. This will allow you to continuously make an impact and improve without reaching a ceiling that limits your growth.

Posted by: lrrp | October 20, 2021

Why expert developers make the worst tech leads

‘A developer’s experience crafting code and designing algorithms does not prepare him or her for the unpredictable and highly emotional world of managing people’ Why expert developers make the worst tech leads image

All organisations with more than 50 employees will, at some point, require tech leads. Great tech leads can create a harmonious environment, where each team member is encouraged to use his or her strengths to achieve a common goal. Bad tech leads, on the other hand, can demotivate a team by failing to establish a central vision and by hoarding all the interesting work.

Many tech leads find themselves promoted into this role because they were either the most experienced or considered the best developer on the team. However, this may not be the best way to choose tech leads for the team.

Writing code does not develop leadership skills

Developers spend a majority of their time writing code. They read about new tools, algorithms and technologies and structure software to solve business problems, overcoming many technical hurdles in this process. Although developers work within teams, their focus is very much on what they produce at the keyboard.

When a developer is promoted to the tech lead role, he or she must suddenly draw on different skills, which may never have been needed as a developer. In his or her previous role, a developer could easily avoid being pulled into arguments between fellow coders by returning to the safety of his or her keyboard and taking the “it’s not my problem” stance.

A tech lead, however, cannot ignore these disagreements. If they do, the situation may never resolve itself – leading to endless arguments or a codebase that moves in different directions making it more difficult to add features over time.

A developer’s experience crafting code and designing algorithms does not prepare him or her for the unpredictable and highly emotional world of managing people. A tech lead requires skills that include coaching, influencing, facilitating, motivation and delegating, which brings us to another challenge for the expert developer.

The desire to ‘do’ competes with ‘enable’

Expert developers are recognised for their expertise because they have built up their ability to produce well-written code consistently and on a timely basis. They have honed their sense of good and poor code recognition, and are proud to write good code, whilst avoid working with poorly written code.

When the best developer is promoted to a tech lead role, he or she has to oversee and review the code produced by other developers on the team. If the tech lead was previously the best developer on the team, they might perceive the code written by others as suboptimal. They could explain why the code is poorly written, but they might think it faster if they simply rewrite it, or do the task themselves to begin with.

Although the tech lead’s thinking may hold true in the short term, this attitude has other side effects. Given additional responsibilities, the tech lead’s time cannot possibly scale to cover all the work the entire team must produce. Also, it signals to other team members that the tech lead does not trust them, and can have the effect of making other developers feel disempowered.

Though initially difficult, the expert developer promoted to a tech lead role needs to reframe the way that he or she adds value to the team. He or she must stop viewing the solution as writing the best code themselves, and instead take a longer-term view of enabling others in the team, so that they too can write code just as well as they can. With this broader focus, the tech lead can make the team collectively more effective.

Writing code is not the same as designing a system

Developers spend their day designing code to meet some need. However, ‘clean code’ is not valuable until it is deployed and made available to end customers, which requires a different mindset – instead of developing code, developers must develop systems.

In many organisations, developers do not know the configuration of their production environment, making wrong assumptions about the code they write. This is often the difference between a system that works, and a usable and performant system that works.

The ‘works-on-my-machine’ anti-pattern is common for great developers, but tech leads have to think in terms of the overall system, and not just the code.

The good news

Although organisations must be wary about promoting the best expert developers to the tech lead role, not all is lost. Good developers can make great tech leads but organisations must recognize that tech leads also require a set of complementary skills.

The activities and situations most developers work in day-to-day do little to prepare them for leading a team, enabling and encouraging team members, or focusing on the overall system.

Good tech leads require a good amount of technical knowledge, but they do not necessarily need to be the best. They need to be good enough that the team respects the tech lead technically, but they will probably draw more on their leadership skills day-to-day than their technical skills.

Organisations can cultivate the next generation of tech leads by sending potential tech leads on leadership courses and highlighting the skills they must build in their new role.

In this article, I’m sharing 7 tips that can help you become a senior software developer. Keep reading.

Complete control over at least one programming language

Skill in the Programming language is a key to get success in the software development field. If you want to build a successful career in software engineering, then you must obtain mastery over at least one programming language because this will help you to gain good control over the software development process.

Java, Python, C++, etc., are some of the programming languages which will be very useful for you. It is generally not recommended that you must learn 3 to 4 languages simultaneously at a time because it will make everything messy rather you must try to focus on any one language in which you have an interest and get mastery over it, then go for the next.

Switching to the next language will be much easier once you get good control over a particular programming language.

Knowledge of Data Structure and Algorithm

A good software engineer should be well versed in data structures and algorithms because if you don’t have these skills, then it will not be possible for you to write any real-world application. So you must have proficiency in data structure and algorithm.

An algorithm is defined as a set of steps to be followed to perform a specific task or to solve a particular problem. An algorithm forms the basis of every programming code and plays a pivotal role in software development.

Knowledge of basic structure like an array, map, linked list, etc., helps in the proper functioning of the program and leads to the development of robust quality software. A good programmer must have all knowledge of them. If you want to become successful in programming, then you must obtain command over them as early as possible.

Skill Enhancement in the Software Field

You must try to supplement your study by visiting coding sites like StackOverflow and other websites like CodinGame and CodeWars, which offer thousands of problems, and if you put your efforts into solving them, you can improve your skills and obtain greater capability in your work. However, it demands a lot of hard work and patience to bring improvement.

You need to explore open-source code more and more. For this, you need to find projects that you think are interesting and look into their source code to know about how the developers accomplished the task.

In addition, you must try to find developers who are experienced and ask them for help in the form of feedback on your project, etc. This step will not only help you to enhance your knowledge and skills but also bring your mistakes into the limelight. It will help you to check your performance parameters and maintaining your qualities.

Reading of Code Made by Experts

Just like reading books enhance the knowledge of a person, in a similar pattern, if you read the code written by some expert software engineers, then there is a high chance that your skills in software development will improve a lot and help you to get excellence in this area.

Reading code also helps to boost your analytical thinking, which leads to the generation of new innovative ideas. Further, you must try to read a more diverse set of projects to get an extensive understanding of the range of your work. Once you enter this field, you must always try to be a constant learner. If you become a good learner, then you will be able to solve critical problems more efficiently.

Learning Cloud Platform

Cloud is another area open for a Software engineer to learn to get advanced competency in the field of Software development these days. Nowadays, almost all companies irrespective of their sizes and domains are shifting their environments into Cloud due to cost-saving and better scalability, which simply means that sooner or later, you need to work in a cloud environment.

There are many popular Cloud platforms like Amazon Web Service (AWS), Google Cloud Platform (GCP) or Microsoft Azure, etc. If you get knowledge of them, then it will help you to take one step forward against your competitors. However, you are not required to learn all of them, and in fact, learning one of them will give you a fair idea about others.

Understanding of Networking Basics

With the advancement of technological development, we see that the entire world is interconnected nowadays, and this is all possible due to networking. You can find computer networks all over, starting from home where you use your WIFI and across many devices in school, college, and offices, which uses Local Area Network (LAN) to the Internet.

Even most of the applications developing these days are not standalone applications but are based on the client-server model. This entire model makes use of networking because under this, the client computer is connected to the server to give instructions, and the connected server does the task as desired by the client. This is all possible due to networking.

That is why networking is now interlinked with software development. Hence, to compete in changing environment, you must have a good knowledge and understanding of networking.

Advance Excel skill and use of Text Editor

Advance knowledge of Excel is one of the important skills that a programmer must have in their armor. The reason is that Excel provides many useful features and functionalities that can help you to perform sophisticated data analysis. It also helps you to keep track of the progress, data reconciliation, data quality check, easy comparison, sorting, filtering, etc., and many more.

Besides, it is extremely user-friendly and easy to work with. So It is highly recommended that you must have advanced knowledge of Excel to generate more efficiency in your work.

A good Text Editor is also very helpful to the Software Engineer. This tool helps in the easy development of program code. It has lots of features which can make the work of Software development and writing code very easy. So it is very beneficial for you if you work on any good text editor of your choice.

Posted by: lrrp | August 16, 2021

What I Look for When Hiring Senior Software Engineers

As a senior software engineer at a large growing tech company, I have the privilege of helping interview many other software engineers who apply to come work with me. Throughout the last year, I participated in about 50 interviews for positions ranging from mid-level software engineer to senior software engineer to engineering manager.

This experience has given me time to reflect on the qualities and skill sets that I value in other senior software engineers, and as a result, I try to craft my interview questions in such a way that I can hopefully get a glimpse into these attributes during the brief time I have with each candidate.

So, without further ado, here are the things I look for when hiring senior software engineers.

Ability to communicate clearly with technical and non-technical people

This is important for two reasons. First, as a senior software engineer, you’ll serve as a mentor to junior and mid-level engineers. Other engineers will often come to you with questions, and you’ll need to be able to explain technical concepts to them in simple terms. When you give code review feedback, you’ll need to explain clearly why a piece of code is not ideal the way it currently is written and how it can be improved.

Second, as a senior software engineer, you’ll often lead through indirect influence. You aren’t managing anyone directly, but you do need to be able to spread your ideas throughout the organization and rally people to join you in your cause for clean code, higher engineering standards, or whatever it may be. If you can’t communicate your ideas effectively, you’ll have a hard time convincing others that your ideas are worth their time.


Second, as a senior software engineer, you’ll often lead through indirect influence. You aren’t managing anyone directly, but you do need to be able to spread your ideas throughout the organization and rally people to join you in your cause for clean code, higher engineering standards, or whatever it may be. If you can’t communicate your ideas effectively, you’ll have a hard time convincing others that your ideas are worth their time.

Emotional intelligence and maturity

A senior software engineer needs to understand that they are not their code. You must take your ego out of any argument or discussion. Understand that criticism of the code is not criticism of the person.

Senior software engineers need to be able to have hard conversations with other people whether it be about code quality, job performance, or managing expectations regarding project timelines.

At the same time, senior software engineers need to understand how their words and actions affect other people. Emotional intelligence includes not just a self-awareness but also an awareness of those around you. Senior software engineers should know how to constructively provide feedback in a way that uplifts and inspires, not degrades and demoralizes.

Humility

Senior software engineers do not know everything. Nor should they! The field of engineering is far too massive for any one person to master it all.

A good senior software engineer understands this fact and is comfortable with it. You don’t need to know everything, but you should be able to recognize when you don’t know something, when to ask for help, and how to find answers to questions on your own.

This understanding leads to humility. There is no room for ego in the software engineering world. You should never feel like you are indispensable or that you are the only one who can adequately perform your job duties. The team and the company will go on without you if and when you move on.

High standards for engineering excellence

Senior software engineers set a high bar, both for themselves and for those they work with. They use effective tools like code formatters and code linters to enforce standards and coding styles. They understand the importance of tests and don’t allow untested code to be merged into the master branch. They configure CI/CD pipelines to automate the tedious part of code reviews and to ensure that the master branch is always kept in a working state.

Senior software engineers view programming as a craft, not just a job. They are proud of their work.

Expert in their domain

Senior software engineers have advanced to this level for a reason: they are good at their job. This means knowing their tech stack or language of choice at more than just a superficial level. Their expertise is T-shaped - deep knowledge in a few areas and a breadth of experience in many other areas.

They gain this expertise through years of tackling hard problems, volunteering for tough projects, accepting stretch assignments, and learning from those around them.

Senior software engineers take advantage of the wealth of experience available to them by reading classic programming books like Clean CodeRefactoringThe Pragmatic Programmer, or Design Patterns. In doing so, they vicariously learn lessons from domain experts who have spent decades perfecting their craft.

Passion for learning

Senior software engineers are excited about their job. They’re interested in new things. They’re always exploring new ideas through reading articles, watching videos, building proof of concept apps, or maybe even writing and producing content.

In short, they’re not stagnating in their career, and it shows.

Conclusion

Hard skills are important, and a senior software engineer needs to know their stuff. They are expected to be experts in their field, or at least in a subset of a few key areas.

However, as important as hard skills are, I’ve often found that soft skills end up being just as important, if not more so.

In summary, here is the list of qualities I look for and value in other senior software engineers:

  1. Ability to communicate clearly with technical and non-technical people
  2. Attention to detail
  3. Emotional intelligence and maturity
  4. Humility
  5. High standards for engineering excellence
  6. Expert in their domain
  7. Passion for learning
Posted by: lrrp | July 30, 2021

5 Mindsets of Unsuccessful Developers

#3 Learning only happens on the job

There are plenty of things that can stifle you on your path to becoming a good software developer, and often they are states of mind that can be difficult to recognize because they are internal and part of you.

And there’s one thing I learned since I started programming, it’s that all unsuccessful developers typically share similar traits.

Knowing what to avoid is more important than knowing what to do!

Expecting Everything Instantly

It is definitely very important for programmers to learn new things quickly and apply them. That is the nature of the job that we are in.

But starting a tutorial of Kotlin and expecting to write Kotlin code in 2 days is just not going to happen.

And this habit of learning a little bit of something and then deciding to move to something completely new is really what it’s all about. That is exactly what is preventing you to become good at something.

Do you see what I mean?

Skipping around, dipping a toe in every language/framework, and doing half the tutorial track on various resources. You might end up being able to say “hi” in each language, but you won’t get close to speaking fluently in any of them.

Quitting Is Only For Losers

This may sound counter-intuitive. But sometimes you have to quit something to start something better. I am not talking about quitting my job or changing careers.

This applies to the realm of Software Development. The problems that you solve daily require you to change approaches and you should be flexible in quitting one solution for others.

What I mean by that is you should not be attached to the approach. So whenever you see something not working out, scrap it and start it from scratch with the same enthusiasm and a new approach.

“Genius is to know when to stop!” — Unknown

Take your time and explore. You are here to learn and bring something better to the table.

Learning Only Happens On The Job

This is one of the mindsets I had which hindered my progress. I realized later that I do not have to wait to work on projects on the job to learn something interesting.

I am not talking about enrolling in online courses and then forgetting everything just a few months later.

It is more related to the ideas that you might have in the back of your head. If you don’t think you have those ideas then maybe try scratching your head! 😉

All I am saying is that you should create something using the tools at your disposal.

Programming is just a tool to bring ideas into reality.

So work on something of your own. That will not only boost your confidence but also will help you learn so much more.

Three years ago I had an idea that I turned into reality by creating this Android app.

Saying Yes To Almost Everything

As software developers, we face not only syntax and logic challenges but client communication. This is crucial because sometimes, your client will ask you for features that will take a lot of time and will not add value to the final product or are not the aim of the application.

Generally, in a situation like that, the only option is to say yes and deliver the features. And that is not wrong by any means but before that always aim for more clarity.

The best way to achieve clarity is by asking questions.

By bringing clarity you and your team might be able to find an alternative solution making a win-win situation for both parties.

The problem is, most people never ask questions. They sit in this confusion and lack of clarity in discouragement.

Documentation Is Not Important

The general argument for writing or maintaining documentation is that when the code is under a lot of development, it’s more work to update both docs and code, which slows one down. If such work is delayed, divergence becomes increasingly likely.

But I don’t see any rule where you are supposed to write documentation when you are developing. You can defer the documentation.

I generally write expressive code and tend to add a Javadoc-style comment block to any non-trivial function for internal code, explaining some less obvious code.

But the second I write code that is interfacing with other developers I write it as an API. I fully document it, explain the action of each method and any non-obvious consequences, and then leave it with the expectation that it is done.

The simplest documentation that takes the least effort, but explains the functionality and purpose of the software fully, is the optimal solution to documentation.

Conclusion

A fixed mindset is an unproductive way of thinking that sits opposite of what’s called a growth mindset. As you might imagine, a growth mindset fosters personal growth and development.

The fixed mindset hinders growth, as its predominant concept is that we’re either good at something or not based on inherent abilities. This mindset contributes to negative thought patterns and puts limits on healthy behaviors.

Becoming a better version of yourself doesn’t happen overnight, but this is the perfect time to start, and avoiding the above mindsets will help you reach there faster!

Would “re-cubicling” yourself be your next best career move?

Now that employers are (cautiously) rolling out their reopening plans, professionals are deciding whether or not they want to continue working from home — as well as how to negotiate these arrangements.

The Great Resignation is in full swing, with 4 million Americans quitting their jobs in April 2021 alone. A survey from Monster.com conducted last month found that an astonishing 95% of workers are considering changing jobs. And while managers are waking up about employee balance, it may not be fast enough: 61% of global business leaders say they’re thriving right now, but for those without decision-making authority, the stat is a whopping 23 percentage points lower.

Work-from-home hype is everywhere at the moment, which is why a study I recently stumbled across nearly knocked me off my chair.

Nicholas Bloom is an economics professor at Stanford. And according to Mr. Bloom’s research, when it comes to moving up in your career, working remotely may not be such a great idea.

The study was from 2014 and obviously doesn’t take into account the forced remote working conditions of the last 18 months. But in a recent article for the Harvard Business Review, Mr. Bloom refreshed his concerns about the hybrid workplace transition.

The study had other terrific results that work-from-home enthusiasts have long championed: Improved productivity, higher employee satisfaction, and lower employee turnover. However, promotion of these employees fell — by a lot.

Why?

Working from home: Ideal or isolating?

The study followed the results of a work-from-home experiment at Ctrip, a Chinese-owned travel company with 16,000 employees. Ctrip randomly sorted a group of call center employees into either working from home or commuting to the office.

  • Work-from-home employees had a 13% increase in performance.
  • When Ctrip expanded the experiment to include their whole workforce — and gave workers the power to choose their setup — 50% opted to work from home.
  • This mass adoption caused productivity to spike even more, lifting overall performance improvement to 22%.

The results were impressive. But after 21 months, a more unsavory statistic about the test group surfaced: Work-from-home employees were only being promoted at half the rate of employees who were going into the office.As expected, ambitious workers with no other home or family responsibilities opted for as much office time as possible to maximize networking opportunities. In-person environments allow for spontaneity and visibility that can only be recreated so much on Zoom calls.

It’s a diversity challenge that many companies are dealing with at the moment. According to the Bureau of Labor Statistics, 59.8% of American families with children have two working parents. A lot of these professionals want to make work-from-home work for them.

But there’s another important statistic that isn’t getting much press: As noted in the aforementioned Harvard Business Review article, Bloom and colleagues found that 21% of workers never want to work from home again.

Meanwhile, I’m going in the opposite direction

I’m currently in that “get me the hell out of my apartment” camp. Working remotely isn’t new for me — I’ve been at it for about seven years — but quarantine helped me realized I need firmer boundaries between work and home.

So I leased an office — for myself. It’s a splurge for sure, but probably cheaper than couples therapy. My energy is much better, and when you’re self-employed, good energy makes money flow. Working from home is great. It can also be lonely. Voluntarily re-cubicling myself was drastic, but I needed something drastic to buck my bad habits from lock-down. Perhaps you do too.

My sense is there’s an ebb and flow to this desire for freedom as we go through different stages of life and career. If you hadn’t worked from home before COVID arrived, parts of it may feel novel and luxurious. Parts of it probably also suck. Those feelings may change over time, so it’s important to collect as much data about the hybrid work landscape as you can.

Should workers be home, at the office, or both?

That’s ultimately a decision your company will have to make. As you wait it out and assess your options, though, here are a few things you could do to keep momentum in your corner.

  • Keep up the Zoom coffee dates. Ugh… I know. But hear me out. There’s a saying in networking: “10 minutes of belly-to-belly time is more powerful than a year of emailing back and forth”. I’ve built a lot of my business up through virtual happy hours and remote connections, and while video calls aren’t exactly the same as being in person, they’re pretty close when it comes to having someone’s undivided attention. One intimate conversation will always take you further than a hundred cute Slack comments.
  • Lay promotion groundwork now. If the option to work from home is on the table, pitch your employer or supervisor on what it would take to land a promotion under these circumstances. Employers are back on their heels at the moment; voice how you see yourself staying with the company for the long term. Drag me all you want for saying this, but if your company refuses to even entertain a conversation about what it would take to keep you for years to come… your best interests are probably not a priority.
  • Think about your long game. If you know working from home is a good fit for you — and employment prospects with this arrangement are bleak — consider doing your own thing. A consulting side hustle is how my self-employment journey began years ago, and it might be a great fit for you as well. Entrepreneurship ain’t easy, but it will let you build your career on your terms.

Life and family responsibilities inevitably shape our definition of career success. But working from home can be a double-edged sword. Position yourself in ways that keep you both visible and relevant and you’ll propel your career forward while also finding the balance that helps you live your best life.

Posted by: lrrp | July 29, 2021

10 Admirable Attributes of a Great Technical Lead

It‘s a position that requires intricate calibration of various personality traits.

This image has an empty alt attribute; its file name is 1_2uujqxyquvfrwkpsrubz-g.jpeg

Over the course of my career in software development, I have had the great privilege of working under different technical leads. They are the people who drive the forefront technical direction of the team. I have learned much from them.

To be a great tech lead is hard. It’s an intricate balancing act between two poles of the same attribute. Too much on one side and one can fall.

Below are a few of the attributes that I admire in the best tech leads.

1. Having an Opinion Yet Not Being Opinionated On Everything

There is no tech lead who doesn’t have any opinion on anything. They are promoted to a tech lead because they have their core technical competency and are able to direct a team.

They have opinions, which leads to their decision on how the team should move forward. This is great — as at least as a team, we have a direction.

A smart tech leader, while also having opinions, knows when to keep their opinion to themselves and just listen. They know when they should harvest the knowledge of their team members and synthesize them into a better solution before deciding the course forward.

Even Steve Jobs, who was viewed as “a dictator who listened mainly to his own intuition,” said this:

“It doesn’t make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do.” — Steve Jobs

2. Filled With Energy Yet Calm In All Situations

I cherish tech leads who are driven. They are filled with energy. They bring the team forward. Their presence makes the team feel vibrant. Such energy is positive. They are infectious.

However, the energy that a great tech lead has is not the energy that just boosts uncontrollably. It is focused and channeled towards the goal of making the team move towards positivity.

In any crisis, the usual energetic leader is not generally bursting with anxious energy. Instead, the lead now preserves and channels one’s energy in finding resolutions to the issue. Outwardly, he is calm, as he knows this will avoid chaos in the team. The lead is composed and stays focussed, knowing bad times will not last forever.

Even if there’s no resolution to the issue, the great tech lead will still spin-off something positive, calmly.

Just as Thomas A Edison stated when his factory was burned down:

Although I am over 67 years old, I’ll start all over again tomorrow.

— Thomas A Edison

After the fire, he began rebuilding the next morning, without firing any of his employees.

3. Disown Their Team’s Successes and Own Their Team’s Issues

I once heard a teacher say this to their student:

If my student score A in exam, they have made it! If my student fail in exam, I failed

— Anonymous Teacher

Similarly, a great tech lead always promotes their team members’ achievements. When the team has successfully delivered the result, the lead will praise the team, and share the good news to all, stating how well one team has done, and never one own.

However, when issues arise and need to be resolved, the tech lead will take the lead and own the issue. It may be a mistake by one of the team members, but there is no time for playing blaming game — it’s more important to get to the issue and solve it.

4. Can Comment Well and Code Even Better

If you’re a technical lead, you need to be coding.”

— Martin Fowler

I’ve heard many people say that when you’re a senior developer, you have the most time to code and be an expert in the field. However, when you’re promoted to lead developer or technical lead, time is now diverted to meetings, stakeholder management, discussions, planning, and so on. Coding time is minimal or gone.

That happens to a lot of technical people when they reach a leadership position. However, I’ve also worked with technical leads who although have many to handle on one plate, but one’s technical skill is still strong and growing. They find time to code still.

I can understand it is not an easy thing, as it requires one to pursue learning and exploration of ways to improve how one learns. A smart tech lead learns on their own through study, but they also learn from their fellow team members.

Of course, with the proper support from the organization, continue to allow some time for tech leads to focus on improving their technical skills, instead of swamped with administration and management work. Its benefits are vast — a tech lead who is technical will not only not lose one’s technical capabilities, instead one can still closely connect with one’s team technical progress.

A very good example of a great technical leader in the industry is Linus Torvalds, the creator of Linux and Git.

Talk is cheap. Show me the code.

— Linus Torvalds

Despite being such a high-profile personality in the tech industry, he is still very technically connected.

5. Appreciate Old Tech and Embrace New Tech

I have seen an experienced developer who has much experience in one’s belt. A pure VI coder. One does magic with just VI and is very productive with it. To this developer, people who use IDE are pure lazy modern developers, never taking time to learn shortcuts and improve their productivity.

I have also seen a new smart developer, who knows almost every single feature and trick on IDE and is proud of their knowledge of it. To this developer, people who stay with VI or EMAC are from the dinosaur age and have never progressed to the new world.

Both are equally wrong. Not in the sense that they prefer what they like, but by demeaning the preference. I have seen a tech lead who has experienced enough to experience the worth of VI but also appreciates the handiness of the modern IDE tool.

Having a chat with such a tech lead is such a comfort, as we can get much insight into the past, of how the past influence the current technology, while also how things have progress positively, and how we can leverage and combine both tech to make our work better.

Mixing one’s wines may be a mistake, but old and new wisdom mix admirably. — Bertolt Brecht

6. Communicate Fluently and Connect Frequently

Which leader doesn’t communicate? Of course, they all do. The higher up a leader, the better their communication skill. Those who communicate well have better influencing ability and attract more followers.

However, not all leaders connect. Some communicate and influence to attain some mission and goals, for the good of the team or for personal gain. Once that is achieved, they move on to the next mission and goal.

A great leader cares for the team members. Other than communicating and leading the group, they also connect with each team member, understanding them as a person. Their focus is not only to achieve common projects goal but also how to grow its team member for the better.

There was once a question asked to a group of new leaders…. “Why do you train your people?”

The first one replied, “So that we can scale the work, and have the work not be dependent on a single person”.

The second one replied, “So that our team members will grow in their skill and be more empowered “.

Both are the result of training the people, the first one is focused on the job, and the second one is focused on the people.

7. Strive to Answer Brilliantly and Dare to Ask Stupidly

Tech leads are usually a mentor to their team members. They are normally more experienced and technically more competent in some domain. Therefore, they can coach their team members.

Being the coach, they may not know everything. That doesn’t mean the tech lead should just ignore and not support the team member when faced with the unknown. The tech lead can still strive to provide good pointers, guiding the team member on how to go about finding a solution. Always strive to provide as great a guide as possible.

On the other hand, sometimes team members will be better skilled than the tech lead in some areas. In fact, that’s always true, as the combined knowledge of the team members will definitely surpass what the tech lead has.

The tech lead who I respect doesn’t feel ashamed to admit when they are ignorant and dares to ask even questions that may seem stupid. To the lead, it is better to be “stupid” now and learn it well, than to be “stupid” and have to pretend to know it for the rest of one’s career. Such unresolved “stupidity” will compound over time. Avoid imposter syndrome.

If you ask a stupid question, you may feel stupid; if you don’t ask a stupid question, you remain stupid.

— Tony Rothman

8. Is Firm Yet Can Be Flexible

I have experienced leaders who see everything as one or zero with nothing in between. Either right or wrong. Everything goes by the book. If it is not followed, the known consequences will follow. Firm.

Such inflexibility deprives creativity. The team is ruled by mundane routines that are predictable. This is great if it is on the factory production operation floor, as every action needs to follow the procedure to the exact dot. One day, all such jobs will be replaced by automation and robots.

I have also seen the “Mr. Yes” leader, who is okay with everything. They are there to please everyone. It won’t be long before the team becomes chaotic with no processes in place. Everyone does what one likes. The team won’t last too, as the team has no focus or direction.

A great leader knows when to be firm and when to be flexible — they have set defined boundaries. The leader knows what matters and what’s not essential. They understand what the bottom line is and are flexible on the way to achieve it.

Boundaries are basically about providing structure, and structure is essential in building anything that thrives.”

— Henry Cloud

This allows team members to get their creative juice going. They can define the sub-boundaries, and own some decisions.

Boundaries are not set and stone — they change with time. A great leader re-evaluates the boundaries from time to time. Bending them when possible to open up new possibilities.

9. Leading Without Beating

The way the shepherd leads their sheep is by calling them — the sheep will then come and gather around. No beating and chasing is required. On the contrary, cowboys use whips to chase around the cows to make them move in the required direction.

In no way am I equating team members to sheep or cows. We are civilized human beings and well able to take instructions. We will willingly take instructions that ratiocinate with our value system. We will also take instructions if we are being unwillingly coerced.

A great technical leader demonstrates technical maturity, and constantly able to provide sound rationales behind one’s decision. “Because I say so” is not in their vocabulary. Although one has veto power for one’s team technical direction, it’s rarely used.

There will be some critical occasion, the tech lead has to do some unpopular decisions, challenging the status quo. In doing so, though it’s an uphill task to convince the team — they strive to ascertain the team of the decision and how it will benefit the team. Unless the team follows, they will not move forward. There’s no beating required.

You do not lead by hitting people over the head-that’s assault, not leadership. — Dwight D. Eisenhower

10. Execute It With Brain — Do It With Heart

Perhaps this last attribute sums up the core of technical leadership. A great technical leader is not only great in technical but also great in leading.

Technical demands the brain think logically, coupled with using its past experiences and the skills acquired. Leading demands that attribute that connects with the people and touches the heart. A sixth sense that cannot be reasoned with. Technical leadership requires both.

The stake to be a technical lead is high. High demand on both ends. It bridges between higher management and grass-root technical people. An equivalence balance of both capabilities is most crucial.

People don’t care how much you know until they know how much you care.

— Theodore Roosevelt

TL; DR

In reality, there is no single formula to be a great tech lead. It’s a demanding position. It requires both sides of one’s capability: the heart, and the mind. Sometimes, heavier on one side than the other, and sometimes the other way round. It is situational, applied differently to different people.

It may sound impossible, but I have seen many great tech leads who, while they are not perfect, strive for perfection. They are smart yet kind. Knowledgeable, yet humble. Busy, yet approachable. It was my privilege to have work with them. Hats off!

The infrastructure of any solid relationship is trust. While certainly true in every sphere of your life, it’s essential in the workplace. After all, it’s been found that employees working in high-trust environments have reported:

  • 76% more engagement
  • 74% less stress
  • 70% more alignment with their companies’ purpose compared to employees in low-trust environments
  • 50% higher productivity

Moreover, numerous studies have found that trust is critical to team success. And, this is most true as remote managers are struggling with trust issues during COVID-10. Thankfully, you can use the following 7 strategies to turn this around.

1. Mitigate your team’s stress.

According to author and leading trust expert Paul Zak, stress is one of the most forceful oxytocin inhibitors. Why’s that important? Well, oxytocin is the hormone that’s responsible for social and romantic bonding.

As such, this chemical is kind of important when building trust with your team. Specifically, it helps teams work and grow together. And that can completely transform the workplace for the better.

“In my research, I’ve found that building a culture of trust is what makes a meaningful difference,” wrote Zak. “Employees in high-trust organizations are more productive, have more energy at work, collaborate better with their colleagues, and stay with their employers longer than people working at low-trust companies.”

“They also suffer less chronic stress and are happier with their lives, and these factors fuel stronger performance,” he added. So, yeah. This just makes sense.

But how exactly can you reduce workplace stress?

For starters, stop micromanaging your team. Instead, grant autonomy by letting them work however and whenever they want. Since they’re currency WFH, this is key since it can make work-life integration easier — like juggling work and homeschooling their kids.

Additionally, make it a point to communicate with them regularly. Regardless if it’s a quick phone call, weekly Zoom check-in, or through Slack, this gives you a chance to acknowledge them or address any concerns.

What’s more, you should make yourself available so that you can provide guidance. For example, if they’re struggling with time managementwhich is a stressor that 46% of employees, then offer advice on how they can fix this problem.

You should also encourage them to take time off and be respectful of their boundaries. That means not bombarding them with messages when they’re off-the-clock. And give them access to mindfulness apps like Calm.

2. Serve up the feedback sandwich.

Giving credit where it’s due is a proven way to build trust in the workplace. In fact, a Globoforce study found that those who received recognition from their leaders recently were significantly more likely to trust them (82% vs. 48%).

Here’s the thing, though. Eventually, singing your team members’ praises loses meaning. Studies actually show that “negative” feedback (if delivered appropriately) is more helpful than positive reinforcement.

The reason? People want to learn and grow. And, they want to be challenged, not cuddled.

A simple way to achieve both types of feedback is using the sandwich method. Here you would deliver feedback as follows; positive, constructive, positive.

Why does this work? Because you’re kicking and ending things on a positive note. At the same time, you’re also delivering honest and constructive feedback.

3. Get to (virtually) know your team members.

The cornerstone of fortifying any relationship is getting to know the other person. And, by that, I mean getting to know them outside of the workplace. Even if that’s regularly meeting with them in person, it’s having frequent and informal chats with them via text, email, or scheduled “coffee” meetings through Zoom.

While you don’t want to cross any lines here, ask them how they’re doing. Inquire about their hobbies, passions, or how their family has been. It sounds simple. But, spending a couple of minutes each week getting to know each team member helps you bond over similar interests while showing that you genuinely care about them as a person.

4. Make sure that your goals, objectives, and intentions are crystal clear.

Not to be too crass here. But, this is leadership 101. Always make sure that you always do this from jump street.

For instance, let’s say that when a team member has completed their portion of a project, they must notify the project manager. That may not sound like a biggie, but what is the preferred channel here? If it’s through Slack, but they sent an email, that could cause bottlenecks and lots of ibuprofen for the headaches this caused.

In short, make sure that you share your goals, objectives, and intentions with your team. More importantly, double-check that they understand them so that you’re all on the same page.

5. Be competent but also vulnerable.

“Trust in leadership is also based on a leader’s demonstration of on-the-job expertise and ability,” writes executive coach Dina Denham Smith. “In virtual teams where people can feel disconnected, strong communication is an especially critical leadership skill, one on which your competence will be judged and trust built or diminished.”

While you certainly do not want to cause information overload, “there’s no such thing as over-communicating,” adds Denham Smith. After all, “if you don’t communicate frequently and clearly, your people will fill in the blanks with their own, usually worst-case, assumptions.” Additionally, you need to be open about your expectations and transparent “on company direction, policies, and procedures, including the decision-making process.”

At the same time, admit that you don’t have all the answers. You should even own up to your mistakes. And, if you need help, ask for it.

“While it may seem counterintuitive, leaders who ask for help draw others to them through this display of humanness, inspire others by making them feel needed, and garner trust and followers,” adds Denham Hill.

6. Freshen up your virtual events and meetings.

Even though virtual meetings have been around for years, they’ve become the status quo thanks to the COVID-19 pandemic. While an adequate way to keep in touch and build rapport, they’re also exhausting. However, you can spruce them up to establish trust while also bolstering morale.

If you need some ideas, Calendar Co-Founder John Hall has the following suggestions:

  • Get underway by acknowledging your team’s achievements or sharing a joke.
  • Host theme events, like a holiday party or virtual lunches where participants share their favorite recipes.
  • Conduct weekly check-ins to provide updates or ask how everyone is holding up.
  • Always follow virtual meeting etiquette, like muting your mic when not speaking.
  • Encourage silent brainstorming sessions.
  • Organize virtual team-building activities such as fitness challenges or “happy hour.”
  • Keep them engaged by challenging them. For example, you could ask how they’ve overcome a problem in the past.
  • Shake things up occasionally, like surprising them by taking a virtual field trip or inviting a guest speaker.
  • Schedule events when it’s best for your team. While you’ll never find the perfect time and date, you could poll them to see what works best for the majority.
  • Wrap each function up on a high note. For instance, you could ask positive-direction questions like, “What did you find most valuable?”

7. Be consistent.

According to Jack Zenger and Joseph Folkman, there are three elements of trust; positive relationships, good judgment/expertise, and consistency. I think that you should have an idea about the first two. So, let’s go over what consistency means.

Consistency “is the extent to which leaders walk their talk and do what they say they will do,” they explain for HBR. “People rate a leader high in trust if they:

  • Are a role model and set a good example.
  • Walk the talk.
  • Honor commitments and keep promises.
  • Follow through on commitments.
  • Are willing to go above and beyond what needs to be done.

While this may not be the most important element, it’s still essential. For example, let’s say that you penciled in a one-on-one for Thursday at 3 pm. You had a family emergency and didn’t let the team member know you had to reschedule.

Your team member arrives on time and patiently waits. After some time has passed, they email you, and you reply that you had to cancel. That’s not only disrespectful of their time; it also shows them that you can’t be trusted to hold up your end of the bargain.

Posted by: lrrp | July 22, 2021

Delegating Effectively as a Tech Lead

Lessons and missteps in engineering leadership

Being a tech lead is difficult.

As a tech lead, you’re often expected to continue to be a high performer as an individual contributor while also taking on additional responsibilities to help the team. These additional responsibilities may include breaking down work into clearly defined tasks, grooming the backlog, prioritizing work, mentoring junior engineers, and resolving blockers for the team.

The hardest part of being a tech lead is learning to balance your individual work with the needs of the team.

How do you get your own work done while helping the team remain productive? You can’t do it all, and you certainly don’t want to burn yourself out by working longer hours.

One solution to managing this added workload lies in learning to delegate effectively. So the question is, when should you delegate and when should you do something yourself?

The Delegation Matrix

Tasks can often be characterized along two spectrums — complexity and frequency. A task may be simple or complex, and a task may need to be performed frequently or infrequently. We can use these attributes to determine when work should or should not be delegated.

Engineers love to automate tedious work. Ideally, anything that you have to do frequently should be automated as much as possible. For example, if you need to gather metrics for your team’s work each sprint, see if there’s a way to automate that process.

In the event that the task cannot be automated, simple and frequent tasks should be delegated. These could be things like running standup meetings or performing simple code reviews. Simple and frequent tasks are things that anyone on the team should be able to do with little or no additional training, so don’t make the mistake of thinking you have to do everything yourself. You’re here to help your team, but your team is also here to help you.

Simple and Infrequent Tasks

If a task is easy and rarely needs to be done, just do it yourself. If it would take longer for you to explain to someone how to do the task than it would for you to just do it, then go ahead and tackle it on your own.

Please don’t misunderstand. There is a lot of value in training team members and helping others grow. However, these kinds of simple and infrequent tasks generally are not the core responsibilities of someone’s job and are not essential to anyone’s career progression.

An example of a simple and infrequent task might be running a script once per quarter to generate a report. Or it could be purchasing tickets for an upcoming team activity — nothing too exciting, and nothing too time-consuming.

Complex and Frequent Tasks

Again, automate everything you can. If you can take a complex and frequent task and automate the process to complete it, you should!

Assuming you can’t automate the task, complex and frequent tasks should be delegated to your team members to help them grow. As a tech lead, you are someone who is good at breaking down work, planning projects, resolving blockers, and handling incidents. Train your team members to develop these skills too!

Ask a team member to lead the planning session for the next project your team is assigned. Delegate to a colleague the exercise of breaking down complex work into smaller tasks. The next incident that occurs, invite a teammate to debug the problem with you.

When you can train your team to handle these complex and frequent tasks, they will progress in their careers. It also frees you up to focus your time and energy elsewhere, as you are no longer the only person capable of doing this kind of work.

Complex and Infrequent Tasks

Complex and infrequent tasks are oftentimes the most difficult to delegate. These tasks don’t happen regularly, so they don’t consume too much of your time. They may be valuable for other team members to learn, but due to the infrequency of the task, the return on investment of training and delegating the work isn’t as high.

Complex and infrequent tasks should be delegated to rising leaders on your team as stretch assignments. You might ask a senior engineer to help provide a performance review for the intern that they mentored last summer. Or you might ask a senior engineer to do some research and then give a high-level estimate for a new feature that product management is considering but hasn’t committed to yet.

These types of tasks don’t come up often, but they can be good learning experiences for all involved.

Summary

Let’s return to the delegation matrix. Here it is, all filled out

As you can see, much of your work can be delegated! Your role as a tech lead is to help keep the team productive, and oftentimes the best way to do that is to invest some time upfront to train your team members so that soon they can handle even the most complex tasks on their own.

Older Posts »

Categories