Tópico da Programação

[Plagio o Original]

Aprender VIM não custa nada, na verdade é divertido. É como aprender um instrumento de música: a gente começa sem saber nada, mas vai ganhando tecnicas ao longo do tempo. Só que não é tão sexy como aprender um instrumento

Ok, temos os vim bindings que permitem, sei lá, eliminar tudo o que têm dentro de um if ou numa função, se forem com o cursor do vim até a uma linha qualquer da função, dentro dos {}, e meterem no teclado `di{` (delete inside {), o vim vai apagar tudo o que está dentro dos parentises retos

aprender estas coisas é divertido.

Depois têm coisas que a minha mente explodiu quando eu aprendi. Por exemplo, correr bash dentro do vosso IDE.

ok, imaginem que têm uma lista, no meu caso costuma ser um Dockerfile.dockerignore, em que metemos pra lá dependencias, imaginem uma coisa assim:

!/path/to/lib/b
!/path/to/lib/a
!/path/to/lib/c

Tinha uma colega que mandava vir se esta lista estava desorganizada. Vocês sabem, aquela code review que não serve pra nada mas vocês fazem só pra achincalhar ou fazer perder o tempo da outra pessoa. Ordenar esta lista pra mim é 1 segundo. Vocês vão com o cursor para qualquer linha desta lista, e correm: !ip (bash inside paragraph) e depois escrevem: sort (o comando unix para ordenar uma lista qualquer por ordem alfabética), e o VIM apaga a lista antiga e mete isto:

!/path/to/lib/a
!/path/to/lib/b
!/path/to/lib/c

isto é tudo muito divertido de aprender, juro

 

Editado 14 Março 2025 por Plagio o Original

[Sandes.]

Citação de Plagio o Original, há 29 minutos:

Aprender VIM não custa nada, na verdade é divertido. É como aprender um instrumento de música: a gente começa sem saber nada, mas vai ganhando tecnicas ao longo do tempo. Só que não é tão sexy como aprender um instrumento

Ok, temos os vim bindings que permitem, sei lá, eliminar tudo o que têm dentro de um if ou numa função, se forem com o cursor do vim até a uma linha qualquer da função, dentro dos {}, e meterem no teclado `di{` (delete inside {), o vim vai apagar tudo o que está dentro dos parentises retos

aprender estas coisas é divertido.

Depois têm coisas que a minha mente explodiu quando eu aprendi. Por exemplo, correr bash dentro do vosso IDE.

ok, imaginem que têm uma lista, no meu caso costuma ser um Dockerfile.dockerignore, em que metemos pra lá dependencias, imaginem uma coisa assim:

!/path/to/lib/b
!/path/to/lib/a
!/path/to/lib/c

Tinha uma colega que mandava vir se esta lista estava desorganizada. Vocês sabem, aquela code review que não serve pra nada mas vocês fazem só pra achincalhar ou fazer perder o tempo da outra pessoa. Ordenar esta lista pra mim é 1 segundo. Vocês vão com o cursor para qualquer linha desta lista, e correm: !ip (bash inside paragraph) e depois escrevem: sort (o comando unix para ordenar uma lista qualquer por ordem alfabética), e o VIM apaga a lista antiga e mete isto:

!/path/to/lib/a
!/path/to/lib/b
!/path/to/lib/c

isto é tudo muito divertido de aprender, juro

 

Obrigado pela partilha vou ler mais logo

[Solero]

Não há nada como uma boa commit history, linear e sem merge commits. Uso bastante o interactive rebase no VSCode para editar os commits e recomendo vivamente.

[Plagio o Original]

Citação de Solero, há 1 minuto:

Não há nada como uma boa commit history, linear e sem merge commits. Uso bastante o interactive rebase no VSCode para editar os commits e recomendo vivamente.

interactive rebase tbm é fixe, tbm podes fazer na linha de comandos, só que o gajo vai te abrir o vim pra editares as commits, se quiseres fazer squash / fixup / rename, etc

[Solero]

Uso a CLI mas com essa cena, assim que corro algo tipo:

git rebase -i origin/master

Abre-se uma tab no VSCode com isto:

pick d1daa86 add foo
pick 661975e add bar
pick 6a42b1f bump version 


# Rebase e647a52..e647a52 onto e647a52 (1 command)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup [-C | -c] <commit> = like "squash" but keep only the previous
#                    commit's log message, unless -C is used, in which case
#                    keep only this commit's message; -c is same as -C but
#                    opens the editor
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
#         create a merge commit using the original merge commit's
#         message (or the oneline, if no original merge commit was
#         specified); use -c <commit> to reword the commit message
# u, update-ref <ref> = track a placeholder for the <ref> to be updated
#                       to this position in the new commits. The <ref> is
#                       updated at the end of the rebase
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#

Depois é ir fazendo os ajustes com os comandos para reword, squash, edit, etc a cada commit.

git rebase --continue até ficar tudo direitinho.

Editado 14 Março 2025 por Solero

[Plagio o Original]

Citação de Solero, há 2 minutos:

Uso a CLI mas com essa cena, assim que corro algo tipo:

git rebase -i origin/master

Abre-se uma tab no VSCode com isto:

pick d1daa86 add foo
pick 661975e add bar
pick 6a42b1f bump version 


# Rebase e647a52..e647a52 onto e647a52 (1 command)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup [-C | -c] <commit> = like "squash" but keep only the previous
#                    commit's log message, unless -C is used, in which case
#                    keep only this commit's message; -c is same as -C but
#                    opens the editor
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
#         create a merge commit using the original merge commit's
#         message (or the oneline, if no original merge commit was
#         specified); use -c <commit> to reword the commit message
# u, update-ref <ref> = track a placeholder for the <ref> to be updated
#                       to this position in the new commits. The <ref> is
#                       updated at the end of the rebase
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#

Depois é ir fazendo os ajustes com os comandos para reword, squash, edit, etc a cada commit.

git rebase --continue até ficar tudo direitinho.

então vais ao terminal e o gajo abre-te isto no vs code? meu deus

[Solero]

https://blog.delpuppo.net/why-i-love-gitlens-in-my-vscode-interactive-rebase

Citação de Plagio o Original, há 8 minutos:

interactive rebase tbm é fixe, tbm podes fazer na linha de comandos, só que o gajo vai te abrir o vim pra editares as commits, se quiseres fazer squash / fixup / rename, etc

Sim, eu apenas uso diretamente no VScode porque assim faço tudo aqui, sei mexer com VIM mas nao para desenvolver, tipicamente apenas para cenas tipo debugging em logs e preciso de encontrar padroes ou editar ficheiros diretamente, etc. Um dia destes talvez me meta a experimentar mas o VSCode é perfeito para o que eu preciso de fazer, por isso nunca houve uma necessidade de brincar com neovims e afins

Editado 14 Março 2025 por Solero

[Plagio o Original]

Estou com vontade de continuar o meu rant sobre o VIM, vocês pediram e eu estou com tempo hoje à sexta feira

imaginem que vocês querem programar em Go no vscode, que é a linguagem que eu estou a programar agora. Vocês sabem o que o vscode ou o intellij faz quando vocês querem instalar a extensão que vos dá suporte à linguagem? são os LSP (language server protocols), que sabem como interpretar o vosso código de acordo com as linguagens.

vocês obviamente podem por isso no VIM. Sabem qual é a vantagem? Vocês acham que eu faço right click no VIM, procuro a lista interminável de opções, para ver onde é usada a minha função, ou pra ver quais as implementações de uma interface? Não, faço gd (go to definition) ou gi (go to implementation), e o VIM mete-me numa lista tudo o que quero saber, e posso navegar no código super rápido

e tem uma vantagem: o vim não faz as 500 porcarias que o intellij faz, e por tanto é muito mais rápido.

O intellij dá-vos a opção de gerar unit tests para uma função. Vocês sabem que podem fazer a mesma coisa no VIM? Aquilo está a usar comandos já existentes, no golang  é o go-test, ou lá o que é. Criei um script para isso, faço ctrl+g g (um atalho que criei e internalizei na minha cabeça) e aquilo gera-me o unit test para a função.

como disse, estou a trabalhar à velocidade do pensamento. Eu penso no que preciso de fazer, executo o shortcut, tá feito. Não há aqui scroll, selecionar código com o shift + setas, nada disso. O objetivo é pensar no que querem fazer e executar imediatamente

podem mandar dinheiro pro IBAN por MP por esta lição, já que se vão fazer o mesmo que eu, posso passar a ter concorrencia de algum colega que esteja a ler isto que queira ser tão produtivo como eu

obrigado

[Jimpo]

pessoalmente uso rato e safo-me bem

[Solero]

Citação de Plagio o Original, há 1 hora:

Estou com vontade de continuar o meu rant sobre o VIM, vocês pediram e eu estou com tempo hoje à sexta feira

imaginem que vocês querem programar em Go no vscode, que é a linguagem que eu estou a programar agora. Vocês sabem o que o vscode ou o intellij faz quando vocês querem instalar a extensão que vos dá suporte à linguagem? são os LSP (language server protocols), que sabem como interpretar o vosso código de acordo com as linguagens.

vocês obviamente podem por isso no VIM. Sabem qual é a vantagem? Vocês acham que eu faço right click no VIM, procuro a lista interminável de opções, para ver onde é usada a minha função, ou pra ver quais as implementações de uma interface? Não, faço gd (go to definition) ou gi (go to implementation), e o VIM mete-me numa lista tudo o que quero saber, e posso navegar no código super rápido

e tem uma vantagem: o vim não faz as 500 porcarias que o intellij faz, e por tanto é muito mais rápido.

O intellij dá-vos a opção de gerar unit tests para uma função. Vocês sabem que podem fazer a mesma coisa no VIM? Aquilo está a usar comandos já existentes, no golang  é o go-test, ou lá o que é. Criei um script para isso, faço ctrl+g g (um atalho que criei e internalizei na minha cabeça) e aquilo gera-me o unit test para a função.

como disse, estou a trabalhar à velocidade do pensamento. Eu penso no que preciso de fazer, executo o shortcut, tá feito. Não há aqui scroll, selecionar código com o shift + setas, nada disso. O objetivo é pensar no que querem fazer e executar imediatamente

podem mandar dinheiro pro IBAN por MP por esta lição, já que se vão fazer o mesmo que eu, posso passar a ter concorrencia de algum colega que esteja a ler isto que queira ser tão produtivo como eu

obrigado

E o VIM tem integração com o GH Copilot? Se sim, manda o IBAN

[Plagio o Original]

Citação de Solero, há 2 minutos:

E o VIM tem integração com o GH Copilot? Se sim, manda o IBAN

Sei que tem, mas não uso

[HappyKing]

Acho que hoje em dia preferia dar um tiro na cabeça a programar só usando vim. 

Quero que se f*da se o IDE demora mais a abrir as coisas, não dispenso por nada.

E sobre essa questão da performance já vi muito programador que era muito rápido a fechar histórias e depois deixavam o código com mais buracos que um queijo suíço. A lógica do mais vale feito que perfeito é gira mas leva não raras vezes a percentagens de reworks absurdas. 

Editado 14 Março 2025 por HappyKing

[Bashir]

Citação de Jimpo, há 11 horas:

pessoalmente uso rato e safo-me bem

Rookie mistake. 10x engineers não usam o rato para programar.

Citação de HappyKing, há 2 horas:

Acho que hoje em dia preferia dar um tiro na cabeça a programar só usando vim. 

Quero que se f*da se o IDE demora mais a abrir as coisas, não dispenso por nada.

E sobre essa questão da performance já vi muito programador que era muito rápido a fechar histórias e depois deixavam o código com mais buracos que um queijo suíço. A lógica do mais vale feito que perfeito é gira mas leva não raras vezes a percentagens de reworks absurdas. 

Eu quando analiso/comparo performance incluo o tempo de rework que é gerado nas code reviews. Nós pelo menos não passamos nada que não seja aprovado por 2 outros developers. Há sempre aquele approve à confiança em algumas coisas, mas na lógica tentamos ser rigorosos. Até porque temos um monorepo de libs q é usado em N apps diferentes. Não é tão simples martelar ali à toa quando já sabemos que provavelmente só está a 'agradar' a uma das apps.

[Mica]

Citação de HappyKing, há 9 horas:

E sobre essa questão da performance já vi muito programador que era muito rápido a fechar histórias e depois deixavam o código com mais buracos que um queijo suíço. A lógica do mais vale feito que perfeito é gira mas leva não raras vezes a percentagens de reworks absurdas. 

Acho que estão aí dois problemas diferentes.

Falava-se em programadores rápidos porque conseguem fazer tudo com atalhos do teclado e efetivamente acaba por perder menos tempo. No final do dia não é muito importante.

O que referes está muitas vezes relacionado com pressões da gestão/scrum masters/etc de que temos de fechar x e y para ontem e por isso alguns dão primazia a fechar coisas do que a garantir que estão feitas em condições. Outras vezes está relacionado com a própria natureza do programador.

E claro que alguns desses podem ser os programadores "rápidos", mas é só uma coincidência.

Citação de Jimpo, há 18 horas:

pessoalmente uso rato e safo-me bem

Eu ainda hoje sou miserável com o rato e não é só a trabalhar, já perdi no CS contra um gajo de touchpad, para se perceber bem a dimensão.

[HappyKing]

Citação de Bashir, há 14 horas:

Eu quando analiso/comparo performance incluo o tempo de rework que é gerado nas code reviews. Nós pelo menos não passamos nada que não seja aprovado por 2 outros developers. Há sempre aquele approve à confiança em algumas coisas, mas na lógica tentamos ser rigorosos. Até porque temos um monorepo de libs q é usado em N apps diferentes. Não é tão simples martelar ali à toa quando já sabemos que provavelmente só está a 'agradar' a uma das apps.

E fazem bem. O meu comentário foi baseado no comentário do Plágio porque já vi muito aquela teoria dos story points entregues no fim do sprint como avaliador absoluto e depois perdiam-se outros tantos story points a corrigir passado algum tempo. 

[Sandes.]

Eu ia dizer que até empatizava um pouco com o Plágio porque a minha situação é semelhante: andei 2 anos e meio a render o máximo possível a minha empresas, feedback dos clientes ao ponto de dizer que eu era a pessoa mais importante num projecto que rendeu 5x mais do que era o objectivo e etc, e quando chega o ciclo promocional fico a ver navios. Disse que fiquei muito desiludido, o meu manager até disse que foi um erro da parte dele e que julgou mal e tal...mas nada mudou, continuei a ver navios, nem um aumento tive. O que não empatizo é mesmo andar a falar mal ao pessoal, isso é mais um ponto para o meu post umas páginas atrás: deus me livre de trabalhar com alguém como tu, fds.

No meu caso pus-me logo a procurar saídas, uma delas até falei aqui que era ser contractor (não se materializou porque a empresa em questão decidiu congelar novos contractos com externos), e agora estou muito bem encaminhado para uma oportunidade em que vou provavelmente ganhar o dobro do que ganho a fazer o que andei a fazer nesse projeto. Opah se há coisa que aprendi com esta falta de reconhecimento é que é preciso ser um bocado mercenário, a maioria das empresas está-se a cagar para o que tu queres. Se morreres hoje amanhã abrem a vaga

[Solero]

@Plagio o Original eu só quero saber se és daqueles que tem um boneco de anime como avatar no Slack

De resto, aposto que não te sabes vender tão bem aí na empresa como no cmpt

[Mica]

Citação de HappyKing, há 15 horas:

Certo, eu referia-me ao teu comentário, não ao teu trabalho em especifico. Tenho só alergia à questão da medição de story points. 

Os story points deviam servir para medir o quanto sabes sobre aquilo que vais ter de fazer, e não o tempo que vai levar. E concordo com o que disseste no outro post, podes fazer muita coisa que não vai estar a ser monitorizada num ticket/story, como mentoria, por exemplo. Eu faço mentoria a novos membros e por isso raramente acabo as sprints com mais story points, mas o meu chefe sabe disso, não só porque comunico-lhe mas também porque ele é muito bom e tem noção.

Acredito que medir a quantidade de trabalho por story points possa fazer sentido para contractors, visto que deles é esperado que façam trabalho x ou y e nada mais.

Citação de Sandes., há 11 horas:

(...)

No meu caso pus-me logo a procurar saídas, uma delas até falei aqui que era ser contractor (não se materializou porque a empresa em questão decidiu congelar novos contractos com externos), e agora estou muito bem encaminhado para uma oportunidade em que vou provavelmente ganhar o dobro do que ganho a fazer o que andei a fazer nesse projeto. Opah se há coisa que aprendi com esta falta de reconhecimento é que é preciso ser um bocado mercenário, a maioria das empresas está-se a cagar para o que tu queres. Se morreres hoje amanhã abrem a vaga

Verdade, e não te sintas mal por causa disso. Eu sempre que senti um pingo de estagnação mandei CVs e eventualmente, com mais ou menos esforço, consegui o que queria. Todas as promoções que tive até hoje foram conseguidas a apresentar uma carta de despedida na empresa x e a assinar contrato na empresa y.

Para além disso, nenhuma empresa vai colocar uma estátua tua em frente à porta principal, por muitos anos que fiques lá por amor à camisola. No final da tua carreira profissional será muito mais interessante contares o que aconteceu nas 7 ou 8 empresas onde estiveste do que nos 25 anos de dedicação à mesma empresa.

E existem empresas que valorizam o funcionário e tem um programa de promoções em condições, são é raras.

Editado 16 Março 2025 por Mica

[Petar Musa]

Os story points não fazem sentido nenhum como são feitos e só servem para dar emprego a uns tontinhos.

Não sei se foi o Happy ou o Plágio, mas concordo com um deles quando diz que lá não conta o tempo que se vai perder a fazer debugging e a corrigir esses bugs.

E waterfall ❤️

[Solero]

Citação de Plagio o Original, há 10 horas:

 

Eu não sei se sou a melhor pessoa para dar conselhos sobre isto tbh, porque eu próprio também sofro um pouco do mesmo mal, mas acho que no fundo tem a ver com dar a devida visibilidade ao teu trabalho. E essa do trabalho falar por nós implica que alguém esteja a ouvir. O pessoal tem mais do que fazer diariamente do que estar a pensar no que o Plagio fez neste quarter e como merece uma promoção ou um aumento. Ter um chefe que saiba puxar te para cima e que tenha voz na empresa também ajuda, claro.

Há pessoal que é tão bom nisto que ser competente passa a ser opcional - assim que lhe bate à porta uma posição de manager então, fica escudado no trabalho de outros e está mais ou menos lançado, só tem que espalhar o charme e a small talk nas reuniões de status e boa.

Bem vindo à corporate ladder. Enquanto developer, a minha opinião é a de que, mesmo com um mercado de trabalho menos pujante que há uns anos, jogar esse jogo nem sempre compensa porque à partida estão dispostos a pagar mais por ti noutro lado.

Alguns exemplos que acho que podem ajudar incluem ter uma bragging list onde apontas os teus feitos ao longo do tempo para falares nas avaliações, evitar discutir temas que interessam a várias pessoas em DMs (quanto mais público melhor) pois passas a ser visto, se achares que faz sentido começa a fazer Tech Talks onde abordas um tema e fazes uma apresentação/demo sobre isso, etc.

Editado 17 Março 2025 por Solero

[Sandes.]

Citação de Solero, há 3 minutos:

Eu não sei se sou a melhor pessoa para dar conselhos sobre isto tbh, porque eu próprio também sofro um pouco do mesmo mal, mas acho que no fundo tem a ver com dar a devida visibilidade ao teu trabalho. E essa do trabalho falar por nós implica que alguém esteja a ouvir. O pessoal tem mais do que fazer diariamente do que estar a pensar no que o Plagio fez neste quarter e como merece uma promoção ou um aumento. Ter um chefe que saiba puxar te para cima e que tenha voz na empresa também ajuda, claro.

Há pessoal que é tão bom nisto que ser competente passa a ser opcional - assim que lhe bate à porta uma posição de manager então, fica escudado no trabalho de outros e está mais ou menos lançado, só tem que espalhar o charme e a small talk nas reuniões de status e boa.

Bem vindo à corporate ladder. Enquanto developer, a minha opinião é a de que, mesmo com um mercado de trabalho menos pujante que há uns anos, jogar esse jogo nem sempre compensa porque à partida estão dispostos a pagar mais por ti noutro lado.

Esse foi o meu problema estes anos. Tenho pena porque o meu chefe/line manager é um gajo porreiro, mas não é bom nessas cenas.

Sinto que a única forma de realmente ter esse crescimento/venda pessoal sem ter um chefe que o faça por ti é

1. Ser muito claro com o teu chefe daquilo que queres. Por exemplo, @Plagio o Original tu pediste uma promoção ou estavas à espera que te fosse dada no ciclo habitual? Eu insiro-me na segunda opção, acho que devia ter sido mais claro com o meu chefe que queria e merecia a promoção.

2. Publicitar trabalho feito, seja com posts da piç* no slack, seja por tentar organizar demos para pessoal fora da equipa, wtv. O pessoal que mais fala na minha empresa nessas m*rda acaba sempre por ter mais exposure e assumo que o pessoal acima vê isso e puxe os seus managers a ver promoções ou a meter em projectos interessantes ou assim.

[Mica]

Quanto a vocês não sei, mas eu criei OKRs mal terminou o ciclo promocional de 2024 e entreguei ao meu chefe, agora fazemos reuniões mensais para ver como estão a correr e se está tudo bem encaminhado para poder atingir a promoção. Eu não teria este tipo de discussões a meses de começar o ciclo promocional, porque isso deixar-me-ia numa posição frágil. Como deveria justificar que aquilo que fiz era para uma posição acima da minha? Daí os OKRs darem jeito, podem meter alguns objetivos que só são esperados de alguém uma posição acima (p.e. principal vs senior, ou senior vs mid-level).

Se no fim do dia não houver promoção nenhuma, há todo um mercado de trabalho desejoso por vos contratar, sobretudo com competências para uma posição acima.

[Jimpo]

ja pensaste em usar o rato? se calhar o problema esta ai.

[Petar Musa]

Citação de Sandes., há 49 minutos:

2. Publicitar trabalho feito, seja com posts da piç* no slack, seja por tentar organizar demos para pessoal fora da equipa, wtv. O pessoal que mais fala na minha empresa nessas m*rda acaba sempre por ter mais exposure e assumo que o pessoal acima vê isso e puxe os seus managers a ver promoções ou a meter em projectos interessantes ou assim.

Isto é ouro. As pessoas têm que saber que existes se queres subir na hierarquia.

Um dos meus objetivos para este ano é fazer 3 apresentações: 1 para europa, 1 para a Ásia e outra para as Américas. Tenho 0 jeito para isso, mas sei que para chegar onde quero tenho que fazer estas coisas.

E sempre que vou aos esritócrios da Europa dar um passou-bem aos managers e mostrar o que valho quando há oportunidade.

Ou isso, ou fico o resto da vida a chorar na base da pirâmide.

[Mica]

Eu também invento, desde fazer uma demo para o departamento de tecnologia inteiro sem ninguém me pedir, ser orador numa conferência de forma voluntária, a tirar uma certificação de segurança (CISSP) sem me ter sido exigida. Não faço isso para agradar ninguém mas sim porque são cenas que me podem ajudar a conseguir a promoção aqui...ou a ganhar mais noutro lado. Eu só não quero é ter de trabalhar até aos 67, e é quase um crime nesta área não tirar proveito disso, quando tanta boa gente gostava de conseguir e não pode.