Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Learning to Code Is So Damn Hard

vikingcodeschool.com

Post reply on HN
Print view View original

181–190 of 270 posts

Re: Why Learning to Code Is So Damn Hard

#181

Post by bigger_cheese »

There is a difference between knowing how to write code and being a "software developer". I think a lot of people confuse the two. I am an Engineer (not the software kind) I write code almost every day in my job but I do not identify myself as a programmer. For me code is a tool to be used to solve a problem, like Calculus or Linear Algebra.

When I was at Uni we were required to take two subjects through the computer science faculty, "Intro to algorithms and data structures" and "Fundamentals of Software Engineering". The first subject was hugely interesting and I "Got it" right away. It was basically teaching you how to represent a problem computationally, we learnt about Binary and floating point representaion, what a stack was that sort of thing. This is heap sort, this is bubble sort, this is O(N) this is O(Log N) it clicked for me.

The second subject not so much. It was all about Unit tests, object oriented programming, the waterfall model. We had to write an essay about Ariane V failure. The lecturer was really big on a guy called Bertrand Meyer and his ideas about design by contract. The subject was really hard to engage with and almost caused me to lose interest completely. It was probably a good subject to learn if you were planning a career in software development but for a first year engineer not so much.

As cruel as it sounds I think the best way to teach someone to code is to explain algorithms and data to them. "Here's a Ruby tutorial try to follow along and you to can be a programmer" is dishonest and in my opinion not learning the fundamentals up front is what causes that "chasm of dispair" the article aludes to.

Re: Why Learning to Code Is So Damn Hard

#182

Post by jussij »

Why programming is hard is why everything is hard.

You’re not going to get good at anything unless you work hard at it.

All these hand holding sites are worthless because all the stuff on them is so easy. But they are popular because people are always looking for the easy option.

Want to be a good programmer. Buy a well-recommended book and spend 3 hours a day, 7 days a week trying to write code. Start with hello world and then build from there.

After three 3 months of that hard grind you'll either have some idea on how to write code or you will find you don't have the aptitude to be a programmer.

The bad news is even if you do find you can write code, the hard grind has just started.

You'll have to repeat the process for other programming topics like data structures, programming patterns, testing strategies, understanding database design etc etc.

Move forward five years and you're well on the way to being a well rounded developer.

Re: Why Learning to Code Is So Damn Hard

#183

Post by troels »

epochwolf wrote: post #111
grey-area wrote: post #99

Earlier quoted context omitted.

The guides on the ror website are pretty good: http://guides.rubyonrails.org/ Which bits did you find were magic? The bits of convention I can think of you'd have to know about are: DB naming conventions - these are used so that it can do joins etc easily behind the scenes, they're pretty simple so not a huge problem I find. Rendering at the end of controller actions - it'll render the template with the same path as…

The routing system and associated view helpers can really get confusing. For example: link_to @story.title, @story You have to know that rails has some automatic routing based on the class of an object. If @story is a Story class, rails basically does this underneath: link_to @story.title, send("#{@story.class.name.downcase}_path".to_sym, @story.to_param) There's implicit conversion of class names going on under the…

I have to agree - The path helpers are very opaque. It would probably do Rails well to generate a app/helpers/path_helper.rb file with the actual implementations in them.

Re: Why Learning to Code Is So Damn Hard

#184

Post by troels »

lelandbatey wrote: post #84
SilasX wrote: post #71

Earlier quoted context omitted.

Unless you're doing Rails, in which case it'll be read as a magic method and guess what you meant :-P Seriously, that was a major sticking point for me having programmed for a long time: going from "if you have not declared that identifier, game over" to "magic happens".

That is absolutely something that irritates me. I've just inherited a large RoR application, and the amount of "magic" and things by convention is driving me crazy. There should be answers to questions like "why is this the way it is?!" On a side note, if anyone has some great resources for RoR, I'd love to have them linked. I suspect my inexperience is the source of my problems, and I'm welcome to any assistance any…

Ryan Bates' Railscasts are great. Unfortunately he stopped producing new ones, but they are still a great resource:

http://railscasts.com/

Re: Why Learning to Code Is So Damn Hard

#185

Post by snake_plissken »

Also, for rookies and veterans alike, when you are learning something new (especially tech stuff) and it's getting progressively more difficult, remember to take it easy on yourself and to relax. Those stress induced tension headaches from squinting, furrowing your brow and getting overwhelmed from the unavoidable and apparent decrease in your progress are productivity killers.

Relax, and remember that at some time, everyone is a neophyte.

Re: Why Learning to Code Is So Damn Hard

#186

Post by sklarsa »

From my experience as someone who is primarily self-taught, I think that having a more experienced programmer who can act as a mentor is vital to one's own growth as a developer. My first experiences programming in a professional capacity consisted of writing VBA macros to either automate tasks like moving or reformatting data, or in one instance, run an iterative algorithm that could not be expressed simply with excel formulas. Looking back, I was stuck at that level for several years, until I was given some new assignments that were signficantly harder than my previous ones, and I had no idea where to begin. I discussed some of my current assignments with a colleague who had some programming experience, and he gave me a few basic lessons (in VBA) about object-oriented programming and communicating with SQL databases using the OLEDB library. Based on this knowledge, I set out to build some advanced, database-enabled spreadsheets, relying heavily on Google, Stack Overflow, and various blogs whenever I hit a snag. As I was progressing, I would bounce architecture ideas off my mentor and he would give me some topics to research in more depth. I would then go back to my online resources to figure out how to apply these new concepts to help solve my problem. As time went on and I became more confident in my skills, with the advice of my mentor, I moved from Access to SQL Server and from VBA to C# and the .NET Framework, eventually reaching a point where I became a self-sufficient programmer developing full scale applications used across my firm.

