I wish somebody had told me this when I started.

I wish somebody had told me this when I started.

You guys are missing the point. He's not telling people how to become a software engineer but how to learn programming. Never did he indicate that this is the best option for a career. Sometimes people just want to have fun with programming but not work in the field.

I like reading about linguistics and learn languages. Do I want to become a linguist or translator? Hell no. Can I get a job in linguistics with my knowledge? Hell no! I'm surprised they didn't ban me from /sub/linguistics yet or just set up a bot that posts everything I write to /sub/badlinguistics considering how often I just fuck up and write nonsense on reddit.

Of course you need to learn linear algebra at some point for games. But is that the right way to start? Considering how many people consider the first few semesters of a CS degree the hardest, I'd say no.

Do stuff you enjoy first. Do stuff you enjoy. And once you hit a wall, learn what's needed to climb over it.

Sitting down working through textbooks is not fun if your goal is not a CS degree.

Scott: What they gotcha teachin' here, young sergeant?

Jackie Black: Edged weapons, sir. Knife fighting.

Scott: Don't you teach 'em knife fighting. Teach 'em to kill. That way, they meet some sonofabitch who studied knife fighting, they send his soul to hell.

This is great advice for starting out, but you'll eventually have to change tactics.

This will produce a world of developers who only know a few "hows" but never the "why". I've been in the field for over a decade, and I've seen this too often. Code that works for the sake of just working.

I remember directing my brother to Khan Academy when he asked to how to learn code. Then I checked out a few of their tutorials and thought that they were fun little toys, but nothing that would lead to a career.

Eventually, you'll have to start digging deeper and figure out why your code works, and not just that it works.

What I would like to see is a training program where they give you a problem and suggest tools to solve it.

Then give you the same problem and give you a different set of tools to solve it.

Then, go into detail on why one tool is better to use in this scenario than the other and how to use each tool in the future.

But eventually, if you really want to get serious, you'll have to start reading some boring books and learn on your own about the fundamentals.

I like this video, but for the point it is dancing around: programming needs to be understood as a gestalt phenomena like music.

Say you want to play guitar. Well, you pick it up and strum it and it sounds like shit. So you go out and learn to read a bit of tab and 'learn' some songs. More accurately you learn where to put your fingers in sequence and you learn how to strum for that particular song. You do this a few times before you realize you have no idea what you are doing beyond cutting and pasting. So you start to learn the notes on the top two strings. You learn the names of the chords. You learn the major scale. You learn what the strings are called. What? There are things called intervals? And you start to go down the rabbit hole. You start to transcribe songs you've heard, or at least your interpretation of them. You start to play phrases on your own. These two things is where the learning really begins. Eventually you learn all of these techniques and theory and begin to play with others. At first you start with very simple songs but you build off of each other and show each other some cool phrase you're excited about. This whole time you are still learning theory and technique and maybe even branching out to unusual tuning and buying different guitars and really trying to figure out why the greats did what they did, not just what they did. Then there you are remembering whole songs, experimenting with alternative phrasing that sounds just as good as the original and even writing your own stuff that isn't half bad. Maybe even people will hear it and want to pay you to play. But every day you are practicing and learning and growing. It is a lifelong process of growth that you should never want to stop.

It is a bit of a chaotic upward spiral because you have to know a bit of everything to really learn anything. I don't think newbies really get that. They want it to be linear. It is not a linear process at all. Some parts of it can be made to look linear but only by stripping the soul out of it. This is why, I think, people who are good at music are good at programming -- not some deep underlying mathematical brain system but because they are comfortable with this approach. Sometimes you just have to dive in and do your best.

I remember asking my sensei long ago "is it better to block, or dodge, a strike?"

pause

"i dunno. just don't get hit."

The truth is CS, college, etc are probably just gates setup to pass people that would have inherently been good programmers anyways. Does college (often) give good understanding of complex ideas in concise ways, teach you "how you learn" (i.e. how to learn),a nd other very useful skills? Yes. But, it's not really because you went to college that you are a good programmer/engineer/etc.

It's also a good metric for people that are willing to suffer through deferred gratification and take things "seriously". So, again, college IS a metric but for things most HR people wouldn't give a lot of thought.

For the sake of humility, let's not forget the fact thousands if not millions of dollars are probably calculated by Microsoft Excel and some nasty VBA in hundreds of SMB/SME organizations.

This will produce a world of developers who only know a few "hows" but never the "why". I've been in the field for over a decade, and I've seen this too often. Code that works for the sake of just working.

