Thursday, November 3, 2011

CS education, and education after education


Computer scientists, software engineers, programmers, system architects... Various different terms that sometimes mean the same thing, sometimes not. Unfortunately our industry is rather confused, and with no governmental certification process like doctors or civil engineers, the situation likely won't change. Two separate software engineers will have vastly different areas of knowledge and understanding, and will likely have had vastly different educations. While one may have gone to a java school(I'm going to refer to these as vocational schools because that's what they really are) another may have gone to a school that teaches lots of theoretical computer science, algorithms, data structures, compilers and very little practice.

Regardless of which type of school people go to, or even if they're self-taught, there are some jobs available, but not the same jobs. The vocational school people will likely never get a job in a "computer science" company, because they don't know big-O analysis and can't optimize themselves out of a paper bag. But they'll get jobs in many respectable companies that want "2+ years of java experience, including spring, hudson, JBoss and recent java technology xyz". Or "Ruby on rails". Or whatever. More power to them.

On the flip side, the theoretical computer science guys don't know java, or maybe they've just done some toy apps in it. They probably have not had an entire class in working in some SDK or API. They haven't done any android or iPhone programming because they were too busy writing a basic file system for their operating systems homework. JavaCo probably won't hire them because they don't care about operating systems. Or compilers. And these kids don't have the prerequisite 2 years of java experience. Now then, my honest opinion is that these guys have learnt how to *think* about programming, and that they will catch up to the Java veterans in a short time, and soon be far more effective, but that is a matter for a separate essay, and one which has been covered by many really smart people.

And you know, we probably do need Java schools, because there are lots of companies out there that stick to the same tools and need people to work on dull business apps and pay well for them. Word is that cobol is still one of the best paying skills to have. And people graduating from these schools deserve respect. They have different priorities in life, and programming to them is often just a job. Get an education, get a job, get married, live a happy life. Good.

And then there's people that want to do cool new stuff. New stuff changes a lot. If you're going to go to school, don't learn about new stuff. It will change soon enough. Instead learn about the basis this new stuff comes from. I didn't do this. I went to a what I shall call a vocational school for games development, one that is very well(and deservedly so) respected in the industry, but many of the skills I learnt there are now defunct. I had to learn the stuff I didn't get an opportunity to learn in University by myself. It's harder, but doable. There are a lot of good books including some that are free and resources for it too. Still, learning this at a school will be significantly easier and having the papers to prove it helps. If you have the opportunity to do so, go to a school that teaches you about how to think about programming, to understand how things work. These skills will let you figure out whatever language and API are trendy.


Another problem that plagues our industry is that a lot of people just stop learning. While as a doctor or engineer you would be expected to keep up to the latest techniques, the vast majority of developers stop learning. The average developer does not read one book a year. They are happy with where they are. Steve Yegge talks about this in his essay being the averagest. This isn't just a problem with the people though, it's very much a problem with the organisations. Post-education education is not encouraged nor is it rewarded. The places that do this right are highly sought after workplaces. They offer mentoring and regular workshops. These places attract the people that want to keep learning, and they keep making them smarter and more valuable. Investing in people triple-dips returns, making better people, increasing loyalty and increasing the attractiveness of a workplace. And it's economical. If it takes 40 hours to teach someone a new skill that will pay off at a 5% productivity upgrade, that skill will be repaid in 800 hours, or a few months. The problem is, productivity increases are hard to quantify and measure, so decision makers will often just ignore the opportunity, choosing the safe way of doing nothing, where it is hard to blame them for doing something wrong. When in doubt, do nothing! Frustrating.

So often, it will be down to a developer to learn on their own. Perhaps you can gradually prove the benefits of what you learned, and convince those around you of its value. Perhaps not. Regardless, should you find yourself thoroughly unsatisfied, if you know a lot, you can easily try somewhere else where you're likely to be more satisfied. And the people hiring active learners generally understand the importance of people, and the importance of developing them.

Education is important, and it really should be a continuing process. Learning to think is far more efficient than rote memorisation. A lot of people learn physics and memorise the formulas. Smarter kids understand the formula and can figure them out from scratch, and understand when to apply them. In my honest opinion the effort required isn't really very different either. The former process is merely more front loaded, so progress seems faster initially.

This post is a work in progress and I'll likely have to take another pass at it to polish up some of the ideas and for clarity.

Wednesday, November 2, 2011

Let's try this again

Not too long ago, Steve Yegge made a lot of headlines for his little platforms rant. A rant that was only meant to be internally visible on Google+. It was good reading, but not what I want to talk about. Steve Yegge had kind of gone of the radar for a while since getting more and more busy at Google, but he's a really smart guy and has had a lot to say in the past(and he has plenty of haters too of course).

He once said "you should write blogs". Practice writing. Use writing to form your thoughts. I felt that he was more or less on the spot about that. Programming and system development are complex subjects. To be able to write succinctly about them is a valuable skill that will be appreciated as much, if not more, than programming ability.

So after my last couple of false starts, I'm doing this again. And I'm just going to use it as a platform to mull over things. Some entries may stay unpublished a while, others may go over large edits after publishing.

There are a lot of things I want to write about, many of them that have gotten a fair bit of coverage before and are still problems. Hopefully they will provide me with enlightenment, and perhaps someone else will get something out of my ravings. Perhaps not. Among others, subjects I hope to take a poke at are:

  • Programming/software development in Japan. There are some unique anti-patterns that happen here, and many aspects of the industry have their own quirks. Some better, some worse.
  • Education after education. So, for many people this is just a non sequitur. I fall into the camp of people that feels like other professions that any serious software developer should be taking and given time in which to keep their skills up to scratch and modern. More so, people need to be aware of their shortcomings and work hard to improve them.
  • Recruitment and interviewing. Another one of those huge problems in the IT industry. Good people are really hard to find, they rarely enter the job pool in an open way, and it is also really hard to figure out if someone is good or not. In addition good people also tend to leave companies as they pass their value apex. There is nothing more important to a company than the people working there and the people that you can attract.
  • I'll likely write about some programming stuff too. I'm starting a new job at a research position in January so should get to work on some pretty cool stuff, and can hopefully talk about it.
I intend to write this without watering down my opinions. This industry is still very young compared to others, and there is still a lot of broken stuff going on in it. Hopefully I won't just be preaching to the choir.