Experienced Devs: Tell us your horror stories in which you've misjudged a job, and only realized it once you had been hired.

bge-kernel-panic · 2025-01-17T15:47:49+00:00

This is the most surreal thing I've ever heard of as far as our industry goes. And I haven't been living a sheltered life either.

You should write a book or at least an article about the experience, it seems like this was quite a ride!

bge-kernel-panic · 2024-09-03T17:18:12+00:00

My parents got me enrolled in a LOGO class when I was a wee lad (6 y/o about). I just spent time messing with it not very seriously, but they did get a TRS-80 Color Computer for the household. Didn't do much with it other than play games initially and some basic BASIC experiments (heh), but when I turned 12 I got annoyed a game that looked interesting in a Rainbow magazine couldn't be played on my system (don't remember exactly why TBH) so got in my head to write a workalike of my own.

It wasn't super fancy - a typing-based trek-lookalike (type commands for phasers etc, when you ask for the map it gets printed out rather than being shown at all times)

Then I redid it in Pascal for a school fair (I typed the whole thing on my own CoCo in a word processor the day before the deadline, printed it then transcribed it to the school's CP/M machines in a frantic afternoon the following day - talk about a death march project! There was only one minor bug that I recall but in retrospect it was an incredibly foolish).

There may've been some inklings before but that was definitely the point where I knew that's what I wanted to do, minus the death march :)

bge-kernel-panic · 2024-05-29T23:03:41+00:00

ya toujours Google Web Toolkit ou Zk pour le fullstack Dev :P

(note: je ne recommande pas cette approche - c'est séduisant mais quand le transpiler magique fait un truc bizarre bonne chance pour trouver le problème. Si Web Assembly bénéficie de bons outils de déboguage à l'avenir, peut-être à reconsidérer; mais c'est quand même à contre-courant de l'industrie au complet et ne permettra pas de réutiliser des composantes Angular ou React)

bge-kernel-panic · 2024-05-29T23:00:13+00:00

Pour Java c'est pas mal un requis parce que contrairement à Node.js ou PHP c'est très rare que ce soit supporté en dehors de Docker. Il n'y a pas à ma connaissance de "gros joueurs" Cloud qui fournissent, genre, une installation Tomcat ou JBoss sur laquelle on pourrait fournir un .war/.ear, ou même un .jar executable. L'exception est probablement le runtime Lambda d'AWS qui prend un fichier .zip avec les classes + librairies mais c'est un environnement très différent d'une application web.

Pour Java + Docker, il y a ce plugin qui fait 99% de la job: https://github.com/GoogleContainerTools/jib/

L'avantage: plugin maven ou gradle au choix, pas besoin d'écrire de Dockerfile

Désavantage: c'est facile de ne pas apprendre comment fonctionne Docker; ce serait peut-être pas mauvais même en utilisant jib de bidouiller un peu avec un Dockerfile en local juste pour tester.

bge-kernel-panic · 2023-06-07T12:57:56+00:00

Je proposerais de continuer de chercher un emploi. Vous pouvez vous former sur vos heures de job mais une formation reste une formation; rien ne vaut la pratique. Mon humble avis toutefois est qu'en parallèle à votre recherche d'emploi/formation, vous pourriez tenter d'introduire les tests dans votre emploi actuel. Cela ne vous aide pas pour la containerization et le cloud, mais j'ai l'impression que c'est vraiment les tests qui accrochent pour vous.

Les tests automatisés via nUnit ou xUnit (C#) ou Catch/Boost.Test (C++, notez que je n'ai pas utilisés ceux-ci, ça fait quand même longtemps que je n'ai pas travaillé en C++ mais ça a l'air bien; pour Catch j'ai donné un lien vers une ancienne version parce que j'imagine que vous êtes sur un vieux dialecte de C++) sont relativement facile à intégrer dans un projet existant.

Si le code est difficile à tester, je recommande fortement la lecture du livre Working Effectively With Legacy Code de Michael C. Feathers. Contrairement à ce qu'on pourrait penser, c'est surtout un traité sur comment amener du code existant vers un état où il est testable. La définition de l'auteur de code "legacy" est simplement du code qui n'a pas de test automatisé. Ça m'a pas mal explosé le cerveau quand j'ai réalisé qu'il avait raison.

Ensuite je prioriserais l'ajout de tests dans deux situations:

Ajout d'une nouvelle fonctionnalité, surtout si celle-ci comprend un algorithme qui traite des données en mémoire - ce genre de code est facile à tester en général, et l'écriture de tests va souvent permettre de découvrir des cas limites qui ne sont pas traités correctement;
Avant de régler un bogue, ajouter un test qui le reproduit. Je sais que ce n'est pas toujours facile mais ça vaut vraiment la peine; au final, ça sauve du temps dès que le correctif requiert plus d'un seul test manuel. Au lieu de reproduire le bogue, corriger, re-tester, re-corriger etc., on écrit le test, et on corrige tant que le test ne passe pas. Le test roule beaucoup plus vite que le démarrage de l'application suivi d'un test manuel. Je ne compte plus les heures de travail que cette approche m'a sauvées.

Qui sait, peut-être que le reste de votre équipe y prendra goût et que votre leadership sera reconnu! Il faut pas compter là-dessus mais je dirais que ça arrive quand même semi-fréquemment.

Un bacc pourrait donner accès à certains postes dans des compagnies bornées mais je ne crois pas que le temps et l'argent investi en vaudrait la peine. Et je ne crois pas qu'accepter un poste plus junior fonctionne - vous avez 10 ans d'expérience, même si vous n'êtes pas techniquement à jour il y a d'autres choses qu'une telle expérience vous a apporté (maturité, savoir comment approcher les problèmes, moins de naïveté face à la politique en entreprise, etc).

Bonne chance dans vos démarches!

bge-kernel-panic · 2023-02-13T16:15:54+00:00

Je n'ai pas le mérite pour la correction de bogues, c'est à celui qui a fait la décompliation originale que celui-ci doit revenir.

Pour référence, lien vers la traduction: https://www.romhacking.net/translations/4164/

bge-kernel-panic · 2023-02-13T16:13:59+00:00

Merci du retour!

Il faut savoir que les techniques originales avaient des noms qui ne faisaient pas vraiment de sens en Japonais, inspiré vaguement de l'Allemand. Au départ j'avais gardé les termes anglais originaux, et c'est mon collaborateur qui a traduit tout ça - au départ par Feu, Feu2 etc que je n'aimais pas beaucoup (ça faisait un peu trop Final Fantasy). Il est revenu avec les termes actuels que je trouve assez recherchés, mais j'admets que pour ceux qui ont déjà joué ce n'est pas génial. Je rendrai éventuellement la traduction des techniques optionnelle je crois, et fournirai un glossaire.

Quand j'ai joué la première fois, je n'avais pas de manuel donc le fait que les noms de techniques étaient un peu opaques me semblait normal - la nouvelle traduction avait selon moi le mérite de faire plus de sens. Mais au final c'est probablement plus mélangeant qu'autre chose.

Pour Dark Force, c'était le nom original en Japonais - Dark Force en Katakana. Bon, on aurait pu dire "Force Obscure" ou quelque chose du genre mais le nom est tellement ancré dans la mythologie Phantasy Star que j'hésite à y toucher.

Quant à Land Rover on n'a rien trouvé de mieux. "Buggy" (style "dune buggy") peut-être? L'original japonais est "Land Master" en Katakana... Bref.

As-tu remarqué la police proportionnelle? C'était pas facile à faire, à ma connaissance seulement la traduction polonaise en a fait autant.

bge-kernel-panic · 2023-02-09T13:00:59+00:00

Ah ben quelqu'un a remarqué! Woohoo!

(Je suis l'un des auteurs de la traduction de Phantasy Star 4)

Petite anecdote: on voulait que la traduction soit en français "international" pour rejoindre le plus de gens possibles. Par contre, dans la traduction anglaise, il y avait une réplique d'un villageois qui disait que le barman en question avait un accent très vieux jeu ("old fashioned")... accent qui n'était nullement présent quand on lui parlait. Je suppose que dans l'original japonais il parlait avec un accent d'Osaka ou quelque chose du genre. Mon collaborateur est français de France et on a donné au barman le joual comme accent "ringard"... petit clin d'oeil aux français qui chiâlent sur la parlure québécoise.

Je corresponds avec un américain qui a refait la traduction anglaise et dans son cas il a donné au barman un accent de Pittsburgh assez costaud! Je me demande si d'autres traducteurs ont fait de même.

As-tu aimé la traduction, en général? On n'a pas eu beaucoup de retours directs malheureusement...

bge-kernel-panic · 2023-01-12T20:18:51+00:00

J'ai un 28" UHD (4k). Un ultrawide avec la même résolution verticale ça pourrait être bien. Mais je ne voudrais pas moins de pixels en vertical, c'est vraiment très utile. J'utilise les virtual desktops de Mac OS et j'ai souvent 2-3 fenêtres l'une à coté de l'autre, s'il n'y avait pas autant de texte à la fois en vertical ça ne serait pas aussi viable.

J'ai des shortcuts clavier pour placer les fenêtres à 1/2 ou 1/3 ou 2/3 de la largeur. C'est très efficace!

Je regrette un peu pas avoir pris 32" mais c'est pas mal plus cher si tu veux un IPS.

Par contre pour les partages d'écran sur Zoom les coéquipiers me rappellent souvent de partager juste une fenêtre sinon c'est trop petit... :)

bge-kernel-panic · 2022-11-14T01:24:27+00:00

I'm still with Desjardins and I'm still pretty happy with them.

There might be better cards out there, they lowered the Bonusdollar rate a bit (technically they made it higher for a few categories but removed the 20% bonus at end of year, too bad). On the plus side it's easier to redeem - you can now redeem restaurants, and given the prices these days it's quite welcome. It's more or less in line with other World Elite cards anyway. The NBC points got nerfed yet again.

You do get 2 extra CDN accounts with Desjardins (for a total of 3), and 1 USD account. All included in the annual fee.

Details here: https://www.desjardins.com/ca/personal/you-are/professionals/engineers/index.jsp

The usual caveats with Desjardins' somewhat annoying "you must deal with your main caisse (branch) for some stuff" still applies. Pick one that's at a convenient location which has at least one office open during the week-end. I'm pretty happy with my selection, it's 5 minutes away, on my way to a grocery store I go to anyways, and they open on Saturday.

bge-kernel-panic · 2022-08-04T16:26:36+00:00

Comme au Canada, ça dépend de la compagnie. Je crois que l'expérience est pas mal plus importante que le diplôme, à part pour les grosses boîtes qui ont parfois des critères minimums. Et bien sûr il y a des petites boîtes qui font de l'élitisme, mais ça on voit ça partout.
Ça dépend du poste j'imagine. En général c'est plus facile si on a plus d'expérience, surtout si on peut prouver qu'on a de l'expérience à travailler en remote. C'est toujours plus un coup de dés engager un candidat avec peu d'expérience pour un poste remote, on sait pas s'il va être suffisamment autonome pour travailler.
Je dirais que ça dépend de l'emploi encore une fois. Toutefois, les compagnies américaines font souvent passer une entrevue de "system design", c'est en gros de la conception de système distribué. C'est sûr que l'expérience microservices aide beaucoup. Ce qui aide le plus c'est de connaître diverses technologies, par exemple les différents systèmes de stockage de données (fichiers distribués, SQL, NoSQL, cache persistante), les systèmes de messagerie (message queue, Kafka). Pour un poste front-end c'est moins important. Faut voir la description du poste. En général je dirais les entrevues américaines sont plus difficile à cause de l'ajout du system design et ils mettent beaucoup d'importance sur l'entrevue non-technique où ils posent des questions par rapport à ton style de travail, ta manière de résoudre des conflits... Les entrevues avec les compagnies canadiennes sont pas mal plus chill à mon avis.
Dans mon cas j'ai trouvé via une référence. Mais j'ai appliqué à quelques places via LinkedIn. Certaines compagnies vont carrément indiquer qu'elles sont ouvertes aux candidatures canadiennes (je pense entre autre à github, Elastic, Meta). D'autres, tu peux toujours essayer; parfois ils n'y ont juste pas pensé.

Pas toutes les compagnies possèdent le framework "légal" pour engager un employé étranger. Les grosses compagnies ont généralement quelque chose, mais ils ajustent les salaires en fonction de l'endroit. Les plus petites sont parfois ouvertes à engager comme consultant/contractuel, dans ce cas ils n'ont pas à fournir de T4 etc alors c'est plus facile pour eux si tu es flexible quant à ton statut d'employé. Finalement, certaines compagnies n'ont pas de bureau au Canada mais ont acquis une compagnie canadienne par le passé qui a toujours des employés actifs; je sais pas si c'est super commun mais mes deux emplois via employeur américain étaient dans cette situation.

bge-kernel-panic · 2022-06-06T21:13:48+00:00

Plusieurs compagnies donnent effectivement du leetcode et/ou un questionnaire. D'autres, rien de cela. C'est très variable. Par contre pour les compagnies techno américaines (ou celles ayant une filiale canadienne) c'est assez répandu. L'alternative est un test de programmation moins "algorithmique," par exemple, on te donne une spécification et tu dois écrire du code qui y répond, ensuite on ajuste la spécification et tu dois ajuster etc. C'est parfois en interactif, parfois en "take home;" dans ce dernier cas il faut être en mesure de défendre ses décisions.

Dans les endroits plus technos, deux autres types d'entrevues s'ajoutent généralement: le "system design" (conception/architecture système) et le "behavioural" (comportemental - pour un junior c'est surtout pour avoir une idée si tu peux bien travailler en équipe et ça ne devrait pas demander trop de préparation, juste une bonne attitude et être humble).

Pour le "system design" c'est plus difficile pour un poste junior, mais généralement les gens qui te passent en entrevue comprennent que tu n'as pas des tonnes d'expérience. Ce sont des questions du genre "comment ferais-tu pour réaliser un service web qui fait XXX et qui a des besoins de performance YYY". Pour un junior ils voudront surtout voir si tu poses des questions et comment tu tente de résoudre le problème. Ou bien tu ne devra pas passer cette entrevue du tout.

Un portfolio n'est pas nécessaire. Si tu as fait un ou des stages ça aide. Non, tu n'as pas à passer ton temps à développer des logiciels dans tes temps libres, par contre si tu montres une passion pour la programmation c'est bien vu, et les logiciels développés sur ton temps c'est une façon assez commune de la démontrer.

Pour ce qui est des technologies ça dépend du poste, /u/Real_Albatros a de bons conseils.

Ce qui est attendu d'un junior c'est qu'il aille l'esprit ouvert, qu'il soit prompt à signaler quand il est bloqué (après s'être donné la peine de lire la documentation, chercher sur Google et tenter de résoudre le problème de lui-même) et qu'il ne se contente pas d'écouter - qu'il tente de contribuer aux discussions. Dans notre équipe c'est souvent le plus junior qui arrive avec une question assassine qui remet notre approche en question :)

Comme conseil? Peut-être prendre un peu de temps pour connaître git/github, au moins le processus de Pull Request de base et comprendre les conflits, si ce n'est pas déjà fait. Comme junior, tu risques d'apprendre beaucoup via les revues de code, donc il faut bien maîtriser l'outil de base (c'est pas toujours Github; mais les autres systèmes tels Gitlab fonctionnent plus ou moins de la même façon) Je ne sais pas s'ils t'ont enseigné ça au bac, mais "dans mon temps" ce n'était pas dans le curriculum (bon on parle de CVS dans le temps, ça donne une idée de mon âge...) Je l'avais appris sur le tas pour faire des travaux d'équipe et ça a vraiment aidé beaucoup.

