Using acronyms and abbreviations that come from the online subculture is acceptable in certain situations: IM with friends, twitter (where space is limited), and texting are three of them. An email to your boss, coworker, or a client is generally not.



Most people (but if my experience is worth anything, not even close to everyone) are fine in the area of not deliberately writing like that when communicating in some official capacity. So, in the "Me Rite Reel Nice" chapter of My Job Went To India, Chad Fowler focuses more on unintentional mistakes. He relates research that found

more than half of companies consider writing skills when making both hiring and promotion decisions. Forty percent of surveyed companies in the services sector said that a third or fewer of their new hires had the writing skills they desired.

Furthermore, Chad describes the necessity of knowing how to write well: As companies and teams move to a more distributed global model, much of your communication will be with the written word.

Unintentionally riting bad - fillng ur txt w/ speling and gramer mistakes can make you look sloppy, [im|a]mature, or even ignorant.

Sound like an easy way to stand out? See that red underline on the screen? That often indicates a spelling error. See if you can fix it. You wouldn't let that stand in your code would you? So why let it stand in your writing?

and making spaceships run away from you instead of seeking you out in Nebulus: Ozone Riders.



I even asked Glitch, Wes, and Jonathan (teammates on the project) to remind me of some simple vector math and draw it out on the wet erase board for Nebulus. And I still made them go the wrong direction (which ended up being pretty cool, actually).

In other words, I haven't had much experience with AI as it's typically implemented in games, and what little experience I have had is limited to things I wouldn't (personally) classify as AI to begin with.

Still, I have had some experience in what I might call "classical" AI (perhaps "academic" is a better term). Stuart Russell and Peter Norvig wrote the Microsoft of books on Artificial Intelligence (90% market share for AI textbooks), and I've read through a fair bit of it. I've implemented a couple of algorithms, but mostly I've just been introduced to concepts and skimmed the algorithms. In addition, I've been through Ethem Alpaydin's book, Introduction to Machine Learning, which would have comparatively fewer ideas applicable to games.

I guess what I'm trying to say is: although I have some knowledge of AI, consider the fact that Dave's experience dwarfs my own when I disagree with him here: It is precisely the fact that we don't have enough processing power that gets in the way of more realistic AI in our games. Or, put more accurately, the problems we're trying to solve are intractable, and we've yet to find ways to fake all of them.

I'm not convinced you can separate the failures of AI from the intractability of the problems, or the inability to design and implement a machine to run nondeterministic algorithms for those problems in NP.

Compared to deciding how to act in life, deciding how to act in Chess is infinitely more simple: there are a finite set of states, and if you had the time, you could plot each of the states and decide which move gets you the "closest" (for some definition of close) to where you'd like to be N moves from the decision point. Ideally N would get you to the end, but even for Chess, our ability is limited to look ahead only a small number of moves. Luckily for Deep Blue (and others), it turns out that's enough to beat the best humans in the world.

Even though Chess is a complex problem whose number of game states prevent us from modeling the entire thing and deciding it, we can cheat and model fewer states - when we can make an informed decision that a particular path of the decision tree will not be followed, we can forgo computation of those nodes. Still yet, the problem will be huge.

There are other ways of "faking" answers to the AI problems that face us in development. Approximation algorithms can get us close to the optimal solutions - but not necessarily all the way there. In these cases, we might notice the computer doing stupid things. We can tweak it - and we can make special case after special case when we notice undesired behavior. But we are limited in the balance between human-like and rational. Humans are not rational, but our programs (often) are made to be.

