Content

Living on the edge, noobs and Future geeks (programming)

Page is part of Articles in which you can submit an article

written by owen on 2015-Jul-17.

related image

The problem with living on the bleeding edge aka being a "future geek" (FG) is that you are obsessed with the "new" and "sexy". You have to be constantly looking for the next moonshot. You need to spend all your time watching 3 hour video lectures and reading shill articles that promote one thing or another - things that often do not really do anything more than create new ways to do old stuff - but have potential to be big in the future. You keep searching for that one thing that will change the programming game.

There are limitless new things that are coming out and countless anti-patterns that are useful in specific situations. Promises for example solves a problem that was created when people started passing around callback functions willy-nilly. Promises are not a new feature, it is a hand railing on a steep staircase - a bug fix - a way to curb a culture of confusing annoymous functions. Promises is like a thing you do because you are having trouble keeping track of your own convoluded code. It is not something that you NEED to do to be productive. It is a niche feature that is good to play around with and experiment if you are a future geek.

The Problem

And there in lies the problem; being productive and using all the fancy new stuff is not always the same thing. Living on the bleeding edge of programming, you need to always be experimenting and formating your harddrive because it is littered with unfinished projects and beta software. You cannot just wake up and start using generaters and be productive. Future geeks end up promoting new features to people who do not need them or even know how a callback function works. One or 10 new languages come out they are the first to jump on board and seave through them picking out advantages and disadvantages. This is a useful skill that takes YEARS to master.

The main gist behind this article is that there are some of us that exist to promote hype. We revel in it like pigs in mud. We are never working on the thing you think we are working on. We have beta browsers, beta OSs, beta APIs and a whole separate beta machine. Our entire work flow is beta.

Future geeks say things like "this how everyone will be doing it in the future" or "this is the direction in which everything is going". They are the same people that said STRUTS and XML templates were the future back. Today they do not even mention STRUTS. Because guess what? STRUTS is dead even though it was MVC and open source from as far back as 2000! Future geeks are like a boat on the sea, bobbing up and down dodging rocks. They disappear for a while, unreachable and comeback up with something else. Totally forgetting what they were working on 6 months ago. For the none-future-geeks amoung us this wonderful skill becomes a confusing nightmare.

When a future geek shows a shiny new thing - it really means that he has already mastered it and is reading up on something else that he is not ready to talk about. You on the other hand will spend your time testing out this new "thing" but you never quite get everything working as promised and noobs end up perpetually chasing this one new carrot after another because you never have enough time to master every new thing.

Even when you do catch up to future geeks, they will be long gone, unto something new because that is what future geeks do - THEY LIVE IN THE FUTURE. The future geek is easily bored with classic problems and small bugs. They have 100% control of thier working environment. FGs do not even need to spend time actually using these shiny new things, they can simulate usefulness virtually in thier head - "Yeah these generators will be good in X situation in a large project X with X members". Then they make one or two prototypes at record speed (in the dead of night) and they are done, running OFF TO SOMETHING ELSE! You like FOR LOOPS? Look here we have ITERATORS, they run faster and make your code 10x cleaner, easier to read and you can hide magic functionality by extending them! Its super cool! There is always a useful use for this or that which will save you tons of time.

The problem is the noobs cannot learn this way, they never reach a level of understanding of anything, they are like a fish out of water anytime an edge case pops up. Novices get into all sorts of problems when they try to use the new tech in the real world. They lack problem solving skills because they do not understand the "why" behind promises, or functors, closures, custom iterators or whatever. They learn promises then get stuck in trying to apply them to every problem they find. Nails when all you have is a hammer. They do not have the experience of running blind in a forest full of thorns and finding that one apple. They lack the classic-pre-poop programming knowledge to debug and analyse problems that they stumble upon. All the magic chain functions attached to pointers are really just new ways to do old things without the headache of actually writing all the stack manipulation code behind it. Oh yeah a "stack" is a type of array/map/list, you can look it up on stackoverflow. It is all the same thing but if you cannot comprehend what an array is then you are pretty much dead in the water.

An Example

Look at this problem that someone had. The bug is a result of a misunderstanding of variable scope and order of execution (jQuery);

        
function getGame(year){
        $.ajax({
        dataType        : 'json',
        type                : 'GET',
        url                 : GG.api_url + year,
        success: function(data) {
                return data;
        },
        error: function() {
                console.log('getGame Function Failed');
        }
        });
}

var response = getGame('1999');
console.log(response);

What results is that console.log(response) prints a empty string. I can almost instantly see the bug are because I have the classic problem solving experience. But not everyone has the experience to see such problems. But alas. Of course instead of pointing out the real reasons why the code was not working as expected, a future geek would see the problem and suggested a solution/feature with which to mask the misunderstanding such as this;


function getGame(year){
return $.ajax(GG.api_url + year);
}

getGame('1999').then( function(response){
console.log('success!', response);
}).catch( function(err){
console.log('fail!', err);
});

When u see a programmer doing something that shows a fundamental misunderstanding of programming, you have to slow down and stop being a future geek. You should try to get THEM to understand the "WHY" the code is not working instead of throwing some random new thing at them or promises or clojure or hip-hop or whatever. A promise is a comfort to a fool. Try to get them on their own feet so that they too can understand and sieve though all the crap that is being thrown at them. Let them develop a competence to think for themselves. Teach a man (or woman) to fish instead of giving them fish.

The solution works. It solves the problem of getting the console.log(response); to output the correct value. The bigger problem is that the new code solution loses all the flexibily/functionality that the programmer originally had and replaces it with a small, single use, dedicated line of code. Niether does it teach the programmer anything new nor WHY the original code did not work. All it does is dig the programmer into a bigger rabbit hole. A rabbit hole full of traps and more superfulous documentation. Follow these bread crumbs over here until you find a ginger bread house.

Conclusion

We want new productive, skilled programmers - NOT script kiddies with ADHD who follow us around on twitter, jump on every new thing that comes out, never completing any projects or pushing anything online or post on stackoverflow everytime they have a problem. Consume APIs all day until they run out of copy/paste code and meet up on problems. They will have problems. It is a certainty but you want them to learn and become better from these problems.

There are certain basic things that programmers need to understand when writing software; Scope, Order of execution, asynchronicity are fundamental in programming. There is no magic language or feature that will help you avoid learning about pointers and stack over flow and race conditions. You have to start somewhere but please stop making people chase carrots, leading noobs a stray. Instead pop out some cool new projects for them to look at and play with, introduce them to essential concepts, teach them to be awesome.

Addendum

Quality dropped this article in my lap recently by share coincidence. Its pretty good.

permanent link. Find similar posts in Articles.

comments

    Comment list is empty. You should totally be the first to Post your comments on this article.


comment