For a motivated student, I think this method of teaching can yield tremendous results. With the vast amount of detailed information out there from tons of easily accessible sources, having a more experienced mentor create a path for the novice to follow but also letting the student figure out the implementation details on his/her own can be very rewarding. It allows the student to develop strong problem-solving skills within a smaller context (so the student doesn't get overwhelmed with indecision) yet also provides a support system when the student truly is stuck on a problem. I'm not suggesting that this is the BEST or ONLY way programming should be taught, but for someone like me, who learns best by doing, it can be a great way to get started in the field.

Re: Why Learning to Code Is So Damn Hard

#187

Post by rcthompson »

SiVal wrote: post #179
rcthompson wrote: post #43

When I was in college, one CS professor explained the difficulty of coding to me in terms of discreteness vs continuity. In the real world, things are continuous. If you accidentally build your structure with 9 supports instead of 10, then you only lose 10% of the strength of the structure, more or less. The strength varies continuously with the amount of support. But if you're writing a 10-line program and you forge…

With respect to your CS prof at one of my favorite places (Go Cavaliers!), this is not an issue of discrete vs. continuous. If your structure can have either 9 or 10, but not 9.001, supports, it is discrete, not continuous, regardless of failure mode. And remove one of the 3 legs of your stool, and you probably wouldn't have 2/3rds of its support remaining, but whether you did or didn't would be an issue of proportio…

I agree that "discrete vs continuous" is not the perfect way of expressing the difference; it's just an analogy. (But the structural support example is continuous. You could have 9.5 supports by adding a 10th support with half the strength, etc. "Amount of support" is the continuous measure.)

But it's not just an issue of graceful degradation. The fact that tiny changes in a program can have very large effects is a feature, not a bug. We grade programming languages on their ability to concisely express complex operations, and that conciseness necessarily means that very different operations are going to have similar expressions (e.g. subsetting rows vs columns of a matrix typically differ only by a small transposition of characters, but the effect is completely different).

You can write software that degrades gracefully, but one syntax error (or other "off-by-one-character" problem) is still going to kill the program. You can talk about running your program on a large set of redundant servers with no single point of failure, so that you can update them one-by-one with no downtime, and that makes you robust against even syntax errors. But that's not helping you teach novices how to write code.

Re: Why Learning to Code Is So Damn Hard

#188

Post by jussij »

hibikir wrote: post #171
greggman wrote: post #76

I was never told learning to code was hard. I never found it hard. I found it fun. I was introduced in 8th grade by a friend who brought a listing to school of a small program he wrote in BASIC and it took off from there. I didn't have all the resources of the internet to help (this was 1980) Like the article mentions there's just a ton to learn. 6 months of Code Academy will help you learn basic stuff, variables, lo…

That's because you, like all of us that learned in the 80s, were very, very lucky. We started in a world where writing good, production code and learning the very simple basics of programming were the same thing. I started with a ZX Spectrum. You could use simple machine code, or simple basic. Libraries? What are those? The one barrier to get good was when you ran out of memory, and had to switch to machine code and…

I think a lot of that despair is industry self-inflicted.

I've been in the software industry for a long time and I can't remember a time when the industry created as many new buzz words as quickly as it does today.

Take something as simple as ASP.Net for example.

In just a few years it has gone through these iterations:

* Classic * WebForms * MVC * MVVM * Razor

Each name change represent nothing much more than a new software design patterns, yet because they have a buzz word attached they become new skill set.

Look at something as simple as IOC, which again is just a new software design pattern.

Now ever IOC containers has become a buzz word and shows up as a skill requirement on the job description.

So here are just a few new IOC container buzz words that you might need to get on your resume:

* Autofac * CastleWindsor * EntityFramework * LinFu * Ninject * PicoContainer.NET * Puzzle.NFactory * S2Container.NET * Spring.NET * StructureMap * Unity

With so many buzz words things appear complex and overwhelming, but the reality is if you've seen one IOC container you've seen them all and if you haven't seen any, chances are if you are good with software design patterns it won't matter.

Re: Why Learning to Code Is So Damn Hard

#189

Post by bobbles »

ibebrett wrote: post #25

This may be thinking back on things with rose tinted glasses, but I learned to code in qbasic when I was 12 or so at a Boys and Girls club after school and fell in love. It was entirely effortless and fun to me. I think the difference is at that point I wasn't trying to program to enter some lucrative career and be a startup guy (where are these "coders" going to be once the market dies down and a new industry is hot…

I'd always thought that programming might be interesting. Picked up BASIC for dummies and basically built my career from that moment. It's crazy how stuff like that can happen.

Re: Why Learning to Code Is So Damn Hard

#190

Post by Dove »

Huh. This must be a generational thing. When I started learning to code 20 years ago, there wasn't any hand-holding. There were college courses and textbooks and sometimes mentors and ultimately your own ability to work things out from documentation and first principles. My projects grew in scope as I got better at it, but I never thought it was anything but awesome.

Then again, I never set out to "be a developer". I was bitten by the coding bug as a kid, and tripped over the discovery, as an adult, that it paid pretty well.

Post reply on HN