As I’ve mentioned before, I don’t really do much coding at work. Most of my time these days is spent greasing the wheels of a soul-crushing bureaucracy with my blood.
Well, that and attending meetings.
They are of a piece.
But occasionally I do still delve into slightly more technical stuff. Mostly it’s on my own time, but recently I’ve actually been learning a little (gasp!) while at work. I recently moved over to managing a new team. My old team used Java. My new team uses .net. I’ve never done any dev in .net so I decided to pick up a book, crack open Visual Studio and try to make myself a little less clueless.
The key word being ‘little’. As a manager, I feel it’s my duty to be mostly clueless. Otherwise, what do the developers on my team have to bitch about privately?
It’s been awhile since I’ve used anything Microsoft-related for coding. In fact, my last professional experience was using VB at my first job back in 2002. Before that I used Microsoft’s VC++ for some time during school.
Now having been primarily using Java the last few years, this is where I’m supposed to start whining about the lack of checked exceptions in .net or the way it uses “:” instead of ‘extends’ and ‘implements’ to denote that a class derives from another.
The problem is this, though: I don’t care.
It doesn’t matter.
None of the differences matter. Or at least they don’t matter relative to having good code. You see, the thing is, I’m more and more convinced that about 90% of all code just flat-out sucks. In light of this, I’ve come to the conclusion that the choice of language is largely a triviality.
Now, don’t get me wrong. I’m not disputing the assertion made by Sapir-Whorf that language affects how we think and solve problems. In Java, everything’s an object. This does have a lot of implications (good and bad). But you can write equally crappy code in an OO model or a functionally decomposed model. One may fit your paradigm, but neither precludes having a good implementation any more than the only one guarantees an elegant solution.
I’m not saying writing in 80x86 assembler is just as good as C#. It’s a snap to do text-parsing in Perl, whereas it basically sucks when you have to do it in Java. That said, I still maintain that the language you’re using is towards the bottom of the list of: things to worry about ™.
At the place I worked prior to where I’m at now everything ran on Apache mod Perl. When I started I had never used Perl and I immediately took a dislike to its simplistic, loose typing and lack of a spiffy IDE. In fact, when I was made technical lead on a new, high profile project, one of the things I and some other members of the team pushed for was that we should switch to Java.
Oh, Java has strong typing. There’s Eclipse. It has integrated unit testing. Developers will be easier to find (We were having a hell of a time finding good Perl developers). There were any number of reasons to make the switch, none of which I regard as completely wrong now. The thing is, though, it didn’t make that big of a difference.
Shortly after we made this decision we brought in our first batch of Java developers . I explained to them a bit about the project, gave them an initial implementation I had written of what they were to develop more fully, and set them loose.
They came back two weeks later with a train-wreck of obfuscated, hopelessly overcomplicated code. And it didn’t even really work. My boss after looking at both sets of code suggested we toss what they’d done and begin again using my initial prototype.
Of course, we eventually got rid of the people who’d written the code, but we kept soldiering on in Java (we did use Perl for some things). A year later we had something largely workable and a new “architect” was brought in to assess our work.
His first complaint: this isn’t in Perl. Java is not a dynamic language and doesn’t have closures. This should be rewritten in Perl.
Of course, that first craptastic implementation wasn’t the fault of Java. Any more than some of my frustrations with our old code base has been the fault of Perl. They were implementation details. Whatever we did wrongly in Java, I’m sure it would have been equally wrong in Perl. Maybe in different ways, but still wrong.
Worry about the code foremost. If you already have that nailed, then, maybe you can start worrying about what language it’s in. I haven’t seen many people get past that first step, though.
Well, that and attending meetings.
They are of a piece.
But occasionally I do still delve into slightly more technical stuff. Mostly it’s on my own time, but recently I’ve actually been learning a little (gasp!) while at work. I recently moved over to managing a new team. My old team used Java. My new team uses .net. I’ve never done any dev in .net so I decided to pick up a book, crack open Visual Studio and try to make myself a little less clueless.
The key word being ‘little’. As a manager, I feel it’s my duty to be mostly clueless. Otherwise, what do the developers on my team have to bitch about privately?
It’s been awhile since I’ve used anything Microsoft-related for coding. In fact, my last professional experience was using VB at my first job back in 2002. Before that I used Microsoft’s VC++ for some time during school.
Now having been primarily using Java the last few years, this is where I’m supposed to start whining about the lack of checked exceptions in .net or the way it uses “:” instead of ‘extends’ and ‘implements’ to denote that a class derives from another.
The problem is this, though: I don’t care.
It doesn’t matter.
None of the differences matter. Or at least they don’t matter relative to having good code. You see, the thing is, I’m more and more convinced that about 90% of all code just flat-out sucks. In light of this, I’ve come to the conclusion that the choice of language is largely a triviality.
Now, don’t get me wrong. I’m not disputing the assertion made by Sapir-Whorf that language affects how we think and solve problems. In Java, everything’s an object. This does have a lot of implications (good and bad). But you can write equally crappy code in an OO model or a functionally decomposed model. One may fit your paradigm, but neither precludes having a good implementation any more than the only one guarantees an elegant solution.
I’m not saying writing in 80x86 assembler is just as good as C#. It’s a snap to do text-parsing in Perl, whereas it basically sucks when you have to do it in Java. That said, I still maintain that the language you’re using is towards the bottom of the list of: things to worry about ™.
At the place I worked prior to where I’m at now everything ran on Apache mod Perl. When I started I had never used Perl and I immediately took a dislike to its simplistic, loose typing and lack of a spiffy IDE. In fact, when I was made technical lead on a new, high profile project, one of the things I and some other members of the team pushed for was that we should switch to Java.
Oh, Java has strong typing. There’s Eclipse. It has integrated unit testing. Developers will be easier to find (We were having a hell of a time finding good Perl developers). There were any number of reasons to make the switch, none of which I regard as completely wrong now. The thing is, though, it didn’t make that big of a difference.
Shortly after we made this decision we brought in our first batch of Java developers . I explained to them a bit about the project, gave them an initial implementation I had written of what they were to develop more fully, and set them loose.
They came back two weeks later with a train-wreck of obfuscated, hopelessly overcomplicated code. And it didn’t even really work. My boss after looking at both sets of code suggested we toss what they’d done and begin again using my initial prototype.
Of course, we eventually got rid of the people who’d written the code, but we kept soldiering on in Java (we did use Perl for some things). A year later we had something largely workable and a new “architect” was brought in to assess our work.
His first complaint: this isn’t in Perl. Java is not a dynamic language and doesn’t have closures. This should be rewritten in Perl.
Of course, that first craptastic implementation wasn’t the fault of Java. Any more than some of my frustrations with our old code base has been the fault of Perl. They were implementation details. Whatever we did wrongly in Java, I’m sure it would have been equally wrong in Perl. Maybe in different ways, but still wrong.
Worry about the code foremost. If you already have that nailed, then, maybe you can start worrying about what language it’s in. I haven’t seen many people get past that first step, though.
11 comments:
Totally agree. The guy I want on my team is the critical thinker who is able to find clear and simple solutions, not a "LanguageXYZ-certified expert" who happens to knows semantics and syntax but somehow overcomplicates every system he touches.
Yeah, the importance of having good people is something I only implicitly touched on but really is the key here.
I don't know that I did a spectactular job of explaining myself, but my meaning wasn't quite that language doesn't matter *at all*.
It's more just that the deficiences or strengths of any given language are far less meaningful in most cases than the thought (or lack thereof) put into the code itself.
You can work around the shortcomings of a given language. It's a lot harder to work around fundamentally crappy code.
Eclipse has support for Perl with EPIC and Perl is one of most testing oriented languages. Look at Test::More (core module) and big number of testing modules on CPAN.
chorny-
Thanks for the comment.
We did use Test::Simple and Test::More for unit testing, but it was we had a large, fairly monolithic clegacy code base which made it hard to backfill tests to the code. That was not the fault of Perl, of course.
I also tried Epic briefly. It was fine for running standalone Perl code, but I was never able to get our webapp (within Apache mod perl) to run locally and connect via the IDE. I'm guessing it could be done with sufficient effort, though.
Isn't this, in many ways, the core purpose of UML? Model your solution in a generic way and then implement using the language of choice?
@dantelope
are you suggesting you design before you code. Blasphemy ;)
UML? Meh.
I am less and less a fan of BUFD (big upfront design). This coming from someone who used to spend hours and hours racking his brain before writing a line of code.
Nowadays, I'm more of an 'emergent design'/TDD fan. Though that doesn't mean I think one shouldn't think things through (and people like Beck, etc have never argued you shouldn't *plan*).
Thing is, planning is useful. But as the Prussian general Moltke said 'No plan ever survives contact with the enemy'.
I think even when people plan things out in an abstract way, they're still likely to make arguments in favor of one language or another. Even though I wrote this blog, I'm the same way. Right now, I'd still probably argue for Java instead of Perl or .net.
So, this is as much a reminder and enjoinder to myself as to anyone else.
I like turtles.
More importantly, I'm a big proponent of identifying the problem and coming up with a simple (and realistic) solution before deciding on the implementation details. Luckily, most of my team is made up of guys who grasp this idea. We're mostly a C++ and Java team, but our Java codebase is on average cleaner and easier to understand (as can be said for Java in general).
Unfortunately, we also have old and mostly cryptic core C++ code that has been written by cave-dwelling, shower-avoiding, WoW-masters with too much spare time on their hands. Their sexual attraction to Design Patterns and unnecessary complexity is only overshadowed by their desperate need to prove their l33tness in the eyes of their code reviewers and coworkers. Granted, the code "works", but you'd have a much easier time understanding a woman's emotions during her menstrual cycle. Nobody wants to touch the code (much like a menstruating woman), and there are no active plans of rewriting it.
It seems like the overhead and cost of re-implementing the core of a service infrastructure outweighs the benefits, at least in the management's eye.
With that in mind, I'm still a big fan of Perl. Mostly because I don't understand pointers ;)
Haha.
Yes, cleverness in code is always to be avoided IMO. If you find yourself thinking about how clever you just were with your code, rewrite it.
Cleverness, more ofteh than not, is the enemy of clarity.
Oh, and I miss pointers. And C++. :(
what about brute force?
it is, perhaps, no surprise (or coincidence) that i prefer
a) brute force
and
b) bash as my weapon of choice
though these days I do find myself doing more with perl, and wishing for objects to tinker with.
is java or (insert random suggestion here) a viable alternative to perl/bash for system administration and data/output manipulation/brokering?
i suppose this is why python, etc came into existence. I'm slow to pick up on new tools when my old ones bludgeon my problems away just fine and dandy.
then again, do sysadmin languages and programmer languages really have to be different? are they really different? is it just a stereotype perpetuated by the crown to keep the peasants in line?
@tedley
That's a totally fair point. I think there's natural tendency in a blog like this (or any time you take a stance in *reaction* to something) to make grand pronunciations, because nuances tend to take the fire out of something.
That said, I was really only thinking about application programming and not sysadmin stuff. Using Java for sysadmin would be pretty retarded. So, in that sense, language *does* matter.
I was more talking about the dogmatism that occurs about a particular language (or feature of a language) with the precondition that both can pretty much do what you need them to. Again, writing webapps in C would be pretty painful.
The best example I can think to illustrate my original point was the conversation I mentioned in the blog about hte architect who said something to the effect that Perl should always be used in preference of Java because Java doesn't have closures. Usually, it's not quite as extreme as that, but people get very attached to very (in my view) trivial things (He, of course, would argue it was not a "trivial" thing).
Another less extreme example would be when you have people who have used IoC argue you *have* to use it to make your code testable. "Oh, you need to use Spring".
Except you don't. You can solve many of the same problems without having to use IoC. The lack of IoC doesn't make or break your ability to accomplish any of hte goals IoC seeks to accomplish, you just need to go about them in a different manner.
Post a Comment