Oh, they can read and listen fine enough; but they don't always have social tact or good English grammar. Improving these things is incidental to employing good project management: it often happens when you take a direct approach to stakeholder communication and project planning, but it's not strictly a prerequisite. Even then, much of that only entails improving the clarity and completeness of communication; while there are structural and informational improvements, grammatical improvements don't necessarily come along.

Consider for a moment an e-mail that claims there are problems, that things aren't working, and that people want things too much. Such an e-mail can communicate the situation in all its completeness as I've just done, with little to no information on the specifics, with fragments of one thought jumbled with fragments of another as the text races back and forth between different issues. Such an e-mail would be much better if it first grouped together each part of the problem and relayed these groups sequentially, and second included a complete explanation for each part of the problem. Even then, the e-mail may be one giant paragraph, loads of run-on sentences, fragments of thoughts, and so forth.

As a project manager, you might learn to interpret this, and then produce a better-formed document to pass on to the other stakeholders; you'll continue to receive hackneyed garbage from your engineers, who still communicate like brain-damaged gradeschoolers, and just deal with it.

In the same way, these people may not deal elegantly at all with human beings; I myself am a very logical, fact-driven person, and have such a problem. In my case, I prefer to look at a problem and produce a solution; however, responding to problems often entails pointing out some painful, annoying things that people are still sore over, in the process highlighting all of their recent personal failures and generally shoving these things back in their faces while showing them how much better and more intelligent you are than they. I've found it more effective to separate out the case study and describe a solution, theoretical risks, and justification from the broad field of my work, allowing them to make the implications themselves and offering to provide the case studies if they need some specific concerns to raise to upper management. After rolling the ideas around and discussing them, the sting of failure is anesthetized, and they're far less hurt by the reminder now that they feel some control over the situation.

Of course, either approach I've described here is technically correct: I follow the same analytic process and deliver the same results regardless. I've learned to apply some consideration of complex human interactions when delivering those results, which is a whole different concern from my hard technical skills. I have said many times that there are no super brains: genius is technique, and I was born with the same capacity as everyone around me; this, too, is technique, and anyone can learn, as I have to only a small degree yet, to interact better with people just as well as they can learn grammar, computer programming, or quantum physics. As I've also come to understand lately, such skills are critical for success in the workplace.

People with STEM degrees tend to be more affluent, thus more articulate, than poor, inner-city negroes who nobody likes anyway. They can pass an interview at Burger King better than a fourth-generation-welfare black kid. If we fixed our school systems--if we adjusted schools in our poorest cities to attend to the needs of the poverty-stricken minorities they service--such individuals would grow up poor and without a college education, but articulate, sociable, and on the same footing as middle-class engineers when they walk into the local WalMart looking for a job.

Speaking, writing, organizing your office memos, dealing skillfully with people. These are called soft skills, and are humanities. Humanities include linguistics, social sciences, communications studies, and even law. A lawyer goes to a specialized school and then apprentices for years in nearly a decade of study entirely in humanities; diplomats, politicians, and business executives make a critical study of humanities to learn to negotiate and to speak in public; teachers go to college to study humanities, learning how to interact with children and parents. These are all studies in humanities.

Everything organized has some method of organization. People talk about schemaless documents, but they arrange them into related collections which carry some common features.

Popular computing languages do not in general have only one Open Source implementation, and do not get abandoned.

Yeah I work with technical people. 99% of them are moronic, drooling fuckups who somehow secured themselves a job without being able to construct a clear sentence. Somehow, they're able to do complex things in databases and write architecturally demanding software, even though they communicate like brain-damaged teenagers high on some unholy concoction of mind-altering substances.

I thought this would be a similar economic argument: 74% of STEM majors don't work in STEM fields, but instead in services (fast food), retail, social services (trashmen) or as aids running papers back and forth. I've made such arguments to illustrate why we need to dismantle the government's activities in post-K-12 education and leave workforce building up to the market, using this STEM market glut as a prime example.

They made a more humanizing argument which I can't disagree with. Both arguments are quite valid: the ability to deal with people, to write well, to communicate, to create, these are also important job skills.

