Found a post on IdianGeek (via DZone) for a Programmer Competency Matrix.
I was a little skeptical about it at first, but after reviewing all the boxes in the matrix, this could actually be a pretty useful evaluation tool for developers. Granted it's not perfect, but it's better than some other ways I've seen developers evaluated.
Evaluating my own skills against the matrix reveals that I'm pretty solidly in the Level 2- Level 3 range...which means that either I'm a better developer than I thought, or the matrix needs a little more tweaking. I'm going to lean more towards the latter possibility...
Nevertheless it's pretty useful to evaluate one's own skills against what people are looking for out there, and I do see a few places where I could expand my knowledge and abilities listed in that matrix.
And looking at the first item on the matrix listed under Level 3 for books, I seem to already be on my way towards improvement :-)
SICP
At about the same time every year - sometime between April and June - I end up buying a bunch of books from Amazon. I don't plan it that way...that just seems to be the time of year that I always get the urge to plunk down some cash for something to read. Maybe it's the weather or something.
Anyway, it usually works like this: Throughout the year, every so often I'll pop onto Amazon and see what stuff comes up in my recommendation list (I've bought so much from those guys they they probably know my every habit by now -- beyond the same-time-of-year-book-buying thing -- so the recommendations I get are usually pretty solid). If I see something that interests me I'll add it to my shopping list. The book doesn't have to be particularly engaging...just something that looks a bit interesting at that moment. This is basically the first pass through my is-it-worth-buying filter.
When I feel the need to buy some books I'll peruse the list and see which ones are really worth buying. I inevitably will buy more than one book -- even though Amazon has free shipping on most of their stuff, I like buying in bulk since it's decidedly more efficient to ship that way. I'm not a particularly eco-conscious person...but I do seem to have a preference for efficiency, and having a bunch of books shipped together in one big chunk seems more efficient to me than buying one here and one there throughout the year.
Hmm...chalk that up as another possible reason for the same-time-of-year-book-buying thing.
So anyway, I've had one book in particular that's been sitting in my shopping list for quite a while: Structure and Interpretation of Computer Programs (known as SICP to most people familiar with the book). I had learned of the book through various sources on the web, as it's been recommended by the likes of Ragawald and Joel Spolsky (who's mentioned the book here and here, and also mentioned it on the first or second stackoverflow podcast...which is worth checking out, btw), and over at learning lisp there's some good posts about the book that made me think about getting it.
I was on the fence about buying the book for some time. The book can be read for free on MIT's website here, so for a while it didn't seem like it made much sense to buy it when I could read it for free. But my preference is to actually have books (especially technical books) physically in my hand when I'm reading them. And, despite the fact that a lot of programmers don't read technical books...I actually enjoy reading them. And for all the craze over Kindle and electronic books, there's a lot to be said for actually having the book in your hand to read.
So finally, with this last batch of books I purchased I said, "screw it" and bought SICP.
And I haven't regretted it.
I haven't finished reading it yet, but I would certainly rank this book up there on my list of must-have books (one of these days I'll make a "Best of" book list here...but I'm a programmer...and I'm lazy...so it can wait). SICP does have a fair amount of math-related material in it, but I'd have to say it's way easier to follow than, say, The Art of Computer Programming Series, which lean very heavily on mathematics (at least Vol 1 does...I haven't delved into Vols 2 or 3).
SICP also uses Scheme -- a variation of Lisp -- for all of the code in the book. What's great, though, is that the book explains the Scheme language early on in such a seamless manner it's almost like you're not actually learning the language at all...which is really the point, since the focus of the book is on the concepts and not the language used.
And so far this has been the biggest point I've taken from the book: It's not the language you're using that's important. It's the concepts a language embodies and uses that are far more important. This is the very essence of computer science that many people don't see, or simply choose not too -- instead they simply focus on the quickest way to solve a problem in Blub. There is some merit to that approach...but it sacrifices long-term gain for short-term results.
And after diving into this book, I really think I'm beginning to understand this more that I ever did before. I had always felt that developers (myself included) should concentrate on learning and understanding the underlying science of our profession, as it is so much more enduring than the solving-a-problem-with-the-language-of-the-day that commonly goes on. In some ways we seem to be stuck on a treadmill of reinventing the wheel when it comes to the craft of software development, without advancing much.
SICP has really begun to open my mind up to other areas of software development that I really wasn't seeing, or saw but didn't fully appreciate.
This book is worth it's not-too-insignificant weight in gold, as far as I'm concerned.
Anyway, it usually works like this: Throughout the year, every so often I'll pop onto Amazon and see what stuff comes up in my recommendation list (I've bought so much from those guys they they probably know my every habit by now -- beyond the same-time-of-year-book-buying thing -- so the recommendations I get are usually pretty solid). If I see something that interests me I'll add it to my shopping list. The book doesn't have to be particularly engaging...just something that looks a bit interesting at that moment. This is basically the first pass through my is-it-worth-buying filter.
When I feel the need to buy some books I'll peruse the list and see which ones are really worth buying. I inevitably will buy more than one book -- even though Amazon has free shipping on most of their stuff, I like buying in bulk since it's decidedly more efficient to ship that way. I'm not a particularly eco-conscious person...but I do seem to have a preference for efficiency, and having a bunch of books shipped together in one big chunk seems more efficient to me than buying one here and one there throughout the year.
Hmm...chalk that up as another possible reason for the same-time-of-year-book-buying thing.
So anyway, I've had one book in particular that's been sitting in my shopping list for quite a while: Structure and Interpretation of Computer Programs (known as SICP to most people familiar with the book). I had learned of the book through various sources on the web, as it's been recommended by the likes of Ragawald and Joel Spolsky (who's mentioned the book here and here, and also mentioned it on the first or second stackoverflow podcast...which is worth checking out, btw), and over at learning lisp there's some good posts about the book that made me think about getting it.
I was on the fence about buying the book for some time. The book can be read for free on MIT's website here, so for a while it didn't seem like it made much sense to buy it when I could read it for free. But my preference is to actually have books (especially technical books) physically in my hand when I'm reading them. And, despite the fact that a lot of programmers don't read technical books...I actually enjoy reading them. And for all the craze over Kindle and electronic books, there's a lot to be said for actually having the book in your hand to read.
So finally, with this last batch of books I purchased I said, "screw it" and bought SICP.
And I haven't regretted it.
I haven't finished reading it yet, but I would certainly rank this book up there on my list of must-have books (one of these days I'll make a "Best of" book list here...but I'm a programmer...and I'm lazy...so it can wait). SICP does have a fair amount of math-related material in it, but I'd have to say it's way easier to follow than, say, The Art of Computer Programming Series, which lean very heavily on mathematics (at least Vol 1 does...I haven't delved into Vols 2 or 3).
SICP also uses Scheme -- a variation of Lisp -- for all of the code in the book. What's great, though, is that the book explains the Scheme language early on in such a seamless manner it's almost like you're not actually learning the language at all...which is really the point, since the focus of the book is on the concepts and not the language used.
And so far this has been the biggest point I've taken from the book: It's not the language you're using that's important. It's the concepts a language embodies and uses that are far more important. This is the very essence of computer science that many people don't see, or simply choose not too -- instead they simply focus on the quickest way to solve a problem in Blub. There is some merit to that approach...but it sacrifices long-term gain for short-term results.
And after diving into this book, I really think I'm beginning to understand this more that I ever did before. I had always felt that developers (myself included) should concentrate on learning and understanding the underlying science of our profession, as it is so much more enduring than the solving-a-problem-with-the-language-of-the-day that commonly goes on. In some ways we seem to be stuck on a treadmill of reinventing the wheel when it comes to the craft of software development, without advancing much.
SICP has really begun to open my mind up to other areas of software development that I really wasn't seeing, or saw but didn't fully appreciate.
This book is worth it's not-too-insignificant weight in gold, as far as I'm concerned.
Not Sure if I like This Idea...
Gizmodo mentioned this months ago, and Wired's got an article about it again...
People have a hard enough time driving as it is.
And, while I know they'll market this as something for passengers, or in some way to encourage drivers to not use it while driving, you know someone's going to do it...whether Chrysler intends it to be used that way or not.
I like Chrysler personally: Even though their sales have taken a big hit like Ford and GM, I still prefer their cars over those two companies. I like the styling of their cars, and I've owned a few in the past (Dodge specifically - I call myself the accidental Mopar guy...I'll save that story for another day), and all of them have been solid cars that have lasted longer than anything I've ever owned previously.
I see this more as a marketing gimmick...which is a shame. I think Chrysler needs to stay focused on building quality, well-styled vehicles rather than gadgetry. I think they'd also be better off not going integration crazy, like Techdirt mentions:
I think in the near futures, automakers that provide solid integrating for existing gear will attract buyers. In the current economic climate, people aren't going to want to ditch their existing equipment when they buy a car...so why not leverage it and help them save a few some cash?
I've seen some high-end concepts from the likes of BMW that provide seamless plug-in capabilities for iPods...but these are way out of the price range for most people. This technology isn't that expensive (hell, I've actually considered hacking connections into my own car...which isn't really that hard), so this should be a no-brainer as far as I'm concerned.
Nevertheless...I just hope in the future I don't get rear-ended by some super-busy-marketing-guy because he decided to check his email while going 90 MPH down I-95...
update: And on a related note - A desk setup that fits on the passenger side of the car.
This takes driving while distracted to a whole new level...
Chrysler wants to turn your car into a rolling WiFi hotspot where you check your Facebook profile, upload pictures to Flickr, and eventually be part of a nationwide traffic-control network.I like the idea of adding new technology to cars as much as any other geek - and having some mobile network connectivity in a car is certainly a nice idea - but I'm just not sure if I like the idea of turning a car into a wifi hotspot.
People have a hard enough time driving as it is.
And, while I know they'll market this as something for passengers, or in some way to encourage drivers to not use it while driving, you know someone's going to do it...whether Chrysler intends it to be used that way or not.
I like Chrysler personally: Even though their sales have taken a big hit like Ford and GM, I still prefer their cars over those two companies. I like the styling of their cars, and I've owned a few in the past (Dodge specifically - I call myself the accidental Mopar guy...I'll save that story for another day), and all of them have been solid cars that have lasted longer than anything I've ever owned previously.
I see this more as a marketing gimmick...which is a shame. I think Chrysler needs to stay focused on building quality, well-styled vehicles rather than gadgetry. I think they'd also be better off not going integration crazy, like Techdirt mentions:
Automakers love to build new technology into their cars in order to control the experience, but that's not what consumers want. Having an MP3 player is nice, but it's easier if you can just use your iPod. Having a built in GPS system is cool, but the new Garmin has a lot more features. Working with consumer electronics devices that people buy seems like it may be a lot more sensible than trying to recreate the wheel.
I think in the near futures, automakers that provide solid integrating for existing gear will attract buyers. In the current economic climate, people aren't going to want to ditch their existing equipment when they buy a car...so why not leverage it and help them save a few some cash?
I've seen some high-end concepts from the likes of BMW that provide seamless plug-in capabilities for iPods...but these are way out of the price range for most people. This technology isn't that expensive (hell, I've actually considered hacking connections into my own car...which isn't really that hard), so this should be a no-brainer as far as I'm concerned.
Nevertheless...I just hope in the future I don't get rear-ended by some super-busy-marketing-guy because he decided to check his email while going 90 MPH down I-95...
update: And on a related note - A desk setup that fits on the passenger side of the car.
This takes driving while distracted to a whole new level...
The Real Reason Microsoft is Doomed...
The lack of attention to usability represented by these experiences blows my mind.
Raganwald linked to an epic Bill Gates e-mail rant, from which came the above quote.
That one sentence best sums up why I've never been a fan of Microsoft. Sure they have plenty of hardworking, amazingly-smart people there (or at least they did before Google came along), but for all the efforts put into the likes of Windows by the army of developers in their employ, Microsoft just never seemed to get usability figured out.
Of course, this probably proves just how hard usability can be, too.
But it must not be too hard when you have other companies of somewhat lesser stature figuring it out, and profiting rather handsomely from it.
But there's something that bugs me about that email...
Throughout his time as Microsoft's CEO, Bill Gates gained a reputation both inside and outside of the company as being a ruthless manager. Whether there's any real truth to it I'm not sure, but I doubt so many would think of him as being ruthless had there not been some truth to it. Joel Spolsky has a nice little anecdote of his time at the company that makes Bill Gates appear more methodical and calculating than ruthless.
Nevertheless, at Microsoft everyone knew who was in charge.
Getting back to that rant article. When asked about the email, Bill Gates says, "There's not a day that I don't send a piece of e-mail ... like that piece of e-mail. That's my job."
OK, let me get this straight: Bill Gates, founder and CEO of Microsoft has been sending rants like this to people down the chain of command at the company he founded for - I would assume - a rather long time...
...why the hell hasn't anyone been listening?
What Hath Java Wrought: The Long Version - Part I
Well...it took longer than I was hoping to get the ball rolling on this, but here we go: My extended, less anger filled post about Java...
I've received mostly favorable feedback about my rant regarding some of the issues I have with the evolution of the Java language. However, I obviously wasn't very detailed in explaining the problems as I see them, and rather than just leave a bunch of incomplete thoughts hanging out there (and giving the appearance of bitchiness) I think it's more appropriate to spell out the problems I see in a clearer manner.
A big reason I want to expand on this topic is the fact that if Java is to continue to be a popular and useful language, those of us that use the language on a regular basis need to discuss the implications of making changes to it. Adding features is not necessarily a bad thing, but there doesn't appear to be much coherent discussion about the implications such language changes can have. Or, if there is, it quickly degrades into a "Java Sucks"/"No it doesn't" back-and-forth crapfest.
The post on Jeff Campbell's blog I previously mentioned stated something along these lines, too: We've got to make it a point to shine some light on the issues surrounding Java's future. When we devolve into a mindless raving over whether Java is worth a damn or not (which I obviously did with my rant) we lose sight of the goal, which is making sure that Java remains a useful solution for developers' problems.
And sometimes, achieving this goal means telling those that want to make changes to the Java language "No."
A Little Context
Before I get ahead of myself, I want to explain what prompted my little tirade...
I've been a using the Java language for a long time: I started using the language professionally during the 1.1 days and have used every version up to and including the latest (Java 6 as of this writing). And, while the language certainly isn't perfect, it's been an enjoyable experience for me to use for the most part. I've written all manner of application with it, ranging from simple to complex, desktop to web, and so on.
Over the last couple of years of working with Java, I've begun to notice a trend in the projects that I've worked on: The code seems to have grown increasingly more complex and difficult for developers to both comprehend and maintain. Now some of this complexity is a result of Java being a wordy language (the Kingdom of Nouns, as it were), which results in more complex solutions than you might get out of some alternative programming languages. And some of this also was probably due to programmer error as well (as is too often the case). But I've noticed that a good portion of the problems seemed to correlate with extensive use of newer language features in Java, such as Generics - basically, any project that made extensive use of Generics seemed to turn into a maintenance nightmare. Quickly.
Now, I personally think I understand Generic Programming - and specifically Java's implementation of Generics - pretty well: I've used it successfully in many situations and to good effect. I'm sure there's more I can learn...but I at least know enough to not get myself in trouble.
Also, being that I've used Java for so long now, I've spent a whole lot of time without this feature in Java. As a result, I'm just as familiar with solving problems in Java without using Generics in my code at all. This has proven valuable, as it has given me insight into which solutions (Generic or non-generic) work best for a given situation. Unfortunately, I think I'm probably an exception to the rule1.
The fact is Generic Programming as a concept can be difficult for the average developer to understand - it requires a certain level of abstract thinking over and above what's typical in Object-Oriented Programming. Having Generics in Java - a widely used and popular language - means that a whole lot of average Java developers have now been given a tool they very likely don't fully understand how to use, which has the unfortunate result of decreasing productivity in a project when it's used improperly2.
And this is exactly what I'm starting to notice: Lots of code that is getting progressively harder to maintain and comprehend because of either too much, or simply incorrect, use of Generics.
Now this may only be anecdotal, but I've started seeing it frequently enough that it's caused me a bit of concern. And combined with my experiences with annotations - a feature that I've yet to find very useful - and with the upcoming proposal to add Closures, and with the idiocy of JSR-308 (yes, I think it's a ridiculous idea as I'll get into later on), I've started to wonder what the future holds for Java developers.
The Big Picture
Right now it doesn't look good.
For one thing, what are we really trying to accomplish by adding some of these features - and in some cases entire new concepts - to the language? Are these changes actually meant to address serious flaws with Java, or are they just for the sake of trying to keep the language relevant in the face of competition from the likes of C#, Ruby, Python, and so on?
I realize there are many factors at play when wishing to add features to Java, but if we don't take the time to look at the big picture and analyze what we really are trying to accomplish we're going to end up doing more harm than good - adding features to any language should never be undertaken lightly.
Now, I realize that there probably are people thinking about the problems inherent in changing a language, but unfortunately for Java, the process in place for considering changes to the language - the Java Community Process (JCP) - seems far too amenable toward adding to the language from what I can tell. This isn't so much a situation where there are bad apples in control of the process, or anything such notion - I'm sure there are many smart people (far smarter than me, in fact) helping to manage Java's evolution both as a language and a platform. My feeling is more that the process itself is to blame, making for a situation where adding features is all too easy to do.
Not Hating the Language
Even with all the issues I'm seeing with Java, I don't want people to get the idea that I hate the language, the community, or anything or anybody associated with it. I've spent a good part of my professional career in the Java world - and I'll likely continue to do so for the foreseeable future.
And contrary to what my original rant may have indicated, I want to see Java continue to be useful for software development. I've invested a great deal of my own time and energy in both learning and using Java and it's related technologies throughout my career...and I'd very much prefer that knowledge to not waste away due to what I see as misguided attempts to "improve" the language.
At the same time I'm also not a Java evangelist: Java may be the most popular language in use out there today, but I'm realistic enough to know that it is not the Golden Hammer. There are other programming languages better suited to using for certain tasks, and I'm more than willing to use - and in fact I have used - other languages when the need or opportunity has presented itself.
If anything, I'm a pragmatist: I use what works, and I continue to learn new concepts, technologies, languages, and tools in the hopes of creating the simplest solution possible that both solves the problem at hand and is easy for developers to understand and maintain.
If Java happens to fit the situation, I'll use it...if not then I'll try something else.
Killing The Golden Goose
But whether Java continues to be a part of my tool set will be largely dependent on what changes are made (or not made) to the language in the future and their potential effects on the developer community.
If the cumulative effect of language changes results in projects growing more complex and harder to maintain, or even if Java develops (or continues to develop) a reputation of being more difficult to use compared to alternatives, I (along with many developers, I'm sure) will start distancing myself from the language, and push for alternatives in the workplace. This is the scenario that I see unfolding across the industry if the powers-that-be ultimately decide to continue to mess around with core aspects of the Java language.
It's not so much that the concepts or features individually are bad in and of themselves - in many cases they appear to be sound ideas worth adding to Java - but the cumulative effect of all of these new features will result in Java becoming more difficult to work with as more projects make use of new features in ways that weren't originally considered, or possibly even desired. It's the unintended consequences that worry me, and that "road paved with good intentions" that we're all too familiar with.
I should also note that I'm not so close-minded to believe that the Java language should never be improved, either. There have been some successes in changing the language in the past (the improved for-loop, for example), and I think there will likely be some good ideas in the future as well.
My main concern is that if we continue down the "improvement" path blindly, or too eagerly, Java will eventually get bogged down under isn't own feature set - which will have been expanded under the the misguided premise of making the language "simpler" or "easier" for developers to work with. It will essentially get turned into an "everything language" - trying to incorporate all features and concepts from all languages.
This is obviously an impossible goal for any language to reach for, and no programming language that I've ever used has even come close to trying to accomplish such a thing. Programming languages are designed to address some specific area of concern, not every one imaginable. But Java's current course puts it squarely along this path: Trying to absorb ideas from other languages currently in use in the hopes of maintaining market dominance.
The irony of all of this to me is that the very people pushing to "improve" the Java language - all in an effort to keep it relevant and useful for developers - will cause it's eventual disfavor in the industry...for no other reason than because they didn't fully understand why Java came to be so popular to begin with.
[update: Part II is here]
1 - No, I am not trying to stroke my own ego here. I am just trying to point out that, from my own personal observations both on the job and elsewhere that I seem to have a much firmer grasp of the concept of Generic Programming than many other Java developers -- particularly when to not use it.
2 - If you are offended by this then odds are you are not an average developer. The very fact that you are reading this blog likely indicates that are a in the above average bracket - see this blog post.
I've received mostly favorable feedback about my rant regarding some of the issues I have with the evolution of the Java language. However, I obviously wasn't very detailed in explaining the problems as I see them, and rather than just leave a bunch of incomplete thoughts hanging out there (and giving the appearance of bitchiness) I think it's more appropriate to spell out the problems I see in a clearer manner.
A big reason I want to expand on this topic is the fact that if Java is to continue to be a popular and useful language, those of us that use the language on a regular basis need to discuss the implications of making changes to it. Adding features is not necessarily a bad thing, but there doesn't appear to be much coherent discussion about the implications such language changes can have. Or, if there is, it quickly degrades into a "Java Sucks"/"No it doesn't" back-and-forth crapfest.
The post on Jeff Campbell's blog I previously mentioned stated something along these lines, too: We've got to make it a point to shine some light on the issues surrounding Java's future. When we devolve into a mindless raving over whether Java is worth a damn or not (which I obviously did with my rant) we lose sight of the goal, which is making sure that Java remains a useful solution for developers' problems.
And sometimes, achieving this goal means telling those that want to make changes to the Java language "No."
A Little Context
Before I get ahead of myself, I want to explain what prompted my little tirade...
I've been a using the Java language for a long time: I started using the language professionally during the 1.1 days and have used every version up to and including the latest (Java 6 as of this writing). And, while the language certainly isn't perfect, it's been an enjoyable experience for me to use for the most part. I've written all manner of application with it, ranging from simple to complex, desktop to web, and so on.
Over the last couple of years of working with Java, I've begun to notice a trend in the projects that I've worked on: The code seems to have grown increasingly more complex and difficult for developers to both comprehend and maintain. Now some of this complexity is a result of Java being a wordy language (the Kingdom of Nouns, as it were), which results in more complex solutions than you might get out of some alternative programming languages. And some of this also was probably due to programmer error as well (as is too often the case). But I've noticed that a good portion of the problems seemed to correlate with extensive use of newer language features in Java, such as Generics - basically, any project that made extensive use of Generics seemed to turn into a maintenance nightmare. Quickly.
Now, I personally think I understand Generic Programming - and specifically Java's implementation of Generics - pretty well: I've used it successfully in many situations and to good effect. I'm sure there's more I can learn...but I at least know enough to not get myself in trouble.
Also, being that I've used Java for so long now, I've spent a whole lot of time without this feature in Java. As a result, I'm just as familiar with solving problems in Java without using Generics in my code at all. This has proven valuable, as it has given me insight into which solutions (Generic or non-generic) work best for a given situation. Unfortunately, I think I'm probably an exception to the rule1.
The fact is Generic Programming as a concept can be difficult for the average developer to understand - it requires a certain level of abstract thinking over and above what's typical in Object-Oriented Programming. Having Generics in Java - a widely used and popular language - means that a whole lot of average Java developers have now been given a tool they very likely don't fully understand how to use, which has the unfortunate result of decreasing productivity in a project when it's used improperly2.
And this is exactly what I'm starting to notice: Lots of code that is getting progressively harder to maintain and comprehend because of either too much, or simply incorrect, use of Generics.
Now this may only be anecdotal, but I've started seeing it frequently enough that it's caused me a bit of concern. And combined with my experiences with annotations - a feature that I've yet to find very useful - and with the upcoming proposal to add Closures, and with the idiocy of JSR-308 (yes, I think it's a ridiculous idea as I'll get into later on), I've started to wonder what the future holds for Java developers.
The Big Picture
Right now it doesn't look good.
For one thing, what are we really trying to accomplish by adding some of these features - and in some cases entire new concepts - to the language? Are these changes actually meant to address serious flaws with Java, or are they just for the sake of trying to keep the language relevant in the face of competition from the likes of C#, Ruby, Python, and so on?
I realize there are many factors at play when wishing to add features to Java, but if we don't take the time to look at the big picture and analyze what we really are trying to accomplish we're going to end up doing more harm than good - adding features to any language should never be undertaken lightly.
Now, I realize that there probably are people thinking about the problems inherent in changing a language, but unfortunately for Java, the process in place for considering changes to the language - the Java Community Process (JCP) - seems far too amenable toward adding to the language from what I can tell. This isn't so much a situation where there are bad apples in control of the process, or anything such notion - I'm sure there are many smart people (far smarter than me, in fact) helping to manage Java's evolution both as a language and a platform. My feeling is more that the process itself is to blame, making for a situation where adding features is all too easy to do.
Not Hating the Language
Even with all the issues I'm seeing with Java, I don't want people to get the idea that I hate the language, the community, or anything or anybody associated with it. I've spent a good part of my professional career in the Java world - and I'll likely continue to do so for the foreseeable future.
And contrary to what my original rant may have indicated, I want to see Java continue to be useful for software development. I've invested a great deal of my own time and energy in both learning and using Java and it's related technologies throughout my career...and I'd very much prefer that knowledge to not waste away due to what I see as misguided attempts to "improve" the language.
At the same time I'm also not a Java evangelist: Java may be the most popular language in use out there today, but I'm realistic enough to know that it is not the Golden Hammer. There are other programming languages better suited to using for certain tasks, and I'm more than willing to use - and in fact I have used - other languages when the need or opportunity has presented itself.
If anything, I'm a pragmatist: I use what works, and I continue to learn new concepts, technologies, languages, and tools in the hopes of creating the simplest solution possible that both solves the problem at hand and is easy for developers to understand and maintain.
If Java happens to fit the situation, I'll use it...if not then I'll try something else.
Killing The Golden Goose
But whether Java continues to be a part of my tool set will be largely dependent on what changes are made (or not made) to the language in the future and their potential effects on the developer community.
If the cumulative effect of language changes results in projects growing more complex and harder to maintain, or even if Java develops (or continues to develop) a reputation of being more difficult to use compared to alternatives, I (along with many developers, I'm sure) will start distancing myself from the language, and push for alternatives in the workplace. This is the scenario that I see unfolding across the industry if the powers-that-be ultimately decide to continue to mess around with core aspects of the Java language.
It's not so much that the concepts or features individually are bad in and of themselves - in many cases they appear to be sound ideas worth adding to Java - but the cumulative effect of all of these new features will result in Java becoming more difficult to work with as more projects make use of new features in ways that weren't originally considered, or possibly even desired. It's the unintended consequences that worry me, and that "road paved with good intentions" that we're all too familiar with.
I should also note that I'm not so close-minded to believe that the Java language should never be improved, either. There have been some successes in changing the language in the past (the improved for-loop, for example), and I think there will likely be some good ideas in the future as well.
My main concern is that if we continue down the "improvement" path blindly, or too eagerly, Java will eventually get bogged down under isn't own feature set - which will have been expanded under the the misguided premise of making the language "simpler" or "easier" for developers to work with. It will essentially get turned into an "everything language" - trying to incorporate all features and concepts from all languages.
This is obviously an impossible goal for any language to reach for, and no programming language that I've ever used has even come close to trying to accomplish such a thing. Programming languages are designed to address some specific area of concern, not every one imaginable. But Java's current course puts it squarely along this path: Trying to absorb ideas from other languages currently in use in the hopes of maintaining market dominance.
The irony of all of this to me is that the very people pushing to "improve" the Java language - all in an effort to keep it relevant and useful for developers - will cause it's eventual disfavor in the industry...for no other reason than because they didn't fully understand why Java came to be so popular to begin with.
[update: Part II is here]
1 - No, I am not trying to stroke my own ego here. I am just trying to point out that, from my own personal observations both on the job and elsewhere that I seem to have a much firmer grasp of the concept of Generic Programming than many other Java developers -- particularly when to not use it.
2 - If you are offended by this then odds are you are not an average developer. The very fact that you are reading this blog likely indicates that are a in the above average bracket - see this blog post.
IT in Corporate America
A new blog, Tales of an IT Director, just popped up with a fantastic first post. The comments are well worth reading, too.
Here's what he (or she?) has to say in general:
As many of the comments on that post make evident, there are many reasons for this phenomenon. In fact in any one organization that has a stifled IT department, there could be many reasons ranging from bad management to office politics to greed and so on.
But for the most part, no matter where you look in Corporate America, you'll see the typical reason being that IT is simply considered a cost center - somewhere that money has to be spent - not so much to improve the business in any way, but rather to simply keep things running smoothly. The prevailing reason for this is usually that IT is not central to the company's business: If you're selling widgets, you don't care if you have the best computer hardware and software out there. As long as the company can sell widgets and turn a profit, it's just fine with what it has.
If nothing else, Corporate America (and much of American society as well) by and large is pragmatic - it's not about having the best, so long as whatever you have gets the job done. This has worked extremely well throughout our history, and it's likely not going to go away anytime soon. This is something techies need to keep in mind when dealing with Corporate America.
Of course, this doesn't excuse businesses simply ignoring their IT department completely, nor does it make it any less frustrating to work in an environment where IT can't influence change in an organization. And in many cases I think this is to the detriment of the company in question, as you could potentially be ignoring a significant number of people that work for you...for no other reason than you can.
There has to be a balance between the two extremes, of course. Unless you're working in an IT-centered business, IT shouldn't be running your organization. At the same time, IT shouldn't simply be ignored and just treated as a money sink. Either extreme is bad.
Of course, trying to convince a company that's ignoring IT to listen isn't easy either. About the only thing you can usually do is try to influence change under the radar - using tools or technologies you know are better than what the company insists on using. But you have to be careful to pick and choose your battles here, as one wrong decision can blow up in your face big time.
But, if no matter what you do you can't seem to convince the powers-that-be to change their ways, sometimes you just have to walk away. I think those companies that fail to listen to their IT departments at all will be the ones that suffer in the future as other companies come along and clean their clocks with either better organized, or more efficiently run operations thanks to leveraging their IT departments strengths.
That first post was damn good...and I look forward to reading more. And I wish him (or her) luck on the new job.
Here's what he (or she?) has to say in general:
IT in Corporate America (herein after referred to as CA) doesn't have to suck. But by and large, it does. Why don't the smart people who work in CA get the opportunity to show how good they can be? Part of it comes by being saddled with inferior tools: bad version control, bad testing tools, bad test data, bad languages, bad platforms. However, these are technological problems that have good technological solutions. Why aren't they embraced? Why use Serena or Harvest for version control when there's svn and git? Why does it take 4 hours to find a user id in development to test a change that took you 30 minutes to implement when a daily refresh of test data would solve the problem? Why buy expensive monitoring software that accomplishes nothing more than sending out snmp messages to a blackberry when you can use nagios for the same thing? And finally, why do the people who propose these changes never, ever, ever get listened to?The post then goes through quite a few other issues, but I think this one paragraph basically sums up most people's frustrations with working in large organizations and/or large IT departments.
As many of the comments on that post make evident, there are many reasons for this phenomenon. In fact in any one organization that has a stifled IT department, there could be many reasons ranging from bad management to office politics to greed and so on.
But for the most part, no matter where you look in Corporate America, you'll see the typical reason being that IT is simply considered a cost center - somewhere that money has to be spent - not so much to improve the business in any way, but rather to simply keep things running smoothly. The prevailing reason for this is usually that IT is not central to the company's business: If you're selling widgets, you don't care if you have the best computer hardware and software out there. As long as the company can sell widgets and turn a profit, it's just fine with what it has.
If nothing else, Corporate America (and much of American society as well) by and large is pragmatic - it's not about having the best, so long as whatever you have gets the job done. This has worked extremely well throughout our history, and it's likely not going to go away anytime soon. This is something techies need to keep in mind when dealing with Corporate America.
Of course, this doesn't excuse businesses simply ignoring their IT department completely, nor does it make it any less frustrating to work in an environment where IT can't influence change in an organization. And in many cases I think this is to the detriment of the company in question, as you could potentially be ignoring a significant number of people that work for you...for no other reason than you can.
There has to be a balance between the two extremes, of course. Unless you're working in an IT-centered business, IT shouldn't be running your organization. At the same time, IT shouldn't simply be ignored and just treated as a money sink. Either extreme is bad.
Of course, trying to convince a company that's ignoring IT to listen isn't easy either. About the only thing you can usually do is try to influence change under the radar - using tools or technologies you know are better than what the company insists on using. But you have to be careful to pick and choose your battles here, as one wrong decision can blow up in your face big time.
But, if no matter what you do you can't seem to convince the powers-that-be to change their ways, sometimes you just have to walk away. I think those companies that fail to listen to their IT departments at all will be the ones that suffer in the future as other companies come along and clean their clocks with either better organized, or more efficiently run operations thanks to leveraging their IT departments strengths.
That first post was damn good...and I look forward to reading more. And I wish him (or her) luck on the new job.
Perfectionism
Via DZone: A post about Programmer Insecurity.
It starts:
However, I think some situations in the post that are being interpreted as insecurity are actually cases of something else entirely: Perfectionism.
At first glance they can both appear to be similar, but where an insecure developer would likely say, "Nobody's going to like my code, I'm going to release it", a perfectionist developer would say to himself, "I don't like this code, I'm not going to release it." Perfectionists make a choice based on code quality, while insecure developers make a choice based on fear.
On the surface they both appear to be the same kind of behavior to an outsider, but I think it's important to be aware of exactly which behavior you're dealing with - insecurity is typically bad since it's usually coming from the inexperienced developer who will never really learn the "right way" to do things without getting feedback, where perfectionism can actually be a benefit since the developer is focused on writing quality code and typically already has a good deal of experience under their belt.*
In either case, however, the overall argument that the post is making - avoiding walling oneself off from the rest of a team, or not communicating - is very much on-the-money. You've got to be communicating and working with your team no matter what. Otherwise you're asking for trouble.
This requires both the insecure developer to learn to have some confidence in their abilities, and the perfectionist to not try so hard to be perfect...and for project managers to keep them both in line.
*- Of course, perfectionists can get a bit carried away, too. Sometimes they'll have unrealistic expectations and get caught up in pursuing an impossible goal....not that I know anything about this, of course :-)
It starts:
I want to chat about something that I’ve never noticed before, but probably should have. There’s always been a stereotype out there of programmers being nerdy, anti-social people (Q: How do you know when an engineer is outgoing? A: He looks at your shoes!). But my revelation of the week is that most programmers seem to be really insecure about their work. I mean: really, really insecure.The post then goes on to list some examples of ways that developers try to hide code from (or at least not show the code to) their peers on projects, all of which certainly reinforce the idea that there's quite a few people out there in developer-land that are insecure.
However, I think some situations in the post that are being interpreted as insecurity are actually cases of something else entirely: Perfectionism.
At first glance they can both appear to be similar, but where an insecure developer would likely say, "Nobody's going to like my code, I'm going to release it", a perfectionist developer would say to himself, "I don't like this code, I'm not going to release it." Perfectionists make a choice based on code quality, while insecure developers make a choice based on fear.
On the surface they both appear to be the same kind of behavior to an outsider, but I think it's important to be aware of exactly which behavior you're dealing with - insecurity is typically bad since it's usually coming from the inexperienced developer who will never really learn the "right way" to do things without getting feedback, where perfectionism can actually be a benefit since the developer is focused on writing quality code and typically already has a good deal of experience under their belt.*
In either case, however, the overall argument that the post is making - avoiding walling oneself off from the rest of a team, or not communicating - is very much on-the-money. You've got to be communicating and working with your team no matter what. Otherwise you're asking for trouble.
This requires both the insecure developer to learn to have some confidence in their abilities, and the perfectionist to not try so hard to be perfect...and for project managers to keep them both in line.
*- Of course, perfectionists can get a bit carried away, too. Sometimes they'll have unrealistic expectations and get caught up in pursuing an impossible goal....not that I know anything about this, of course :-)
Subscribe to:
Posts (Atom)