Re: Productivity

I accidentally discovered Google's Go language recently. I really mean that it was an accident. As much as I like to discover these things, it's really a matter now of asking "How did this come about? Why did someone go to that much effort? What problem were they trying to solve?"

After a very short while, I had read that it was C-like, but it looked rather Python-esque. In short, it looked unintelligible, full of mystical short-hands, unstructured, arcane, & a veritable nightmare for maintainability. It's exactly what people are claiming as necessities for "better productivity".

I was aghast. How can someone be more productive when they can't fathom the code they wrote last week? How can having a faster compiler (or an interpreter) make up for the fact that you can't understand the code?

When I think of productivity, my first thought is an IDE. By that, I really mean INTEGRATED, I mean DEVELOPMENT, & I mean ENVIRONMENT. Maybe I need to elaborate. If there is a way to do everything in the one application, from design & (some) documentation to deployment & issue resolution, then it's integrated. User documentation is distinct - not a part of development - & issue tracking itself should be accessible from elsewhere (not limited to devs). There should be some consistency in accessing all of the tools that a dev uses - the databases, web servers, editors, debuggers, multiple languages, preferably across multiple environments (for a given project). That is the environment, which these days should support agile tools & methodologies like continuous integration, pairing, reviews, etc.

The IDE is what people (devs) use to be productive. Shortcuts, gestures, menu layouts, integration points, plug-ins, etc, are what makes the dev work better & smarter, without losing their train of thought or having to drop everything to do one small task with an independent app (or on a remote system).

No amount of fiddling with a programming language can ever replace familiarity with a well-set-up IDE & experience of developing in a given environment.

I started looking for comparisons of Go with other languages. I saw someone comparing the number of lines of code. Do people still do that? I can't remember counting code for quite some time - like in assembler, when you had a very small memory on board. Since then, a file of source has not had a limit, & my typing has improved. Better still, my IDE does most of the completion for me, so I don't have to worry about long names for imported features or matching my curly braces, etc. My IDE will even fix up the formatting for me later. It's that good. It's not that hard.

For those wondering, I have been an Eclipse fan for a very long time - even when it was absolute rubbish - because I believe that a real IDE is the only way to real productivity. I believe in it so much that I convinced my current VP-Eng to invest in IntelliJ so that the whole team has the consistency of environment that allows good dev technique to spread across the team.

It's at that point that I shall end this - if you're a lone wolf coder who uses EMACS, then you probably think that Go is a wonderful improvement on Visual Basic. That doesn't make it any more likely for me to hire you. If you're a professional team-player producing commercial-grade product, then you're unlikely to give whizz-bang programming languages a second thought.

The first thought is always - cool, I wonder if they came up with some new concept I could use in the real world? In this case, the answer is "no".