Camila Henrique

Communication tips for tech people

Photo by Volodymyr Hryshchenko on Unsplash

Hello hello!

I want to talk about communication, mostly focusing on what we, geek souls, do as common mistakes and what we can do to improve it.

Personally, I’ve always tried to make an extra effort to communicate as clearly as possible. And that is a rule I live by, specially when I talk to non-tech people. What I mean by that are managers, scrum masters, project stakeholders and clients for example. We need to know that when we’re talking to someone, and that person is not from an IT area (or maybe even is!), they may simply not know the terms we are used to.

When you try to sound fancy talking about your job, about how you solved or stopped something from happening the other day, you may feel a need to drop-in some technical terms…perhaps you should ignore that need.

Truth is that you will sound like someone who has no empathy to their listener.

Eventually, your colleague may even ignore talking to you because they just don’t get what you say. Ouch.

Imagine you know nothing about cooking, and then you go ask a chef for a recipe, and they talk about all different kinds of kitchen utensils and cooking techniques, using all kinds of French names and other stuff you have no idea about. Would you like that kind of approach? Wouldn’t it be better, if the chef explained it to you in an easier way? Gosh, you just wanted to have dinner.

So whenever you feel like taking a shortcut and use all the terms you do on your job, take simpler steps. Describe them, explain what they are, use common terms, and most importantly – show examples.

Once you remember this rules, your communication should flow more naturally, and people will want to talk to you because now they get it!

Where can you apply all this?

Everywhere. In person/online meetings, emails, blog posts, events. There’s no limit, go for it.

Take a few extra moments to actually explain the process. Always give the person the context behind what you’re talking and they’ll most likely understand it. Don’t get too attached to some terms. You may be even repeating the same thing without realizing it, because you’re not listening to yourself.

For example, let’s say you’re running out of space on your server’s disk drive, due to the size of your backup files. You need to bring in your manager to discuss your options, which may include budget wise decisions.

Start by giving them context. Explain what are the backups. Explain WHY you need to take backups. And win they heart by scaring them off with “here’s what happens if we lose the files for a week”. Show them a screenshot of how much disk space you’ve used vs how much you’ve got left. Bring them the info of how often you clean the folders and zip files, and approximately how much time you spend on that. Once you lay the ground, they will see how relevant that is, and why you need their ~~money~~ support.

That’s what works for me. Looking at if from a slightly different communication tool, I love it when someone is having an issue and they send me an email with all the information I need upfront. A beautiful email would contain things like:

what happened
when it happened
what’s the suspected root cause
what happens if this is not fixed within x hours/days/weeks
who uses it
and if they’re an angel they may even give me a suggested fix (mostly within IT teams)
they avoid using really specific terms and describe things instead
they avoid using internal terms that others from outside the team may not know

That makes my life easier. I don’t need to be going back and forth about the issue, because just with that one email, I have enough to *at least* start investigating. Honestly, by being proactive about that email, the person just saved ourselves a chunk of time and our inboxes some space. There is nothing more frustrating than going back and forth trying to understand what happened and the other person is just trying to scape from your questions.

There are many other tips about this topic, so I’ll bring it again. In the meantime, what’s something you do that makes your life easier when communicating with non-techs? Share it on the comments below 🙂

Would you like to read this post in Portuguese? Click here.

Dicas de Comunicação para pessoas da área de tecnologia

Olá!

Hoje eu vou falar sobre comunicação, com foco no que nós, geeks, cometemos como erros e como podemos melhorar.

Pessoalmente, eu sempre tentei fazer um esforço para me comunicar do modo mais claro possível. Isso é uma regra interna para mim. Especialmente quando eu estou falando com pessoas que não são da área de TI. Como por exemplo, gerentes pessoais, gerentes de projetos, scrum masters, parceiros e clientes, por exemplo. Nós precisamos saber que enquanto estamos falando com alguém, e a pessoa não é da nossa área (ou às vezes até podem ser!), eles podem simplesmente não conhecer os mesmos termos aos quais estamos acostumados.