The thing is you'll find this with people who have been formally trained as well. I agree with the main point of the video, that craft follows interest, and to build interest, you need a problem. Diving in to mechanics is not for everyone.

For instance, one of my first self-directed programming problems was to try to build a tile-based RPG. This taught me a ton about arrays and optimization more than I would have ever learned abstractly. It gave me tools that have transferred to just about everything I do now. I never finished that project, and it was undoubtedly a mess, but had I not approached it I would have had zero interest in shoveling bytes from array to array or understanding as to why one would ever do that in the first place.

It may not be for everyone, but in my experience, approaching a conversation with someone who "wants to know how to code" has always been much more successful when asking what do you want to do?, not by immediately suggesting a language that has my own pet set of favorite paradigms for a beginner.

I think "getting serious" follows, for both formally trained and non-formally trained people alike. At some point, if you really care to solve that problem, you're going to pick up the skills you need if you're committed. All of a sudden, those boring books don't seem so boring once you have some context.

That's his secret. He's always freaking out.

I have heard this philosophy thrown around at times and theoretically it sounds great, and can be a very practical starting step. But the major issue I have with it is that if I'm someone who is at absolute zero as far as compsci knowledge, I may not even know what types of questions and problems are solvable. Assume I don't even know what a computer is capable of and help me come up with an idea for a problem to solve. Telling me to solve problems I may not even know exist seems backward. There needs to be some basis of understanding.

"Best defense, no be there."

-- Mr. Miyagi

https://www.youtube.com/watch?v=TFr30p0aZl0

A person with an analytical mindset, given a handful of "hows," can generalize to the "why." Unfortunately we don't teach an analytical mindset very well. :(

Wonderful video. The ideal programming language tutorial should maximize the speed with which the user gets to awesome. :) This is why LOGO had it right 40+ years ago. While most language tutorials teach you to print "hello" and all kinds of numbers, LOGO got you drawing cool and interesting figures. What would you show a friend? A bunch of factorials or a super cool fractal?

Indeed. The most interesting and most resonating comment came first, (paraphrased) "I started when I was a kid"

So did I.. How about the rest of you? The degree and career came eventually, but long before I even began the degree, I knew how to program. Through CS courses, I learned theory and tools which aided me in being a professional, and then the real learning began as a professional with business driven work.

How many of us could illustrate verbally or in writing "tell me how to start walking" or "how do I learn to ride a bike"?

It is a hard question to answer, how to learn to code.. I feel like I've known for as long as I can remember, and in the early days as a kid, there was no goal or theory or learning pathway, it was just coming up with and answering creative puzzles that felt important at the time.

Only one problem...

It has been proven that there are whole classes of problems which are inherently unsolvable.

Considering how many people consider the first few semesters of a CS degree the hardest, I'd say no.