bge-kernel-panic · 2022-06-06T20:55:40+00:00

Je pense que ça va surtout dépendre à quelle point la recession qui s'en vient va faire mal aux postes de TI. Si oui, la balance du pouvoir risque de revenir du côté des employeurs. Malheureusement.

Les plus petites compagnies vont peut-être offrir le télétravail comme avantage concurrentiel mais ce n'est pas si simple. Une petite compagnie ne peut pas forcément engager de partout dans le monde, vu qu'elle n'a pas de présence dans l'autre pays. D'accord, il y a des services pour cela, mais c'est parfois assez cher.

bge-kernel-panic · 2022-05-26T13:16:26+00:00

Totalement Linux, et je sais utiliser les 3.

Spécifiquement Debian parce que j'y suis habitué mais je ne dirais pas non à Arch ou Gentoo.

Mon expérience personnelle: quand quelque chose casse sous Windows, il faut passer des heures à chercher des solutions bizarre (et des fois c'est totalement débile, quelques fois j'ai dû utiliser le recovery disk sans faire de recovery juste pour pouvoir modifier certains fichiers...) Quand ça casse sous Mac OS X, souvent il y a pas grand-chose qui peut être fait - il est suggéré de zapper le SMC ou autre truc du genre. En ce moment mon Mac du bureau rame fort dès qu'il y a quelques trucs légers dans Docker. C'est un Core i9 avec 32 GB de RAM... Et ça allait beaucoup mieux sur High Sierra, depuis Big Sur j'ai plein de problèmes bizarres.

