Showing posts with label programmers. Show all posts
Showing posts with label programmers. Show all posts

Saturday, 17 November 2018

Can you Learn to be a Programmer...

I was asked this very interesting question this week... "Can you learn to be a programmer?"... Lets be clear, the question is can you be a programmer, not can you learn to program.  I believe anyone can learn to use a programming language, to drive their computer to perform a task for them, after all computers are tools and everyone can learn to use any tool.

Be a person trying to write a batch script, create a spreadsheet to do their home accounts, throwing together some python to process a few text files or creating a whole compiled program of some kind, pretty much anyone can make themselves, with a book, a little internet searching and enough time, appear on that bell-curve of skill.

Does this therefore make everyone a programmer?  I think it most certainly does not.  I can pick up a saw and a hammer, I have in my time knocked out some dovetail joints and repaired the odd chest of draws, does that make me a carpenter?.. NOPE... And likewise, if that self same carpenter picked up their laptop and wrote a bit of C# to tally the number of planks they use they are not a programmer.  He has programmed, just as I have knocked some holes in wood, but one does not transgress nor deign to call oneself the other; it would be insulting to the skills in the craft inherent to each's own chose trade.

And there's the key phrase, chosen trade.  Anyone can program, but to be a programmer you've got to choose to apply yourself, either through some personal interest, a passion, experience and ability at the task.  You must strive to learn, to expand and to know your craft.

Very many folks come to try and be a programmer after learning simply to program, throwing a few lines of code together is not enough; certainly not in my mind it is not enough.

Why do I say this?  Well, I sat down this week with several lovely students at my old Alma Mater, and I was bereft to hear from Computer Studies and Systems and even Software Engineering Students that they hadn't really programmed anything before, they asked me "how do you get into programming", "what should I program to get better at it [programming]" and they indeed asked "can you learn to be a programmer".