Could it be the language that they learn has some impact on that perception? A lot of universities switched to Java for their intro courses, and Java is a terrible beginner's language because (a) it contains a lot of boiler-plate keywords that aren't germane to getting the job done, which stems from (b) forcing everything into the object-oriented frame of mind, and (c) because of it's C-like syntax, there's a lot of grappling with recognizing { as begin or re-learning what =means (instead of an assertion of equality, or a check there of, it means assignment in C-like languages)... all of these contribute to Java's unsuitability for a teaching language.

Now, while encapsulation, inheritance, information hiding and polymorphism are important concepts, they aren't essential for the first steps of teaching programming... and sometimes (especially in the case of inheritance/extension) might be over emphasized to the point where the advantages of "going the other way" [see comments] simply don't register.

Pascal, which was designed as a teaching language, addresses a lot of the deficiencies of Java... but perhaps in a bit too simplistic a way -- as, after learning it, the principles of OOP are still a bit out-of-reach/unfamiliar (unless you're using an extension like, say, Borland's unit [module] construct).

For teaching, I'd actually recommend Ada -- it has a separation of interface and implementation inbuilt with its package [module] system, it has private types [which along w/ the interface/implementation divide show off implementation-hiding/encapsulation], it has type derivation [which show off inheritance], generics can be used to show static-polymorphism, and it has the task construct which allows for logically parallel code to be written. -- There's no reason that such "advanced concepts" (to the absolute beginner) can't be gently introduced.

This is excellent advice. And I also used to write programs to solve math problems using TI-Basic on my TI-86.

There is just one problem with this advice: most people don't realize how difficult solving a particular problem might be to solve. For example, they may want to write a program to automatically fill in a form they have to fill in regularly on a website. This problem seems simple and intuitive: it is just a lot of repetitive typing with maybe a few variable substitutions in a few places.

But the actual implementation of such a program is probably extremely complicated. Even with good tools, like using some extension to Firefox or Chrome that lets you make use of the debugging tools and JavaScript to interact with forms on websites, implementation may involve an understanding of a web framework like JQuery, JSON, XML, and they may need to learn a thing or two about the website's public API that they are interested in using. So now, they not only need to learn JavaScript, but have an understanding of a whole bunch of technologies that are all working together. Where does one begin? For someone who doesn't know anything at all about programming, this is probably a deal breaker, finding out the amount of work involved, even with the correct language and tools, may make you loose interest. The amount of time spent solving the problem programmatically far exceeds the time it will save you.

It's kind of a chicken-and-egg problem, you can't learn programming without having a problem to solve first, but you can't know how easy or hard a problem is to solve unless you have some programming knowledge. Often times, it is good advice to just learn a programming language for the sake of learning it. You won't be able to solve problems right away, but over time, but with patience, persistence, and practice, you will start to learn totally new ways of solving problems that you had never thought of before.

And to that end, it is good to choose a popular language that has been integrated into a lot of software and has a lot of good supporting libraries, and there are really three languages that fit this bill: JavaScript, Python, or Ruby.

Disagree strongly with this. Logo did nothing to capture my imagination in highschool. We used VB afterwards which was much better because you could make real apps with it.

From what I've seen, most people find the math classes (Calculus, Algebra, Linear Algebra, etc.) to be the hardest, not the programming/algorithms classes.

Your entire argument sounds like elitist horse shit because you seem to think the only exception would be "prestigious" universities.

Regional universities and even better community collages will have plenty of theory work to go along with the practical. There IS an entire spectrum of education besides "prestigious" and DeVry.

For me university was valuable because it presented me with a package of highly useful general skills to learn. If I hadn't gone to university, I would've maybe picked up quite a few of those skills along the way, but it would've been piecemeal over a much longer period of time and, I imagine, quite a lot more difficult. The package of related skills taught in a structured way with guidance and learning resources always at hand gave a holistic perspective on computing that I think amounted to more than the sum of its parts.

I can't speak for everyone, but when I find myself using an abstraction I don't understand it makes me really uncomfortable.

It's like if you were in a tall building, and one of the balconies had no floor, but people were standing on it anyway.

"How is that possible?" You ask, before stepping into thin air.

"Force fields." They reply. "Just trust it. It's cool and fun!"

"... How does it work?" You ask, because you don't want to take a risk you don't understand.

I was shown a lot of "Look how EASY computers are!" GUI stuff in high school, and it never interested me, because it was really easy, until something didn't work, then it became impossible. I could only understand the system when it worked, and as soon as it didn't, I became frustrated and quit.

It wasn't until I took 3rd year uni programming classes in C and learned about processor architecture that it all really made sense to me. From then on I knew that there was always a solution to any problem, and started learning to trust the abstractions since I knew I could fix them.

I often tell my coworkers: "It's all just ones and zeroes. If we line them up right, we can do anything!"

Don't forget tracking IPs. GUI interfaces in Visual Basic are fantastic to track IP addresses.

One of the most frustrating things in college was that there were very few classes where you actually programmed. Most classes were about algorithms, problems, how to solve things, etc. In college, all I wanted to do was code; all this theory bullshit put me right to sleep. Still, I persevered, graduated, and entered the work force a couple months later at a B2B software firm doing Java.

Amusingly, during the interview, they asked me all kinds of specific code questions, most of which I felt I bombed because I didn't know much language specifics having never had to do it in college. However, my last interview was with an architect, and he asked me an algorithm question which he admitted was the best, most efficient solution to the problem (and had me do big-O on it). I think it was that final interview that got me the job.

Anyway, now that I have 8.5 years of experience in the field, rising quickly to "senior" in 4 years, now a lead, it's clear that my education in college (the "theory" that I so abhorred back then) is what has made me successful. I see juniors come in that know coding syntax, but are awful at problem solving. Out-sourced programmers that know lots of Java APIs and stuff, but if you give them a general problem, they fall on their face trying to solve it (even a simple one). I'm often writing pseudocode for them which they sometimes still have problems coding.

These are people that just went to a 6-month or 2-year programming school to learn how to code things, not how to solve things. They make fine juniors or maybe mid-level programmers, but they're not senior-level or lead capable because their problem solving skills aren't to snuff. They can't translate a real world problem into a programmatic solution. If you give them a strict algorithm, they can translate that for the most part, but can't come up with that themselves.

This is why I put a lot of importance on a Bachelor's when I interview. I put emphasis on algorithms, not syntax or programming language. I always have the same response as the dude in the video when people ask me "how can I learn to program?": you don't. You learn to solve problems, then find a tool to do it automatically.

TL;DR:

A Bachelor's degree that taught me theory/problem-solving annoyed me as an undergrad because of lack of programming, but ended up being my biggest strength and differentiator in the industry. Have noticed tons of people in the industry that can't problem solve, but are merely coder monkeys translating algorithms to code. Cannot come up with the algorithm themselves.

This was some pretty terrible advice, and all it leads to is cargo-cult programmers.

Every year we have newbies come into our company. I lobby very hard against the guys who sneer in their interviews that their degree was pretty worthless because they are self-taught and "who needs all that theory nonsense".

Inevitably, we end up hiring them because HR decided the sheer number of buzzwords they put on their CV was more important than our evaluations of them. And inevitably, we spend the next couple of years putting out their fires.

Like that one time one of them pushed out an update to a product that caused our update cycle to increase from 30 seconds to 80 years, because they inserted an O(N5) algorithm when it was originally O(N), because what do you know, they forgot all of the complexity theory stuff that was taught because "it was boring".

Or that one time when someone "optimized" our pushdown automata state machine parser to a Regex because "regexes are cool, it's what all hackers use". Except it was parsing stuff that needed to recursively count tokens, which is something Regex's cannot do. Sure, it was about 30x faster for his two test cases. But as soon as it hit production, all hell broke loose and nobody's deployments worked anymore. When questioned, his response was "What's recursion again?"

If you're a programmer who ignores all of the theory behind computer science, then you're never going to be a good programmer. You're always going to be a "Code Monkey": Someone who pounds out code as fast as they can, never truly understanding what the implications of what they're doing are, and will usually produce code which appears to work correctly, but will be so fragile as to fall apart as soon as it encounters an edge case, a maintenance cycle, or any situation where optimization, speed, and stability are important.

Sweet baby Jesus that's terrifying.

I've developed excel/VBA tools for organizations that process hundreds of millions to even billions of dollars a year... I am not a programmer.

Do you need to know vector calculus to write physics engines for games? No.

Does it help? You bet your ass it does.

So since you do both, do you just freak out whether it is math or programming?

Really? Do we really need to define what "getting hit" means here? Are we in the Age of Morons when you can't have succint conversation anymore without having some idiot interrupting you asking you to define the obvious? Do we really need to define every single fucking word that comes out of the mouth or is written down? "Please gentle sir, do not fuck me" does not mean "do not penetrate my anus with your colossal penis", it means "do not be an asshole to me" which in turn means "do not be an unpleasant person towards me" with means whatever it means in a given context.

The thing is you'll find this with people who have been formally trained as well.

Seriously, I encounter this more with people who have a CS degree which is supposed to certify that they did learn those fundamentals.

All of a sudden, those boring books don't seem so boring once you have some context.

Absolutely, this is how it worked for me. I started with some simple problems to solve, had written a bunch of simple apps. As they got larger though they became harder to manage. I sought out more tutorials or examples online of better practices. In some cases books made the most sense but with the internet it's not as necessary. As I understood the language more, I also looked at code in open source projects to see how they did things and thought about why they did them like that.

Everyone learns differently though, so some prefer to learn the tools before they really know what they'd make with them, while others need to have a problem to solve, and then the seek out a better tool.

not sure why you're being downvoted for this

i think most people who've attended an "average" public school or pay close attention to our national education system can attest to the fact that the core skills behind developing an analytical mindset—working with abstraction, critical thinking, iterating and growing from mistakes, creative problem solving—are not being emphasized at a young age because of a variety of factors (budget cuts, poor teacher education, inane state-mandated tests, strong emphasis on SAT prep at a young age)

and let's not generalize analysis skills to engineering—i'm studying english/biological sciences and notice the same skill gap in the humanities and sciences. i'm inclined to believe analytical and critical reasoning are essential for success in any field

I doubt someone without programming knowledge is going to pluck one of those ones out of the air when they pick a first problem.

Almost everything to do with opengl needs some basic understanding of linear algebra. The basic principle of everything is homogeneous matrices. If you're just using unity or whatever, you won't necessarily have to use them since it'll abstract things into x y z, and rotation functions. But if you've got a fundamental understanding of how matrix math works (which is taught in linear algebra class), it makes understanding those functions a lot easier.

Do you need to write physics engines to make a game? No. I highly doubt most people want to learn to code just to make physics engines.

This is the most useless stupid video on introducing people to programming I've ever seen. It shoots down potentially helpful advice and provides none of its own.

"Use programming to solve cool problems!"

Is akin (to continue using the musician metaphor) to:

"Use musical instruments to write cool songs!"

What would be a lot more useful is to actually list out BOOKS or web tutorials that people could read to learn about areas they are interested in. The "advice" given in the video is useless.

I'm sure I saw Jerry Seinfeld stabbing a cop at around 3m03s...

So, dodge then?

This is a great analogy and one that I experienced myself. It's that very FIRST step that makes or breaks it: Some people "want to learn guitar" so they start learning some chords. They learn an A and a C and a G and an F that's really hard and never quite sounds right. Then they get bored and move on to something else. Similar to people who want to "learn to program" learn a few functions or do a couple tutorials or whatever and give it up.

If that first step is learning a simple song, it's completely different. You learn the chords to play the song, and it sounds nice and motivates you to do something more complicated, and go up the spiral you described.

For programming, that first step should be a simple program you want to write...a program that does something useful. And you learn the tools needed to do that, and up the spiral you go.

I'm a pretty good developer that should could have skipped college. It's possible that I would have been better off but getting a degree was important to me.

College is a lot more about social and cultural enhancement than it is about learning the necessary skills to get a job. I think we, as a nation, lost sight of that some time ago.

It's because of this that, in my opinion, kids that go to college for the training are often worse at actual development than their counterparts of the same age which got into programming organically.

That's not to say that the person who went to college won't get better. It's just that when it comes to writing code, the earlier you start and the more frequently you practice, the better off you'll be (generally speaking).

A CompSci curriculum is about math, abstract theory, and solving tedious problems for tedious sake. Students will get very little exposure to good development practices, exposure to new languages, and solving large, sprawling challenges. Real world experience is the only place you'll experience that.

If I had skipped college I likely would have done what I ended up doing anyway: starting a small development company. I'd have a lot less debt, that's for sure. Plus the years I spent in a dorm eating ramen while cramming for test after test could have gone to building my company. Instead, I poured a ton of money into an institution that pays their football coach millions a year while CompSci professors are lucky to rake in 60k.

On the flipside, I met my wife in college. I made life-long friends in college. I experienced a number of life-changing events that probably wouldn't have happened had I been plowing away on starting a company. I also got far more out of classes like sociology, philosophy, english, psychology and even an oceanography class (that I took by mistake) than I did those pertinent to my degree (math, comp sci, physics).

edit: verbage & clarification

As a career programmer I'm interested in how, exactly, you think it doesn't apply.

I second this. I do Applied Math and Computer Science. Computer Science majors tend to freak out when they have to do difficult math, and Applied Math majors tend to freak out when they have to do programming. It seems surprising, but I swear to god it's true.

I worked in games until recently... there's a level of complexity in physics that really must be framed in terms of linear algebra in order to manage the difficulty of the problem. This is especially true when you're trying to polish a game to a professional level.

Many people post in forums about bugs in their character movement, for instance. When you delve into their character controller, you discover that it's written entirely in conditional logic, with no parametric time (only implicit time from frame ticks), manipulating game state directly: if (pressingLeftThisFrame) { character.x -= MOVE_SPEED; }. Then they want to know why their character move at an uncontrollable rate when they turn off vsync. Or they want to make a ninja rope that conserves momentum. Or they want to add a replay function.

Well, the truth is, if you don't model physics and character movement as a differential equation parameterized by time, I can't help you. While it's true that you can just hack more and more conditional logic into your controller, that's not going to provide universal solutions regardless of framerate, screen size, map scale, etc. Everything will wind up janky, and you'll add a shit-ton of "tuning parameters" that you try to guess based on, say, your average framerate.

This will not result in a development process that can include rapid experimentation, nor can it result in a polished finished product.

The one exception to the above rant is if you're working on a fixed hardware configuration. If you're targeting NES, or the 486 DX2 66MHz, or your homebrew board specifically, you don't have to worry about universal solutions. You just make it work. But, if you expect your shit to run the same everywhere, you better believe you need mathematical solutions.

I respectfully disagree. I think it's good advice for those of us who are in the position to give advice and act as mentors to someone who comes to us seeking help. I was recently in this position with my own brother and took the same route as suggested, knowing specifically that my brother usually doesn't stay motivated to push through tedious tasks for very long. Helping him down the path of finding something interesting to work on and then finding appropriate tools for the job was extremely helpful. He stuck with it and built some neat stuff, surpassing my knowledge in some of these tools along the way. I know that if I would have laid out some academic learning path he wouldn't have lasted for more than a month or two.

As respected computer/programming/tech experts amongst our families and friends who might express an interest in programming, I think we have a tremendous capacity to help get people excited and use that excitement as a motivational foundation that they can build their skills on top of. If you look at the video with the perspective that we are the audience and not the fledgling programmer, I feel that it offers a great piece of advice.

There needs to be some basis of understanding.

Sure, but he provides that in the video.

I think it's safe to assume the everyone capable of articulating the statement "I want to learn computer programming" has actually used a computer. And if you've used a computer than you have an idea of the kinds of things computers are capable of doing.

For example, if you've visited a website you are aware that computers are capable of creating web pages and sharing them on the internet. If you've used a graphing calculator, you are aware that computers can graph shit. If you've used Google Maps you're aware.... You might need to have someone (like the dude in this video) to make that basic connection for you, but once someone has done that you've got a good start.

We used VB afterwards which was much better because you could make real apps with it.

That's another wonderful way to teach someone to program. Have them quickly create GUIs. I guess this is why VB was so popular.

I expected something about how as a junior you shouldn't stress over the quality of your code or your algorithms or anything because it'll get better over time as long as you keep the flame alive. That would fit better in this subreddit.

Where did I put my camera?

90% of your class won't know how to program on day one. You're fine. You'll probably be grumbling about how rudimentary the first semester of coursework is.

people expect computers to know what they want from vague explanations, thats an unsolvable problem and pretty common for starters, like - change color - (color of what, where, to what?, etc)

Equating matrix multiplication with linear algebra is almost identically silly to equating programming with computer science.

Or he could block the blow so it doesn't hit him?

I'd respect the hell out of a programming newbie who tried to take on an unsolvable problem with "absolute zero as far as compsci knowledge." That's some goddamn vision right there. And I think they'd quickly learn, in the course of their basic research (google, wiki) of the problem that it was allegedly insurmountable.

This is so true. I interview people occasionally for my company, you'd be surprised the number of people we knock out with simple questions like:

1) Create a function which takes an array of integers and returns the average.

