Having listened to those two I do have to concur.
Those two are prime examples of a first class moron. Homicidal morons, which is the only thing that truly distinguished them. They didn't have one coherent original thought between them. And they spoke in macros like lolcats. They even botched that. For the first time you get to hear them speak themselves. If you ever wondered what kind of moron falls for hate rhetoric, look no further.
Consider this proposition: We'll give you this belt loaded with explosives. For free. All we ask of you is that you put it on and release this button when we tell you. If you would please just go over there. A bit further. Further still. Yes, yes, paradise will be awesome.

In many ways they remind me of those two middle-class schoolboys who blew up the Boston marathon out of a vague feeling of disappointment with the American Dream. The younger ran over his brother while making a dash for it with his car.
Terrorist is too big a word for them. They are homicidal idiots and that's what they are. There's a difference between spending years in preparation and practice like the 9/11 guys did. It only takes a sick mind and a special brand of idiocy to attack somebody with knives.
What's really sad is that those two morons triggered other morons to attack people who had nothing to do with them employing the same impeccable logic that triggered that attack on that Sikh temple because they obviously were hate-mongering muslims.

It's like a big circle-jerk that didn't quite happen because the participants couldn't find each others dicks.

You may choose to feel terrorized but I will stick with contempt and disgust.

...and Sega before that.

I wonder if they know that those generated sales if the game wasn't too bad. It might even be legally justified. But a smart move this isn't.

Well. I don't. I'm running a Chrome plugin that replaces the word "cloud" with "butt". Makes a lot more sense that way.

Well, the application container has a separate thread per running request. So that's why you keep your resources thread local. While it is true that in most cases requests aren't served concurrently you still have to program like they were. Thankfully you only have to watch shared resources. But one fool with statically defined variables can seriously rain on your parade.

The submitter has no power. No influence. Which is good since he also might not have a clue. If he had one then he'd know that this is a management issue.

I also doubt most of what is written in the blurb. Multithreading is a non-issue in most business software since we spent the past 20 years to make sure we don't have to fuck that particular beehive ever again. The only place where you need this skill is either on a systems level where you wouldn't have survived into an old age if you didn't know anything about it in the first place. Also who has not ever fucked up a VCS commit?

I either call BS or beehive fucker on this one.


Sorry for being so drastic but I had to deal with that kind of attitude when on of my new hires thought he knew everything best and started to fuck with one of my most experienced guys. I offered him to go with the program or simply go. So he went. Last I heard he quit his new job after 6 months. I smell the same kind of BS right here. Same stench.

...and this is why a lot of working environments are what they are. What you describe is a reign of terror that is unable to hold on to good people, ensure they stay valuable and will have a high fluctuation. A fucked company. With no management competence whatsoever.

Thankfully I feel quite safe in my assumption that you are not currently holding a management position.

Yup. It is. There have been books written about this but they only seem to be read by techs. Too little MBA mumbo-jumbo and too much common sense.

Michael Lopp has described this as The Fez. Rands in Repose is an awesome blog and his book is also quite nice.
http://www.randsinrepose.com/archives/2005/01/24/avoiding_the_fez.html

Joel Spolsky also had a few run-ins with having to manage while being tech.

Technology is transient. Methodology isn't.

The most useful skill is an understanding how to achieve what. If you can do it in one language you can do it in all. Language is syntax and that's it. APIs have documentation(or you shouldn't use them). I've not seen anything truly new in the past 20 years. Only old concepts with a new name. Or combinations of old concepts.

I once got asked what this "cloud" thing actually was. I told them that it's some server somewhere that you bet the farm on that it is maintained and available without being able to check. Cloud = server + blind faith. If you explain it like that then nobody is really that interested. Bring on the next buzzword. And it better not be "Message-Oriented Middleware" or "Software As A Service" or anything like that.

Well, if you don't know how the VM works then you are pretty limited in what you can achieve. While I would generally agree with you that understanding computers is beneficial I don't believe you have to have done a lot of C. Uphill, Through the snow. Both ways. That's how we synchronized our shared memory in the olden days.

Anecdote time:
When i was a newbie I had a project lead on a project that involved communication between a Java client and a C server. My project lead insisted that simply opening a socket and go with the protocol we should talk to the server by RMI. So far so bad. The server guys wrote an RMI component that translated it to their protocol.
Then our project lead went ahead and said that we should only exchange Strings. And since that wasn't insane enough he insisted that we encapsulated our data within XML.
So what we had was XML in Strings over RMI. Because connecting to a port was too difficult. When he got demoted I didn't get his job because I had "rocked the boat". In retrospect I have to be thankful for that. By then the team was deeply dysfunctional and started baaing like sheep. The customer was somewhat impatient due to a 1 year project overrun. The vendor of the server wanted to sue. And our management was confused what the problem was. You are truly fucked when your management sends in the mediators. I still stuck with them for 3 further years and learned a lot about management. And hiring tech. A career building failure, so to speak.

Yeah, we use immutable objects a lot. Either you are threadsafe by design or you aren't threadsafe at all. There is no retrofitting.

That is a relatively recent addition. I think they went with Doug Lea's concurrency package. For the first 10 years of Java's existence there was very little to help encapsulate concurrency. IIRC worker threads didn't even exist in 1.2 when they introduced Swing.

Database connections and concurrency are things I do not trust APIs with unless they are very well documented. In case of threads I bloody well need to know where the locks are so I can think it through. Deadlocks are ugly. Also concurrency is a technology independant concept. While there is a way to handle it in Java, the techniques are the same everywhere. Although it does help that the support within the language(not only in the API) is quite good.

...also these are processes. You only need to synchronize on shared resources. Assuming the OS doesn't already do it for you.

Nothing to feel stupid about and you did exactly the right thing.

That's the learning process. And that's why experience is so valuable.