Hacker News new | past | comments | ask | show | jobs | submit login

> a clueless middle manager who has never coded the simplest of programs in his/her life.

I've never had manager who hasn't coded ever in his life. WhatI had most of the time was a manager who hasn't coded in a longtime.

I've had both, and I don't know what is worst to tell you the truth. The ones who have coded a long time ago think that their experience in another language/ecosystem still allows them to estimate tasks in a completely different environment, when in fact it doesn't.

The non-technical manager will focus more on the business side and will be easier to manage in many situations, but the problem is that that type fo manager will neglect tasks that are purely linked to technical debt, refactoring etc that don't add new functionality to the system but are still really important.

I've had both as well as in my opinion the worst: The manager who pretends they can code and knows just enough to be able to trick HR and other managers.

It's only happened to me once, but the guy was pretending to be a past Java expert and didn't know the difference between Java and Javascript. I don't mean we grilled him on the differences in syntax. I mean in conversation he would use "java-script" to mean a Java source file, and said he had experience with Java frameworks like jQuery and Angular. Don't know how he expected to fool any developers, but he actually kept the job longer than I expected, even with people calling him out as fake.

Every job in corporate land has the person, at every level, who makes you ask "how is this person still here?"

I had a manager with a PhD who insisted on never writing multi-threaded applications because when he tried he failed and considered them dangerous. I routinely wrote apps using 10,000+ threads before. Now he is a head of development of some company. Real life is a comedy.

Just create child processes with a shared memory region. That's not multi-threading.

Hah, I've used the forking server approach very successfully before.

Plus, threads and processes are essentially the same on unix land – kernel flags will control behavior like shared memory. Which you can still setup manually. Or just use whatever IPC fancies you.

Technically correct is the best kind of correct ;-)

> I routinely wrote apps using 10,000+ threads before.

Running on how many CPU cores? Were you writing code for a supercomputing cluster? Otherwise for what kind of system could 10,000 threads possibly be an ok strategy?

Bunch of natively 256-thread CPUs, distributed enterprise messaging system (TIBCO-style) in Java (before NIO). It was normal to have 60,000 threads/machine, just debugging was a bit weird. Whole London, Frankfurt and NYC trading was running on the same or similar systems.

Can't wait for 64-core Threadripper to have something similar at home in a little box ;-)

It can work because when sleeping the only cost is literally the size of the stack (that you can set to a low value).

> never writing multi-threaded applications

Did he suggest an alternative ?

Outside of "use something that is not multi-threaded" not.

Putt's Law: "Technology is dominated by two types of people, those who understand what they do not manage and those who manage what they do not understand."

Putt's Corollary: "Every technical hierarchy, in time, develops a competence inversion." with incompetence being "flushed out of the lower levels" of a technocratic hierarchy, ensuring that technically competent people remain directly in charge of the actual technology while those without technical competence move into management.


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact