The one to first come to mind is often This is wrong!. The other one, easy to miss, is a parallel path of I am missing important information.
Before I know what the case is, I try to act as if the cat is both dead and alive at the same time. Both options are true and false. It keeps the door open for different scenarios, and have respect for the competence in the person receiving feedback.
Take a code review as an example, where I encounter some asynchronicity. that looks like it would cause a race condition.
Lets look at the alternative conversations.
- Race condition, fix it!.
- Oh, thank you for spotting. I knew I had to fix it, but forgot.
- This looks like something that could cause a race condition. Or is there anything I am missing?
- Oh, thank you for spotting. I knew I had to fix it, but forgot.
- Race condition, fix it!.
- This part of the data is immutable now. You must have worked with the other team the week we changed that. Good I got to tell you!
- This looks like something that could cause a race condition. Or is there anything I am missing?
- This part of the data is immutable now. You must have worked with the other team the week we changed that. Good I got to tell you!
The tone shifts a lot depending on how the first sentence is phrased. And the difference is clearest when the reviewer is wrong.
There is a risk of not sounding sincere in the question, then it won’t work. People who are underestimated might seem ignorant rather than humble. That has to be taken into account.
The next time you give feedback, phrase it so that the conversation can flow also when you are wrong.
]]>If we want people to learn new things, collaborate with an open heart, and challenge the limits of their capacity, we do that by creating a safe and nurturing place for them.
The way out of the comfort zone is to have a comfort zone to start with. Make people feel so safe that they get bored and start creating, so cherished that they dare make a fool of themselves, and so relaxed that all energy go into the task at hand.
]]>It is not your fault.
Software causes stress in the workplace.
The stress can come from things breaking down unexpectedly, like projectors not starting, audio missing in the video conference call or the e-mail draft disappearing as you refill your coffee.
There are also the thousand cuts from the paper free work place. Interfaces that are clunky, dropdowns with a thousand options, where the most common is the last. Forms demanding you to type in the same information three times and then complains about the format. (Perhaps by erasing everything you entered in so far.) Information portals with unreliable search and no predictable structure. Not to get stared on permissions to add or change information (or structure).
This text is about coping with what you can not change. Part two is about eliminating the source of the stress (bad software).
Software should never make you feel stupid.
When the printer throws a tantrum or an app suddenly restarts, the responsible people are:
Unless you are on that list, it is not your fault.
Software doesn’t have to be like that. The industry knows how to create intuitive interfaces. There are processes for writing reliable software. User research exists, just not enough. You deserve better software. No human is non-technical, it is the technology that is inhumane.
Reporting issues with software has two benefits. If the software organisation is good, it will use the feedback. For organisations too immature to appreciate it, at least you can use it to let out some steam. Put your frustration into precisely worded descriptions and screen recordings showing the problem. Be polite, since that will help the organisations who welcome it and annoy those who don’t.
If the workbench has the wrong height, or the knives are blunt, you can not expect the best results. The same is true with IT. You have to adjust the expectations on your staff accordingly. (At least until you are able to fix the software.)
The cognitively ergonomics of a workplace are as important as the physical ergonomics. Software that is hard to use and/or unreliable, will affect the work, regardless of the attitude among the employees. It is biology.
Software developers also suffer from IT-related stress. No one is too clever to benefit from easy to use software. If you are taxed by flaky tests or buggy editors, know that you also deserve good interfaces and reliable experiences. You are not less for wanting to work smart rather than hard. If you struggle with getting software to work, it has nothing to do with your aptitude as a developer. You don’t have to be smart to make someone else feel stupid.
If you are a manger, or a role model, in IT, don’t idealise fire fighting. Acknowledge when infrastructure and tooling are slowing you down, and celebrate the canaries in the team.
]]>Still research shows that the shapes constructing glyphs are similar over different alphabets. So is the frequency of those shapes. On top of that, the common shapes in our alphabets are also those common in nature. Patterns we did evolve to recognize.
Neurological research on cats shows how the matching of parts to a whole works when recognizing shapes. The process of matching a shape, in different fonts and sizes, to a specific letter, seems to be build into our brains. Or, more correctly, our letters have evolved to match how the brain decodes shapes.
An “x” is easy to recognize, but takes three movements to draw by hand. So the theory is that the cost of forming a letter is seen as less important, than the cost of recognizing it. When exploring shorthand and scribbles, other shapes are found, shapes optimized for our motor function.
Our current alphabets, not only the Latin one, have evolved to be easily decoded. They have not evolved to be easy to shape.
We have not evolved to create software, but we should let software development evolve as our letters have.
Code should always be easier to read than it was to write!
]]>IQ is a measurement widely used, though problematic, due to its history and how it has been used. (I recommend this series by RadioLab)
For a group working together the same phenomenon is called “collective intelligence factor”. Just like individual intelligence, it aims to describe why some teams have consistent better performance, independent of the nature of the task. Research by Woolley et al. shows that there are two major factors that contribute to how intelligent a group of people is.
- Correctly reading the emotional state of others
- Equal contribution in conversations and turn taking
Compare this with aspects of ensemble programming.
Regular retrospectives create a place for learning about others experiences. Retrospectives are a great way to improve your work, and one aspect is practising empathy. It creates a forum for sharing your perspective, including how you feel. An ensemble session ending with a short retro builds a feedback system for the team interactions.
Talking on a timer creates a framework for distributing contribution. We are not very good at judging how talking time is actually distributed. Strict ensemble working, with a timer, helps us get input from everyone. It could also help us get a better sense of what equal talking time feels like.
The interactions of a team is more important for the result than their individual intelligence. That is good news. It is hard (or even impossible, depending on definition) to improve ones intelligence. The dynamics of a team, and how we read and regard others emotions, can develop.
If you want to improve the general performance of a team, help them:
One way to do this is through ensemble working, ending it with a short retrospective.
]]>The first time I heard of Westrum organisational culture I misheard it as “Restroom Culture”. I thought it was a way to tell company culture by looking at shared facilities. It turned into a neat mnemonic, so now I bring you the explanation of the three organisational cultures of Westrums, using restrooms. Hopefully, though a bit silly, it will help you remember the real name, as well as the concept. What kind of culture do you work in?
No one dares to use up the last square of toilet paper. That person will be punished and might even be fired. The storage is locked, some few select have a key. If you are friendly with someone who has access to extra toilet paper you might get a fresh roll. But first you have to find out who those people are, and how to suade them. No one dares to mention that it might be wasteful to limit access to toilet paper. The last one who brought up the subject was first publicly blamed for all restroom related problems and then let go. Some people bring their own rolls, but in secret, so that it won’t be taken for critique.
Toilet paper is refilled Tuesdays and Thursdays. If it runs out any other day there is a form to fill out that heed approval from your bosses boss. Any suggestion to change this will be ignored. Employees are not trusted with important things like toilet paper.
Toilet paper is stored where everyone has access to it. If it runs low anyone who notices takes action. There is also a supply of sanitary products available in all restrooms, as a result of an employee initiative.
]]>In ensemble programming we can use the same principle, but for a forest of developers. Everyone in the team does not have to be good at everything. The important thing is that the team has enough psychological safety so that all developers are “independent” and can add to the total result.
This is one way to understand the power of ensemble programming.
]]>Some other animals are hatched with everything they need to know to survive. The parents, or rather the source of the egg and sperm, might be miles away. Still the young know what to do to get by on their own.
As a grown up human it is easy to forget everything we once didn’t know. In the software industry I see this manifest in a specific way.
Software developers are mammals.
Every TLA (three letter acronym), language caveat, “convention over configuration” and buzz-word you know, was once new to you.
Software developers do not hatch.
Remember this when you interact with people that are new to the technology you are using.
Remember that you once did not know the things you know today.
Be kind. State things explicitly. Create documentation that make people feel smart (and not in the “I just deciphered something” way). Be curious about what others know that you have yet to learn.
Software developers are born, not hatched.
ps. I recommend the Wayfarers series by Becky Chambers for more inspiration on things like sentient reptiles.
]]>With people working closely, preferably in the same room, the result will be better. But with only verbal communication there would be no ticket systems, version control data or minutes from sprint meetings to tell the story about the work.
Taken to its extreme, this could be compiled source code with no other information accompanying it.
Working tightly with the customer, a relationship based on good communication and trust, there might not even be a contract. But a contract is also an artefact of that relationship, that can tell stories about it to those who come after.
Working with one thing at the time, measuring effect as we go, there might not even have to be a plan. The step we are at now will get results directing the next step. That is a great way to get value through the door. But without a plan, there will be one place less where our intentions and dreams are recorded. In worst case we end up with a compiled binary and nothing else. With no artefacts produced by processes, tools, contracts, documentation or plans, there are no clues to how the product ended up the way it is.
That is, while there is value in the items on the right, we value the items on the left more.
One of the values in the items to the right is communication with the future. Telling coworkers to come, or future versions of ourselves, the context of our decisions. When agile “goes overboard” this is one of the things that are lost. Few projects end up as only a compiled binary, but a lot is left with less context than would be helpful. The understanding of software is dependent on context. Tell the story of you software with deliberation when cutting down on accidental artefacts. Do not let your reasoning go traceless.
]]>Then the focus is moved to connecting with the child.
“What part of this chapter did you like the most? What do you think will happen?” Most of the time the request is actually about connecting with the parent.
Next time I get a feature request, that will not be instantly prioritised, I will try the same.
“Yes, it would be nice to also be able to filter days by phase of the moon . If it would not have caused any other tradeoffs we would implement it today, but it is not possible at the time.” Then move on to connecting and getting the customers perspective. “What problem would filtering on moon phase solve for you? What made you come up with that idea?” It might be that this customer has insights that you can not get from your perspective (some live their lives by the rhythm of the moon). It can also be that the customer likes your service and wants to be a part of the work, feel connected and seen. By both asking about the feature and taking interest in the customer the questions move from justifying the request to understanding the customer.
So next time a customer scream for ice cream, see it as an opportunity to connect.
Ps. One such parenting book is this “Med känlsa för barns självkänsla”.
]]>When I started working I met a lot of people who had worked in the kind of projects that the agile manifesto was a reaction to. They had first hand experience of the pain that agile was supposed to fix. Often they had fled the old company before ending up in a team with me.
In my world “working software over comprehensive documentation” was a “no sh*t Enola”. But I still thought that it was a good idea to write some things down. I am quite forgetful. For those previously stuck in waterfall without water, documentation was the evil personified. The manifesto states “…, while there is value in the items on the right, we value the items on the left more.” But to some it still turned into “no processes, contracts, tools, plans or documentation!!!”. That made it very hard to be the new kid in the team. It made it hard, full stop. It actually gets very tricky to write working software, collaborate with customers, adapt to change or interact with people, without any kind of structure.
The inevitable pendulum of human culture, one could say. We do see “agile frameworks” with lots and lots of structure those days. So much processes, contracts, tools, plans and documentation that it could be argued that there is no room for agility in them. Are we doomed to the eternal circle of throwing out babies and bathwater?
My suggestion is that we put all our focus on what we do want. I believe that The heart of agile with its collaborate, improve, deliver and reflect is one way to do that. Things that we want to avoid will change with time. For me right now it might look like “Working software over extensive backlogs” “Customer collaboration over genius entrepreneurs” “Individuals and interactions over 10x programmers” (Ok, to be fair, I do not really value the right side of those, but I would perhaps miss them if they were branded as the new evil.) Being guided by what we fear won’t help us. It might even make us avoid the things we do want, like collaboration, since it is harder to collaborate without processes for retrospective or tools of communication.
Bridge the agile gap by focusing on what we do want! We can use the left side of the agile manifesto, The heart of agile, Theory of Constraints, Lean or any other teaching that share their general message. I would say that the essence is: Focus on what really brings value, do it together, optimise for fast feedback and use what you learn. And if you see an old oaf who refuses to write a readme, or a young brat who seem to want waterfall all over again, remember that you probably work for the same outcome, you just have different experiences.
]]>Objective is a thing presented clearly to the mind. Sub in subjective is the same sub as in submarine and subterfuge. In the subjective, there is something hidden. Something is present beneath what we see. It can be called context or a person’s world view. The problem is that it is not explicitly stated.
When we try to solve a problem, or adapt to the present situation in some other way, it is important to know what is really there. In NVC there is an unfulfilled need that might be hard to state explicitly if we are allowed to be subjective or even judging. In TOC we need to find a conflict that can be challenged or a false dichotomy. That might be hard if causes and effects are hidden in assumptions. Mindfulness is the practise of seeing things as they are so that they lose their power over you. Things hidden beneath the subjective are hard to see. In acceptance therapy we have mindfulness, but also acceptance through acting. We can not act correctly if we do not know, and accept, what is going on.
So trying to fix a problem that is described in subjective terms is like debugging a system we have no access to. The best we can do is to guess, and perhaps restart a server.
If we learn to break down the subjective statement into objective statements, by making the implicit explicit, we can finally see the entire puzzle we are trying to solve. When figuring out what to do, we need all the information on the table. That is why subjective statements are dangerous, they hide information from us.
]]>Theory of Constraints (TOC), created by Goldratt, has a thinking process called a Current Reality Tree. It is build to figure out the root problem in a system. It is about gathering information and then question assumptions to find a really good solution. TOC is used, among others, to optimise production and increase sales.
The two frameworks might seem to have very different purposes and target groups. NVC is about people and communication. TOC is about money and logic. To me that is a false dichotomy. As I learn more about both TOC and NVC I see a lot of similarities. Empathy driven development shows that empathy is a technical skill. The parallels between NVC and TOC that I list below is in agreement with that. Hopefully that can make both communication and logic feel more accessible.
One of the fundamentals in NVC is to create such big understanding between people that fulfilling others needs become easy and pleasant. (That is also directed onto oneself, by knowing my inner motives for doing a task, it becomes easier to do it.) By looking at the need, rather than at a specific request, finding something that will fit everyone is easier. In TOC this is called “no compromises”. Goldratt claims that no-one should ever compromise. Compromises are giving up on finding the solution that will benefit both. And, according to TOC, there is always a solution that will make both parties happy. The only thing you need is a thinking process that help you find the real issue to solve and what assumptions to question to find the answer.
To increase performance of a system with TOC you need to know what to measure. That is the origin of the title The Goal for the first TOC book. If you do not measure outcomes for the entire system there will be local optima that decrease the system performance. And you will get what you measure, so you better measure what you want to get. In NVC the conflict between parts has to be distilled down to our needs and what emotions are connected to those needs. Focusing on how we think that those needs should be met are not helpful. That is the same thing as creating local measurements in a factory.
When it comes to gathering data TOC and NVC are using almost the same wording. We need to look at how things are now. And there is no judging. We only want to know where we are right now, and it should be objective. Worth noticing is that the phrase “I am angry.” is as objective as “This machine has a maximum output of ten units per hour”. While “you make me angry” and “this machine is too slow” are both subjective. In TOC this is structured in a Current Reality Tree, with a handful of undesired effects connected with “if this is true, and this is true, then that is true” as a directed graph. In NVC the giraffe has taught us the formula “When W happens, I feel X, since I have a need for Y, I would rather have Z happening”.
TOC has bottlenecks. NVC has needs that are not met. In a current reality tree, assumptions about other participants are challenged. Look at the problems. Then look at your counterparts problems. Try to find a solution that fixes both your and your counterparts problems. In NVC we listen with compassion and try to really understand our counterpart. That enables us to give with joy. To me that sounds the same.
TOC then create a future reality tree, while NVC can create a suggestion to the solution. In both cases this is discussed and evaluated further.
Ifs and then’s can be spoken or drawn as a tree. Having a clear picture of what is going on is powerful regardless of how. Emotions carry information, and can be treated as information. It is hard to know what the real problem is. We can not guess what other people are thinking, or the needs of a customer we seldom talk to. All of this, and more, can we get help with from both NVC and TOC. And since it is hard work to learn how to communicate and think better it is good that we can practise it in almost all we do. But then it helps to see that what we practise with a friend is also valuable at work.
We need logic, even if not everyone likes directed graphs. Emotions are valuable data, and I wish that more people would feel comfortable with using it as such.
If you are comfortable with NVC or TOC try to explore the other system. If you are new to both I would recommend TOC as a start, but focus extra on the parts in the books that are about relationships.
]]>As a consultant there are thresholds made by fear everywhere. Recognising it as fear might be hard, but Patrick Lencioni gives us tools for understanding the origins of our emotions. In his book Getting Naked : A Business Fable About Shedding The Three Fears That Sabotage Client Loyalty he divides them into the fear of losing the business, being inferior and feeling embarrassed. Strategies that both challenge those fears, and benefits the customer are listed in the book. This is what I took with me from reading his work.
The fear of feeling embarrassed makes us withhold ourselves from the customer. Asking questions, that might be dumb, aids the customer by making sure that everyone actually understand what is going on and that nothing important is missed. The outside perspective from a consultant will also bring a company new insights. But that only works if the consultant has the courage to share their thoughts, even if they seem obvious or silly. Celebrating our mistakes also fight this fear and makes it easier to try things out, for us and those around us.
The fear of losing the business holds us back from giving everything. It can be in terms of giving help to a prospect customer that ends up being all they need from us. Or having our honesty bring a customer relationship to an end. The solution is to jump into the cold water. If you enter a situation where something feels off, bring it up. It is only by getting naked that the consultant can point out that the emperor has no clothes. But we tell the kind truth. It is not about embarrassing the emperor, it is about getting him a better tailor. Start helping the prospect customer before any contract is in place. Show that you bring value before negotiating the rate. Then you know that it is you, and not your CV, the customer wants. And everyone knows you can make a difference, since you already did.
The fear of being inferior is the foundation of the imposter syndrome. The naked consultant solves this by taking pride in not being proud. If something needs to be done, we will do it. If there is a way to save the customer’s face by taking the proverbial bullet, we will do it. This is enabled by a true interest in the customer’s work. Success for the customer’s company should always be closest to our heart. Only work with customers where you can share their passion. This way we have something to focus on instead of our ego. It is our ego that fears being inferior.
Being in a kind environment help us battle all of this. I wrote earlier that practise is the only thing that makes sauna and cold baths easier. I did not mention the crowd of friends cheering you on from the door to the changing room. I know that I am not enough. But when in a good environment, my team and I got this, when working together.
The DevOps report tells us that the number of elite performing companies have increased between 2018 and 2019. At the same time the medium and low performing group is still more than half of the respondents. The IT-industry needs nakedness. For those ready to jump into the cold water there will be plenty to do for a very long time. And I will fight my fears every day, as a consultant and employee, for the joy of seeing progress.
From my Finnish friends I have learned that in the sauna I am not naked, I just don’t wear any clothes. As a professional it is the other way around — I am fully clothed, but completely naked.
This is a slightly modified version originally posted on LinkedIn.
]]>As a developer I spend my work days submerged in code. That is my work environment, together with all the tooling that come with it. For work to be pleasant it matters how the code is written. And just as software architecture, with its patterns and structure, come form the architecture of houses, there is now software interior design. I like to share some of my principles around it.
You do not have to like things the way they are, but you can not act appropriately to a situation while pretending it to be another. Sometimes it can be hard to know what is really going on. But when you do know, try to see it for what it is. That is the first step towards changing it, or dealing with it otherwise. Sounds like sappy self help talk? But if it was your hard drive being full, you would not imagine that ignoring it would solve the problem. First when you acknowledge that you have a space issue you can either stop adding stuff, start deleting things you do not need, or look into options for more terabytes. Probably all three. Take the hard drive problem solving attitude with you into other, more sensitive, areas. The reality will give you a starting point to act from, the fantasy will not. If you want to look more into this you can search for “ACT, acceptance and commitment therapy”. It is really just about tools for dealing with your life the same way you would with a software problem. Find what is really going on and then fix it, or figure out how to live with it.
Think about how you think and feel. The symbolic interactionism of social psychology sees the self as a dialogue between the “I” and the “me”, where the “me” consist of what we think that other think about us. It is like writing code with the code review in mind. “I need to run the linter so that Ed sees that I care about the team”. But what we write is not code, but our identity. Meta cognition is to add another layer. “If I write the function like this, Ruby is going to say that I need better naming, and Ruby is someone I trust, so I should think some more about the name.” “This function could be broken up in two, and Tess at my old job would probably tell me to do that, but in this team we have longer functions, so I should probably not care about what Tess says right now, perhaps later. “ We can do the same thing with our thoughts and emotions. “I feel sad right now. That is ok. I could be sad since I am hungry, or since I felt misunderstood during that conversation I just had. If I get something to eat, at least I can rule that out. Still sad. What was so hurtful about that conversation? …” With a conscious relationships to the conversations in our head, we get power to change our (inner) lives.
One example is how we can use time to change our perspective. As a kid, when walking home through the cold and the dark, I focused on the feeling of finally getting home. Then I could use that sense of joy and relief as a shield against the Nordic winter. I shifted my perception of time into the future, just enough to keep walking, but not enough to worry about tomorrows homework. The same trick helps me get some rest by focusing only on the present. If I let the past and the future fill my head there will be no break. But in the present, probably in a sofa with a cup of tea, there is relaxation. Even if it is only five minutes, they are fully mine if I shrink my reality to only be those five minutes of peace. Letting regrets or worries sabotage my moment will not solve anything. Rested I am better prepared to deal with the things that I can do something about.
Mindfulness is a good word to look for, if reading more about this. That is a tool for adding monitoring, orchestration and debugging into our own thoughts and emotions.
You are not done yet. As a software developer we learn new things all the time. Communication, regulation of emotions, self awareness, relationships and other things that make it easier to be a human, are also skills you can practise. If you believe that you can learn the new features in the next release of your favourite tool, you can learn this too. There are books. There are exercises. There are videos and podcasts. But just as coding, it takes practise. Life is unfair. Not all got put in front of a computer at a young age being encouraged to tinker with it. Not all are encouraged to talk about emotions or expected to take responsibility for their relationships. Luckily there is room to catch up. Just know that you can change. And learn. And grow. In all areas of life. Believe that failure is not a sign that you have reached your limit, but a clue for what to learn next.
These tools do not always work for me. I am still learning, growing. But they help often enough for me to want more of it. And I know that with practise it will make my life even easier. Also when my life gets harder in other ways. Keep growing!
Further reading:
Debugging your brain by Casey Watts is a concise book with practical advice on meta cognition. I highly recommend it. It is also available on audio!
]]>There are null checks at each level of the code. The log prints messages of “this should never happen”. Every other line gives the impression of a bomb about to go off at any time. Only an infinite amount of safety checks will save our lives.
Solution. Have an explicit way to deal with the unexpected.
For the uncertainty of the outside world, such as user input or network data, create a validation boundary. Push that boundary as far out in your code as possible and make all the code after that a safe place where everything has a valid format. Let the boundary deal with input that would not be useful for your code.
For the fragility of our systems, hardware that break and buffer readers who get digestive issues, catch errors purposefully. What are the consequences for the rest of the system if this breaks? Who needs to know? What can they do about it? What do they need to know to handle it? This is also what the uncertainty boundary needs to do, in protecting the rest of the codebase in a constructive way in respect to different kind of users.
This way we will trust our braces or our belt. And we can leave out the duct tape.
Breaking the “single responsibility principle” can sometimes be caused by a believe that the highest design priority is how many lines of code that can be scanned per second. Then we hesitate to break things into smaller units and hide them behind abstractions. So why do we feel this distrust in code we have not read? I think that it happens when reading the code is the only way to know what it does.
Solution: What you see should be what you get.
Side effects are a good way to drive a developer crazy. Seemingly random things in a method intended for something else. That indicates code to be read line by line. Having collaborators that can be accessed without being provided by the outside is also a way to create a sense of uncertainty. Especially if it is a shared state that can be mutated. Explicit is better. Code that depends on inputs, dependency injection, will have to be clear on who it collaborates with. Together with language specific features, such as types, paths of exceptions or asynchrony and naming conventions, we can let the code tell its story.
Then the developer will feel safe not to read every line. Stay safe!
ps. Tests are also good for not being scared, especially when refactoring.
]]>TL;DR; Use a linter for your code! And fix all errors and warnings. Your brain will thank you.
In software, a linter is a static code checker. It looks at syntax, code format and white space, spelling, coding conventions, patterns that might cause bugs and other things that is not related to business logic. A lot of them have configurable rules, ways to make exceptions (that can be used for gradual introduction in legacy projects) and ways to auto-correct your code.
I see a linter as a cognitive tool, something we use to relieve our brains so that there is more energy left for things like problem solving. Here are three ways linting does that:
Social negotiation takes energy. When a team has decided on the linting rules the discussion is done, or at least not constantly debatable. And it is enforced without any specific person having to take the fight. Have a pipeline for the code where linting is checked before code ends up in a flow shared by other developers.
Code that is regular is easier to read. Having a common standard is much more important than what standard you use. But the removing of noise only works fully if you do not let the linter add noise. Therefore it is important not to let any errors, or warnings stay. If you have something in your code that you want to keep, though the linter is protesting, make an explicit exception to silence the error or warning. As an extra, some linters can also recommend a simpler syntax for achieving the same behaviour. That can make your code less verbose without obfuscating it and then also remove noise.
A lot of what the linter does is things you would like to do, but now you do not have to. As with spell checking, you can find and fix all the deviations from how you want your code to look, while reading it and having it reviewed. But as with spell checking, that is neither the fun part of writing nor the most energising thing to give and get feedback about. Let the computer do the boring stuff.
Linting might find bugs. Especially in languages without a compile step, the checking for risky syntax is very valuable.
So, go and lint your code! And add the linting as an automatic step when writing code. That way you let the machine do a little more of the boring job, and leave more energy to do fun things, like problem solving.
]]>Psychological safety is found to be the key to why some teams benefit from diversity and others don’t. A part of being an underestimated person — someone who most of the time is the “diversity” of a team — is sometimes entering worlds where you feel you don’t belong. In a team without psychological safety you do this by sacrificing your voice. Just like the mermaid, you then lessen your chances of actually getting to stay and be recognised for what you can bring the team. Research shows that underestimated people are extra sensitive to the presence of psychological safety. One of the factors for predicting successful teams is that every voice is given the same space. In a psychologically unsafe space the underestimated people act as the canaries in the coal mine. They get silenced first. Therefore, only psychological safe teams can benefit from diversity.
Just as the little mermaid could not get her voice back, there is no way a single person can “become psychologically safer” or fix the issues in a team on their own. If those with strong voices want to utilise the full potential of their team, and listen to everyone, they will have to do a lot of the work. It might seem unfair to expect the prince to do the work when it was the witch who did the bargain with the mermaid. Life is not fair. The prince has power the mermaid has not, regardless if he asked for it or not. With great power come great responsibility, regardless of how the power is granted.
It might be easier to just keep the mermaid mute and pretty, dancing to please the prince as in the original story. But that will not build a great team. And even though the original story of The Little Mermaid is said to have a happy end, it does not include the prince. In STEM that is sometimes referred to as “the leaky pipe”, when the group grow more homogeneous as people that are underestimated leave.
So if you are underestimated and mourn the loss of your voice — have some hope. The magic word is psychological safety. It is the key to succeeding at all knowledge work done by a team. Awareness of it will grow. If the pain is too big, remember that it was Disney that made the happy end “to live happily ever after” with a prince. The original mermaid ended up spending 300 years with her sisters before going to heaven. Find a place that do you justice.
And if you have a mermaid or two on your team, and want to hear what they have to say (not only watch them dance until they leave), read up on psychological safety, and then act on it. Diverse teams have a competitive advantage if all voices are given equal space. And no one should have to lose their voice to get access to the software industry.
]]>So what if we made all time touch time with total disregard for individual productivity? If we instead optimize for the groups productivity, making sure that a feature never has to wait for information needed to be completed.
With a batch size of one and only one workstation, where would we end up?
And people are surprised that using ensemble programming can be a competitive advantage.
]]>