Hacker News Reader

Comment by vfc1 | Hacker News Reader

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.

View on HN

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.

> never writing multi-threaded applications

Did he suggest an alternative ?

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

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

Technically correct is the best kind of correct ;-)

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.

> 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).

Reply on news.ycombinator.com