Linked by Thom Holwerda on Wed 27th Mar 2013 10:45 UTC
General Development "Programming is hard. Don't ever feel bad because you aren't as good at 'just googling it' as the person next to you. Don't ever let hackathon snobs talk you out of creating the next Twitter for cats or Yelp for public washrooms. Even the dumbest ideas (like trying to make animated polygons disappear and reappear) will help you improve as a programmer. Learning to program is largely about learning to learn - and the best way to learn is to do." For some reason, I love this short story.
Order by: Score:
I miss the retro years
by AndyB on Wed 27th Mar 2013 11:43 UTC
AndyB
Member since:
2013-03-22

This story reminds me of my youth writing Spectrum BASIC code for fun. I used to spend hours making patterns on the screen, or drawing line art using PLOT and DRAW commands. The code would go on for 100's of lines to produce something average at best!

What it did do though was give me a sense of logic, many of my friends at the time couldn't program a computer, nor did they want to. I think if you couldn't get your head around BASIC then programming was not for you!

In case you're wondering, I now do most of my coding in PHP, Javascript, and HTML. Very different programming objectives, but still the same logical sequences picked up all those years ago!

Reply Score: 2

RE: I miss the retro years
by lucas_maximus on Wed 27th Mar 2013 12:57 UTC in reply to "I miss the retro years"
lucas_maximus Member since:
2009-08-18

I remember when I first understood recursion and it was like magic.

When I first understood the "this" keyword in JavaScript ... I felt like a God.

Edited 2013-03-27 13:01 UTC

Reply Score: 3

Only natural to improve
by error32 on Wed 27th Mar 2013 11:55 UTC
error32
Member since:
2008-12-10

It is only natural that when you start coding it will give some horrible code. Every developer who looks back on his older work will notice some 'facepalm' constructions in there.
Every skill whatever it is takes time to get to grips with. Nothing to be ashamed of, just remember not to bring it as an example to a job interview for a developers position ;)

Reply Score: 4

RE: Only natural to improve
by jburnett on Wed 27th Mar 2013 13:07 UTC in reply to "Only natural to improve"
jburnett Member since:
2012-03-29

I don't know, I would probably hire a candidate who could pull up code from when he was 8 in addition to whatever he was doing at the present. It would speak volumes on the meticulous nature of the person that they still have it. And it would show a life long passion.

Reply Score: 3

RE[2]: Only natural to improve
by Alfman on Wed 27th Mar 2013 14:39 UTC in reply to "RE: Only natural to improve"
Alfman Member since:
2011-01-28

jburnett,

I played alot with graphic effects. For sentimental reasons, I just searched for and found my old qbasic and pascal development collection from the 90s only to discover that none of it will run under windows 7 64bit. I feel sad that I don't have a machine / OS that can run them anymore.

Reply Score: 2

RE[3]: Only natural to improve
by sbenitezb on Wed 27th Mar 2013 14:55 UTC in reply to "RE[2]: Only natural to improve"
sbenitezb Member since:
2005-07-22

jburnett,

I played alot with graphic effects. For sentimental reasons, I just searched for and found my old qbasic and pascal development collection from the 90s only to discover that none of it will run under windows 7 64bit. I feel sad that I don't have a machine / OS that can run them anymore.


If only emulators existed...

Reply Score: 3

RE[3]: Only natural to improve
by Laurence on Wed 27th Mar 2013 15:27 UTC in reply to "RE[2]: Only natural to improve"
Laurence Member since:
2007-03-26

jburnett,

I played alot with graphic effects. For sentimental reasons, I just searched for and found my old qbasic and pascal development collection from the 90s only to discover that none of it will run under windows 7 64bit. I feel sad that I don't have a machine / OS that can run them anymore.

TurboPascal binaries stopped running on Windows since Vista. I remember that day well as I needed to bang out a quick CLI program for work so thought Pascal would be my best bet (not having been sold by .NET at that point). Needless to say, I did end up using .NET and was presently surprised at just how much things had improved.

If you want to reminisce, then I'm sure they'd work in DOSbox (open source DOS emulator).

Edited 2013-03-27 15:28 UTC

