Hacker News Reader

Comment by quanticle | Hacker News Reader

    It’s perfectly possible for someone who still performs surgery to play a
    decisive role in how a hospital is run. Or for someone who still represents
    clients in court to be a big cheese in a law practice.

I'm not sure that's the case. A good counterexample is the Manhattan Program. Sure, Oppenheimer was a great physicist. But was he as good as, e.g. Teller, Fermi, Feynman, Szilard, Von Neumann, etc? No, he was not. He knew enough physics to keep up with the geniuses, and, more importantly be respected by them. But he wasn't working day-to-day on the atomic bomb. His job was to oversee the program and distill its status into reports for the Army, so that external stakeholders would continue funding this enormously expensive project.

Similarly, I'm not sure it's a good idea to have your best programmers also be managers. They're too valuable to pull away from day-to-day involvement with the code. Instead it might be better to select programmers who are good (but not necessarily great) at coding, but also display strong organizational and communications skills.

View on HN

> It’s perfectly possible for someone who still performs surgery to play a decisive role in how a hospital is run. Or for someone who still represents clients in court to be a big cheese in a law practice.

It is, but it has to be on their terms. I am currently doing more than one job, not on my own terms and I am ... not happy.

I cannot do either job with the level of quality I expect from myself. And I would be good at either of those jobs alone. The context switches cost energy. The timetables are in fight with each other. One job demands from me to be free for whatever comes the other demands to plan ahead for years. How can I be free for what coems through my door if I have crumbling infrastructure I should be maintaining at any given point in time? I have to essentially either do it on a day by day basis, or I have to sacrifice something.

Sure go ahead give your employees two jobs. Hell give them three. But please spend 10 minutes figuring out if these jobs are actually compatible with each other and if you can live with the friction losses between them. You expect to get the results of 1/n employees on each job, but you might end up getting less than that for real, unsolveable reasons.

And for some reason managers always pull shit like that, when what would actually be needed is n seperate people doing the job and then they go all [surprised_pikachu.jpg] when that one employee quits and everything goes to shit, because they had no time documenting what they did.

Just treat your good people well and let them do good work. If you have their good will and you treat them well, they will produce better work than if you threaten them into accepting terms that save you a bit in the short term but destroy you in the long term.

While I can't speak from first hand experience of juggling programming and management jobs, I've observed the same problem in my part-time team leads to believe what you say is true.

I'd like to add yet another aspect you didn't mention:

