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.
