Let’s face it, we were still a fast-moving startup, even if the above anecdote might give you the opposite picture. Our code was still changing drastically every couple weeks. Changes of the entire architecture or complete re-writes of components were not uncommon, as is usual for some early stage startups. And as you might expect in such a situation, the code wasn’t of the highest quality either: Half the time, the build would be broken. Testing and documentation were basically non-existent. It was unlikely that anyone from outside the team would even have gotten the thing up and running. Even if they did, it would be outdated a moment later.
The correct answer is almost always 7.
I remember when I was in school we were explicitly warned if asked “how well do you know $LANG” in an interview to never answer 9 or 10. If you do then you will be asked a language lawyer corner case which proves you don’t know what you’re talking about.
Answer too high and you get made a fool. Answer too low and you project not having significant experience with the language. I would have rated my C++ knowledge to be a 7 when I graduated 14 years ago. And if asked today I’d probably still answer 7.
7 is a very very safe answer. :)
I asked that question for years in interviews, with the follow up of "Okay you're an N, what does an N-1 struggle with?" It was always funny to hear everyone say they're a 7, and then get answers ranging from "a 6 would struggle with declaring functions" to "a 6 would struggle with template meta-programming."
It's a bit of a mind-game, but it's actually really effective.
Oh gosh you’re a monster.
“A 6 is someone who doesn’t realize the answer to this question is always 7”.
When I interviewed Jamie for a position at ZenTech, he seemed like an enthusiastic engineer. With solid tech skills, ideas for process and product improvement, and a great team attitude, he was the obvious choice.
But, two years later, Jamie was “that guy”. You know, the one who wants to code without being bothered.
L'impact désastreux de la soi-disant rationalisation de la gestion : le management se concentre sur quelques chiffres qui deviennent donc les objectifs de fait, au détriment des vrais objectifs de la recherche.
When a measure becomes a target, it ceases to be a good measure.
Il y a un espèce de mythe autour du «daily stand-up», et dans de nombreuses boites il se retrouve utilisé à toutes les sauces de manière totalement inutile.
Les situations où un «daily stand-up» est inutile voire nuisible sont bien résumées dans l'article :
Everyone is working on their own tasks / user stories, with very little need for coordination outside of the regular sprint meetings. This can cause a host of other problems, but you probably do not need a daily standup meeting.
People are not even working on the same project. Everyone on the "team" is on a different project, e.g. people in an agency working for different customers. So your team is not even a team!
Your team is working closely together all the time. They are co-located, and they always work together on a single user story. Everyone already knows what everybody else is doing, so you do not need a daily meeting where everyone is stating the obvious.
Je soupçonne que la raison principale pour laquelle la majorité des boites qui font des «stand-up» en font, c'est parce que ça donne une impression de contrôle au management.
It is mainly used for reporting the progress to a manager
C'est du même auteur que le précédent post que j'ai bashé, mais ça c'est une bonne idée.
C'est marrant d'ailleurs, parce qu'en mettant une numéro de version /v1 dans ses routes pour garantir la compatibilité, ça suppose que le service derrière la route en question respecte le semver. Le numéro de version majeur du service a changé alors il faut que je change le numéro de version dans la route.
 dans le cas d'une architecture micro-service où une route=un service. Dans le cas contraire on tombe dans le cas que j'évoquais, du logiciel complexe où «au moins une chose change à chaque fois», mais dans le cas d'un service web basée sur des API REST, on n'a pas vraiment d'excuse de faire un monolithe comme ça.
So if the cost of a developer who does negative work is so high, how do they get hired? Part of it can be explained by an interview process that needs improvement, but a less talked about part is the temptation to lower hiring standards.
Sometimes a company is in a situation where a lot of work needs to be done very quickly. If there are not enough developers in the company to accomplish that goal, then more developers need to be hired. Since developers have the advantage in the job market today, it can take quite a bit of time to make a good hire. That is when the temptation to lower hiring standards appears. When the amount of work is overwhelming, some people hire in a panic. They think having more bodies in the office can only contribute to more work getting done.
That is far from the truth. Not all developers will bring positive value to your team. I understand the pressure of tight timelines, but hiring in desperation won’t solve that problem. It’ll make it worse. Bad developers will not only slow you down, but they can cause your great developers to leave your company.
Un article sur la pertinence des micro-services. Je suis assez d'accord avec ce qu'il dit :
Les micro services peuvent être une bonne idée d'architecture dans certains cas, mais ça ajoute pas mal de complexité du point de vue de l'organisation et de la synchronisation des équipes, sans apporter grand chose dans la majorité des cas.