I've had a couple of experiences in very dynamic work situations where every developer is juggling multiple development jobs at once. If those aren't very well managed (which I've never seen done), the individual jobs/projects will immediately cannibalize each other: The thing that's the most critical right now gets way more attention than anything else, which causes those other things to go unattended for too long, which increases the risk of them becoming critical in turn (either through errors because of rush jobs or because of arbitrary deadlines coming up). The result is constant firefighting.

The thing is that juggling management and development jobs basically looks like asking for that to happen (at least to me). Most important "management issues" are more impactful than the development job (especially when done as a rush job) and in my opinion even less likely to be plannable/mechanical in nature. This means that it's even likelier that some tasks will cannibalize the amount of attention others get by themselves and it's never going to be a simple 1/n calculation. And if you maintain that you could reach that kind of multitasking nirvana anyway with enough iron discipline, I'd argue that this discipline should be considered a large multiplying factor of the context switching costs involved.

Yeah, the last thing you want as a patient is ending up under the knife of one of those “still performs surgery" managers. They often do so not because they are actually still good at it, but because they see it as a status thing and nobody can stop them.

This is very true. I've been in the same position and eventually I just burned out.

If you think a programmer can become a manager, you can guide them, but can't force them to become your vision of a manager. The reason they can be a good manager is because they know more than you.

This, of course, requires a certain level of humility from the upper management, which they usually don't have.

> It is, but it has to be on their terms.

It's exactly this. Everyone wants the long term productivity and quality boost of combining roles, but not all necessarily understand or want to pay the cost. Improving efficiency is just another way to grow a business beyond mere sales.

Any organizational change would incur some initial failures, missed deadlines, etc. The friction you're describing doesn't last forever.

Certainly some roles are easier to combine than others. It shouldn't be a huge risk in the grand scheme of things, but more places really should try to give the devs the bigger picture and loosen the reins a bit instead of being afraid of scaring them off. I personally think having the "unsolvable" in your hands is exactly where you always want to be in a career.

> A good counterexample is the Manhattan Program. Sure, Oppenheimer was a great physicist. But was he as good as, e.g. Teller, Fermi, Feynman, Szilard, Von Neumann, etc? No, he was not.

All I know about this is what I read in Richard Rhodes' The Making of the Atomic Bomb but....the impression I got from the book was that Oppenheimer was probably as good as most of those but that he never achieved quite the same level of academic fame due to a combination of continually shifting interests (i.e. never staying on thing long enough to go deep enough to become "the guy" for that thing) and losing a huge chunk of his most productive years focusing on being a manager.

Luis Alvarez said of Oppenheimer "It was amazing to see how rapidly his mind worked, and he came to the right conclusions"

Alvarez also "believes Oppenheimer would have won a Nobel Prize for his astrophysical work if he had lived long enough to see his predictions concerning exotic stellar objects—neutron stars, black holes—confirmed, as they have been, by discovery."

Segre called him "the fastest thinker I’ve ever met,” with “an iron memory . . . brilliance and solid merits"

Bethe compared Teller and Oppenheimer "fundamentally . . . very similar. Teller had an extremely quick understanding of things, so did Oppenheimer. . . . They were also somewhat alike in that their actual production, their scientific publications, did not measure up in any way to their capacity. I think Teller’s mental capacity is very high, and so was Oppenheimer’s but, on the other hand, their papers, while they included some very good ones, never reached really the top standards. Neither of them ever came up to the Nobel Prize level. I think you just cannot get to that level unless you are somewhat introverted"

I also have a vague understanding of an anecdote from the book of someone saying that whenever anyone talked about their work on the Manhattan Project, Oppenheimer always showed an astonishing depth of understanding but I can't find a reference to it.

The reference I was looking for is included in full in another comment[1]

Hans Bethe (who won a Nobel Prize in 1967) said, among other things,

"There was just nobody else in that laboratory who came even close to him"

[1]: https://news.ycombinator.com/item?id=34117168

> Sure, Oppenheimer was a great physicist. But was he as good as, e.g. Teller, Fermi, Feynman, Szilard, Von Neumann, etc? No, he was not.

In the documentary The Day After Trinity there’s an interview with physicist Hans Albrecht Bethe who worked on the Manhattan project and later won a Nobel prize. Oppenheimer’s cognitive abilities are briefly discussed, and Bethe says something like “It quickly became obvious that he was intellectually superior to us.”

It’s also noteworthy that Oppenheimer learnt Sanskrit, just so that he could read Bhagavad Gita in the original language.

So I think he could hold his own, even against those other geniuses.

Your (almost) quote helped me find the thing I was trying to remember in my sibling comment

https://news.ycombinator.com/reply?id=34115186&goto=item%3Fi...

With your quote helping, the reference from the book is:

Robert Oppenheimer oversaw all this activity with self-evident competence and an outward composure that almost everyone came to depend upon. “Oppenheimer was probably the best lab director I have ever seen,” Teller repeats, “because of the great mobility of his mind, because of his successful effort to know about practically everything important invented in the laboratory, and also because of his unusual psychological insight into other people which, in the company of physicists, was very much the exception.”

“He knew and understood everything that went on in the laboratory,” Bethe concurs, “whether it was chemistry or theoretical physics or machine shop. He could keep it all in his head and coordinate it. It was clear also at Los Alamos that he was intellectually superior to us.”

The Theoretical Division leader elaborates:

He understood immediately when he heard anything, and fitted it into the general scheme of things and drew the right conclusions. There was just nobody else in that laboratory who came even close to him. In his knowledge. There was human warmth as well. Everybody certainly had the impression that Oppenheimer cared what each particular person was doing. In talking to someone he made it clear that that person’s work was important for the success of the whole project. I don’t remember any occasion at Los Alamos in which he was nasty to any person, whereas before and after the war he was often that way. At Los Alamos he didn’t make anybody feel inferior, not anybody.

Yes, it's like people have completely forgotten, or maybe never heard of, the Peter Principle.

https://en.wikipedia.org/wiki/Peter_principle

> The Peter principle is a concept in management developed by Laurence J. Peter, which observes that people in a hierarchy tend to rise to "a level of respective incompetence": employees are promoted based on their success in previous jobs until they reach a level at which they are no longer competent, as skills in one job do not necessarily translate to another.[1]

The concept was explained in the 1969 book The Peter Principle (William Morrow and Company) by Laurence Peter and Raymond Hull.[2] (Hull wrote the text, based on Peter's research.) Peter and Hull intended the book to be satire,[3] but it became popular as it was seen to make a serious point about the shortcomings of how people are promoted within hierarchical organizations. The Peter Principle has since been the subject of much commentary and research. Co

Yeah that's kinda my take too. A good manager should have enough knowledge to understand the field and be respected, but that's it. Putting your best technical person in this job would probably be a waste:

- excellent biologists, physicists, computer scientists and so on, are rare. You should put them where they can yield the best results. Same for people with managerial qualities.

- managing may requires qualities that are in conflict with excellence in a field. Juggling projects, building relationships or the will to play some political/administrative game may be very useful for a manager, but not necessary something an excellent developer or a surgeon would have maxed out as a skill.

Well, let’s add that most of the projects are boring CRUD apps. They have a few pain points and over a long time will need novel extensions, but their base is basically LEGOd together, hardly comparable to the Manhattan project of CS which would be something like a high-performance JIT compiler, database, etc.

Even though most commercial programming work is trivial (in the sense Math professors use the term) it doesn't mean you don't need excellent programmers (or that at least some of your programmers are excellent).

All of us who worked as developers for a few years have seen the seemingly trivial program be incredibly difficult to support/extend/fix/debug (especially after being in production for a few years). At the beginning of my career I thought this was circumstantial but having been doing this for a living for 20 years now this is common and I keep seeing this pattern over and over again - not so great programmers will easily manage to make your "trivial" program very much not trivial to continue developing.

Sure, I agree (to the point where I sometimes question the need for cheap, not so great programmers at all). But even those great senior developers can on average only dream about being the next Von Neumann :D

It's really not that easy a problem to solve and sometimes the suboptimal solution seems better than the alternative (which would be to hire nobody until we find a good senior developer).

Despite the fears of over-abundance of programmers driving down wages being around at least since I've started working, there is a shortage of good senior programmers. A lot of companies (many non-tech) need programmers these days, most programmers are not that great, most work is not that exciting but it still needs to get done. So it's also often not even about the cost of programmers but about their availability (for the price you can pay).

Let's say you're running the internal software department at ACME Insurance and Customer Care Services in your average big-but-not-major Western European or North American city. You need programmers to develop and maintain your creaky Java Enterprise Edition + Oracle DB internal system that has been appropriately handling your insurance and customer care services needs for the last 18 years.

At this point centuries of developer-years have been spent on this system and it's crucial for €/$ millions or revenue yearly that your company depends on. You can't offer the kind of compensation, prestige or interesting projects that the local FAANG development offices can offer to easily recruit great senior developers. What do you do?

Ask why your senior leadership team cannot find a significant fraction of that ARR to spend on really high quality engineers?

How do you know it’s not significant? What if the company is making $5M in yearly revenue with 20% profit margin (so net income of $1M, remember most industries don’t have profit margins as high as software)?

I remind you in this case their main business is not even software, but insurance and customer care services (with the software there to support that).

They can’t/shouldn’t spend 40% of their profit margin ($400k/year) in matching facebook’s compensation for a top notch senior developer.

“Everything not impossible is trivial.” - Mathematics.

That said, yeah, it’s frustrating the percentage of code which simply doesn’t matter as long as it works at all.

Although the point about mediocre engineers making things way harder than they need to be gets exponentially worse as the decisions get earlier in the process. So many times you look at implementing something and ask yourself why we’re even doing this at all.

Let’s not forget half the programmers working today are below average. So CRUD programs are fine when created and maintained for years to decades by people in the middle of the bell curve. But everyone’s going to touch code created by terrible programmers, if nothing else when they are getting started.

The only real option for most projects to improve quality is simply keeping the same team members for a several years as they improve. This does get increasingly expensive over time, so few companies try that hard to maintain people yet the world stumbles along.

The thing I notice the most is with juniors out of school: some of them have masters degree, but they are really disoriented when put on the job. Program might be trivial, but the ability to work is not taught in school, so there is all of that to learn

I’d up the ante on the “Manhattan Project of CS”. It’d have to be something that was theoretically possible, but never done before. Like a quantum computer that actually works, say, not the toy implementations they’ve built to date.

I wouldn’t put quantum computers at the forefront of CS, at most it is an intersection between several fields. CS is much more theoretical than engineering.

The Manhattan project wasn't exactly pure theory.

Fair: CS is a poor analogy. But yeah, Manhattan involved more disciplines than just applied nuclear physics. There was applied chemistry, for example, to purify the isotopes. And von Neumann, Feynman, et. al. had to engineer purpose-built computers for brute-forcing all the differential calculus. And obviously, geology and metallurgy, to find and forge the U and Pu, had to be involved too.

"most of the projects are boring CRUD apps". This is often repeated but to me it indicates that something is wrong. As soon as it is boring, it no longer is programming. If they are so boring why isn't it just done by a configuration file that anyone could type?

Well, to a degree it is done by a configuration file, it’s just written in the DSL of a big framework like spring. Like, most of the code is just declaratively specifying what should happen, not really the how. Add a few filter/mapping and you are ready.

That configuration file would be, in the best reasonable case, isomorphic to the boring parts of programming and, in the more likely case, worse than programming with a general purpose language and the associated tooling ecosystem.

The trick is that usually what you require is boilerplate until you don't need boilerplate, where the "not boilerplate" parts are hard to predict ahead of time, and configuration files are pretty bad at this as it's usually difficult to "break out" of the configuration.

Very high level frameworks like Rails are probably a better fit for this where you can write simple operations extremely easily, but it's still all just code that can be customized when you need to make small tweaks.

Configuration files are code files. It's just that the code is at a much higher level of abstraction, and, usually, domain-specific.

Now, what would be the cost of maintaining a domain-specific compiler and its tooling on top of the configuration files?

That's true for most abstractions, btw. When you abstract something, you now need to maintain both the abstraction and the code using the abstraction.

Most of it is actually less boring than the saying seems to imply if you choose to actually look at the problem in a complete full stack manner.

The issue is that much of it needs a craftsman not a scientist or engineer. Virtually all of the value I have added to software in my career has involved doing the equivalent of a "This old house" renovation and bringing things up to code.

I go in and untangle years of small hacks so that the data path is clear and special cases happen in the same place. I get things onto boring technology rather than bleeding edge or high availability stuff. Most mid-size companies, even serving the enterprise don't need "scalability" in the sense that Google does or a startup hopes for.

I definitely not meant “boring” in a negative way, maybe “not-novel” would have been a better expression.

There is great value (both personal satisfaction, and even more business) in “renovating”. Of course it depends on the project at hand.

The challenges with most modern software are more long-term maintenance, extensibility and quality vs. actual hard engineering problems, but that doesn't mean that those problems are boring or trivial, as evidenced by the unmaintainable mess that many codebases are.

yep. I get paid very well to manage teams who essentially assemble IKEA furniture ... but with code.

If I want interesting problems, I have a computer at home.

One of my best buddies is a machinist, he sets up the exact same dozen or so CAM jobs every day. He and I both do 3d-printing for fun at home specifically to challenge ourselves!

Nowhere on that phrase he says the person will manage daily communication, or team coordination.

It's perfectly possible for technical people to work on decision making too. In fact, the idea of specializing decision making into a group that does none of the technical work is absolutely stupid.

The practice of having most 'final' decision making at some SVP level is stupid on its face. I can see a need for tie breaking between two teams, but the person who spends 4 hours a year thinking about a project needs to butt out generally.

Actually Oppenheimer was in the same league as the others during his pre-manhattan careers, and have several equations named after him

This is short term thinking that leads to promoting the least competent, and it hasn’t worked well.

No, this is favoring competence at the skills necessary for a different role, rather than assuming competence at one set of skills extends to another.

You misread it, I think. The parent comment wrote "They're too valuable to pull away from day-to-day involvement." That's short-term thinking. Of course you should only hire people in roles that match their capabilities. Instead, the thought process behind the parent comment leads to "Who provides least value right now? Ok, bad luck he/she makes a bad manager."

Yea, the perverse incentives* of this culture can utterly destroy a company long-term.

(*) The better you do your job the lower your chances of promotion. Hard work and dedication becomes a road to serfdom.

I think your paraphrasing is inaccurate, they said

> Instead it might be better to select programmers who are good (but not necessarily great) at coding

Good but not great doesn’t mean they are the least valuable, it means they are competent or at worst average. This may be a good indicator that they would like to explore other forms of career advancement than mastering programming. You for sure shouldn’t just pick someone and make them a manager, you’d need to survey a few people or create an opening and take applications from interested parties. You also need to evaluate for competence and train them to become managers.

Beyond a pretty basic level, programmers don't get promoted into managers, they switch career into it.

That's not what my comment is about, at all.

Tell that to my two previous managers. They were more or less forced into a management role. One left, the other retired.

I used to think like this but as I've gotten older I've seen the value of transitioning into management. I had aspirations of going beyond staff but I don't think it'll happen in my lifetime. I've peaked, and the cycle of getting close to the next title, getting laid off, and getting put back down at the bottom of the current title is exhausting.

Your best engineers should produce value. It's often a good idea to have your best engineers (with the ability to manage) manage. They can train the next generation of best engineers and act essentially as coaches. That's a tremendous value-add that far exceeds the results one engineer can produce. As an additional benefit, if they're anything like me, not programming for 10 hours a day means programming becomes fun again in your personal time. I generally disagree with this concept of the "savant" programmer. In my decade+ of work I've seen quite a few of these. They're never as good as they seem and often more trouble than they're worth. If a programmer does not display strong organizational and communications skills they shouldn't be advancing beyond mid in any serious company. This type of person generally costs more than they're worth because you have to silo them for anything to get done. Not worth it. If such a "savant" can't develop the proper communication skills perhaps they'd be better in academia.

Who is left to do any actual programming in this model? Only the entry level? And who is to clean up their mistakes? Management?

You needn't have identified yourself as management, your myopia speaks for itself. My sympathy to your organization.

Reply on news.ycombinator.com