Quando você tenta parecer espertinho ou espertinha falando do seu trabalho, sobre como foi incrível resolvido aquele problema no outro dia, você talvez sinta uma coceirinha de vontade de jogar uns termos técnicos na conversa…talvez você devesse ignorar essa necessidade.

Na verdade, você só vai aparecer alguém que não tem empatia com o seu ouvinte.

Eventualmente, seu colega pode começar a evitar falar com você pelo fato de não te entender. Essa doeu.

Imagine que você não sabe nada sobre cozinhar (exemplos meramente ilustrativos, ok?). Então você decide pedir uma receita a uma chef de cozinha, e ela te ajuda, mas falando de vários utensílios que você nem conhece, técnicas que você nunca ouviu falar, usando nomes franceses que você não tem ideia nenhuma se são comida ou um xingamento. Você gostaria de ser ajudado assim? Não seria melhor, se a chef te explicasse de uma maneira mais simples? Você só queria jantar, sabe…

“Por que voce não me explica como se eu tivesse 5 anos?”

Então, quando você pensar em pegar o atalho cheio de termos complexos do seu trabalho, talvez dê passos mais simples. Descreva o que está acontecendo, explique o problema, use termos mais conhecidos, e mais importante – mostre exemplos.

Uma vez que você lembrar dessas “regras”, a sua comunicação deve fluir mais naturalmente, e as pessoas vão querer falar com você pois afinal agora eles te entendem!

Onde isto pode ser aplicado?

Todos os lugares e momentos. Reuniões em pessoa e online, posts de blogs, eventos. Não há limites.

Use uns momentos a mais pra realmente explicar os processos. Sempre de o contexto por trás do que você está falando e será mais fácil te entenderem. Não se apegue aos termos. Às vezes você pode até estar repetindo coisas sem perceber, por que você não está prestando atenção na sua fala.

Por exemplo, digamos que você está com pouco espaço no seu servidor, devido ao crescente tamanho dos seus arquivos de backup. Então, você precisa falar com um gerente para discutir opções, que podem incluir decisões que envolvem o orçamento.

Comece explicando o contexto. Fale sobre o que são os backups. Explique por que você precisa deles. E finalmente, ganhe seu gerente com um belo susto mostrando o problemão que você tem se perder os arquivos por uma semana. Mostre um screenshot de quanto espaço você tem vs o quanto está livre. Leve a informação de frequência com qual as pastas são “limpas”, e quanto tempo é gasto nisso. Uma vez que você tenha estabelecido esse terreno, eles vão entender o quão relevante isso é pra você, e por que você precisa do DINHEIRO suporte.

Isso é o que funciona pra mim. Pensando em uma forma um pouco diferente de se comunicar, eu AMO quando alguém tem um problema, e me mandam um email com toda a informação de antemão. Um email lindo desses geralmente possui o seguinte:

o que aconteceu
quando aconteceu
qual a suspeita de problema
o que acontece se isso não for consertado em x horas/dias/semanas
quem foi impactado
e se eles forem um anjo divino eles ate incluem uma sugestão de como resolver o problema (mais comum sendo um outro time de TI)
eles evitam usar termos muito específicos e descrevem mais
eles evitam usar termos internos que não fazem sentido para outros times

Isso tudo facilita a vida. Eu não preciso ficar escrevendo vários emails, por que logo de uma vez eu tenho o mínimo pra poder começar investigar. Honestamente, sendo proativa no email, a pessoa nos salvou um tempinho e espaço na inbox. Não há nada mais frustrante que tentar pescar informações e a pessoa fugir das perguntas respondendo o mínimo do mínimo.

Existem várias outras coisas que eu gostaria de falar sobre esse tópico, então provavelmente ele voltará. Enquanto isso, o que você faz pra se comunicar com leigos que deixa sua vida mais fácil? Comenta aí embaixo!