2) Fizzbuzz, or as we call it, Bookworm.

3) Design tables for a database with authors their books. What if a book can have multiple authors?

4) Write some SQL that returns a list of authors with a last name that begins with 'A' that have written at least two books.

Gotta say I was pleasantly surprised by the twist in this video

Would YOU drop-out if you find yourself studying collections and algorithms in C in a few years? Please do not. What craftsman or artisan can produce good work with no tools or without an understanding of the past?

I was speaking more from the vantage point that they are learning about different sorting algorithms / how to make collections. I agree, it's totally necessary learning, but it seems like a huge turn off. You and I might enjoy this type of thing, but I can certainly say I would not have enjoyed that when I was a beginner. Personally, I would never drop out. The reason I'm going to school is to get my degree for job security's sake.

does all software in this day and age have to "stand the test of time"? In some cases, actually it doesn't, and short-lived junk will get the job done and actually make some money.

In the mobile field, not really. The market is too fluid to plan for something to last over 2-3 years. Just look at smartphones. They've come out of nowhere to dominate the market, but even things like the Android API have been in flux/growing over that time. The most I need to do is make my code maintainable for myself or someone else in-house. We all try to use the same structure and style to make that easier.

When I first started working here, they had me create "new" versions of applications we had made as contracts for other companies. One app specifically was only 2-3 years old, but it was completely outdated compared to what we are doing now.

If I were making more of a production application, I would put a lot more consideration into the life of the software of course. And I always do my best to produce high quality work.

people consider the first the first few semesters ... to be the hardest

I only wish I felt that way. I basically slept through the first 4 CS classes and aced them. Once they started throwing in hardcore math statements and equations in, my brain just said "nope".

" Prove the set of regular languages is closed under intersection" Fuck.