5 ms·

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/eco

by vfc1 7y ago

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.

bitL 7y ago
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.
- dominotw 7y ago
  > never writing multi-threaded applications Did he suggest an alternative ?
  - bitL 7y ago
    Outside of "use something that is not multi-threaded" not.
- john_fushi 7y ago
  Just create child processes with a shared memory region. That's not multi-threading.
  - bitL 7y ago
    Technically correct is the best kind of correct ;-)
  - outworlder 7y ago
    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.
- qes 7y ago
  > 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?
  - bitL 7y ago
    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 ;-)
  - p0nce 7y ago
    It can work because when sleeping the only cost is literally the size of the stack (that you can set to a low value).
squeaky-clean 7y ago
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.
- redleader9345 7y ago
  Every job in corporate land has the person, at every level, who makes you ask "how is this person still here?"

by vfc1 7y ago

bitL 7y ago

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.

dominotw 7y ago
> never writing multi-threaded applications Did he suggest an alternative ?
- bitL 7y ago
  Outside of "use something that is not multi-threaded" not.
john_fushi 7y ago
Just create child processes with a shared memory region. That's not multi-threading.
- bitL 7y ago
  Technically correct is the best kind of correct ;-)
- outworlder 7y ago
  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.
qes 7y ago
> 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?
- bitL 7y ago
  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 ;-)
- p0nce 7y ago
  It can work because when sleeping the only cost is literally the size of the stack (that you can set to a low value).

squeaky-clean 7y ago

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.

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