Reply Score: 2

RE[4]: Only natural to improve
by Alfman on Wed 27th Mar 2013 16:40 UTC in reply to "RE[3]: Only natural to improve"
Alfman Member since:
2011-01-28

Laurence,

"If you want to reminisce, then I'm sure they'd work in DOSbox (open source DOS emulator)."

Apart from a few glitches here and there I agree it's extremely useful for reminiscing! The one which kills me is control-break not working like it's supposed to such that the emulator needs to be restarted to exit many qbasic programs. Maybe I need to configure something, but it should just work.


I really have to thank you for suggesting it because I just tried the windows version for the first time and it turns out it has full midi MPU401 emulation. My midi audio programs stopped working correctly once I lost the working hardware. None of the emulators I ran ever had full support (including linux dosbox via timidity). I'm listening to some of my music compositions for the first time in years! I cannot boast, they were crap, but still good times.

Reply Score: 2

RE[4]: Only natural to improve
by moondevil on Wed 27th Mar 2013 17:36 UTC in reply to "RE[3]: Only natural to improve"
moondevil Member since:
2005-07-08

Just yesterday I tried to compile an old Turbo Pascal 6 game I made back in 1992 with Free Pascal and everything compiled just fine!

However as soon as the code tried to do an interrupt call, Windows 7 killed it. Which is to be expected anyway.

Depending how much dirty tricks (low level access) you are doing on your TP code, you might be able to port them to Free Pascal, but it requires some effort.

Reply Score: 2

RE[5]: Only natural to improve
by Laurence on Wed 27th Mar 2013 21:37 UTC in reply to "RE[4]: Only natural to improve"
Laurence Member since:
2007-03-26

I don't have much need for Pascal these days as I've gotten better at other languages. However that's good to know that there is a fall back. ;)

I was looking at Lazarus a few months ago and that looked pretty good (though I didn't really do much with it at the time).

Reply Score: 2

RE[4]: Only natural to improve
by f0dder on Fri 29th Mar 2013 14:34 UTC in reply to "RE[3]: Only natural to improve"
f0dder Member since:
2009-08-05

TurboPascal binaries stopped running on Windows since Vista.

Did something actually happen with Vista that broke TP executables? Or did the programs break because you got a fast machine, and ran into the CRT delay-calibration divide by zero issue? ;)

Reply Score: 2

RE[5]: Only natural to improve
by Alfman on Fri 29th Mar 2013 17:02 UTC in reply to "RE[4]: Only natural to improve"
Alfman Member since:
2011-01-28

f0dder,

"Did something actually happen with Vista that broke TP executables? Or did the programs break because you got a fast machine, and ran into the CRT delay-calibration divide by zero issue?"

I know what your talking about, I vaguely recall an official patch for the divide by zero bug on fast machines, no?

Actually though they stopped working because AMD64 broke backwards compatibility with VME (virtual mode extentions) which is required to run 16bit code under protected modes. This means that 16bit code can no longer be virtualized and must be emulated, and microsoft chose not to support it at all.

The earlier suggestion to use DOSEMU was a good one, as it includes an emulator that works pretty well. But I found on my laptop it has difficulty emulating the native speeds of 16/32bit processors from back in the day. For example, impulse tracker under DOSEMU starts choking when it tries to mix too many channels in real time.

Reply Score: 2

RE[6]: Only natural to improve
by f0dder on Fri 29th Mar 2013 21:21 UTC in reply to "RE[5]: Only natural to improve"
f0dder Member since:
2009-08-05

"Did something actually happen with Vista that broke TP executables? Or did the programs break because you got a fast machine, and ran into the CRT delay-calibration divide by zero issue?"

I know what your talking about, I vaguely recall an official patch for the divide by zero bug on fast machines, no?

That's indeed what I was thinking about - dunno if there was any official patch, but I recall there was a tool that would fix up executables, as well as a source code patch for people to recompile CRT with.

Actually though they stopped working because AMD64 broke backwards compatibility with VME (virtual mode extentions) which is required to run 16bit code under protected modes. This means that 16bit code can no longer be virtualized and must be emulated, and microsoft chose not to support it at all.