The solution developed on top of MySQL started about 11 years prior to our switching from MongoDB. It never worked. It changed hands to a new rockstar developer who, over 14 more months, rewrote the code in 1/3 as many lines and got it semi-working, but it was academic: it could perform the task, but it was slow and clunky and impossible to maintain as a code base. When I installed MongoDB, they spent a month looking at it, and had a working prototype in 6 weeks; 2 months later, they released two entire new projects built on MongoDB to address both the things the first, failed project tried to address and an entirely new requirement.

MongoDB was considered fresh and new around version 2.2, still. It was being talked about and criticized even though 2.2 was deep into its maturity. Similarly, Linux was considered a new product around version 2.4; it was in production in version 2.2, and RedHat was happily chugging along, but it wasn't a cultural revolution in the IT industry until later than that. Scarcely before MongoDB, there was CouchDB and CouchBase, which most people are only aware of academically.

I jumped on MongoDB when it was this thing that some people had leveraged successfully and most people believed was a brand new fad that would go away just like everything else that tried to replace SQL over the past 20 years. MongoDB doesn't replace SQL; it does something different.

In a year's time, we moved from a dev team of 2 and SVN to a dev team of 4 and Git; we moved from raw SQL to ORM; and we incorporated MongoDB into our applications where appropriate. We also moved onto a cluster system with GFS2, which was successful, but badly mishandled: I didn't want the security implications of logging into the internal LAN's vmware vSphere management panel from internet-facing Web servers, and management didn't want to build a DMZ VMware farm, so we used sanlock fencing. Never use sanlock fencing. If we had built the cluster properly, it would have been a reverberating success capable of handling all kinds of disruption without the slightest hitch. I made all the correct assessments, but we decided as a business to go about it the wrong way; I conceded, and my lack of knowledge prevented me from predicting just how bad these concessions would be.

Three huge steps forward, three huge gains. One other huge step forward, done in ways recommended against, with good gains, but with growing pains; and even that moderate failure was both still a major success and readily avoidable in foresight, with the nebulous problem of "this could cause additional issues in some unknown situations" being correct, if unspecific. I know about black swans, I knew they were out there, didn't know what they looked like, but knew how to avoid them; unfortunately, I didn't take the steps to avoid them, and found out what they look like.

They've found a correlation between poverty and small brain size, but it's a complex issue that's not as simple as money or food or whatnot causing a small brain. You have a point about nutrition, and that's an important consideration going forward; it is unfortunate that we can't solve this readily, but it's a good consideration to make.

Still, nutrition is only one small part of it. The brain isn't a muscle: you don't get stronger at math by flexing your math brain parts; you only get better at the particular techniques in use for the mode of math you're studying, and can thus apply those techniques to similar problems. Even so, the brain changes dramatically in structure during learning: people who learn to navigate cities for a living (e.g. black car taxi cab drivers) show a 7% growth in their anterior hippocampi, as they learn to use visualization more effectively. They don't magically gain a better memory, but they do find it easier to visualize and internally inspect things using their spatial reasoning, which forms the basis of techniques to remember all kinds of facts and figures and places.

Poverty is correlated with not learning, which is a direct cause of a smaller brain: by not learning, you don't use the parts of your brain that execute important reasoning and memory tasks; this in turn causes those parts to stay smaller. We know, as well, that poverty is correlated with certain social atmospheres which make learning more difficult. A small child in a poverty-stricken family will face more social pressure, as the social imperative is the natural survival behavior for humans: unable to hunt and gather effectively, humans form communities to hunt and gather more effectively, bringing down large animals to feed the group; one deer can feed twenty people, so you only need an average of one deer every twenty days per person to feed the group. To use less esoteric, more factually reliable arguments, impoverished children suffer from a loss of feeling of importance, and focus more on peer pressure to adapt to a social need and justify their marginal lives.

The larger part of the solution would be to adjust the education system for poverty-stricken communities. We should focus more on bringing children in an impoverished community together in the classroom, granting them a feeling of importance directly beneficial to their educational performance. Early grade school should encourage impoverished children to work together toward goals, to make friends in the pursuit of things they can be proud of, and to guide themselves through a variety of activities all able to serve similar educational needs. While this may create some small gaps in education, it will maximize the breadth of intellectual skills these children develop: we might not be able to teach them an exact, consistent set of memory, mathematical, and social skills, but we can improve their feeling of self-worth and of community while conveying at least some. A middle-class district might get a head start on these impoverished children, but the difference won't be mere success versus failure.

