Lebenslauf

A discussion in Quora inspired me to write this post. Though my German is quite poor and I haven't been using it since the University, the word Lebenslauf popped in my head. "Leben" is life, lauf (laufen) is "run" - a valid expression for the history of my experience as a programmer - everything we, programmers, do in our (professional) life is running programs, pardon the tautology.

I keep on saying that being a good developer is a state of mind, an ability to think as a developer, rather than practical knowledge of this or that programming language. Understanding of the processes is important. Syntax and rules of any language can be mastered.

I've been programming "for money" for about 16 years already. Before that I've been programming "for study" in the University for 5 years. Earlier at school I did my first steps on a monstrous device which we called programmable calculator. The device had no power independent memory and once I typed in my code (which was already a serious challenge) I could not save it. But still it was possible to play checkers on it, sometimes I had enough patience to type in such a long program and was lucky not to make any mistakes.

Then I had ZX Spectrum, it connected to my TV (for a display) and cassette recorder (for a memory). It was a real PC, it understood BASIC, so I learned it.

Then I got access to the University's Macs. They also had a kind of BASIC environment. At the same time I had access to a 286 with MS DOS and another version of BASIC. This was the first time when I discovered that different platforms can run the same code, probably with minor changes, and got my first "multi platform" development experience.

Then I got my first Pentium. Today my smartphone is more powerful than that PC, but in any case Pentium introduced me to the world of C and Pascal and later to Delphi with its visual components. It was so much fun to drag and drop an element to a form, without writing a single line of code!

The fun was over quite quickly when I realized that creation of the same button on a form took no more than 2 lines of code which was sometimes quicker than dragging-dropping and gave me much more flexibility. After all, nobody wanted boring interfaces with standard elements, for customization I had to create GUI elements in code, not in a visual environment.

Then I had to do some work in Visual Basic and Visual C++. All of those development environments were pretty much the same: a visual designer for simple GUI forms, a text editor for coding, a control panel with run / debug / stop / etc buttons, a debug output console. Their design was different, their menu items did not match, but the principles remained. Today's Eclipse and Xcode follow the same pattern.

At some point 2 great things happened and made my life easier:
- code completion
- online documentation

Since then learning of the new language and discovery of new features of various modules, libraries, classes became a well-known and practiced drill. Read the basics for 1-2 hours, environment setup, google for demos and examples, start typing, pay attention to the popups offering variants for code completion, go on! Well, it works for me and I guess for those who have already mastered previously the theoretical basis and acquired practical development skills at least in one or two languages. Beginners still need a properly systemized education.

Later on I had to do something in Java, PHP and SQL and all the time my approach worked fine: there's plenty of documentation and code examples, compilers and interpreters reported errors and indicated more or less precisely the place in code where the problem was, quite helpful.

But one day I got to the point when debuggers failed. The world of embedded development welcomed me. In my case it was interactive television. I could test and debug my applications in the development environment, on the simulators, they worked fine, but those simulators lacked real problems of real devices. In the real environment, when broadcasted to normal set top boxes, without any logging, I just saw my apps crashing and had no idea what happened there.

I faced the reality: all frameworks, development tools, debuggers are quite cool and nice to have, but they should be treated as something complimentary. In the real life I have:
- a good text editor with sophisticated search, code highlighting, lists of functions and objects, but by its nature it's just a "notepad";
- command line compiler with syntax error reporting in the best case;
- run time errors in the application which can be (theoretically) traced.

So in the new reality I started writing my code in such a manner that each function had log output at the beginning and at the end, with all its parameters and result. Depending on the environment I output the logged information to the "face" of the application, or save it to a file or even to a database. All means are good if they help me to find the bugs.

The same approach works for Android and iOS development too. Eclipse and Xcode offer powerful debugging features, but when I run my app simultaneously on a number of real devices I have somehow to collect logs from them. Why not to send them to the server and save there. Of course in the production version the logging shall be off.

Finally I got used to plain text editors and prefer them, also for writing my blogs :)