Quer praticar seu inglês? Leia o post em inglês aqui.

Práticas para comentários e nomes de arquivos SQL

Conhece o sentimento de abrir um novo arquivo, e pensar “eu não vou reutilizar esse código… só vou fazer isso uma vez…”. Nós dois sabemos que você está mentindo.

Eu estou falando isso pois, na maior parte do tempo:

seu código é reutilizável
você é humano e esquece as coisas. Então, talvez amanhã você já tenha esquecido como resolver uma coisa que você fez hoje.
eu nunca vi onde você salva seus scripts mas eu aposto que você poderia fazer uma boa limpeza na sua pasta

Quando você está trabalhando em algo, tente se imaginar no futuro. O seu “eu” mais velho provavelmente não tem ideia do que seja o *projeto_importante_2018_script*. O seu eu mais experiente está feliz lendo este arquivo? Eu acho que não.

Se você fizer um esforço agora para ser mais “arrumadinho” com o seu código, essas pessoas vão ficar muito felizes:

o seu eu futuro
seus colegas de trabalho que leem seus códigos
pessoas que vão assumir seu lugar no futuro, e vão pensar “olha só! essa pessoa não era tão péssima, era apenas ruim mesmo!”

Como adicionar comentários em SQL

Basicamente, existem duas maneiras de adicionar comentários em SQL:

1- adicione “–” e comece a digitar!

2- adicione “/**/” e escreva entre os asteriscos.

Nenhum é melhor que o outro. A primeira opção é mais usada para comentários na mesma linha do código. A segunda, é mais comum para comentar blocos de código, ou escrever comentários maiores que não vão ficar em uma linha gigante.

Comentários iniciais

Pessoalmente, eu acredito que comentários são algo bom. não é algo que eu faça em cada linha do código, porem, quando eu abro uma nova query, automaticamente eu adiciono um cabeçalho de comentários.

Eu começo meus scripts da seguinte forma:

Autor: quem está escrevendo o script.

Data: quando o script foi criado, para edições eu geralmente adiciono um edit na mesma linha.

Projeto: qual projeto o script faz parte. É legal descrever um pouco o projeto.

Descrição: descrever a razão do seu script, aqui é onde você explica onde está parte se encaixa no todo.

Requisitado por: nome de quem pediu que isso fosse desenvolvido. Além dos nomes, talvez seja interessante adicionar também os emails para contato.

Importante: se você está escrevendo uma stored procedure, lembre-se de adicionar o seu bloco de comentários depois do comando “CREATE PROCEDURE”. Fazendo isso, o seu comentário vai estar integrado ao código da proc, e vai aparecer inclusive quando você escolher a opção de “modificar” o arquivo. Se você não fizer assim, o comentário vai ficar salvo apenas no próprio arquivo principal do script.

Dando um nome ao arquivo

Tente ser descritivo e intuitivo quando for nomear seu arquivo, e não abrevie muito. O nome que você escolheu pode parecer relevante na hora, mas de novo, pergunte-se se o seu eu do futuro está te odiando agora.

Se o seu script fizer parte de um projeto maior, então tente começar o nome do arquivo como algo que remeta ao projeto.

Por exemplo: sp_RelatorioFinancasAutomatico_CalculoSalarioFuncionario

Com esse nome, sabemos:

sp: isso é uma stored procedure
RelatorioFinancasAutomatico: nome descritivo do projeto
CalculoSalarioFuncionario: o que a sua parte especifica do script faz

Evite usar termos como “novo”, “velho”, “final”, dentre outros. Isso não é útil em longo prazo. Se você está criando vários rascunhos, por exemplo, seria interessante versionar, usando “v1”, “v2”, ou até adicionar a data no nome do arquivo. Mas, lembre-se que esses nomes deveriam ser temporários, e assim que você descobrir qual finalmente é sua versão “v23_final_novo”, mude esse nome. Outra coisa que você pode fazer é mover seus rascunhos para uma sub-pasta dentro do projeto, assim fica mais fácil de organizar os scripts “finais” e importantes.