Unfortunately, I have little answer for that. I know the tools and techniques to teach, but I don't know much about managing a room full of school children; I can't structure an educational system for this purpose, although I know what would go into it. I know how to solve poverty absolutely, but that's of little use in this context; simply guaranteeing every American gets the basic needs of food, shelter, clean clothes and personal hygiene, and the like won't eliminate the hierarchical nature of our society, and will still leave people struggling at the bottom, even if all those at the bottom are readily surviving and under no immanent threat of starvation and homelessness. In any realistic society, the problem of social pressure within the communities of the poor will always have such implications as must be addressed as I have said; I have not solved that problem, but I would like to.

Development with a proprietary language is ultimately harmful to your own interests, whether you make proprietary software for a profit or Free software.

The one thing every business needs is control. When you make it possible for another company to block your business, you lose control. Your options become limited. Solving business problems potentially becomes very costly, involving a complete rewrite.

The one thing that should be abundantly clear to everyone by now is that making your business dependent on Microsoft anything is ultimately a losing proposition. They have a long history of deprecating their own products after customers have built products upon them.

All Open Source licenses come with an implicit patent grant, it's an exhaustion doctrine in equitable law.

The problem is not patent holders who contribute to the code, you're protected from them. It's trolls who make no contribution and then sue.

Of course these same trolls sue regarding proprietary code as well.

The article is meaningless bullshit.

I evaluate things I use. When MongoDB came out, I told our dev manager we should use it because we are storing flexible, complex data in MySQL and that's just not a good fit. Document stores are better, and MongoDB with acknowledged write mode in a 3-node replica set has roughly the same data consistency guarantees as PostgreSQL with a replicated WAL in the common async mode (there's a small window where the slave server may crash, and the master server may also immediately crash, and the very last few milliseconds of transactions are lost; on MongoDB, the same happens if the first replica node acks an update, the update never reaches the second replica node, and the first replica and the current primary crash immediately).

At the time, we were handling schemaless documents by creating tables in MySQL with rows that described other tables, and using incremental joins to assemble fields from hundreds of tables together to select individual documents. What is a single document collection and a quick find() in MongoDB is any combination of dozens or hundreds of tables in MySQL, accessed with complicated aggregation logic to select information about these tables and then select and join together data from them to build one document at a time. MySQL wasn't intended to store documents consisting of a number of standard fields followed by arbitrary structures of searchable, user-defined fields; MongoDB was.

The article suggests using these types of psychotic schemas in MySQL to avoid innovating by taking MongoDB up. It suggests using Apache and built-in CGI rather than nginx and an external application (WSGI+python, a Perl CGI application manager, php5-fpm, etc.). It suggests sticking to Perl or PHP instead of Python and Cherrypy. It suggests, by extension backwards, sticking to IIS5 instead of moving on to IIS6 or a Linux server.

The article ludicrously suggests not even evaluating new tools and using those which make your work better, faster, lower-risk, more consistent, less likely to fuck off in your face; it recommends you run scared from all the new things. Maybe you should learn risk management and get a good enough handle on your technical and business needs to evaluate new technology and decide which you can use effectively and which you should hold back on.

You'll buy a video, or buy a product with videos; you'll then hate the video and the product, but you'll take a hell of a lot more notice of that particular product or educational course. Dramatizing your persuasive argument--"Buy my course because fucking awesome video with explosions"--is one of the most effective ways to obtain buy-in.

I would say that good code is code that's as simple as possible for its task.

Get off'n my lawn you young punk!

We snuck into the school at night, typed the programs from magazines into a TTY printer terminal in my high school, that was connected to a mainframe at the local university. We didn't even have a monitor, all commands and results were printed on striped, continuous-feed printer paper.

And we got in trouble for it, too! The school got a bill for the mainframe time used. Or we WOULD have gotten in trouble if anyone knew it was us. As it was, the terminal got locked up at night after that. The 70's were the wild and wooly days of computalyzin'!

We should tell the businesses it's their responsibility to solve their own problems. If they can't find workers, then bring in eager young men and pay for their education.