Anyone can become a Developer; the Trick is staying a Developer

At the risk of alienating some of the readers, I will tell you about my favorite writer. It's this angry guy named Harlan Ellison. He's quite famous in the fiction circles, though it was his non-fiction that really won me. He has a cynical streak and is very intolerant of the incompetent. It's pretty refreshing stuff to read as you journey through this life and become frustrated with the reality that in the US, society not only tolerates mediocrity and incompetence, but encourages it.

I had the honor of hearing him speak at some of his public appearances. One of the things he said really stuck with me.

Anyone can become a writer. The trick is staying a writer.

I think that's a fascinating statement. To me, it means that each person knows at least one story that he or she can tell better than everyone else. But it also means that the art and profession of writing is something that requires more than the ability to communicate. It also requires some measure of passion to do well. There's another profession like that: software developer.

In an earlier post, I said that anyone could become a developer. Well, that's true, but I also said this:

Making software is easy, making it right is hard.

To really be outstanding at making something as complex as software, you need to have a true drive for learning and improvement. That means more than 40 hours/week of effort. That means taking time to read other blogs and books, and to take classes, even if the IT department you work in has cheap-ass management that doesn't understand that the best IT staff is one that's educated and skilled. That means paying for it yourself if you have to or finding work somewhere where the management values employee development.

This is especially true in an industry like IT, where the technologies can change in the space of a few years. When I first went to EDS, I learned COBOL. I didn't care for it, but it put food on the table. I always yearned to work on PC-based tools, and eventually got to a project where I learned PowerBuilder. But at this early stage, I was still struggling with learning so many things. I was still learning about my client's business, about event-driven programming, and about SQL, and I was clueless about Object Orientation. Frankly, I was not very good then, and my stuff sucked.

With time, I figured out the tool and now consider PowerBuilder to be one of the best development tools ever made. If you need to connect to and do work with an enterprise database (or even a less-than enterprise database) and you are not using the PowerBuilder datawindow, you are spending more money, time, and effort than you need to be.

So why did PowerBuilder (PB) lose it's luster in the market? A big part of that is the way Sybase handled the product after buying PowerSoft. But it didn't hurt that most developers are idiots. They are so into chasing after The Next Big Thing(TM) that they never stay with a language long enough to develop a level of mastery. I've seen a bunch of PB code over the years and most of it was mediocre at best. There are guys that have been using it for years that never truly utilized the power of the tool. It supported the big three of OO (encapsulation, inheritance, and polymorphism) long before Java ever existed! But guess how many of the PB apps that I've seen actually used OO? None, but in all fairness I didn't really understand it until I took a Steve Benfield class back in 1997. That is really sad, that most developers don't really use the power of OO (or PB), but a deeper discussion of that is for another day. To me, understanding OO is what truly separates the mediocre developers from those that finally hear the music and take that step towards advanced developer. Maybe I'm wrong, but the body of code I've seen indicates that many haven't made that leap.

Getting back to my point, one of the pivotal parts of staying a developer is to grow your knowledge. Besides commitment, patience is a big part of that. Experience counts for a lot in making software, because the core challenges in this industry aren't likely to change. Oh, the intensity and the trappings of the challenges can rise and fall with the changing times, but things like data access, data storage, security, concurrency, and performance will always be the things we struggle with, and the mediocre will fail to consider, happy as they are to simply toss out a huge nesting of IF statements. Striving for adaptability, agility, maintainability, and elegance are the things to which the mediocre will only be able to give lip service. I can't tell you the number of times I've seen complicated spaghetti code, and thought how it would be so much easier if the folks that built the app would have used true OO. OO is a bit tricky to figure out at first, but once you get there, you realize it's the only way to make code more agile.

