But, I don’t Write Java That Way!
One of the things I do in my writing is exploring different technologies and programming languages. I write about a lot of things I am not an expert in. I write about colonizing Venus.
Read more: Why Colonize Venus Instead of Mars
Does anyone seriously think I am a trained space engineer? I write about microprocessors architecture, stuff like pipelining, branch prediction, instruction decoding, you name it. Yet I am not a trained chip designer.
Read more: Why Pipeline a Microprocessor?
I am not your expert advisor on technical matters. I am a popularizer. I am a tourist in the land of technology. I go visiting and I write back about what I see. I give you the out-of-the-box experience. What does some technology or programming language look like to somebody who unpacks it the first time and takes it for a spin?
So when people go, “You should not be writing about Python” until you know it better or “You clearly don’t know enough about C# to write about it,” then those readers are entirely missing the point. I am giving a beginner perspective, and that is an important one. Let me take a step back to explain why.
I used to work at a company where we made complex 3D modeling software for industry experts such as geologists, petrophysicists, reservoir modelers, well drillers and a whole bunch of professions and titles that I don’t even know. This software had hundred of dialogs, each of which could have 10 or more tabs with several dozen options to toggle on each tab. In addition we had dozens of different ways of displaying the same kind of data. We could give you a 2D view, a 3D view, an intersection view or many other things of a whole host of different specialized objects.
Read more: Data Objects in Geological Modeling.
In short, this was complex stuff and one of the major problems we faced was that customers were starting to move to competing software. But how could this be? Whenever we added new features, we asked the premier expert on our software at all the big companies for feedback. We gave them what they wanted. One advanced feature after another.
That was the problem right there. We only listened to the experts. We forgot to listen to the regular users. To the beginners. While I had always cared about user experience, this was really the big beginning for me. I began user testing and studying GUI design. I began testing less experienced users. It quickly became clear that usability had not been taken serious enough. I started pestering management about this. A bit out of the blue, they made me head of UX for the company. I guess that is what you get for being a pain in the neck.
Read more: Understanding Visual Layout in GUI Design.
When I did UX training, the response to a user who could not figure out our software was never: “You are stupid and need to practice using our software more!” Blaming the user is not very productive. If beginners cannot use your software correctly, then you need to consider redesigning it. That may not always be an option, but then you have to be humble, and admit you have a problem instead of shifting blame on the user.
A programming language cannot be defined in terms of what a star performer with all the expert knowledge is able to perform. It has to be viewed through the lens of what an average developer is able to achieve. And in this regard a language is not merely the syntax and semantics in the spec document. Rather a language is the whole ecosystem that comes with it. The community, practices, tools and libraries. Say there is an excellent way of writing Java code, but if it is not the dominating style practiced by the community then that is frankly irrelevant. Your average new developer is going to pick up the style of coding that dominates the language community.
Read more: Object-Oriented Coding: Java vs Go.
This community is the product of all your past mistakes. If a language went down the wrong path early in its practices, then that will likely haunt you for a long time. It thus pays to get the fundamentals right early on. This is IMHO part of the “features” of a language even if it is not mentioned on any spec document.
Thus if you complain about my coding style, I would challenge you to demonstrate that it goes against the community advice. That you have your own unique and superior coding style isn’t all the relevant to the discussion.
Okay… I suppose I just put myself in the firing line.