Tutoring: Working with Students

I was tutoring for years, and if there's something I miss at my current workplace is the students around me: they were an inevitable part of my teams since january 2005, until I left EPAM last summer.

(Please note: these guys were mostly at their first or second workplace, and still doing university: in Hungary, it's common that young software engineers are taken as full- or part-time employees while still studying.)


Working with students is hard. It's hard because even if they know the theoretical answers, and didn't forget them right after passing the exams, it's not yet burned into their brain with "learning-by-doing". They're not confident enough to work in an elegant way.

The Beauty of MVC

The widely-known Model-View-Controller pattern was published first in 1988 (by Krasner & Pope). It was originally indented to represent user mental models and so on, and while some people may want to superseed it with new paradigms, today I want to talk about its beauty.

Because MVC not [only] models the user's mental model, it models the world.

It's nothing else, than a practical implementation of Hegelian dialectic.

Let's start with a simple scheme. The user sits besides a computer. [S]he looks at the monitor, while trying to achieve something by pressing buttons on the keyboard, or trying to wander around with a mouse or on a touchpad.

Generally, we don't really distinguish between the different input peripherials with MVC. The monitor is the output, other human-computer interface peripherials are for input, it's that easy:



(Based on image of flickr user ntr23 under Creative commons license)

A consistent naming scheme proposal for Javascript callbacks

Basically, there are two schemes of javascript callbacks:


function(other_params, onSuccess, onError){
}


and

function(other_params, callback){
}


where callback is called with:

callback(null, params..)

on success, and


callback(exceptionobject)

on failure.

What if we would choose the first one, but instead call them differently?

function(other_params, _return, _throw){
}


Imagine the body:

function(other_params, _return, _throw){
 var params;/*...*/
 some_other_async_operation(params, function(result){
    return_(result);
 }, function _catch(e){
    throw_(e);
 } 
}

Is it more clean what's happening here?

I came to a level, with some helper functions:

(function(x){
    var return_ = arguments.callee.getCallback(arguments);var throw_ = arguments.callee.getErrorCallback(arguments);
    var result = {};
    try_(result, "=", db.view.call_(db, "xxx/xxx", {startkey:x+"_", endkey:x+"_z", group:true }))(function(){
        console.log("success");
        console.log(result.length);  
    }).catch_(function(exception){
        console.log("error");
        console.log(exception);
        throw_(exception);
    }).finally_(function(){
        console.log("returning");
        return_();
    })();
})(10);

Opinions, ideas?

Software and Design

Recently we have seen a rise of "designers" in engineering practices, particularly software engineering. While visual designers and artists were always present in every engineering field - the frescos weren't painted by the architects of the basilicas most of the time - it's strange to see opinions of software engineers taken as "they don't understand design anyway"

Because software IS design.

A software in itself is nothing more than a plan, an explicit, consistent set of thoughts which we give to the computer to build from. The masons of the virtual dreamcastles aren't us, the programmers: we merely give the plans to the computer to build it from bits and bytes as bricks once turned on.

Our thoughts are explicit, because the computer can think only one way.

Our thoughts are consistent, at least, from the computer's perspective. Non-consistent thoughts get a so-called syntax error, and would never start on the user's machine. Any inconsistency means the literal crash of the program.

Design in software engineering is the blood-swearing process of getting an idea consistent and in harmony to its environment.

To the contrary, creating some nice buttons in our terminology is NOT considered design: one of my former bosses called it "masturbation". Creating buttons which are consistent and are in harmony with the user's train of thought and of the application, simplified to the end, but not a single step further IS design, and it's really hard work.

What surprises - and saddens - me if I get a "design" document from a designer which clearly wasn't distilled this way what we call design.