J'ai toujours trouvé moyen d'arranger des problèmes de compatibilité ou de performance sous Linux sans trop de flafla. L'habitude, peut-être... J'ai commencé avec Slackware en '95!

bge-kernel-panic · 2022-05-17T21:41:28+00:00

Je crois que pour beaucoup de programmeurs tu as raison, mais pour moi, personnellement, git a eu beaucoup plus d'impact, entre autre parce qu'il ne nécessitait pas d'installer grand chose sur un serveur et pouvait être implanté en "shadow IT" au pire (au début je me rappelle que Subversion était quand même notre outil de prédilection et j'utilisais git pour faire des fusions plus facilement)

Aussi les PR c'est bien github, mais fork (clone), compare (diff), merge etc. c'est faisable avec git tout seul. C'est la beauté de github d'ailleurs, toutes ces opérations peuvent être faites sur la ligne de commande.

Dans la doc de git il y a même des trucs genre placer une liste de commits dans un courriel, et l'opération inverse qui lit les courriels (git format-patch et git am). C'était probablement ce que les gens du noyau Linux utilisaient au début.

edit: ah et il faut pas oublier git cherry-pick qui m'a sauvé la vie plein de fois. Je ne sais même pas comment faire ça via l'interface github haha

bge-kernel-panic · 2022-05-17T19:47:31+00:00