Presumably, they give the policeman in GTA 4 a series of inputs and a decision mechanism, and he's thinking purely rationally: so sometimes the most rational thing for him to do based on the decision model we gave him is to run around the front of the car when he's being shot at. Sometimes he jumps off buildings. (Video via Sharing the Sandbox: Can We Improve on GTA's Playmates?)



It may not be smart, but it is rational given the model we programmed.

You can make the decision model more complex, or you can program special cases. At some point, development time runs dry or computational complexity gets too high. Either way, game AI sucks because the problems we're trying to solve have huge lower bounds for time and space complexity, and that requires us to hack around it given the time and equipment we have available. The problems usually win that battle.

Game AI has come a long way since Pacman's cologne (or maybe he just stunk), and it will get better, especially as we move more gaming super-powerful servers. Still, it's far from ideal at the moment.

What do you have to say? (Especially the gamer geeks: programmers or players)

But when I'm done, I get to look back on it with a sense of accomplishment. It's an accomplishment that goes above and beyond the typical new feature or bug fix. That's what I'm doing now.

I was just working on an ordering system where the calculations in one file came out to be a couple of thousand lines of code. It was taking forever - like hacking through jungle with nothing but a dull machete. Most of the small changes I was making resulted in new bugs being introduced to the system. As the number of bugs increased, it started to feel like a jungle. After a while I gave up.

I gave up on my quick-n-dirty add-another-hack-to-a-bunch-of-hacks approach and decided it was time to do something positive for myself, the code, and future programmers who have to touch it.

Extract method (or in this case, extract-template) came to the rescue. Just by extracting related bits of functionality I was able to get the file into manageable, largely cohesive chunks. I didn't go to the extreme: I stopped when it was good enough, touching only those parts I was prepared to fix if I broke them, which meant limiting it to what I was doing there in the first place.

The code isn't incredible, but it's in better shape than it was before I went in. Now, the main calculation file is about 1200 lines, and the other 800 are broken out into different, cohesive files. Forget about reuse, this was just for literacy.

What did you do to improve your codebase today?

There are many ways to communicate - and you should practice them all. In the post linked to Raganwald above, Reg talks about physical communication (as opposed to virtual) and suggests volunteering to present in front of a group as a means to improve your communication skill. It's something I get some small practice with at school, and something which I'd like to eventually do more of in a professional capacity - but I've yet to take the time or show the cojones and actually do it, outside of what's been required of me.

Anyway, he covered it better than I will, so I'd suggest reading it over at his blog. I'll continue with the real point of this one, about not being a "grumpy old code ogre [whom] everyone fears" (Quoting Fowler, pg 125).

Managers and customers are

responsible for something gravely important which they ultimately have to trust to some scary IT guys for implementations... In this situation, what's the most important attribute they're looking for in a team member? ... It's not whether they've memorized the latest design patterns or how many programming languages they know.

They're going to be looking for someone who can make them comfortable about the project they're working on... They're afraid of you.

Recognizing this deficiency in the relationship, you can bridge the gap by reversing the polarity: try looking at your customer or manager as the one on whom you depend for information about it and without whom you could not do your job (that's the case anyway).

I try to do this, but it's hard to tell how effective I've been. Chad suggests finding some email you've written to a manager or client, telling your mom it was written by a colleague, and asking her how it could be improved. That may work, but I don't know if I'm willing to try it. He also says going through old mail yourself will help give you a more objective perspective into your own mail.

Of course, this type of thing isn't for everyone. As one commenter over at Reg's post points out:

Rag, see, we don't want to improve our careers, exactly because an improved career would mean more communication and less code. And we became programmers exactly because we wanted to be spared of that "Hey, how are you, is everything fine?" kind noise most biped animals call "communication", and rather talk to a computer which does not expect any more information than it actually needs to do it's job.

That's the kind of programmer I used to be. Obviously, I've tried to move away from that in recent years. However, it's certainly not a view about your job to be ashamed of: I think an overwhelming majority of us got into this because we were socially awkward. But, I'm not sure the types of jobs where you can do that are going to be around forever. I hesitate to say, "much longer," because I have no idea, to be honest.

The point of it all: This goes beyond simply speaking up. You want to be the "adventure tour guide:" hold hands when you need to, help them navigate the treacherous landscape. Being helpful and somewhat outgoing puts people at ease, where terse messages loaded with talk about details they know nothing about does the opposite.

You want to be open, not shut off.

Do you have any tips for communicating well with non-technical people?

By most standards, that's young.

And I know a thing or two about being set in your ways. We can all see the laugh I have at myself with the title here being "My Secret Life as a Spaghetti Coder" and some of the stories I've told as well.

In fact, let me add to the wealth of stodginess, idiocy, and all around opposite-of-good-developerness here:

I once said I preferred Windows to Linux. While that's not a completely shocking statement, the reason behind it was: I said I preferred Windows because 14 year olds work on Linux. Not because of any experience I'd had with it, but because of my fear of learning it.

Like with operating systems, your ignorance does not make a programming language suck. Although I've been tempted to say .NET sucks because of my early troubles with it, I've refrained, admitted my ignorance, and asked for help removing it.

Because of my prior experience being unwilling to learn, I was quite interested when I read this:

When you are young, you don't have that sense of self to protect. You're driven by a need to find out who you are, to turn the pages of your biography and see how the story turns out. If people around you are doing something you don't understand, you assume the problem is your inexperience and you go to work trying to understand it.

But when you are old, when you know who you are, everything is different. When people around you are doing something you don't understand, you have no trouble at all explaining why they are assholes mistaken.

. . .

If you want a new idea, you have to silence your inner critic. Your sense of right and wrong, of smart and stupid works by comparing new ideas to what you already know. Your sense of what would be a good fit for you works by comparing new things to who you already are. To learn and grow, you must let go of you, you must be young again, you must accept that you don't understand and seek to understand rather than explaining why it doesn't make any sense.

In a couple of paragraphs, Reg sums up almost precisely some of what I've been thinking and writing about for the last several months. He's so close, but misses a fundamental point: the old and young parts are incidental.

My hypothesis is that the level of learning and idea absorption you can attain has little to do with age. Instead, it is influenced more by your perceived level of experience. Normally, age is highly correlated to experience - but it doesn't have to be. In my case, when I was younger I thought I knew everything. Now that I've aged, I came to the realization I know very little.

My conclusion is not that different from Reg's, and this is not some scientific experimental contest, so let me explain why I feel the difference is worth noting: If we blame our reluctance to try new things on age, we are dooming ourselves to think of it as some unchangeable, deterministic process. By thinking of it in terms of perception of experience, we admit to being able to control it with more ease. (My belief is that we have control over what and how we perceive things.)

In other words, we lose our ability to blame anyone but ourselves. That's a powerful motivator sometimes.

Thoughts? Disagreements? Please be kind enough to let me know.

Chad Fowler, My Job Went to India (page 121)

Last week, we finished the section of MJWTI that dealt with executing when we discussed the importance of commitment, and executing on that commitment. This week, we begin adventuring into the world many of us have absolutely no clue about: marketing.

The main thing I want to do here is dispel this myth that marketing is evil, or that it's "just for suits" (quoting Fowler). There's no sense in persisting these illusions that say your super-modesty is an ethical choice in reaction to evil, or that it's not your job.



I cast dispel magic in your general area. I rolled a 17 on a d20. It's enough to pass the check. Therefore, the illusion from which you now suffer will disappear on your next turn.

I agree that it is possible to go overboard, being a braggart. But let's worry about that when you get close to it - you're most likely on the other end of the scale:

Most programmer types were the last kids picked for every team when they were in school. They probably avoided social situations where possible and failed miserable where not possible. It's no surprise that these people are afraid to stick their necks out by trying to show someone their capabilities.

The fact of the matter is that there's no reliable way to objectively measure knowledge-workers. What are they going to do? Count the lines of code you write? LoC as a measure of productivity is a stupid idea. Even if you were to have objective measures of "goodness" and "badness" as it relates to developers, perception would still matter: Someone has to decide if he likes you enough to promote you, or to keep you on the team in times of cutting back, or hire you in the first place.

If people are going to rely on their perceptions to form judgments of you, you might as well be the one to decide what they experience to form that perception.

One way to do that is to Speak Up! In doing so, Chad suggests making a list of groups you interact with and their associated perception drivers. His example looks like this:

Group	Perception Drivers
Teammates:	Technical skills, social skills, teamwork
Manager:	Leadership ability, customer focus, communication skills, follow through, teamwork
Customers:	Customer focus, communication skills, follow through
Project Manager:	Communication skills, follow through, productivity, technical skills

He also suggests making your own list, and trying to change your behavior to emphasize those points which resonate well depending on which group you're around. Critique yourself as you go along. By simply making conversation along the lines defined by perception drivers in each group, you don't need to brag to be seen in a positive light.

It sounds quite technical, but I think it's probably a bit more natural than it seems by writing it down and reading it.

I know I need to give it a try. Yesterday, one of my classmates made a "he talks too much" motion with the duck-quacking of his hands when he thought I wasn't looking. I know it was probably something to do with the way he was feeling, but I could obviously be better perceived at least by that member of my peer group.

What do you think? Baloney? Hogwash? Or might there be something to this perception thing? My vote's with the last one. Don't agree? Change my mind in the comments.

This was a flyer for AnsiCon, which we held at Woodlands Mall a couple of times. We also had a PezCon at Willowbrook one year. It seems mall security was always involved in those things. I once wrote a skapunk song about it called "Misplaced Priorities."



Here we have a menu for a board called Nitrous Oxide. I don't remember who the sysOp was:



I had a Save the Sheep foundation, and promoted it in a couple of bigger pictures. This one was for a board called Pandora, whose logo was cut off at the bottom:



We have here a skinhead that was done for another BBS called Shadows of Darkness:



Sometimes the SkinHeads Against Racism and Prejudice would come to our punkrock shows and start fights with antidisestablishmentarism punks. I normally got along with them though. Once, when I was stuck in the mud in some guy's yard, a group of them brought their truck and tried to pull us out. They ended up getting stuck too.

I've also been paying attention to Sixteen Colors since the same friend who sent me the pictures above pointed me to it a little while back. To prove to you how k-rad 31173 l338 (I was more than 1337) I was, you can see I was greeted in the AvengeView documentation in the same paragraph as RaD Man.

When I first went there, I couldn't find any of my art even though I did find myself in a lot of greetz. But when I went back today, I did find some. Looks like someone uploaded a few art packs from MAD. A couple of pictures I couldn't find through the Sixteen Colors search, but they did come up through Google. If you can't tell, I rather liked drawing cartoons. Here's an alien with his hand down his pants:



You might think his hand is down his pants because I was trying to be funny (I was 15 - juvenile humor is funny at that age.) But it wasn't that I was trying to be funny, so much as I thought a two-hook-hand alien would be less believable than a one-hook-hand alien. And since I couldn't draw hands very well (still can't), I hid the other one in his pants.

This one is my favorite on Sixteen Colors, found through Google:



Were you ever in the art scene? Who were you? Got any art to share?

Some of this is due to the extra ceremony .NET adds as a tax on you and your development time. Most of it's due to my ignorance. I've been honest about that: my ignorance of the overall strategies and thought-processes present in .NET takes full credit for most of my pain.

I've known for a while that I need to read something to "get in the know," and I've been putting it off until I had time. Thanks to a conversation with another developer (who shall remain nameless, unless he tells me he wants credit) this morning, I've decided now is the time.

I'm looking for books that give a strategic overview of .NET. I'm looking for ASP.NET and Windows programming (Windows Forms) to start with. I'd also like to see some strategy guides for Active Directory and Sharepoint. Seeing as I'm sore from fighting so much, a guide for pain-free coding in .NET might also be in order. (I'm going to buy that book since I know the author is a good one.)

I can easily do a search on Amazon for .NET books. O'Reilly has a ton of them. But I don't know what's good or bad or how to tell the difference. Further, except for one person (who shall also remain nameless) I sent an email to this morning, I don't know who to ask.

Well, that's not entirely true. I know there's a crowd of good developers with diverse experiences reading this weblog. So I'm asking you:

What is TFM on .NET? Any suggestions welcome. Short reviews of why it's a good book (or article online) get bonus points.

"Say it, Do it, Show it" - That's the advice this week from Chad Fowler in My Job Went To India. This chapter came at a perfect time for me - my planning is slipping, things to do are piling up, too many people want too many things from me, and I can't seem to decide what to do because there's too much to choose from. (Let me whine some more.)



Chad offers a lot of good advice in this chapter. The first illustrates why planning is so effective:

As you complete each item on the list, mark it DONE. Use capital letters. Say the word, done. At the end of the day look at your list of DONE stuff and feel like you've accomplished something...

It's a stimulating process. It's rhythmic. It allows you to divide your days and weeks into a series of small victories, each one propelling you to the next. You'll find that not only does it give you visibility into what you're accomplishing but you'll actually get more done than if you weren't watching things so closely.

(Link and emphasis are mine.)

Even though my daily plans help me stay focused and get things done, they are only tactical in nature - which means that although I consistently have a direction, there is no coherent strategy to it. That's why coming across this chapter again was so fortunate: once you've "established a rhythm of plan and attack," you should start working on a more strategic level of weeks and months. It's something I've not done: I may have an item on my to-do list that doesn't need to be completed until 90 days from now, but that doesn't add up to coherence.

I've recently been trying some organization practices from GTD (without having read the book), so we'll see if that also helps.

Other than planning and executing, there is a third practice that Chad identifies as useful at work: telling your manager.

You should start communicating your plans to management. The best time to start communicating the plans is after you have gotten through at least one cycle of the plan through execution. And -- this is an important point -- start doing it before they ask you to do it. No manage in his or her right mind would be unhappy to receive a succinct e-mail from an employee stating what was accomplished in the past week and what they plan to do in the next.

I'll think I'll try that.

To summarize the last two weeks, I'd say that the ability to say no and the ability to commit (and execute), while opposites, are still both required skills. However, you should commit only to the right sorts of tasks for the right reasons, and refuse to give in to pressure to candy-coat your answers in the affirmative when you really think the opposite.

Anyway, I'm interested in what you have to say. Got any planning tips, or stories (good or bad)?

At this stage, if you've heard of Rails and you haven't converted, it's entirely possible that you never will. It's also entirely possible that anybody who still isn't even taking Rails seriously by this point might just be some kind of idiot.
...
Every programmer should also read Chad Fowler's "My Job Went To India" book, where he explains that as larger and larger numbers of programmers adopt a particular skill, that skill becomes more and more a commodity. Rails development becoming a commodity is really not in the economic interest of any Rails developer. This is especially the case because programming skill is very difficult to measure, which - according to the same economics which govern lemons and used-car markets - means that the average price of programmers in any given market is more a reflection of the worst programmers in that market than the best. An influx of programmers drives your rates down, and an influx of incompetent programmers drives your rates way the fuck down.

Instead, I want to talk about my first attempt at solving the puzzle, which was an utter failure. A glorious, spectacular failure. Perhaps the single most impressive failure of my career. Failures are often much more interesting than successes, but for some unfathomable reason, people are often reluctant to discuss them.

And this is just the beginning of the ceremony:

Me: read file blah.txt and display it on system output
Java: How should I name the class?
Me: Test
Java: How should I handle errors?
Me: I don't care right now, I just need to display that data to system output
Java: But I need to know this, what if something unexpected happens?!
Me: I just want to make a prototype damn it!
Java: Sorry, can't do it.
Me: Ok, do nothing on error.
Java: And which implementation of Stream class should I use for reading?

Everyone knows that diversification is the key to managing financial risk, but few people seem to apply this principal to their professional careers. Most developer shops are relatively limited when it comes to the number of technologies and problem domains they deal with. If you want to diversify your resume without job hopping every year, then it makes sense to actively seek out technology experiences that are different from the ones you use in your day job.

Neal Ford and others have been talking about the distinction between dynamic and static typing as being incorrect. The real question is between essence and ceremony. Java is a ceremonious language because it needs you to do several dances to the rain gods to declare even the simplest form of method. In an essential language you will say what you need to say, but nothing else. This is one of the reasons dynamic languages and type inferenced static languages sometimes look quite alike - it's the absence of ceremony that people react to.

I want to take exception to the notion that Python is adequate for a real programming project. The fact that 30K lines of code took 110K lines of tests is a real indictment of the language. My guess is that a significant portion of those tests are addressing potential errors that the compiler would have found in C# or Java. Moreover, all of those unnecessary tests take a lot of time to write, time that could have been spent working on the application.

In fact, many people were shocked at the amount of tests compared to code, and that's what the discussion (at least the part I was interested in) centered around. Four times as much test code as application logic is too much. It would shackle you, instilling fear in your heart and soul. No changes would ever be made with that kind of viscosity. Furthermore, tests can provide a false sense of security, a blankie, if you will.



You've got to be kidding. Having a test that will tell you when you broke existing functionality is pressure to avoid changes? To me, that's liberating!

Contrast that with not having a test to tell you when something broke. Does it even make sense to say having tests pressures you to avoid changes? Only if you fear having a program that works over having one that you think works.

Let me try a different approach. Take the following simple program:


There are four execution paths: One where both someCondition and anotherCondition are true, one where they are both false, and one each where one is true and the other isn't.

In other words, we have six lines of code and at least four tests we should write to cover all the cases. If each test is just a single line, we still need to write the method names and end lines, so that would give us three lines per test - for a total of twelve lines of test code.

The test code size is already double the number of lines in our application code for this simple, six line program with four execution paths. How many execution paths are in a 30 thousand line program?

Seeing as the number of execution paths in code is more likely to grow exponentially than linearly with each new line that gets written, 110 thousand lines of test code isn't actually all that much.

Further, the solution to the blankie problem is not "have fewer tests," it is to recognize that passing the tests is a necessary - not sufficient - condition of working software.

Following the blankie argument to its logical conclusion - that fewer tests mean you write better code because you are more careful - we should have no tests.

In fact part of the reason we want the tests is that we can make changes to the code with less fear of unknowingly breaking existing functionality or introducing defects in the software.

In the end, if someone is using the tests as a tool to do wrong, there is something wrong with the person, not the test. They will find another way to do wrong, even if we remove the tests from their arsenal.

Saying "yes" is an addictive and destructive habit. It's a bad habit masquerading as a good one. But there's a big difference between a can-do attitude and the misrepresentation of one's capabilities (extra emphasis mine). The latter causes problems not only for you but for the people to whom you are making your promises. If I am your manager and I ask you if you can rewrite the way we track shipments ... by the end of the month, someone probably asked me if it could be done by then... So, armed with your assurance that you can make the date, I run off and commit to my customers that it will be done.

When you lie about your capabilities (even though it's not malicious), that spreads itself throughout an organization, and harms everyone. Most importantly for you, it damages your reputation. Whereas the man who says "yes" only when he is truly capable may feel bad about having to say "no" more often than you, he will come to be known for his honesty and accuracy in prediction while no one will trust anything you have to say about such matters.

The point is that you need to have the courage to speak up on the job. You need to say yes when you can do something. You need to say no when you can't do something. And as Chad notes at the end, you need to speak out against bad decisions:

As a manager, I make decisions or strong suggestions all the time. However, I don't hire my employees to be robots. It's the ones who speak up and offer a better suggestion that become my trusted lieutenants.

How guilty are you of over-committal and non-committal? I may have learned to not keep quiet, but I still have some work to do regarding the scheduling of -- and commitment to -- tasks in general.

Update: Coincidentally, Reg Braithwaite related The Battle of Britain to software development telling us about Marshall Dowding and his refusals to be pressured into saying "yes" yesterday as well (along with personal stories).

Naturally, I wanted to look for computer-related charities, and more specifically, those with a focus on programming. I first browsed a couple of charity-ranking websites and didn't find anything that I was searching for.

Everyone knows about One Laptop Per Child, whose mission is to educate children in developing nations, who otherwise wouldn't have as much of an education, by providing them with a low-cost, low-energy required laptop.

OLPC is not, at heart, a technology program, nor is the XO a product in any conventional sense of the word. OLPC is a non-profit organization providing a means to an end - an end that sees children in even the most remote regions of the globe being given the opportunity to tap into their own potential, to be exposed to a whole world of ideas, and to contribute to a more productive and saner world community.

On a bit of a smaller scale, I found Computers With Causes, which like so many charities who will let you donate your car, take your donated computer and turn it into good for charitable purposes. Mac Heist puts on a two week bonanza of a sale and donates proceeds to the charity you choose. That's a start, but we could do better.

There is another group, charityfocus, which lets you volunteer your time to help build websites for different charities. That certainly sounds interesting, and more to my point - but it's not quite there.

These are all noble goals, but I'm more interested in a cause that's closer to home, one where technology is not ancillary, but where it is part of the goal. So, I thought I'd do a domain search and start one myself. One of the domains I entered was code4cause.org, but it turns out they're already doing some good work. They don't teach children to program, but they do take on your IT projects and donate proceeds to charities.

I was surprised I wasn't able to find more than what I did. Are programmers that selfish?

Of course not. We donate a lot of our time to open source, for one thing, and I'm sure there are plenty of us who have our favorite causes that aren't computer-related at all.

I like Code4Cause's mission - that would let programmers donate their time to projects and convert that into money to send to charity. But, Code4Cause is based in Europe and Asia, and I'm more interested in something closer to home (which for me, is the United States). What are U.S. software developers doing?

I don't know, but I wouldn't mind seeing something like Code4Cause in the US. Or, at least it would be nice if we could donate the money our time produces to whatever organization we chose. Ideally, I'd like to see something where programming is more of the point, but I'm not sure how it would work. Even if coding remained auxillary, something like Code4Cause would be still be great.

Anyway, where are the coding organizations? Do you know of any I haven't listed? Share them below. Interested in trying to start one yourself? Let me know privately, and if there's enough interest, maybe we can figure out how to start an organization, and what we'd like it to do.

Sorry I don't have any more answers - I'm just fleshing these thoughts out, and throwing them out there to see if it helps.