Essas são coisas básicas que eu faço todos os dias. Espero que você tenha achado útil. Existe outra coisa que você adiciona que gostaria de compartilhar? Deixe seu comentário (:

Quer ler este post em Inglês? Clique aqui.

Até mais!

Commenting and Naming practices with T-SQL scripts

Do you know that feeling when you’re starting another query and this time you’re thinking “I won’t re-use this… this is a one-time thing…”. We both know you’re lying.

I said that because most of the time:

you’re code is reusable
you’re human and you forget stuff, so perhaps tomorrow you forgot something you realized how to do today
I’ve never seen where you keep your scripts but I bet that needs a clean up

When you’re working on something, try to picture your future self. Your older self has probably no clue about what this *really_important_2018_script* project was. Is your older/wiser version happy while reading that? I don’t think so.

If you make an effort now to be more “tidy” with your code, here’s who will be happy:

your future self
your colleagues who read your code
people who will take your job in the future and think “hey! this person don’t suck as much as I thought… just a little!”

How to add comments in SQL

Basically, there are two ways to add comments in SQL:

1- add “–” and start typing!

2- add “/**/” and write in between the stars.

No one is better than the other. The first option is usually for in-line smaller comment. The second it’s more for commenting out blocks of code or writing bigger comments in a way they will not be on one same line.

Initial comments

Personally, I believe comments are a good thing. It’s not something I do with every line, however, when I open a new query, I automatically add my comments.

Here’s how I like to start my scripts:

Important note: if you’re writing a stored procedure, remember to add this block of comments after your “CREATE PROCEDURE” statement. When you do so, the comment will show up when you right-click on the stored procedure and chose “Modify”. Otherwise it’s gone and saved only on your main script file.

Naming your file

Try to be descriptive when naming your file, and don’t abbreviate too much. The name you chose may seem relevant now, but again, ask yourself “is my future version hating me now?”. If the answer is yes, than chose something else.

If the script you are creating is part of a bigger project that involves other scripts, then try to start every file name with something that refers to the project itself.

For example: sp_AutomatedFinancialReports_CalculatingEmployeeSalary

Here’s what we know based on the file name:

sp: this is a stored procedure
AutomatedFinancialReports: project name that’s descriptive
CalculatingEmployeeSalary: this is what your specific script will do as part of the project

Avoid at all costs using “new”, “old”, “final” and relative names on your file. This is not useful long-term. If you’re creating many drafts, I’d go with versions like “v1”, “v2”, or just add the plain date to your file name. But remember this is a temporary name, and that once you figure your “v23_final_new” file, you’ll change the name accordingly. Another trick is to move your thousand drafts to a, guess what, drafts folder. The idea is that your main project folder keeps your already tested and ready to go script.

This is some basic stuff I do everyday and I hope you find it useful. Do you add something else that you’d like to share? Leave a comment (:

Want to read this post in Portuguese? Check out this link.

See you later!

Sobre mim

Como meu primeiro post oficial neste site, eu gostaria de fazer uma introdução minha, e compartilhar sobre o que eu gostaria de falar sobre, assim como meus objetivos escrevendo o blog.

Meu nome é Camila Henrique. Eu sou de Indaiatuba, uma cidade pequena de São Paulo, Brasil. Eu moro em Montreal, no Canadá, enquanto escrevo este post em Janeiro de 2021. Eu trabalho com Microsoft SQL Server desde 2015. Hoje, atuo como DBA/SQL Developer em uma agência. Por último e não menos importante, eu falo Portugues, Inglês e Francês, e adoro aprender línguas novas.

Sobre o que eu vou falar?

Eu sempre fui alguém que gosta muito de ter um mentor. Seja nos estudos ou no trabalho. Eu apenas acho que a vida fica mais fácil quando eu tenho alguém que pode me ajudar a tomar melhores decisões. Porém, eu também entendo que seja difícil encontrar um bom “mentor” para quem está começando. De jeito nenhum eu pretendo substituir esta pessoa na sua vida, mas eu gostaria de ajudar. Por isso, para você, meus queridos iniciantes em TI – eu vou falar sobre os primeiros passos que você pode tomar na sua carreira.

Se você tem interesse em SQL, está se perguntando sobre passos iniciais, ou pesquisando sobre coisas específicas dessa área de dados, eu irei postar dicas práticas que vão te ajudar na vida real.

Eu acredito que nós, humanos da área de tecnologia, frequentemente negligenciamos o poder de saber se comunicar bem com outros humanos. Não importa o que você faça, tenho certeza que seu trabalho em algum momento envolve falar com outras pessoas. E todos sabemos que nós, de TI, não somos conhecidos por desempenhar um bom papel nesse ramo da comunicação. Então, eu quero compartilhar coisas que eu aprendi sobre comunicação.

Se você, assim como eu, é alguém que fala portugues como primeira língua, eu gostaria de te ajudar nessa jornada bilíngue. Vou fazer isso postando tanto em Inglês quanto portugues, para que você possa escolher a língua e praticar como quiser. Eu adoraria fazer parte da comunidade do nosso país, assim como também não quero deixar de aproveitar a oportunidade de atingir mais pessoas com o conteúdo em inglês.

Eu também adoro falar de tópicos que envolvem diversidade no trabalho. Acredito que no nosso ramo não temos muito conteúdo. Então, esse vai ser um tópico que vai aparecer por aqui também.

Por que eu sei que gostamos de descobrir algo mais “pessoal” sobre os outros: eu gosto de yoga, amo desenhar e definitivamente eu compro mais livros do que leio, mas não recomendo que façam isso (tambem nao posso te julgar, se fizer, bem vindo ao clube!).

Eu espero passar um ótimo tempo juntos. Se você me seguir, me conta um pouco sobre você nos comentários, eu adoraria fazer mais amigos online.

Até mais!

Quer ler este post em inglês? Clique aqui.

Get to know me

Hello!

As my first official post on this site, I’d like to introduce myself, share what I’d like to talk about as well as my writing goals.

My name is Camila Henrique. I’m from Indaiatuba, a small city in São Paulo, Brazil. I am living in Montreal, Canada, as I’m writing this in January 2021. I’ve worked with Microsoft SQL Server since 2015. Today I’m a DBA/SQL Dev in a medium size agency. Last but not least, I speak Portuguese, English and French, and I love learning new languages.

What will I talk about?

I’ve always been someone who really appreciates having a mentor. Be that at school or work. I just find it better when someone can guide me towards good decisions. However, I also know how hard it is for people who are just beginning their professional life, to find a good mentor. I’m not by any means trying to replace that person in your life right now, but I’d like to help. So, for you, my dear beginner IT person – I will talk about first steps you can to take in your career.

If you’re into SQL, wondering about first steps, or searching about specific data things, I’ll post beginner tips and tricks that you can practice in real life.

I believe we, information technology humans, often misjudge the importance of knowing how to properly communicate with other humans. No matter what you do, I’m sure your work involves talking to other people, and well, we’re not really known for that. That’s why I want to share things I’ve learned about communication.

If you’re someone who natively speaks Portuguese, like me, I’d like to assist on your bilingual journey by posting in both Portuguese and English, so you can chose and practice as you’d like. I’d love to be part of my country’s community, as well as reaching more people with my English content.

I’m also passionate about topics that involve diversity at work, and sometimes I find it hard to talk about that in the tech field. That’s why this will be one of the topics I’ll present here.

And because I know people like “personal” stuff: I’m into yoga, I love drawing and I definitely buy more books than I read and do not recommend that (but won’t judge you either, welcome to the club!).

I hope we get to spend some wonderful time together. If you follow me, let me know about you in the comments, I’d love to make more internet friends.

See you!