So the breaking deal is Long Mode not supporting VME, rather than Vista breaking anything? AFAIK 32bit versions of Vista (and Win7 for that matter, dunno about win8) still has NTVDM?

I'm curious since I haven't heard about Vista breaking DOS stuff, and DOYC knows it's been blamed for a lot ;) (I've been running 64bit since XP64, so my DOS apps broke before Vista).

Reply Score: 2

RE[7]: Only natural to improve
by Alfman on Sat 30th Mar 2013 02:45 UTC in reply to "RE[6]: Only natural to improve"
Alfman Member since:
2011-01-28

f0dder,

"So the breaking deal is Long Mode not supporting VME, rather than Vista breaking anything? AFAIK 32bit versions of Vista (and Win7 for that matter, dunno about win8) still has NTVDM?"

I wouldn't really know, I never had vista on any of my machines. I don't have a 32bit copy of win7 either.

I've read elsewhere that the windows-xp mode emulator can run dos applications without issue (other than being slow), but microsoft didn't make it available on the edition of win7 that came with my system so I haven't tried it.

Reply Score: 2

Programmers
by Deviate_X on Wed 27th Mar 2013 13:15 UTC
Deviate_X
Member since:
2005-07-11

(1) The best type of code is code that does what was intended to do. (2) The seconds best type of code is code that is written nicely. (3) Hardly anyone remembers the guy who wins silver.

Reply Score: 2

RE: Programmers
by AndyB on Wed 27th Mar 2013 13:28 UTC in reply to "Programmers"
AndyB Member since:
2013-03-22

(1) The best type of code is code that does what was intended to do. (2) The seconds best type of code is code that is written nicely. (3) Hardly anyone remembers the guy who wins silver.

It is possible to be both (1) and (2), it just takes patience, time, practice and more patience!

Reply Score: 3

RE: Programmers
by Alfman on Wed 27th Mar 2013 14:18 UTC in reply to "Programmers"
Alfman Member since:
2011-01-28

Deviate_X,

"(1) The best type of code is code that does what was intended to do. (2) The seconds best type of code is code that is written nicely. (3) Hardly anyone remembers the guy who wins silver."

For one-off coding jobs, maybe. But not in larger long term projects. Writing ugly code often reflects a difficulty in handling complexity. The worst kind of developer is one who's code lacks modularity and solves problems by hacking in changes everywhere instead of solving the problem abstractly. Their code inevitably creates problems that will compound over time, increasing complexity and creating a long term maintenance problem. I've seen it so many times it's not funny.


But on the other hand, to my disappointment, horrible code can still become remarkably successful. One example deserving public shame is OSCommerce, which many of my clients use because it was bundled by their hosting providers and they didn't know any better. The modules were never abstracted properly, which results in horrendous overlapping hacks everywhere with to integrate new features. Functions that do the same thing are copied to different files, it's truly awful code, yet there's no denying it's a successful project.

Another example is the HomeSeer automation software API. It has an absolutely brain dead COM API, which they kept as is when they moved to a dot net version instead of taking the opportunity to actually fix it. In some cases the caller is actually responsible for encoding/decoding raw device point values, which homeseer maps into x10 values even for non-x10 devices, pathetic. The API is so terribly convoluted that I ended up writing a genuine .net wrapper for it to gain intelisense and write drivers much more easily.