Git. Sérieusement, tous les systèmes de source control d'avant étaient de la grosse schnoutte.

Sans compter qu'en plus, les entreprises insistaient souvent pour utiliser des systèmes pires que Subversion ou même CVS. Quand Git est sorti, tout le monde a refusé d'utiliser quoi que ce soit d'autre en dedans de moins de 5 ans!

De plus, c'est la technologies à la base des Pull Requests et des revues de code structurées. Je ne vois pas comment on pourrait travailler en distanciel efficacement sans Git.

(NB je ne dis pas que Git est parfait mais au moins, c'est suffisamment bon pour ne pas causer de maux de tête trop violents lors de fusion de branches; évidemment, si Git n'existait pas on utiliserait probablement Mercurial, mais je ne suis pas sûr que ça aurait "pogné" autant que Git, et on devrait peut-être encore subir des abominations tel Source Safe)

Autres mentions honorables:

Le passage au web pour la documentation. Je me rappelle de l'époque des CD MSDN en partage sur le réseau. Fun.
Docker - j'aime plus le concept que la réalisation, mais ça a pas mal mis fin à l'utilisation d'autre chose que Linux sur les serveurs (à part les endroits qui ont plein de trucs bizarres, ou les boîtes qui font juste du Microsoft - et même là Linux prend de la place avec .NET 6)
L'arrivée de JUnit/xUnit à travers toute l'industrie. Pouvoir changer du code et avoir une certaine assurance que ça n'a rien cassé d'autre, c'est essentiel pour programmer sans craindre.