Even after all the years of learning, I still consider myself far from where I'd like to be. But I see definite growth in my knowledge. And I did it mostly by focusing on one language. Thankfully, it was PB, and not something like a pre-.NET incarnation of Visual Basic. I was able to overcome the initial learning curve, which included the crucial step of making mistakes and learning from them, then continued to simultaneously grow my understanding of the advanced capabilities of the language while reading about programming theory in general. Little of this actually happened while scrambling to meet deadlines...most of it took place after-hours, reading technical journals or in specific technical classes.

That's why it kills me when companies get upset about the poor quality of software, but are at the same time throwing poorly managed software projects at their developers and refusing to pay the cost of employee development. If corporations don't want to invest in sending their janitors to advanced skills training, that's one thing, but if they don't send their thinkers to learn the new tricks in an industry where things are always changing, they're only hurting themselves. Still, if you're not one of the lucky ones working at Computerworld's Top 100 Companies to Work for in IT, then you're often like me, forced to figure out this stuff on your own.

That's why staying a developer is tough. It takes work to improve yourself. There are ways you can get away without putting in the extra effort, and there are also things that can compromise your efforts even if you do make them. More on that in a future rant. But if you're serious about staying in IT, at some point you're going to have to learn something either because you want to or because the environment forces you to. But don't always assume the learning has to be in a new language. If you're using the right language (something that supports OO like C, PB, Java, C#, or VB .NET), you'll be able to make dramatic improvements in your ability by studying advanced techniques and applying them right where you are.

This is where chasing The Next Big Thing can be wrong. I think that getting over the newness of a language is a critical part of being able to move on to using it with advanced concepts. If you don't get to the point where the syntax becomes second nature, then you'll always be in cut-and-paste mode, the thing that might be the biggest cause of PB's demise. Cut-and-paste is a symptom of procedural logic, and procedural logic is the mental baby food of poor or mediocre developers. I can guarantee you there are still people slapping procedural logic routines into their Java and .NET objects and then patting themselves on the back and saying, "Look! I did OO programming!" No, that's "Uh oh programming." The people that never figured out OO while learning PB took their same bad habits to Java, then to .NET, all in their pursuit of The Next Big Thing. The Next Big Thing can't materialize because it's always being compromised by The Worst Old Thing.

Don't be fooled by the few in this industry that write the magazine editorials and work in ivory towers where they get to play with whatever they want and don't have deadlines. They write about how your programming tool is dead and you are crap if you don't move to The Next Big Thing. I say to them, "You're lucky, good for you, now shut the hell up, not all jobs are like yours. The rest of us don't want to hear about your time at the tech conference in Hawaii. We have to figure out how to resolve problems in a myriad of apps supporting a multibillion dollar company, and no, the app isn't written in the latest and greatest, but it's putting food on my table. Who's going to do that if I take a few years off to study an obscure API in .NET? You?" Staying a developer requires learning, but learning isn't always about a new language, sometimes it's about making better what you have, and it should be more about improving productivity than improving resumes.

Once you've achieved proficiency with a language, and are confident that you understand OO and have migrated from cut-and-paste to model-design-and-iterate, then you're probably at the point where you can start picking up all kinds of newer languages because at least some of the universally useful concepts are understood and can be translated over. Sometimes, if you know what you're doing, you can appreciate when the new thing, say Java or .NET, can offer you something your old language didn't like implementation of operational polymorphism through things like interfaces. But I'll bet a lot of the ex-PB guys that went to Java and .NET first heard about interfaces and said, "Huh?" And if you've used interfaces for a while, you know they are powerful, but like recursion, can get confusing if you don't design them well and apply them judiciously. Guess who probably implemented hundreds of interfaces without thinking first?

Anyone can become a developer. But if you want to stay one, try climbing to the next level before moving to the next language. Try supporting your own crappy code for a while, feel the pain those that support and use your apps feel, learn from your mistakes, and realize that there are better ways of doing what you think you're so good at. If you don't, you'll be dumping more of your crap on the ones that follow, you'll just be doing it in a different language. You can count on the lack of metrics in our industry to shield you for a while, but sooner or later, the smart ones are going to stop hiring you.