No matter the industry we work on, the main thing that is required from us is interacting with people.
Do you work in accounting? That’s people business.
Do you work in sales? That’s people business.
Do you work in IT? That’s people business too, even if it’s hard to admit sometimes.
As we do more and more in our organisations, we’ll end up dealing with more and more people, and as the number in interactions grows, some of them will prove more challenging than the others.
Nobody likes conflicts, but sometimes it seems that there is no other way. Or is it?
As Kim Scott preaches in her book Radical Candor, the way to successfully dealing with other people is striking the perfect balance between being humane and empathetic on the one side, and being constructive and demanding on the other. In Kim’s words: Care Personally and Challenge Directly.
How can those two combine?
This is based on the principle that we should spend much more time building a relationship than fixing it. From my experience, I would say that the right proportions are 90% vs 10%.
What if we manage to build a strong relationship with our coworker and direct reports? What if we enjoy time with them outside the office? What if we get to know them? What if we get to know what moves them? What if we get to know their spouses and kids?
When you get to that point, you’ll share a true connection, cause you’ll know her and she’ll know you. Namely, you just won’t be strangers happening to work in the same place, but people that met in the workplace but are much more than just coworkers.
This holds true when the time for the tough feedback comes: the feedback will be much more welcomed as it comes from a person with whom she has a connection. This is how the 10% of the time fixing the relationship should be spent.
Kim goes one step further: she advocates that during the tough feedback no beating around the bus should happen. The challenging should happen directly and right to the point and provide a mean for the coworker or direct report to improve. The main goal is achieving a balance between offering constructive criticism and at the same time being helpful, and not mean.
If you’re able to do this, it would put you in the Radical Candor quadrant, and make you a very effective leader.
That’s nice right? But, if I’m not in the Radical quadrant right now, where am I?
Well, this might actually be bad news!
Ruinous Empathy™ is what happens when you care but don’t challenge. It’s praise that isn’t specific enough to help the person understand what was good or criticism that is sugarcoated and unclear. Manipulative Insincerity™ is what happens when you neither care nor challenge. It’s praise that is non-specific and insincere or criticism that is neither clear nor kind.
Where should we start? I’d say that getting your copy of Radical Candor today is a good first step!
We’ve all been there, little by little a person who we loved working with became defensive toward us, started criticizing everything we do or say and all our efforts to bring the relationship back to normality seem to flounder. What to do then?
Let us consider the period where everything was smooth and collaboration was a breeze.
What changed since then? Did the project become more stressful? Are you struggling to pay back technical debt in your project (see a help on that here thegrid.ai/pierobon/a-different-approach-for-tackling-technical-debt ) ?Are you going through a personal rough patch? Is the other person, maybe?
Try to consider what had changed and do not assume you did not contribute to the situation. As a leader your words and actions have a huge effect on the people you work with, and when you’re not motivating or insecure, it stands out more than you think.
After you highlighted 2 or 3 possible causes get a talk in private.
You can open the conversation by saying how much you loved the level of collaboration and trust you had before (do this only if it true, or sooner or later it will catch you), and continue by asking if there had been a change in your attitude that lead to the situation.
Ask if there is some situation outside of work that might have contributed and verify if some working arrangement might help (remote working, time flexibility, etc).
Remember to not blame the other person for the situation and be listening to every feedback you receive.
Let us assume that during the talk you highlighted 3 or 4 points that caused the deterioration in the working relationship.
Write them down and agree on a resolution plan, defining what each person will be expected to do.
Remember: if you want other people to change you have to change first.
There are quite few things we cannot escape in life, like getting fatter if we don’t exercise or eat properly.
For us developers, though, what we really wish we could avoid is technical debt. Sadly enough, technical debt cannot usually be averted (at least not completely).
From my perspective the very moment when the code is committed, it becomes automatically legacy code that will need to be maintained.
People in the organisation will change, clients will change and most importantly requirements will change. Our shining and beautiful code that we’ve just written will make no sense to the future developers that will look at it (and give it enough time, it will not make sense to whom wrote it in the first place also).
What of it then? As our codebases get larger and larger and get contributed by more and more developers, we’ll find ourselves lost in a code maze without any direction: we’ll see a variables called count, count2 and count3 in a method with several hundreds line of code, with nested foreach and possibly recursion.
How did we end up here? I’d prefer to start with why.
Developers are said to bordering artistry. While I’m not totally convinced by it, I see the great gift we received: we are makers and we love it. The whole process of creation can become a transcendental experience, where we isolate ourselves from the world and solve difficult problems using our mind and knowledge.
The main concern here is that, while we do it, we almost never take a step back and try to figure out if someone else would understand what we’ve done or even like it.
As we will are not able to make sure our code will be easily understood and maintained by others we do code reviews. Usually senior devs go through the code and say what’s good and what is not, often according to their own taste.
What we’ve come up with is a standardized etiquette for the Pull Request submitted and the Pull Request Reviewer.
What am I trying to do?
Please explain with your own words what is your intent with this code change.
What I am thinking in terms of impacts (changes in the app/configurations that need to change in order for this to work)?
Do we need to update the build and or release definitions? Do we need to change the Powershell scripts? How will the application behavior change?
Is the team in sync with this impact?
Is the rest of the team aware of this change? I’m a changing a functionality someone is also working on?
Did I validate the change locally?
For code changes: Did I run the application locally with this change?
For script changes: Did I validate the script locally? Did I account for the script usage in the current builds/releases?
Did I provide tests for this code?
You are expected to provide code for every change you submit. If you were unable to (UI-only change/untestable code) you need to flag this to your dev lead.
How did I improve the codebase?
You are expected to improve the codebase with each and every pull request. If your change did not involve code, fish for:
Does it solve the problem? Will it be relevant two weeks, two months, two years, two decades from now?
Taking a step back, is this a real fix to the problem or just a temporary patch that will get the client to send back another bug report next month?
Does it do it efficiently given the constraints?
Keeping into account the time and budget constraints is this a good solution? Is it worth to invest more time and improve the code scalability/performance?
Would this code be easy to support moving forward?
Would we be able to understand this code in six months?
Does this change has a significant risk of introducing a security breach?
Are there possible security considerations that haven’t been taken into account?
Checklists are not intended to solve all the problems. They serve a very specific purpose: they keep us focus on the fun and great work we want to do, while making sure we do not forget to take care of the houseworks as well.
Having a set of checklists for the PullRequest process ensures that the code that gets in has gone through some serious consideration before being merged and makes the review process more consistent across different reviewers.
After updating to El Capitan I noticed high CPU usage when doing anything mildly demanding on my MacBook Pro.
Connections allow to create integrations.
A connection can be a source, a target or both.