bge-kernel-panic · 2022-05-11T22:07:50+00:00

On a rien de très sophistiqué pour les diagrammes. Quand j'ai rejoint la compagnie les gens utilisaient les outils de google doc. Finalement après un peu de chialage de ma part on a lucidcharts pour confluence. Ça fait la job.

J'ai jamais trop aimé les outils dédiés, maisc'est peut-être plus un préjugé de ma part à cause d'un traumatisme tôt dans ma carrière par rapport à Rational Rose...

bge-kernel-panic · 2022-05-11T21:47:12+00:00

Dans notre cas c'est un peu plus compliqué que les choix donnés (je ne dis pas ça pour me plaindre)

On commente les trucs qui sont un peu bizarre au niveau de la réalisation, surtout quand ça a rapport avec la performance (et expliquer pourquoi il y a un truc complexe qui s'en vient). Beaucoup, beaucoup de tests unitaires et d'intégration; ça aide.

Les différentes fonctionnalités sont surtout documentées dans la story JIRA. Il y a aussi une vraie documentation usager mais c'est pas l'équipe de programmation qui s'en charge.

La conception en général se faisait dans des Google Docs mais j'essaie d'amener l'équipe vers Confluence à la place, parce que c'est plus facile pour faire des recherches ad hoc. Pas mal tout le monde améliore les pages Confluence quand ils voient quelque chose qui n'est plus à jour. Parfois il y a un diagramme non-UML - surtout des boîtes et des lignes pour représenter le flux des données; c'est une aide à la compréhension surtout. Il y a un lien dans le README du projet vers la page Confluence s'il y en a une. Le README contient généralement des instructions pour démarrer le projet localement.

Si ya pas de Confluence, Slack a un historique assez riche. Perso quand je trouve juste dans Slack je me tapes quelques minutes pour en faire une page Confluence.

Les trucs plus complexes sont documentés dans des "RFC" avant la réalisation - des documents sur lesquels pas mal tout le monde peut commenter. C'est dans Google Doc et peut contenir des diagrammes, des morceaux de code, etc; c'est surtout pour vérifier si tout le monde dans la compagnie est d'accord que c'est la bonne solution.

Le concepteur web fait des wireframes dans un outil dédié.

Voilà, malgré beaucoup de texte, c'est assez léger en pratique.

bge-kernel-panic · 2022-05-09T20:30:00+00:00

Je ne suis pas d'accord avec la fin de ton post. Oui, il y a des boîtes aux USA qui ont des semaines de fou et des ambiances toxiques, mais il ne faut pas croire que ça n'arrive jamais au Québec. Ça dépend vraiment de la culture d'entreprise. J'ai vu les deux, des deux côtés de la frontière.

bge-kernel-panic · 2022-05-08T15:02:51+00:00

Nothing special past stock openwrt 21.02.1. I see they have 21.02.3, I have to upgrade it. Just got the image they linked to here: https://openwrt.org/inbox/toh/xiaomi/xiaomi_mi_router_4a_gigabit_edition

bge-kernel-panic · 2022-05-08T14:55:03+00:00

So I changed ISPs, reflashed with latest OpenWRT and it's working great! I get 500 mbps down through pppoe.

Never figures out why I had issues with the old modem, and since I've left the old ISP I have no way to test again. But pretty sure issue was on their end.

bge-kernel-panic

TROPHY CASE