I of course come from a different place in time, which they pointed out with their shock and awe, when I answered they should write programs to support what they are interested in, if they're interested in video film making, write a video encoder or player, if you like games, write some games, if you're not sure just write some programming tools you can use... Say you (like me) repeatedly have to created code to write our structured data (say XML) then write yourself a tool to generate that code in whatever language you need it (I have one written in Python, which generated XML loaders for C#, C++ and Python itself).  I did this because I needed a tool, specific to my needs.  But these students were a little shocked, they asked "why not just get it from github (or wherever)"... And they're right, you could most likely find exactly the solution you want from else where...But... Would you learn anything doing so?... No.

Folks, students if you are reading, you are there to learn, we are in the programming craft to learn, you will not learn without doing.  So, yes use whatever is at hand, get the jobs done, solve the problems of today, by using libraries or leveraging a package manager to get other resources into your projects.  But if you opt to use a library today (like I used tesseract recently to do some OCR for me) when you're done, take a moment, take stock, look what that library does, think how you might do it, try to implement your own even (variations on the same theme).

In this way you will learn more and experience more and feel more confident in your own skills.

Sunday, 15 January 2017

Developer : How Big Is Your Floppy?

What are they teaching kids today?  I've just had the pleasure of talking to a gentleman whom has received a degree in computing from Stanford in the United States, I'm sure he paid a fortune for this education... He didn't know how many bytes were in 1.44 megabytes.

He literally said "about 1.44 million".  This was related to an old format of file being taken and converted for transmission over Wifi, the size of the data was relatively immaterial, but the source; historically speaking; was a 1.44 megabyte HD floppy disk, and though the floppy was long gone, the format of the file with it's limitation was not.

It got me thinking though, he was sat there, I'm sure earning more than myself, and he only had a jogging mental map of memory sizes, so I took a look at the Standard website, particularly the CS101 course... sure enough:
  • "Byte" - unit of information storage
  • A document, an image, a movie .. how many bytes?
  • 1 byte is enough to hold 1 typed letter, e.g. 'b' or 'X'
  • Later we'll look at storage in: RAM, hard drives, flash drives
  • All measured in bytes, despite being very different hardware
  • Kilobyte, KB, about 1 thousand bytes
  • Megabyte, MB, about 1 million bytes
  • Gigabyte, GB, about 1 billion bytes
  • Terabyte, TB, about 1 trillion bytes (rare)

Yeah, a terabyte is rare?... NOPE!... A kilobyte is not "about" anything it is exactly 1024 bytes, and a megabyte is not about 1 million bytes, it's exactly 1024 kilobytes, therefore exactly 1048576.  By using this "about" prefix they had made a megabyte sound 4.8576% smaller than it actually is, that's not insignificant!

And so forth.

This looks very much like an out of date page, but it is the first search result from google too!

Even wikipedia gets the right values before this page did!

Friday, 21 November 2014

Story Time - Programmers Sleeping

Once upon a time I was a loud mouthed, big headed, my code could never be wrong, I'm invincible... 


Kind of programmer...

Over time you will, unless you never go out, you will meet programmers who know more things about you, either about everything, or about certain specific things, and you have to learn to evolve and understand they just know more than you.

They might have been through the problem you're wrestling with for the first time, they might have worked on the base system, or they might just recognise the pattern of the problem you've got.

So don't just dismiss these folks, they know what they're talking about, and even if they don't take it, analyse where they've gone wrong and you learn from it, do not do what happened to me...

We're about six years ago now, and we had a graphical system, this system had been running games from many different sources for several years (about four) so it was a tried system, the hardware was known, it had known bounds and I personally had handled maybe a dozen different people working on it before, their games all worked, and I turn around and can see 32+ games working still to this day.

One thing I don't see right now however is this game from this one guy, because... He's a douche, and I don't actually see him because he no longer works here, of all the folks in his department he was the first gone of his own accord, because... well because he was one of those programmers, one of those people who never really grew up, he considered himself above reproach, he was perfect, his code was perfect and any issues were yours.

So, let us just dive off to games, games at their heart have a loop, which reads/updates the data, plays sound and critically updates the graphics, that's the core of all games from Battle Chess to Call of Duty, this game loop is time critical, if you delay the update or the display the game will look like it's stuck, or juddering, people often call this lagging, but the problem is that loop for interrupted to things didn't look smooth or play smooth.

But computers are fast! So for most trivial problems the data can be updated and the display redrawn faster than the hardware is actually limited to, so the hardware is done and sat idle waiting for the next rendering of the game.

This is called the sleep or delay, and games use this time to do other things, like perhaps check for updates or sort data.

Now this delay has to be controlled, you have to make it a fixed length, or set it up so that the machine works out how long the work it did was since it last drew the screen, and wait for the difference in time to smooth out the drawing.  This makes the game play smoothly, makes animation behave smoothly...

So, if you have a loop and you just randomly sleep for X time, but then the data processing you're doing takes longer than X the game will look like it's stuttering.... How can this happen?...

Well, how about this code:

while ( true )
{
    Update();
    Draw();
    Sleep(1000);
}

So, we update, then draw ,then sleep for 1 second.. okay, but what if the processing in "update" takes 800ms, how long will we take between draws now?... How about 1.8 seconds!  So that cycle the game will look like it took nearly twice as long to draw, and animations will stutter.

What has this got to do with programming?

Well, once upon a time this very code above strolled into view, and the programmer working with it kept saying "your machine is making my game stutter, it runs fine on my machine"... His machine being a more powerful machine with dual core and more RAM... So I pointed this out, he then set about trying to explain it all away.

When he then showed me this code, I just pointed at the sleep and went back to my desk, it was not my job nor part of my remit to work or debug his code, I saw this problem was simply he wasn't changing how long he slept for, but also he was very confrontational, because the contract with the "Sleep" function on Windows (the platform we were using) is not quite what most programmers expect.

You see sleep will go away and pause a process/thread for X amount of time, and it will come back to continue processing up to or after that time... Up to or after... Not immediately, so in a game you can't guarantee that the Windows Scheduler will pick up your thread and come back to your program immediately after 1000ms above!

I told this chap this, and he flat argued, he even went so far as to print out the MSDN documentation pointing out that I was wrong, and I was a wanker, and he went on a tirade around the office.

It was only later I went back and pointed out that he was referencing the sleep function for Windows Mobile, not Windows XP, and going to the right Operating System on the MSDN page, it said "upto or after the delay".

He didn't say sorry, he didn't say anything, he actually sat down and said "fat wanker".

Lucky for him my boss was stood right there and heard him say this, so I left them to it, but I never spoke to this cunt every again, he left the company soon after, he'd apparently agitated not just me but about six other people, arguing when they knew their stuff and then insulting them.

He was perhaps the third worst person I've worked with at this company.


For information about how sleep works, and how variable it can be, check this out.

Thursday, 3 April 2014

Code Line Numbers

I had a programmer sat with me the other day, he seems a good one too, though I've not seen his actual code.  And he surprised me by peering at my development environment and saying...

"How can you program without line numbers on?"

He was serious, we were exchanging information to ensure I wrote code to meet his coding standards... So why not program with line numbers... Well, I could be annoying and say, I don't write BASIC, so I don't need line numbers... I also don't count K-Locs as a form of reward as to how busy I've been, nor use it as a measure of how productive I am... So really I have to ask myself the opposite, "Why don't you program with line numbers on Xel?"

And the simple answer for me is experience.  Maybe you're different, and you like line numbers, if so "This is not the article you are looking for, move along... Move along"... But to answer for myself, it is simply because I'm human, and the human mind likes to see patterns, it likes to see things and tries it's hardest to impose some semblance of meaning into them.  And for me, if I turn line numbers on then I expect 5 to follow 4, and 4 to have followed 3, and 2 to have come before 3 but after 1... It's an order, and in modern code it is an incorrect order because we should be writing, if not object orientated, then at least functional code.

Functions can be called in any order, objects can be instantiated and used differently by different users, your code itself might do one sequence one way today but a different sequence tomorrow.  The functions themselves still do the same single job with the same input, as per their definition, but code as a whole is no longer linear.

So over time my personal experience has told me to group my code into a simple, but not formal - until this blog post - order, which is "Constructors at the top", then the functions defined "in order of frequency of use", so if you have an update function called all the time in a class, put it at the top, so its easy to spot after your constructors.  Especially in a language like C++ where your constructors can be very brief - or should be very brief, if they're not go rear Scott Meters & Bjarne Stroustrop on the topic!

And then functions are laid out in order of use, least used or single call functions are at the bottom.  I've just come to this pattern, its quite hard to even define it here in words, I suppose I should give code examples, but I'll leave this for another day and come full circle to answer the question "How can you program without line numbers on?"

"Code/Function use is not linear, don't give any indicates to your mind that it is, and if you're going to argue about the contents of one function, your function is too long, break it down into sub-functions which will fit onto the screen as a whole and so you don't need line numbers you can see the whole function in a single pass of the eye".