Such a pet peeve of mine. Define it, at least on the page. From wikipedia.
> NAT64 is an IPv6 transition mechanism that facilitates communication between IPv6 and IPv4 hosts by using a form of network address translation (NAT). The NAT64 gateway is a translator between IPv4 and IPv6 protocols, for which function it needs at least one IPv4 address and an IPv6 network segment comprising a 32-bit address space.
Fun fact: I wrote the initial version of that page. I taught networking lessons at a university, IPv6 transition mechanisms were one of the topics we covered, and this one didn't have an article, so I wrote it. It was quite funny when one of the students realised it was who wrote it when they went to Wikipedia wanting to learn more :)
A company I was at 20 years ago did a variation of this for software estimation. It resulted in some good discussions. It wasn't anonymous as mentioned here.
When one person on the team says an element will take one week and another says 8 weeks, there are fundamental differences in assumptions that need to be worked out. That was the good part of the process. The bad was when the Project Manager doesn't let the process play out and simply takes the shortest of the available estimates.
This triggered my PTSD with regards to project managers. People whine about agile and scrum etc. but what they don’t realise is that the biggest benefit of those processes was that they replaced project management led, waterfall based processes.
Waterfall failed for many reasons, but one of them was because you’d get asshole project managers constantly taking minimal estimates exactly as you describe and then applying pressure on individual devs when they overrun the minimum estimates.
One of the biggest contributors to developer happiness and productivity over the last 20 years has been to escape this tyranny.
Professional project management (PMI) embraces critical path, iron triangle, risk management. Iteration was always The Correct Answer™.
Kids today conflate "throw it over the wall" with waterfall.
Agile rejects planning, foresight, vision, end goals. Agile was explicitly concocted to manage upwards, in those organizations unable or unwilling to do proper planning. Unfortunately, the originators wrote down their survival tips, which were then misunderstood by noobs and embraced by profiteers. Just like every other religious text.
Agile is not the victory of iteration over some imagined dark ages of project chaos. The Agile Methodology is to argue about the Agile Methodology. The cult(ural) spread of Agile is no different than any other vacuous self-help omni-fix content-free dogma.
Any decent project manager know their people,so if Mark says it will take 2 days but in reality takes 5, the PM should see these patterns and either help the person to improve estimations,or adjust project deliverables based on this knowledge.
It's one of the many tools in the efficient tyrannical manager's toolbox, with a motto of "my goal is not to have you do effective work, my aim is to advance my goals and keep everyone below as a non-threat to those goals". Keep em busy and insecure.
Sure nice it doesn't work on competent developers, not with the current job market.
> One of the biggest contributors to developer happiness and productivity over the last 20 years has been to escape this tyranny.
We've only replaced the tyranny of deadline crunch with the tyranny of daily micromanagement. You can't even wipe your own ass without so much as a Jira ticket and half a dozen people signing off on it.
And despite all of the rigmarole and rituals, you still have deadlines. Doesn't matter what the Jira board says. If some upper management dickweasel wants their feature, they will get it. Forget the story points and estimates.
Edit: as I recall from doing estimating using wideband Delphi circa 2004, the main differences with planning poker as I see it practiced today are that estimates were in real time like days or weeks, and votes were collected and displayed anonymously, though as you would expect there was temptation for people to de-anonymize their own votes.
PM should always work with/as a business analyst to figure out the business requirements. A lot of times it is the ambiguity of business requirements that leads to bad decisions.
This is the exact reason that I started writing "posts" or "articles" even though I haven't put any on a site yet. I was putting stuff in a wiki and felt like they were unfinished ideas. I've found that the wiki is where the idea goes and the article is where I can really flesh out understanding. When you take the time to write something out with an outline and real consideration, you understand it better. It has helped me figure out my own thoughts on a subject when previously I only had surface opinions.
My experience with code reviews is that they always became adversarial. I tried to implement code reviews in my group many times and it didn't provide a lot of value.
We finally did it by using GitLab and requiring that every merge request to master must be reviewed by two team members. This provided code review on every piece of code instead of only on select pieces. GitLab allows us to enforce it easily, but the process can be done anywhere.
The nit-picky code reviewer gets overwhelmed defending his point of view and starts being a little more selective. The lazy programmer gets overwhelmed with constant changes and actually starts paying more attention. Somewhere along the way it has actually balanced out.
Discussions have allowed us to identify poor practices, new techniques, and implement some standards.
Where I saw it be successful it was a pretty good team actually. Like pretty much everyone on the team was a reasonable person. The way they did it was before you check into any branch (other than master) you need to get a code review from one other person. So you'd go into the chat room, ask for the review and either get a :shipit or an email/notification on github about whatever was flagged. That worked pretty good but idk if the main reason it worked is because it was a reasonable group of people.
And it can be completely subjective. I applied for a position and interviewed with two different teams there. I had a friend on the interview board. One team said that I seemed "inflexible" and the other team thought I was "too compliant" and potentially wishy-washy. So my feedback consisted of opposite perspectives.
Thanks. I've read everything by McConnell and I remember Code Complete as a good book, and the closest I came to an answer as well. I'm familiar with Martin but haven't read The Clean Coder. I'll check it out.
It looks like a book at first glance but is really an outline with a list of references to other locations to read more about each of the topics. Useful but no new or interesting content on its own.
This is what I'm working through and I like it. I've read a ton but nothing clicked until I started actually "doing". And the components are all available in kits. (Make: Electronics Components Pack 1, etc). You can get the stuff cheaper, but this puts it all together in one place for you.
> NAT64 is an IPv6 transition mechanism that facilitates communication between IPv6 and IPv4 hosts by using a form of network address translation (NAT). The NAT64 gateway is a translator between IPv4 and IPv6 protocols, for which function it needs at least one IPv4 address and an IPv6 network segment comprising a 32-bit address space.