Team players, mentors, software architects; they tend to be tossed aside to make room for junior coders who can churn out large amounts of code, even as the company's capacity to deliver and maintain features declines over time due to tech debt. Managers always love a developer who can consistently write 5000+ lines per code per week, regardless of how many features they actually ship and how many bugs they introduce.
As a team lead and engineer who has managed some complex projects, idea of someone writing over 2000 lines of code per week terrifies me... That's over 100K lines of code a year. Think of the unnecessary complexity. There is a very good chance that the same feature set could have been implemented with just 10K lines of code, less buggy and in half the time though that would only amount to 380 lines of code per week!
I tend to think that the dev who can churn out thousands of lines isn't thinking deeply enough about the long term direction of the project; all the code they're writing is essentially throwaway code.
The idea of measuring everything and acting on the numbers you can get is from the 19th century. Managers have been doing that same kind of practice since then, with the same kind of result (it's a very reliable result), without a change.
When you do things right, people won't be sure you've done anything at all.
He did experiments where he would have workers shovel piles of ash from one side of a line to the next, giving them a new shovel size each day. Found that the ideal shovel size holds 21 pounds [1].
The ideological assumption of his work is that management exclusively does the thinking and the workers exclusively do the doing. This falls apart when the workers have unique knowledge and insight that management does not have.
[1] https://www.mentalfloss.com/article/63341/frederick-winslow-...
AKA every time.
AFAIK, Taylor himself wasn't nearly as radical about doing measurements and only acting on them nor about managers deciding everything and not listening to the workers as Taylorism preaches. His work was one of the many, many management theories that was completely modified to appeal to incompetent power-hungry wannabe dictators (and yet blamed on the person proposing the original theory).
It has become taboo to say things like "This code is too tightly coupled", "You don't need to add an external dependency for that", "The inputs to those methods are too complicated; your components are micromanaging each others' state", "You're violating separation of concerns", "The cyclomatic complexity of this code is too high; you could simplify all your if-else statements"... When it's not my company, it's impossible to dismiss code when it works right now, even though it is likely to break later.
"This change is hard for me to read and understand"
or
"This is a large PR, and it may be difficult for me to schedule time to review it. Can it be split up into a series?"
I also configure linters and code quality tools to automatically flag some of the more egregious problems.
I'm 33 but I feel like I already have to make an effort to avoid the dinosaur label. I disagree with a lot of modern tech trends but I simply cannot express my view about them even though I could explain the problems very clearly and logically and can provide far better and simpler alternatives. Unfortunately, hype does not yield to reasoning... And sometimes, you're too far into the tech debt and it doesn't make financial sense to rewrite.
My current reality is that I'm a 33 year old working with 20 year olds who think they're geniuses who are going to take over the world in 5 years; from that viewpoint, I'm essentially a failed engineer because I didn't build a Facebook, Uber or AirBnB even though I had 10 years to do it.
5 years ago I was at a small bootstrapped startup and one of the worst engineers I've ever worked with was saying he'd expect to be a CTO of a mid-size startup in 5 years. He had just started his career. He managed to concoct quite an interesting fictional LinkedIn profile, while in reality he had almost no coding experience. He was a grifter.
In larger, established, tech companies this wasn't as prevalent but mostly because people were a bit more mature and respectful.
I guess it comes down to maturity. In startups and SMBs it was easy to find this attitude. Junior developers are often the most difficult.
Webapp coding is harder than it appears because of them. I haven't worked in a codebase without them.
But they're usually so unlikely to happen it's not worth fixing them all because it can lead to very specific and tricky code. So as long as the consequences of it occurring aren't really bad, I just leave it alone.
Believe it or not, I consulted at one place where the manager decided I was the problem because I was consistently assessing problem code and team processes in similar ways. She asserted that "everyone else understood", even when they plainly didn't understand but where just going through the motions.
Said manager had a number of other issues as well. Worst gig I can recall having in the last couple of decades.
Edit to add: in 1:1s with the manager I was more direct. About the best I can say about that is "at least I tried".
The last greenfield project which I managed from scratch, we didn't have this problem because all developers shared the same mental model of what we were building before we wrote any code. We had a lot of discussions beforehand to get to this shared understanding. There was literally not a single PR which surprised me throughout the entire project and I'm sure none of my PRs were a surprise to any of my team mates either. There was plenty of disagreement throughout but it was always fully resolved through discussion before we started coding each major feature.
Warning: it looks like you’re trying to pack too much crap into a single PR and your peers are unlikely to understand what they are accepting.
I've found that kind of feedback to be useful actually. And when giving similar feedback it is received better with a small change in wording to make it more about the code and not the person. Even if that is the intention the wording does matter. For example:
"An external dependency isn't needed here, try implementing with XYZ instead." "Split this function into x and y for better separation of concerns"
Removing the "you" removes some resistance to receiving the message .
I’ve become fond of mostly asking questions.
I wonder if we could avoid this dependency? Maybe [idea] would work?
Can you see a way to separate the X concern into a module?
Can we split this function up a bit so the nesting won’t be so deep? Would this loop body make a good standalone function?
Without going into specifics, there was a case where I reviewed a PR, asking "this isn't usually how people do file operations, are you sure this is really fine?" To address my concerns, they even wrote a specific test program to "prove" that there weren't any problems with the code. I reluctantly approved the PR since I couldn't just ask them to rewrite the whole patch due to just a hunch.
Lo and behold, after a kernel upgrade and file system change, that weird piece of code caused a multi-week panic for the whole team. The extra funny thing is that the test program above made it trivial to confirm and reproduce the issue once we identified this was the cause.
It's the team that creates that kind of opportunity for feedback though. If the team has dysfunctions like rejecting deeper discussion or not working beyond jira tickets or checking out at meetings, etc. then it's not going to work. Someone that's good at that kind of supporting discussion will feel push back when fostering those discussions so it will fall off over time.
The teams that do the best work and are the most fun to be on can host those types of discussions though, even remotely. It's worth experiencing if you haven't!
I assume you mean the thoughtful person whose probing questions unlock and unblock everyone else.
Lunchtime conversation is only one enabler of this.
I suspect the person is Hamming, as he makes reference to this in his book The Art of Doing Science and Engineering.
This aspect of what it takes to be a Hamming is curiosity about what other people are doing; you can track this by reading shipped emails or lurking in slack channels, then reaching out individually to the people/teams involved when you wonder about something.
Hamming was intentional about doing this at lunch. The magic isn't lunch, it is in intentionally seeking the information and then acting on it.
You do need to cultivate a culture in the team of people being willing to lower their guard and ask questions though. And I think the key to this is just staying humble so people feel comfortable approaching you.
Because lins of code churned out is not and has never been a good measure of productivity.
That "shower thought generator" might very well be more productive than the person they're sitting next to churning out tens of thousands of lines of unmaintainable code if their shower thoughts are causing people to find better ways to solve a problem.
Which is basically the entire point of the article.
Also, solving the same problem with less code is a lot more valuable than many think. Not only are there fewer code paths to test, the system probably has fewer unnecessary constraints and edge cases to consider. How do you account for negative LoC?
It will take me far longer to come up with the correct 100 lines that is both maintainable and can be worked on by others down the line.
I can pad my lines of code in seconds if I wanted to before pushing the changes. That padding provides no business value and might even introduce bugs.
And how do you handle refactoring? If I come in and refactor everyone else's shitty padding by combining helpers and optimizing code, I'll have negative lines of code. Am I an unproductive worker?
Sure, most code is not some complex algorithm but lines of code is a stupid metric that is not representative of the work done and can be gamed by anyone knowing what they're doing.
It's better to have tests more sensitive to failure, like integration or regression tests.
The key there is caching your results. Don’t run unit tests for code that hasn’t changed.
They still serve the important purpose of checking validity of the code under test though, so if they do get modified downstream at some point and they fail you then know the changes aren’t conforming to expectations of the system.
This of course assumes people aren’t writing highly coupled tests and that is more rare than I wish it to be
Why not? Peer feedback is a prime component of most performance/rewards discussions at companies. Work outside of points is certainly not a new concept. A manager's job is to distill this information amongst others to their own management chain at the right time.
> We don't have the counterfactual where Bob didn't ask the questions, and Alice did great anyways.
Bob's time isn't unlimited. There are surely instances where he was helping out Joe, Suzie, Darren, and James and had no time for Alice.
Based on your other comment, you seem to think someone being an unblocker/idea generator/dev lead is a "low performer" who weighs the team down. That's just fundamentally wrong.
> The people that can do this without needing Bobs around are the people that will be rewarded.
Unicorns are few and far between, but sure, you do you.
He asked "can you do it faster" and I agreed, thinking I'll make a throwaway version first and fix it later. Needless to say the project was a disaster, rapidly became unmaintainable.
That's how I learned my job isn't to do what the client asks, it's to make sure their project succeeds even if it means making them (temporarily) unhappy.
And I learned that doing it my way will get me fired because the manager has asked to do faster.
The way I have learned to get around this is by making the manager publicly document the request to go faster. If they don't document, I don't see or act on it. Once they document it, I happily go faster and let it all crash and burn. Then when they inevitably try to blame me, I point at the public documentation of the request to go faster and let the blame fall on the person responsible.
if time is the only actual concern for the project's success, a good approach is to explicitly re-scope the feature list and start asking managers things like:
"do we really need feature X to release? can feature Y wait until after beta? did the request for feature Z come from a user or a stakeholder?"
document all that too of course ;) but then at least there is a chance for safety _and_ success
Yes the project will fail. But if my manager only cares about speed, why should I care about anything more? Why should an engineer be responsible for a manager's poor decisions?
Because the corporate hierarchy demands it. Front-line workers are expendable, much like front-line soldiers. Corporations are not democracies, and neither are militaries.
If your job is to write and commit code, you are the corporate equivalent of infantry. In short: a grunt.
And if I am being treated as a grunt, I will act like a grunt aka I don't care more than my bosses. I will even abandon ship at the sign of incompetence and point out the incompetence to others.
Regardless, it’s an important life skill to learn that it’s generally not enough to ask people to do what you want, you need them to actually “buy in” to what you want, and then they’ll actually care enough to at least try make it happen.
This applies to managers and their employees, or also when trying to get on the ground employees to adopt a product initially sold to their manager/execs.
I don't feel the need to get "buy in" for bad faith managers.
An overly broad statement which, my experience, is not true. Managers come in many shapes.
Although, I suppose ironically, if you act in bad faith as a response to this perception, then I think that perception will quickly become true.
If the project fails, and the manager tries to blame it on you, they are de facto acting out of bad faith given the request. Documenting it just identifies this. If the project succeeds or fails, but no one blames you, then the documented request is just there for the record.
If we don’t know if anyone will want the product, the quality of the product is less valuable than validation of product market fit.
Later, I care much more about avoiding accidental complexity and having a great technical foundation.
This sounds like an improvement over the opposite, a code base that is rarely touched and uses eol frameworks. Software is a living thing and if you don’t act as a ruthless gardener you wind up a museum curator with 1990s DEC hardware running in the 2010’s.
The right balance of staying current and not reinventing the wheel is not trivial.
And yes, 10 years is quite possible these days. Besides the infamous Javascript framework churn, things are moving quite a bit slower in recent years.
In part, this is due to the risks inherent to change have been spread out over 10 years instead of backloaded to the end.
Practicing mitigating risks by proactively taking them has value of its own. The parable of ergodic cakes shows this.[0] What % of cakes will fail if 10 people each bake one, versus one person baking 10 over time?
reactjs came out in 2013, so it meets the 10y metric, but it has some internal churn, such as classes, hooks, etc
There are PDP-11s running nuclear plants today with support contracts to keep them running until 2050.
PDP-11s.
Indeed, business people do not typically model depreciation curves for software as they should. That doesn't mean that the plant control system becomes less valuable (the value is tied to the operation of the plant, probably for the lifetime of the plant), but in many other situations it does mean that.
I'm not going to drive off a cliff just because the OKR tells me there's actually a road there but I wonder about some people...
This is my company. Engineer skills, tech-debt, teamwork, camaraderie don't matter. Do as the management says, in the time they've promised to others or else....
https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
It doesn't always work as designed (ok, maybe rarely works as designed), and TLs can get too bogged down in cat herding, planning, and bike shedding to actually work as an engineer. But at least the spirit of the role is sound.
Now TLM (Tech Lead + Manager), however......there's a role that's set up for failure. Be a manager but be judged entirely on your technical contributions.
Any meaningful contribution or engineering is extra credit.
If you are immature or competitive, you cease being a force multiplier to be a morale destroyer.
If you are more of a domain expert than your Product Managers, you will spend your time fighting and refining tasks to build features the right way.
If you don't have enough time to code, you'll go obsolete.
Where I disagree is with the idea of fighting with product owners. If there's a disagreement around approach or tech choices that's a sign we don't have enough information. Fighting or refining won't solve that. It's a signal that we need to do more discovery work and understand the problem better.
The problem is not needing discovery work or understanding the problem. The problem is when the Tech Lead is the one who's providing all the data for that discovery, or helping them understand the problem better, because of lack of expertise of PO/PM. Or having to push back because of incomplete knowledge.
If there is lack of information or incorrect information, POs should be able to get that information themselves. If a TL is the sole source of that info, then it becomes an issue.
IME this is very common. And it takes too much time of a Tech Lead's day.
If you are more of a domain expert than the product managers, argue for the product managers to be fired - they serve no purpose.
This is a strong statement. There are both people who are writing throwaway code and people who are writing essential code that match the description.
And one will never get to be the latter part without going through a phase where they are doing the first.
The parent comment doesn't contest this. I think it's about the throwaway code author being valued more than the other.
Managers love metrics. There's nothing wrong with metrics, of course. It's when metrics become targets that things fall apart.
https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
What managers care about this at all?
One sign I see if a healthy workplace is one that tracks bugs and QA issues downstream against the same unit of work.
You quickly get a sense for what teams and even individuals are introducing the most bugs and issues.
If you can close tickets fast and your bug rate is low: that’s key, but I have found often that the people introducing the most bugs and issues into the codebase that others have to spend time dealing with are those that seemingly close their tickets rapidly every sprint
You know, most companies.
https://en.m.wikipedia.org/wiki/Carry_On_at_Your_Convenience
I am not against Unionizing "per se" but the role of Unions has never been "tell the management how to run their business". There has been some cases of (smallish) company being "acquired" by their own workforce, and the Unions might have helped with formalizing the deal, but this is rare, and anyway happens only when the company goes bankrupt or decides to shut down.
So I do not understand exactly what you mean here.
A Union can organize and sustain a strike. But they cannot "toss leadership out". Not the CEO, the Board or any manager at any level.
They could theorethically "blackmail" a company saying "strike will not end until X is fired" where X is a PM or manager or whatever but I never really heard of anyone trying this tactic, not to say actually succeed...
Some of that is indeed earned by the businesses reputation, but ultimately this is what I think spurred the decline of union membership in the US because businesses don’t get a lot if any value out of having a union around and the organized workers often find the benefits stagnant after some time
It's been a net negative to workers for ages. All my blue collar friends hate them.
Besides, developers have power in the market, they can negotiate quite a bit without paying money to some political useless figures.
https://news.gallup.com/poll/398303/approval-labor-unions-hi...
I see it as very much a union-by-union thing, much like you would an employer.
Now, some programmers may be able to negotiate good terms for themselves, but the vast majority of that stage is simply how silver your tongue is. Why should you be paid better because you got a better charisma roll with the interviewer? I would want my coworkers to be paid the same as me for the same experience. A senior with 10 years in the field, naturally, would be paid much more.
It's strange you say developers can negotiate, when there've been quite a few layoffs as of late and we see plenty of stories of people having trouble staying in tech. Which is it? The only thing that can give you credible sway is learning rarer or more in-demand skills, and putting together projects that show you understand how to use them. And for how long will that last? A union is a lot harder to fight than an individual.
But yes, there are bad unions. If they're as bad as your alleged blue collar friends say, let's name them! Sometimes their politics or dues or seniority system sucks. Those systems deserve to be put on blast.
But strangely, no unions listed in your comment as bad.
I don't consider charisma very much because I connect it to dishonesty. If someone's put a lot of effort into coming across as charismatic, it means they have considerable skill in psychological and social manipulation. I would value that in a salesman, where it makes sense. Otherwise it's just masking 2.0.
The primary concerns in an interview should be "can you do the job" and "can we bear to work with you". The rest can be worked with.
Its not fun to lose your job, but that can be better than being stuck just getting by at a company where your work isnt appreciated.
A significant part of my personal code review process, is going back through my code, and factoring out complexity. It takes time and humility, but is very much, in my opinion, worth it.
Documenting my code is a trick that helps. When I am writing why I did something, I sometimes reflect, and say to myself "Didn't I just do this a few lines back?"
My code tends to be complex, by necessity, but it should be no more complex than absolutely needed.
A big, big tool for that, is OOP inheritance, which is considered "bad coder" smell, these days.
Is it? I’d agree that there’s increasing awareness of the limitations of OOP, and I’d agree that using inheritance excessively can be one of the limiting factors, but I don’t think I’ve ever personally seen anyone criticised or penalised for using inheritance appropriately.
I have run into folks that don't understand polymorphism. It seems that it is not even being taught.
Old Boomer Yells at Sky
One thing that geeks love doing, is telling other geeks they are bad at what they do. It gets a bit grating, but I’ve come to the realization that I need be true to myself, because it’s a losing proposition, hanging my self-respect on the opinions of others.
I do what I do, and get the results I get. I don’t spend much time, worrying about how I compare to others.
One of the benefits of working at the direction of my own muse.
That should make you even better equipped to design simple interfaces that require as little depth of understanding as possible from the next person.
Similarly I've happily spent my couple of years with functional purity and higher-level types in academic languages - function signatures sometimes orders of magnitude longer than the implementation itself - yet I dip into those depths only as necessary and try to keep my TypeScript interfaces as "stupid" as I can get away with without compromising on semantics. Enums are too fancy for me. I try to keep state at minimum but there's a 'let' every few thousand lines or so.
And all that venturing into lower-level concurrent C++, agent systems, parallel programming, erlang? You ain't gonna know about any of that looking at my concurrent Rust.
> One of the benefits of working at the direction of my own muse.
Oh, well, what I'm writing above is from the point of code meant for collaboration - either open source or professionally. If you're coding for yourself only, or in academia, by all means stop trying to please the crowd and start cranking out some poetry!
I write code that I want to see in a year.
You can see my documentation philosophy in this treatise: https://littlegreenviper.com/miscellany/leaving-a-legacy/
I’ve also seen composition go sideways too.
Sometimes it feels like nobody takes software engineering seriously anymore, if I’m being honest
I never warmed to that. In my experience, it resulted in unholy messes.
“Produce a procedure documentation” gets keyword fulfilled into “here is a document with some steps”, instead of “here is a procedure we wrote, used spelling and grammar checker upon [I’m still shocked so few take the few seconds to correct as they go], run through an automated editor, then iterated through random people from the user population until someone who never saw it before accomplishes the procedure without assistance”.
Some startups succeed because they’re forced into conscientiously thinking through these ramifications in just the right contexts because they’re so close to the coal face. It is also possible to overdo this in the wrong context and end up bikeshedding.
Not everywhere. I’ve casually suggested five big changes to the startup I’m currently working for that others ran with. I’m proud that my ideas even make sense, and my reward is that others come to me for leadership. I would get more glory if I had also carried them out. But I’d rather do the things that others can’t, than what shines the most.
> 2000 lines of code per week terrifies me... That's over 100K lines of code a year
That would be incredible (and scary). But productive people I’ve seen the contributor metrics for who write vastly more than they read, still have a number of deleted lines growing with their added lines in some proportion.
There is a style of less re-use, more copy-pasting that just grows faster but also needs constant refactoring in trivial ways.
I've got a colleague like that. It's all good and management praises him, but this is a time ticking bomb. When he leaves, someone will have to maintain that code.
Or I could elaborate, expound, simplify, and expand my solution.
It depends what I’m getting paid for.
If I’m getting paid for lines of code, guess who’s going to re-implement functions that could have been a single line of code?
Why bother writing a loop function when I could just copy-paste the same code as many times as needed?
Turning one line of code into 3,000 - easy.
Turning 1,000 lines into 100 - that’s when you know you’re working with a professional.
When a market is competitive, the things that matter are roughly: hard work, candlepower, and optics/neurotypicality/maneuver in that order.
When a market is fairly sewn up that order becomes roughly: optics, candlepower, ethical flexibility, hard work in that order.
The hard-ass nerds who don’t give a shit about corporate culture du jour are treated like royalty when someone might fuck your business up.
While “purged” is a strong word, I take your meaning, and whatever we want to call it, it happens when competition is largely pro-forma.
Human beings will do anything to avoid selecting on merit except lose. That’s just human nature. Being mad about it is like yelling at the wind, but compared to even a decade ago, I’m not sure how high I’d be holding my head in today’s competitive landscape for high-prestige achievement.
'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.