There are probably hundreds of thousands of other devs who've experienced this somewhere or other, and I can only imagine how many millions of man hours have been wasted in maintaining software that wasn't written by someone who cared about (or couldn't produce) nice code in the first place. For all my gripes about poor code, there's very little any of us can actually do to eliminate it's existence, so we all just have to learn to live with it.

Reply Score: 2

RE[2]: Programmers
by lucas_maximus on Wed 27th Mar 2013 15:52 UTC in reply to "RE: Programmers"
lucas_maximus Member since:
2009-08-18

Just go to the DailyWTF.com.

Most obscenities are usually committed with Java, VB and PHP (which is a language I absolutely despise).

It is a shame because VB.NET while it can be coded badly you can actually do a good job if you actually understand what you are doing and you can code quite quickly.

Reply Score: 2

RE[3]: Programmers
by btrimby on Wed 27th Mar 2013 16:20 UTC in reply to "RE[2]: Programmers"
btrimby Member since:
2009-09-30

so, most of these documented atrocities are committed using the most popular languages...

There are definitely C# ones as well.


The bottom line is that it's possible to write crap in any language, but it makes sense to see WTFs from code monkeys in the most popular languages.

Reply Score: 2

RE[4]: Programmers
by lucas_maximus on Wed 27th Mar 2013 16:49 UTC in reply to "RE[3]: Programmers"
lucas_maximus Member since:
2009-08-18

Oh I totally agree, it just sad when they happen in languages that are used extremely often, and there is a lot of information out there on how to do it correctly.

Reply Score: 2

RE[5]: Programmers
by moondevil on Wed 27th Mar 2013 17:38 UTC in reply to "RE[4]: Programmers"
moondevil Member since:
2005-07-08

If only I could show the code we get in our offshoring projects...

Reply Score: 2

RE[6]: Programmers
by Tuishimi on Wed 27th Mar 2013 19:27 UTC in reply to "RE[5]: Programmers"
Tuishimi Member since:
2005-07-06

I've seen some bad off-shore code and some very very good off-shore code.

My pet peeve is when there is a good engineer who writes good code, quickly, but then not a single brace lines up or in 5 lines of code each one is indented differently. Try - catch braces and parameter lists are never done the same way twice... etc.

I know that is petty and in some ways unimportant, but it just makes me twitch and I have to clean it up. I guess it comes from the days of programming in the likes of Fortran or COBOL or what-have-you. I really like neat code. It would be cool to attach a pretty printer to the check-in process... I don't like everything a pretty printer does (I know they are customizable) but it would be better than some of the code I see.

Edited 2013-03-27 19:29 UTC

Reply Score: 2

RE[5]: Programmers
by Delgarde on Wed 27th Mar 2013 23:44 UTC in reply to "RE[4]: Programmers"
Delgarde Member since:
2008-08-19

Oh I totally agree, it just sad when they happen in languages that are used extremely often, and there is a lot of information out there on how to do it correctly.


Yes, but the reason you don't get WTFs in obscure languages is that the kind of moron who writes that code hasn't heard of those languages.

They occur in Java, C#, VB, etc because those are the languages most used in the commercial world, attracting people who think they can make a living out of something they have no aptitude for.

Reply Score: 4

RE[6]: Programmers
by lucas_maximus on Thu 28th Mar 2013 07:34 UTC in reply to "RE[5]: Programmers"
lucas_maximus Member since:
2009-08-18

The only one I can really excuse is JavaScript because it is just totally different to anything else I have programmed with before. My manager tends to write very good C#, but his JavaScript looks like a C# programmer trying to make it look like Java.

PHP deserves all the flack that it gets, it doesn't even have a language specification.

Reply Score: 3

RE[2]: Programmers
by progormre on Wed 27th Mar 2013 16:39 UTC in reply to "RE: Programmers"
progormre Member since:
2012-05-20

I've seen tasks countless of times that could be solved elegantly or quick with a nasty hack. Management always goes for the later as long that is a possibility. I don't see any problems with that. Don't see any problem with nasty code either, if I can add another hack and I'm told to do so, I'll do it, if I can not then I'll just tell them that it must be rewritten. Of course I would have explained that eventually the code must be rewritten when the amount of hacks gets to hard to grasp. Then it's up to them to judge whether they can foot the bill now or gamble on paying through their nose later. This is a lot more professional compared to a difficult to deal with programmer who refuses anything but an elegant solution, to me such guys have no place in a business.

So, I understand sloppy commercial code, I do not understand sloppy open source code though, in fact it makes me blush. How can you possibly justify that?

Edited 2013-03-27 16:47 UTC

Reply Score: 2

RE[3]: Programmers
by Alfman on Wed 27th Mar 2013 17:44 UTC in reply to "RE[2]: Programmers"
Alfman Member since:
2011-01-28

progormre,

"Then it's up to them to judge whether they can foot the bill now or gamble on paying through their nose later. This is a lot more professional compared to a difficult to deal with programmer who only refuses anything but an elegant solution, to me such guys have no place in a business."


I've seen that too, but it's not exactly the same as what I'm talking about here. I'm talking about bad and/or inexperienced developers. It's not right to imply that doing something fast & doing it well are inherently conflicting goals. Good software engineers should understand that the larger and more complex a problem is, the more important it becomes to build a good foundation, which will actually yield results sooner than a foundation built on spaghetti code where everyone is stepping on each other's feet and changes need to be made in dozens of places to implement anything.

Most web development projects probably start out as tiny and vague in comparison to corporate projects. This may explain why so little design appears to go into many web projects, which frequently devolve into a mess of spaghetti code. It's just a shame that even for small projects, some developers are so bad that they'll use a nasty hack even when they could have used nice code for the same effort.

Edited 2013-03-27 17:58 UTC

Reply Score: 2

RE[3]: Programmers
by Delgarde on Thu 28th Mar 2013 01:07 UTC in reply to "RE[2]: Programmers"
Delgarde Member since:
2008-08-19

This is a lot more professional compared to a difficult to deal with programmer who refuses anything but an elegant solution, to me such guys have no place in a business.


While I'd agree with that comment in general, I'd note that as the person having to maintain the collection of hacks in the future, I'll be pushing very, very hard to have them fixed properly every time.

Quick hacks are fine to deliver a short-term fix under tight time frames (e.g security issues, production environments crashing, etc), but I'd hate to work for a company where "fix it properly" wasn't the highest priority as soon as the quick fix is out the door.

Reply Score: 2

How I invented GoSub
by joshv on Wed 27th Mar 2013 13:41 UTC
joshv
Member since:
2006-03-18

On my 12th Christmas I was given a TI99/4A. My parents barely knew what it was, or what it did, but I was geek'd. Luckily they didn't have any money to buy games, otherwise I might have spent all my time playing rather than coding and ended up in an entirely different career.

The 99/4A had TI-Basic, a rather competent implementation (for the time), which had a GOSUB. I of course had no idea what the documentation was talking about. GOTO made sense, but GOSUB?

I went about coding with my GOTOs and IFs and quickly found that there were portions of my code that were doing the same thing. Wouldn't it be nice if I could only write that code once instead of having the same lines of code all over the place?

So I put the code in one place at a particular line number, set up some variables for it to work on, and then issues a GOTO to that line number. But then I had another problem, how the heck did I get back to where I came from?

Being a clever lad, I also set a flag before I issued my GOTO, the flag indicated the calling block of code. Then at the end of the block of re-usable code, I interrogated the flag using some IF statements, and issued the GOTO required to return to that calling block.

I rolled my own very fragile subroutines. When I later figured out GOSUB I kicked myself, long and hard.

Reply Score: 12

RE: How I invented GoSub
by AndyB on Wed 27th Mar 2013 13:56 UTC in reply to "How I invented GoSub"
AndyB Member since:
2013-03-22

It's sometimes these mistakes which make you learn! With the limited commands available in those days it was easy to think you have to do all the hard work yourself. Life is much easier now with resources like the internet to reference to see if the answer is already there, there must have been millions of 're-inventing the wheel' cases back in the 80's.

Reply Score: 2

RE: How I invented GoSub
by Laurence on Wed 27th Mar 2013 15:54 UTC in reply to "How I invented GoSub"
Laurence Member since:
2007-03-26

That's not far off my first few years of programming as well.

I do miss those days. I mean, it was harder to write programs, you had fewer hardware resources at your disposal and the web wasn't around to cross-reference stuff when code failed, but programming back then was like stepping through the looking glass into a weird and magical world of infinite possibilities. However these days it's just a hundreds of different interpretations of social networking and rehashes of games but with slightly better graphics.

To be fair though, I'm just jaded because of age. I've seen the evolution of the PC, been a part of the cyclic evolution of workstations (dumb terminals connected to mainframes; through to powerful desktop workstations and now back to terminals hooked up to powerful centralised servers (except this time it's web-based cloud services instead of TSS served over telnet)).

One side of IT does still excite me though, and that's AR and hidden computing (or whatever the term is). The idea of technology adapting to humans - seamlessly integrating into our everyday lives (eg Google Glasses, home automation systems, etc) rather than us adapting our lives to suit the way technology works. These days that's the side of IT that most of my code is written for.

Reply Score: 3

RE[2]: How I invented GoSub
by Tuishimi on Wed 27th Mar 2013 19:33 UTC in reply to "RE: How I invented GoSub"
Tuishimi Member since:
2005-07-06

To be fair though, I'm just jaded because of age. I've seen the evolution of the PC, been a part of the cyclic evolution of workstations (dumb terminals connected to mainframes; through to powerful desktop workstations and now back to terminals hooked up to powerful centralised servers (except this time it's web-based cloud services instead of TSS served over telnet)).


I know it, right!!!!!! Same here. Started back in the early 80's with DEC and have seen a lot of changes in the business. Education-wise as well... CS majors have changed a lot since I went to school.

Reply Score: 2

RE: How I invented GoSub
by looncraz on Wed 27th Mar 2013 19:30 UTC in reply to "How I invented GoSub"
looncraz Member since:
2005-07-24

Wow... EXACTLY what I did!!

Reply Score: 2

RE: How I invented GoSub
by ssokolow on Wed 27th Mar 2013 21:33 UTC in reply to "How I invented GoSub"
ssokolow Member since:
2010-01-21

On my 12th Christmas I was given a TI99/4A. My parents barely knew what it was, or what it did, but I was geek'd. Luckily they didn't have any money to buy games, otherwise I might have spent all my time playing rather than coding and ended up in an entirely different career.

The 99/4A had TI-Basic, a rather competent implementation (for the time), which had a GOSUB. I of course had no idea what the documentation was talking about. GOTO made sense, but GOSUB?

I went about coding with my GOTOs and IFs and quickly found that there were portions of my code that were doing the same thing. Wouldn't it be nice if I could only write that code once instead of having the same lines of code all over the place?

So I put the code in one place at a particular line number, set up some variables for it to work on, and then issues a GOTO to that line number. But then I had another problem, how the heck did I get back to where I came from?

Being a clever lad, I also set a flag before I issued my GOTO, the flag indicated the calling block of code. Then at the end of the block of re-usable code, I interrogated the flag using some IF statements, and issued the GOTO required to return to that calling block.

I rolled my own very fragile subroutines. When I later figured out GOSUB I kicked myself, long and hard.


Sounds like what I did in the interval between age 8 and age 12.

However, given how little learning material I had lying around and how much other time was spent getting a deep understanding of DOS and batch files, reading free promotional materials requested from companies like 3com via 1-800 numbers and fantasizing about what I could build if I were rich, and playing shareware games like Commander Keen 4, I gained access to other languages before I discovered the purpose of QBasic's GOSUB.

Of course, I learned subroutines in a flash when I got a Perl book with companion CD at age 12. That lasted a couple of years, then I discovered Python and never looked back. (Aside from a little Visual Basic 6.0 in my Grade 10 computers course, but 11 and 12 switched to Java and C++)

(Perhaps ironically, I'd encountered Python earlier, but had a bad impression of it because it was "that multi-megabyte thing that various idiots required for their SourceForge projects, penalizing us poor people who couldn't go to the office and borrow an ISDN PRI, T1, or T3 connection... or the mythical OC-3." This was when broadband was just coming out, it was expensive, and our budget didn't already include cable TV.)

Edited 2013-03-27 21:37 UTC

Reply Score: 2

learn to learn
by wigry on Wed 27th Mar 2013 16:26 UTC
wigry
Member since:
2008-10-09

Best way to learn to learn is to go to university. They have plenty of stuff for your brain to chew. Programming just takes a good use of that skill.

Reply Score: 1

RE: learn to learn
by looncraz on Wed 27th Mar 2013 19:40 UTC in reply to "learn to learn"
looncraz Member since:
2005-07-24

Best way to learn to learn is to go to university. They have plenty of stuff for your brain to chew. Programming just takes a good use of that skill.


I disagree.

I learned more in six months of programming C++ with a specific goal in mind than I did with three years of programming in school.

The teachers either weren't knowledgeable enough, or they had to teach to the capabilities of the students - which was FAR below my level.

I learned html in a week, but that would take a year in college - and they wouldn't teach you how to do it manually - they had you use some stupid WYSI*N*WYG editor... and the site then only worked in IE.

Javascript took a little longer (I love JQuery ;-)) - maybe two weeks. PHP took about two days to be productive - but I still haven't mastered it (my use case has changed towards something akin to AJAX).

However, some people are unable to learn on their own... The internet has made things FAR easier.

--The loon

Reply Score: 1

RE[2]: learn to learn
by judgen on Fri 29th Mar 2013 12:29 UTC in reply to "RE: learn to learn"
judgen Member since:
2006-07-12

HTML is a fickle markup language misstress. My sites are all coded to look the same in "links2 -g" as they do in firefox, ie, and safari. It takes some workarounds to get done but they work and the code is a bit longer.
Looncraz, still a fan of your work on the multiuser BeOS stuff, and i use it all the time.

Reply Score: 2

RE: learn to learn
by Lennie on Wed 27th Mar 2013 21:14 UTC in reply to "learn to learn"
Lennie Member since:
2007-09-22

You learn programming fastest by finding a 'problem' you want to solve (the itch) and others suggesting how to improve things.

Then trying to apply the improvements to your projects, that way you'll eventually develop your own style.

Reply Score: 2

RE[2]: learn to learn
by AndyB on Thu 28th Mar 2013 22:35 UTC in reply to "RE: learn to learn"
AndyB Member since:
2013-03-22

Couldn't agree more!

I do think that if you're not cut out to be a programmer then no amount of college/university courses are going to change that. When I was at college learning BASIC and COBOL in the mid 80's, we started out with a class of 30. By the end of the course we had 6 left, no less than 24 dropped out during the first year! Out of those 6, 3 of us could already program before they started the course and just wanted the certificate to prove it.

I accept things will be much different now, but it still takes a certain type of mind to program successfully.

Reply Score: 2

RE[3]: learn to learn
by Lennie on Thu 28th Mar 2013 22:51 UTC in reply to "RE[2]: learn to learn"
Lennie Member since:
2007-09-22

This is similar to what I've experienced in education.

Reply Score: 2

RE[3]: learn to learn
by Alfman on Fri 29th Mar 2013 02:59 UTC in reply to "RE[2]: learn to learn"
Alfman Member since:
2011-01-28

AndyB,

"When I was at college learning BASIC and COBOL in the mid 80's, we started out with a class of 30. By the end of the course we had 6 left, no less than 24 dropped out during the first year! Out of those 6, 3 of us could already program before they started the course and just wanted the certificate to prove it."


Surprises me that they taught basic in college ;)

The stats in our degree in ~2000 were about 50% dropout (I think this was over the whole of the program and not per year, but I cannot remember for sure). But many of us were also there for the "paper". I almost dropped out myself but not for the same reasons being implied here, but because it was very difficult to make the case that the degree was actually worth the six figure expense that my university costed. I wonder how many of dropouts are due to the realization that the benefits are not worth the costs?

Reply Score: 2

RE[4]: learn to learn
by AndyB on Fri 29th Mar 2013 12:35 UTC in reply to "RE[3]: learn to learn"
AndyB Member since:
2013-03-22

Surprises me that they taught basic in college ;)

The whole point of the course was intended for school leavers wishing to learn programming from scratch.

Bear in mind that in those days high schools had minimal computers for learning anything on (I seem to remember BBC Micro's and an RM Nimbus network which crashed more often than it worked) and teachers who knew less than the kids who had worked it out for themselves. If you already knew how to use them you were fine, if you didn't then you had no chance of learning anything either!

Programming was something of a black art which few people knew and even less could do successfully in the 80's!

Reply Score: 2

Hard.
by judgen on Fri 29th Mar 2013 12:25 UTC
judgen
Member since:
2006-07-12

Programming is FUN! If it was not hard, who would play chess for instance?

Reply Score: 2