'In the midst of Shannon’s career, some lawyers in the patent department at Bell Labs decided to study whether there was an organizing principle that could explain why certain individuals at the Labs were more productive than others. They discerned only one common thread: Workers with the most patents often shared lunch or breakfast with a Bell Labs electrical engineer named Harry Nyquist. It wasn’t the case that Nyquist gave them specific ideas. Rather, as one scientist recalled, “he drew people out, got them thinking.” More than anything, Nyquist asked good questions.'No, you probably shouldn't be saying that:
https://en.wikipedia.org/wiki/Harry_Nyquist
https://en.wikipedia.org/wiki/Nyquist_frequency
> but what's stopping a dozen other things at least that useful from being part of the answer?
Because someone needs to act, and that's exactly what Nyquist did, in a very unobtrusive and non-confrontational manner.
> Because someone needs to act, and that's exactly what Nyquist did, in a very unobtrusive and non-confrontational manner
Seems like your headcanon. It reality they ate lunch together and passed ideas around.
I.e. there's no check or control on their output without lunch or breakfast with him, maybe it'd have been little different.
Engineering excellence is not a prerequisite to business success. Managers know this.
Why else many things any one of us could list from the computing business.
Woe is us. Five or ten years is not considered short term
> . I try to give more to the clients that pay more, or at least create something that I can reuse in the future, while making sure what I deliver is stable and not a big ball of spaghetti to make the next developer/engineer cry at night.
I am not sure about the "...who pay more". As I am currently woefully underpaid I am more sympathetic to that view than once I was, but, I still view myself as a professional, and I act with professional ethics.
Partly that means speaking up when I see a project going near the rocks. I do not make too much fuss, but I do say it out loud.
That has cost me plenty. Our industry is full of people who are very good at one thing or another, but do not know their limits.
Part of my "being professional" is knowing my own limits.
It is important to know what you can and can't get away with, and my clients don't pay the cost of the business I'm employed by making bad decisions. Where I am able to, I strive to provide a product that is better than the average, in the hopes that I've developed a solution that can possibly benefit the company or myself in the future in regards to software quality or speed (along with stability) of deployment.
I have heard of the Nyquist frequency, the nyquist limit, the nyquist sampling rate and the Shannon nyquist theorem.
As far as I know no other individual has had this many “things” named after him.
Note that the "Known for" section on his main page has 119 elements. But they're not all named after him.
"In an effort to avoid naming everything after Euler, some discoveries and theorems are attributed to the first person to have proved them _after_ Euler."
I always remember as “questions are harder than answers”.
Woah. He has a huge list of "Known for"!
Good people amplifiers are domain/technical experts; Scrum Masters/Agile Coaches are neither.
At this point i think it is rather well established; eg. "Taskmasters" in - https://en.wikipedia.org/wiki/Bullshit_Jobs
And yes . . . I do code.
It has nothing to do with coding but everything to do with adding tangible value towards achieving an Objective Goal (Business/Technology/whatever). Hence the Problem Domain and technologies used in the Solution Domain are what matter and everything else is ancillary. The Processes/Methodologies used are only useful in as much as they help us understand the problem domain better and map it to a specific solution. Thus the application of the former is informed by knowledge of the latter and cannot exist by itself. Hence the reason we have so many types/variations of Processes/Methodologies; there are some common principles but will always need to be adapted/customized to the problem and tools at hand.
This is what is the problem with modern-day Management/Leadership and eloquently pointed out by David Graeber(Bullshit Jobs - https://en.wikipedia.org/wiki/Bullshit_Jobs) and Jeffrey Pfeffer(Leadership BS - https://jeffreypfeffer.com/books/leadership-bs-fixing-workpl...).
I highly recommend reading this speech by David Packard (one of the founders of Silicon Valley via HP) to new Managers given in 1960 and note how relevant it is for all companies today - https://gizmodo.com/the-hp-way-how-bill-hewlett-and-i-built-...
Relevant Excerpt:
Over the years we have developed the policy that it is important for the supervisor to thoroughly know and understand the work of his group. A debate on this has been carried on by management people for years. Some say you can be a good manager without having the slightest idea of what you are trying to manage, that the techniques of management are all important. There are many organizations which work that way. I don't argue that the job can't be done that way but I do argue strongly that the best job can be done when the manager or supervisor has a real and genuine understanding of his group's work. I don't see how a person can even understand what proper standards are and what performance is required unless he does understand in some detail the very specific nature of the work he is trying to supervise. We have held closely to this philosophy and we intend to continue to do so. We expect you who are supervising to learn techniques of supervision and keep up to date. I want to emphasize you can supervise best when you know a great deal about the work you are supervising and when you know the techniques of supervision as well.
I've had multiple Producers who "understand the work" of creating mobile games as a whole and understand how the team needs to work and interact to produce a result on time.
None of them could code a mobile game to save their life.
What your example is talking is a situation where a fresh off the press MBA is shoved in to a very specific field and they start just doing pure numbers and Excel management out of a management book without knowing how that specific industry operates.
Managing a team of deep-sea welders is VERY different from managing a software team, which is again different from managing a team of people building a physical machine.
True. However, the relationship between them need not be a "Total Function" but definitely needs to be a "Partial Function" to a certain degree. You cannot be completely divorced from the "How" and hope to have a good "understanding" of the system.
>Managing a team of deep-sea welders is VERY different from managing a software team, which is again different from managing a team of people building a physical machine.
This is precisely the point; domain/technical knowledge is needed to effectively Manage a project. This is independent of knowledge of techniques of Management. The problem today is that entire industries have been created out of thin air which posit that the latter is sufficient if one follows a certain process/methodology which is patently absurd.
No, I think at least in large part, you missed the point.
> It has nothing to do with coding but everything to do with adding tangible value towards achieving an Objective Goal (Business/Technology/whatever).
As I understood _Bullshit Jobs,_ "adding tangible value" to some business that doesn't actually add anything of actual (non-monetary) value to the world is bullshit. There are whole industries that make billions of dollars, but everyone who works in them is still doing a bullshit job. (I often think I do.)
From https://en.wikipedia.org/wiki/Bullshit_Jobs :
... as he describes, five types of entirely pointless jobs: ... 5. Taskmasters, who create extra work for those who do not need it, e.g., middle management, leadership professionals.
In companies, he concludes that the rise of service sector jobs owes less to economic need than to "managerial feudalism", in which employers need underlings in order to feel important and maintain competitive status and power.
From https://en.wikipedia.org/wiki/Bullshit_job :
Graeber also formulated the concept of bullshitization, where previously meaningful work turns into a bullshit job through corporatization, marketization or managerialism.
The best amplifier I've met was hired as a junior coder to my team and was paired with a couple of 10x coders on a project with a client who was "hands-on" and loved to micro-manage, having been a software developer themselves a long time ago.
The Amplifier's coding output wasn't that good, but the team as a whole was doing better than before so I investigated.
Turns out the 10x guys weren't that keen on communicating with ... well anyone outside of the team, much less with non-technical clients (or technical clients who loved micromanage). Both were your stereotypical cold pizza and warm cola coders with limited social skills. They could kinda sorta manage the meetings and emails directly from customers but didn't exactly relish it.
The junior hire was more like a 0.5x coder, but had ample social and organisation skills and worked extremely well as a liaison between the team and any external contacts they needed, taking over most "useless" meetings with the product owner and customer.
The junior coder ended up receiving some training and was "promoted" to a Scrum Master/Producer/Project Manager (the exact title escapes me) for the team. Everyone was happy and productive.
Your "Amplifier" is more like what is known as a "Field Applications Engineer" in the Embedded industry i.e. somebody with enough Domain/Technical/Marketing/Sales skills fulfilling a tangible need for the Business. They are more a "Business Process Optimizer" than a "People Amplifier"(a term i made up :-) who i define as somebody who can spark creativity/insights/viewpoints etc. which push others forward in their problem-solving endeavours. It is not merely removing hurdles/book-keeping/time management/liaisoning but an active role involving discussions/brainstorming/idea generation. This cannot be done without bringing some expertise to the table relevant to the problem at hand.
While I did go out to lunch with coworkers more often while working in the office it was almost exclusively with direct teammates, and other groups I occasionally saw where also on the same team.
Now that I'm fully remote, I will typically do a few "hacking sessions" over Zoom every week. Its much easier and more comfortable than standing over their shoulder in tiny cubes we used to have.
That said, especially now that i am fully remote, I've been trying and mostly failing to get developers especially across teams to talk and collaborate more. But its not too suprising: I was recently in a call and I was introduced to another developer who I replied, "Yeah, I know you. I was in the cube next to you for 2 years and on your team for 6 months."
Remote creates some new challenges, but its a culture thing, not a technology thing.
It's not the same as having lunch together but it is enjoyable and useful.
The answer is that I never was good at social things like inviting people to coffee.
But it doesn't help that we're taught to "protect" our time and avoid unnecessary calls and meetings. Presumably so we can write more lines of code, close more tickets, or earn more points like the story and other anecdotes here.
I think I may try something new in my calendar. Worst case I'll end up sitting in front of my computer alone with a block for the next hour and nothing to do but work on all those things I need to do anyways.