Space Station

Career advice

I'm finishing answering an email from a gentleman in India who wants career advice. Never heard of him, he contacted me out of the blue. It's always weird getting email like that, but I usually take the time to answer it. I was able to give him some specifics since he asked specific questions, but here's a bit for you if you're a programmer.

Learn databases! Learn them, damn it! Learn how to design a database, understand why you should normalize your data and why you might break those rules. Understand why NULLs are a Bad Thing and why your DBA usually wants to shoot you for doing SELECT * FROM .... I am so tired of going into a database and seeing columns named "ingredient_1, ingredient_2 ...". I'm tired of fixing SQL injection attacks. Please, just learn databases, will ya!

There's a lot more about databases I could rant about, but I'll stop. Most serious developers today must work with databases of some sort or another and most suck at it. If you have a good handle on the basics, you'll trump most developers out there.
  • Current Mood: awake awake
Perl is definitely not dead-end. There are plenty of large companies which appreciate Perl's power and ability. Plus, there's a lot of legacy code out there which needs to be maintained.

PHP has made huge strides because it's so easy to get up and running. PHP 5 still does not have namespaces, there's no standard naming convention for functions (forcing a lot more memorization), "magic quotes" was a bad way of fixing a common problem and the general structure of the language encourages mixing of the model and view layers. So why do people use it? Because it's so easy to get up and running.

J2EE? I wouldn't worry about that. More and more programming heavyweights are turning to dynamic languages. With the "Web 2.0" hype, dynamic languages are gaining market share because folks need to develop things fast. No sense spending six months developing a new feature that others can whip out in six weeks.

As for ASP related stuff, unless you're talking about Apache::ASP, I wouldn't worry. Most ASP is for Microsoft-only shops. There are plenty of open source shops which can't/won't spends tens of thousands of dollars (or more) on licenses to MS when they can get comparable technologies for free.

I'd be more concerned about Ruby myself. Python's out there, but Guido has (IMHO) made some serious design mistakes and he doesn't seem to "get" what's happening with dynamic languages today. I used to like Python, but I don't see it going anywhere.

Perl's going to be strong for a good, long time. It's a mature, stable, and proven. The CPAN continues to be a huge reason for choosing Perl. Further, Perl 6 will be coming out in a couple of years (I know people think this isn't true, but it is) and it's truly going to advance the state of the art of programming. Those who already know Perl will be better positioned to take advantage of it, but that's a fair ways off :)
I use the term "dynamic" very specifically. I mean "dynamic" and "statically" typed languages (using those terms very loosely). In the former category, we see Perl, PHP, Ruby and Python gaining a lot of ground. In the latter, we generally have Java, C# and other languages.
I know DB basics, and can use them when I have to, but I'll admit my knowledge of them is limited. I couldn't design a schema to save my life, nor would I have a clue where to start with optimization.

Got a book recommendation?
Regrettably, I don't have any good books to recommend. I've picked up my knowledge over the years by learning from others and constantly reading online. The only book which springs to mind is Database in Depth, but that assumes you're already a solid database developer. Still, once you have that, it's a great book.
Does that just deal with writing SQL that's ordinarily difficult or does it also cover core design issues and flaws?
I have written about this here. I could expand upon that further, but the gist of it is pretty simple: by stating exactly what you're looking for in your SQL, you get exactly what you want, you no longer need to worry about minor tweaks such as field order and just as importantly, it likely fails immediately if the fields are no longer there.

In short, being precise instead of lazy has a host of benefits.
Let's not forgot to learn how not to use a SQL database engine as a glorified flat file system. Sadly, I know a lot of these companies are still out there (we compete with them), and in the ten years I've been programming professionally, these people still haven't figured that you can use SQL for processing a hell of a lot more than one row at a time.

On a related side note, I like your database related posts/rants :)
Well, that's a relief that someone likes those rants. I've pissed off a lot of people with them. They get very mad when I point out that the Kool-Aid they've been drinking for years is crap. One of my favorite examples:

SELECT last_name FROM customers WHERE age > id;

We all know that's crap and we sort of know why it's crap and DB "professionals" simply say "don't write crap!". If SQL properly observed the relational model developed over three decades ago, it wouldn't be possible to write that crap (because the relational model would recognize that IDs and ages are different types and it wouldn't know how to make the comparison unless both were cast as INTs).