Does attempting to develop some sort of game, even just as a hobby during leisure time provide useful (professional) experience or is it a childish waste of time?
I have pursued small personal game projects on and off throughout my programming career. I've found the (often) strict performance requirements and escalating design complexity have taught me some of my most useful programming lessons.
In these projects to name just a few, I very quickly came face to face with: "Everything is fast for small N". I also discovered the hard way about using basic object oriented design principles to manage complexity.
In a field where many technologies and topics can be quite dry/dull, I think hobby game development is important in motivating new (and not so new) developers to brush up on essential skills while having fun at the same time.
This question talks about hobby projects in general, however here I am more interested in game projects specially and how valuable they are to professional programmers.
You can learn a lot from game development. Game development requires a discipline that you can't find in other programming projects.
Here are just a small set of things game development has taught me:
Optimization for speed
Sacrificing computational depth for speed
Developing under small constraints of memory
Building a system that works like an operating system but is geared toward speed.
Keeping hundreds to thousands of objects in a tree, each with their own unique characteristics
Some areas of game development have great academic value (like Artificial Intelligence, Procedural Algorithms, etc)
It doesn't matter how much of a hack the code is, as long as the gameplay is there. Translating this to other disciplines, the objective of programming is to make the customers happy, regardless of how clever or ugly your code is.
Because game programmers are forced to use less resources, they become better programmers.
I think extra-curricular development is a good thing whether it is games or not. For a start you can try different technologies and development platforms and it is a great way of keeping your skills up to date. I prefer mathematical algorithms to games, but that's just a preference which doesn;t speak to the value of doing it at all.
If you bring any of this back to your employer then they are getting the benefit of your broadening knowledge which you are gaining on your own time. That is good for them too.
I say code away to your heart's content!
Games have some of the most complicated processing that's "agreeable" to a layman, hobbyist programmer. In high school, all I wrote were games. Want to explore physics? Write a game. 3D graphics? Write a game. High performance computing? Write a game. AI? Economics? Military Strategy? Natural Language Processing? Theorem Proving? Write a game.
You don't have to publish it, you don't have to document it, you don't even have to PLAY it, you just need to fiddle with it, and you'll learn any algorithm you find interesting as you try to apply it -- in a game.
Games are interesting because of the wide domain they can cover. Everything else is just data processing, and you can do that at work!
Game development (or any other sort of personal programming) is a good way to:
learn new languages
learn new concepts (TDD, OO, etc..)
Use and evaluate different tools/technologies (CI, automated tests, etc...)
These sorts of projects give you the freedom to explore different aspects of the programming world that you are not able to do at work. If you are stuck doing line of business applications at work, you probably won't deal with a physics engine, or spacial rendering. But you could explore these subjects in your game.
This would also provide you with a good portfolio of code you can bring if/when you interview for new positions. Assuming the code you write is in decent shape...
If you are looking to get a job in game development, you should absolutely be doing some hobby development on the side while you look. Being able to send a more-or-less complete game along with your resume makes it stand out from the crowd. When we list a game programming job we get a ton of resumes, and while I'm thrilled to hire people with no industry experience to fill them, it's kind of hard to pick between all the options.
Sitting down at a problem and solving it with the tools at hand (whatever the problem is, fixing a database, programming an interface or making chess in ascii) is helping you becoming a better programmer.
Hands down.
I think more importantly, is the hobby game development making you happy?
Many areas of game development can absolutely be applicable on a more professional level, but if that's the only reason why you're developing games as a hobby then you may want to re-evaluate the situation and perhaps put your efforts toward various open source projects that could proudly be displayed on a resume (not that hobby game developing couldn't) or discuss at an interview.
Your hobbies should be something you love doing and if you love game development, then absolutely stick with it and hey, maybe you'll find yourself doing it professionally which ultimately seems like the ideal situation for your scenario.
I don't see how anything that enables you learn, practise and experiment could be considered 'childish'.
Besides, if you are aiming to produce a decent (even 'professional') game, it will almost certainly require learning and mastering skills that are directly transferable to may 'conventional' roles. Optimisation, testing, cross platform working, UI design and usability... the list goes on.
YES
I taught myself C (and Psion's proprietary OO extensions) using the Psion Series 3 TopSpeed C SDK and wrote several games which I released under the GNU license. (Previously I had quite a bit of experience in Turbo Pascal and Pascal on the Amiga and Borland C++ 3.1 on Window 3.1 in a financial analysis internship doing signal processing, but when I got the Psion, I have to go back to C and I used K & R to get a good solid basis for that code.)
Then I parlayed the expertise I learned about the Psion platform into a 3 year gig doing mobile development using their industrial handhelds where I gained experience in databases, too. It was a huge turnaround for them, the product was in disarray and I had a ton more experience in the platform than anyone else - just from that year writing games.
I parlayed that into a Windows development gig where I eventually became IT director and got massive experience with SQL Server, Windows, ASP, data centers, DR, you name it.
Then I moved into data warehouse consultancy.
I owe a lot of it back to that first foot in the door where I really was able to make a massive difference to that first company because of the platform experience in C and that particular C-based library system.
Related
I realize this comes at an enormous risk of being branded "subjective" and "discussion-based", but you don't have to argue with anyone, or me. I'd just like honest answers to the question. So first, the question:
In your experience, is it feasible to say I could find a job as a java or other "non-web" language/system developer without a CS degree?
A little background : I am a LAMP(PP) Developer, and have been working with the web world for the past two years or so, and am about 90% self-taught. [edit] I have been working part-time/freelance in html/css/javascript for about 7 years, and full-time salary doing php/perl for the past 2 years, for clarification. [/edit] A friend of mine who does a lot of Java has convinced me to start learning it, and I'm starting to be curious about my potential employability in a "non-web" environment. So far I've worked for marketing firms and doing application development for a web-based system, so having a Bachelor's degree in a non-related field (music) hasn't held me back yet.
Acceptable format for non-subjective answers :
"Our company does not require a specific degree, if you have a few years of employment history and can prove you know programming you can get a job"
-or-
"With the economy being the way it is, the only way to ensure you'll get past the first level of screening is to have an extensive relevant education"
Yes you can (otherwise I would not have a job). If you can show that you know the stuff, many companies will not bother too much about formal degrees. After all, they (should) hire people because they have certain skills, not because they acquired those skills in a specific manner. Studying at a university is one way, working with programming in practice is another.
Now, I think (guessing here, given my background) that you would learn things in the university that you will not typically pickup from being an autodidact, and that might still be useful when working as a programmer, but I would believe that the more time you have spent working on actual software that has been delivered to (hopefully happy) customers, the less the lack of formal degrees will matter.
In my experience, it pretty much depends on where you want to work, and in some cases, how far up the management ladder you want to go.
Some places I've worked don't really care if you have a degree or not. In fact, in one place I worked it was almost a detriment to have a degree, since much of management didn't have degrees.
Other places I've worked have required a "related" degree. In at least one case I was personally involved with, that was to their detriment, because a friend of mine was much better and more knowledgeable than any of the developers there, and looking for a new job, but they wouldn't even talk to her since she didn't have a degree.
Finally, for some employers, it's just whether you have a degree or not, and your major is not important. I know one guy doing Java development, and his degree is in history. Also, I work in a science facility, and lots of people here have degrees in a relevant science, and have little or no formal software development education.
It's a mindshift for sure, but I don't see any reason why you can't make the transition. A good programmer is a good programmer regardless of the language they're using. I've known guys that write excellent java code and easily make the transition to javascript or ruby. Where you might come unstuck is the fundamentals of computer science which is what you really get from the formal education. Things like pointers, memory management, threading etc are things that I tend to find "self taught" developers are usually not so strong in, but there's no reason you can't learn these things and if you're able to prove to prospective employers that you have a good grasp of the concepts and can prove you know how to use them then I don't think you'll have too much trouble.
In your case you should use your music degree as an advantage and look to land your first application programming job in a company doing music-related application development. Your music degree coupled with programming experience of any kind will certainly open some doors.
You may need to take an initial cut in pay to make the transition, though.
Speaking for my own experience and my country Switzerland: I started with an internal education in a big company and do not have a degree in CS up to now, some 23 years later. I had difficulties finding a job in the 2 years following the burst of the internet bubble, which I was able to breach being self-employed and with some unemployment money from the government.
Most big companies here do not care about degrees, unless you want to pursue a carrier. But then you need an MBA, not CS.
There is one exception, though, which are the consulting companies. They sell their services proportionally to the numbers of Doctors they have in the team, so no chance - unless you have connections.
Small companies here know that they have to invest for somebody to know the tools and languages they use - so if they are in need, they will hire you even with little experience in the exact field.
It might not harm to get some stuff done with the tools you would prefer to work with, but
good employers know that learning yet another language is not the hard part
work experience outweighs private experience
Go for it. Don't quit your dayjob and start looking around. After a few years experience will for sure outweigh education on the job market.
If you have the chance to visit some classes on the side, you can only benefit though. Personally.
My experience has always led me to evaluate past evidence. This means what is there to show what you have achieved. If you are entering a new technology, it will be a while before you will achieve this which means you may have to re-start at the bottom. Do you want to do that? If you are prepared to offer all your skills to a new job (including learning new languages), that would be better. In this way you become incrementally more valuable, irrespective of whether you have a degree or not.
I'm mostly self-taught, and in my career, I have transitioned from VB to C++/MFC to "classic" ASP to Java, and that doesn't even scratch the surface of all the ancillary technologies I had to learn to get my job done. I think all developers should expect to pick up new skills. It just comes with the job.
I think you're making an odd distinction between "Web" and "Application" development. Practically all of my Java work has involved building web sites, and the same is probably true for C#/.NET developers as well. As a LAMP guy, you already have a few key employable skills -- you know Linux, you understand (or should understand) the TCP/IP stack, how HTTP works, etc. And you know how to put together an attractive-looking interface, which is a rarer skill than you might think. You can leverage all these skills as you make the transition to Java/.NET/Whatever.
As for the music degree, don't sweat it. Some of the best programmers I've ever worked with have been musicians. I don't have a CS degree, and it hasn't slowed me down much. A certification might help get you in the door at some companies, but before that try a pet project or two in Java and see where it takes you.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Does anyone have any idea how it would be possible to transition from business to game programming? How would anyone get a start in game programming? It seems much more exciting and rewarding (better paying too?). But it seems like most of the jobs out of school are for business programming. Any advice or insight on how to do it or if it can be done?
This is not a direct answer to your question, "How can I transition?" But instead I'd like to recommend you not go down that road or at least be realistic about what it is like. To back that up I'll quote some stats from the 2004 igda survey on quality of life for game developers:
34.3% of developers expect to leave the industry within 5 years, and
51.2% within 10 years.
Only 3.4% said that their coworkers averaged 10 or
more years of experience.
Crunch time
is omnipresent, during which
respondents work 65 to 80 hours a
week (35.2%). The average crunch work
week exceeds 80 hours (13%). Overtime
is often uncompensated (46.8%).
44%
of developers claim they could use
more people or special skills on
their projects.
Spouses are likely to
respond that "You work too much..."
(61.5%); "You are always stressed
out." (43.5%); "You don't make enough
money." (35.6%).
Contrary to
expectations, more people said that
games were only one of many career
options for them (34%) than said
games were their only choice (32%).
Many years ago I created a couple of game development websites on my own and then was one of the founders of GameDev.net. One of the reasons I did it was to make contacts and get into game development professionally. It definitely worked, a couple of the people who were co-founders have gone on to work in the industry and I'm sure I could have gone that way too but everything I learned about the industry taught me the following things:
There is an endless supply of developers out there who believe game development would be really cool. The people hiring for the industry know this and aren't going to pay you nearly as well because they rely on this basically inexhaustible pool of people.
Many of the developers within the industry may be good with 3D or sound or many other topics but often they are inexperienced with basic software practices that you or I might consider essential. In that category I would put things like source control, test first design, design patterns, etc. Even when they know better the time crunch to get stuff out the door often makes them toss good software practices in a foolish attempt to save time.
Working on a game for two years can quickly become no different than working on any other program for two years. That is, when you have to dig around in the guts of the program day after day and deal with its bugs and only with that one game it's not going to seem all that fun anymore. In fact, you may find yourself playing other games just to get away from it for a while.
What says you are going to be working on Half-Life X or one of the few dozen cool games that come out every year anyway? Remember, somebody is out there building the game that goes with the next Will Farrell movie and it's probably going to be you. Look around at most of the dreck that comes out. That stuff doesn't develop itself.
It's quite a transition! The biggest difference in mindset is moving away from the business world's reliance on abstraction to one where you're focused much more on the particular hardware you're targeting and getting things to run within strict budgets of time and memory. Game programming is a lot more like embedded programming than it is like web programming -- you have to think about the exact memory footprint of everything and CPU time is at a huge premium.
This is even true of being an MMO server programmer, because a) the server has to answer to each client command within 80 milliseconds to feel responsive, and b) the bigger the footprint of the game on the server, the more hardware you have to buy, and that costs real money.
First up you should learn C++ if you haven't already. Almost every game is written in C or C++ these days. Game consoles have strictly limited memory, and if you allocate one byte past 512mb it doesn't slow down, it crashes; at the same time, each trip through the main app loop has to complete in 33ms or less, so we can't rely on garbage collection and smart pointers. The game-development world is one of those special applications where you really need to do all those optimizations that people here say you never need to do any more.
Also, bone up on your math. Games are built out of linear algebra and kinematics -- not just the graphics, but the state of the world and the behavior of every character and object. I like Eric Lengyel's book for game math; it's been my bible for years (though there are many other good ones).
You could try to learn some graphics math and programming as well, but this is sort of a subspecialty now and typically only a couple of people on a game team are really working at the level of DirectX calls. I suspect you're more interested in game logic and server backend, which is less specialized.
Make games. There are many frameworks to help you get started. XNA has the advantage of being a real-world product that actual games are shipped with, unlike PyGame or SDL which are quick to get up and running but have vanishingly little commercial support.
A common route people take transitioning into the game industry is starting as a game development team's Tools Developer.
These tools are often written in higher level languages like C# and are used to aid in the development of the games. For example, you might help maintain or modify the teams in-house map level editor or help develop the tools that convert one media file format into their propriatary file format.
After you have spent some time as a tools developer you can start picking up domain knowledge on the side and naturally transition into one of the many types of game programmers:
Game physics programmer
Artificial intelligence programmer
Graphics programmer
Sound programmer
Gameplay programmer
Scripter
UI programmer
Input programmer
Network programmer
Game tools programmer
Porting programmer
Technology programmer
Lead game programmer
Modern games are often made by huge and highly fractionated teams in terms of roles. So, it might be worth it to pick one of the above specialities and begin studying right away as you attempt to get your foot in the door. It almost goes without saying that you should be proficient in C++ and one of the major graphics libraries (OpenGL, DirectX, etc). Don't stress about learning both, just pick one and learn it. Generally people who know one very well can transition to the other if they need to.
If you're a good programmer you can do it, game programming requires much better understanding of the platforms and tools you use to develop the games.
I think it's much harder to get into the game programming industry than just the regular industry.
The best alternative is to create your own games, get exposure, if you're good enough you'll find your way.
There are many really good competitors though, just check out the many sites that offer free flash games, you can start posting your work to those sites.
The general story is that the way to get into game programming is to start doing it. There's no point in even showing up on a game company's doorstep without a demo of whatever you want them to pay you to do.
If you're coming out of business programming, that'll count against you and be a culture shock besides. The game industry runs on single 20-something males who can be taught that 120-hour work weeks are just how things are done.
I'd recommend keeping your current job for a while and finding a mod team or open source game that could use help. Try to find one that looks likely to create a playable game rather than vanish, at a guess I'd say it will look better on your resume than some test demos both because you'll probably be working on something more advanced than you would at home and it shows you can work in a games team.
I was wondering the same thing!
I've noticed there are a number of good game-programming books at Barnes & Nobles, probably not a bad place to start.
In general though, I'd start looking at books, maybe coding some prototypes, and start looking at what companies are in your area, what tools they use, how you could basically make yourself valuable to them!
By the way, does anyone happen to know if there are particular engines similar to what WOW / Guild Wars are using for MMORPG game development in particular (my main interest)?
I think it is not an easy switch. Game programming is not something you can learn overnight. I suspect an entry level will be quite high if you want more than a graduate salary.
A long time ago I worked in a company that worked in the online gambling field. I then decided I wanted to be engaged in more serious activities.
You really need to answer one question - is that what you want because you like it or just because it seems to be rewarding right now. In the latter case you'll need to understand you'll be plating catch-up and noone can promise the salaries will be as high as you wish by the time you get your skills high.
Maybe consider some certifications/training so that you can step-up your current career position in business programming?
If however it is what you really want then just follow you heart. Show your interest and commitment, potential employers will notice it and hopefully prefer you over a guy who has applied just because the salary was looking attractive.
On the other hand, businees developers/consultants (for example in SAP world) earn quite a generous ransom.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
A little backround:I'm a 22 yr old with just a high school degree and a lot of free time (college did not work out). I am completely new to web programming and I have taken a couple day classes in Photoshop, Illustrator, Dreamweaver, Fireworks, and InDesign. Seeing as these are only day classes, I am by no means a pro at any of them but I am getting more familiar with the Adobe programs. My teacher who was a freelance web designer told me that along with those Adobe programs, if I could learn HTML, XHTML, CSS, Flash, and Java that I would be in good shape regarding getting a job. She also told me if I could get good at both the design and programming sides, I could really get a good job.
I was just wondering if anyone has some advice or information for basically a noob who is starting from scratch and really wants to get into this profession. I've gotten on lynda.com to try and get going on the programming stuff and I'm just trying to turn some of these skills into a job. Best case scenario is that eventually I could be doing freelance and supporting myself...But that is obviously very far away. ANy advice would be greatly appreciated....
Advice You Don't Want To Hear
figure out what went wrong with college - at 22, you should have graduated by now, or close to it
fix it!
focus!
go back to college with a new focus and resolve - you now have a goal
If You Can Teach Yourself, You Can Graduate College
if the problem was boring general ed classes, look into CLEP tests to test out of them
if the problem was curriculum, take classes you are interested in first
if the problem was time, start part-time
if the problem was school choices, research different colleges - many online universities are now accredited
if the problem was self-discipline, then freelancing is not a good career choice
I'm not saying that you can't do what you asked about, but your chances of getting a good job are greatly increased with a degree, even a 2-year degree.
Obviously, this is not the only path, but it is arguably the easiest path. Marketing yourself when you have no degree and no experience is difficult, even if you are overflowing with talent and creativity. (It's easier now with the Internet, but by the same token the marketplace is that much more crowded.)
Good luck!
I'm currently a software engineering consultant. Familiarity with the following list of things helped me get an interview and an offer right out of college.
Note: HTML, XHTML, CSS... these are just markup languages, and chances are they'll barely be glanced at if you put them on a resume. Flash (not so much) and Java are more impressive, but you might want to look into the following additional topics/technologies to really spice up that resume:
Get comfortable with OO (Object-Oriented) principles (inheritance, polymorphism, abstract vs concrete classes, encapsulation, etc.)
Java is a great open-source beginner programming language. I'm primarily a .NET developer so I tend to favor that, but I started with Java in my college days and picked up on it very quickly
.NET 2.0, 3.5 -- C# and VB.NET (LINQ, lambda expressions, anonymous methods, etc.) -- You can start with the Express edition of Visual Studio, but may eventually want to get the full version
Move on to higher level programming concepts such as Design Patterns (MVC/MVP, Command, Facade, Adapter, the list goes on and on) -- I'd recommend the Gang of Four book (Google will tell you which book it is)
Database Management Systems
Learn SQL, be comfortable JOINing, using GROUP BY and HAVING clauses, and familiarize yourself with aggregate functions
Tackle DB design concepts (relational modeling especially)
Start with the free ones, like MySQL or PostgreSQL, then...
Focus on Microsoft SQL Server or Oracle (these are the big cats)
Go deeper with things like Normal Forms, data warehousing (OLAP, MOLAP, ROLAP, cubes, etc.)
Testing: look into unit testing and test-driven development
Software quality assurance - defect prevention techniques, etc. (this goes along with some of the points mentioned below)
Look into methodologies like Waterfall, Agile, and XP (eXtreme programming), perhaps even PSP and TSP
Learn to use Source/version control systems such as CVS, SVN, and VSS (Microsofts, unfortunately not free -- the first two are)
You could get really crazy and learn about static code analysis, but definitely look into code reviews and code inspections
EDIT: I thought I'd give you some books to check out (no particular order):
Introduction to Algorithms, 2nd ed.
Thomas H. Cormen, Charles E.
Leiserson, Ronald L. Rivest, and
Clifford Stein, 2002.
Artificial Intelligence: Structures
and Strategies for Complex Problem
Solving, 5th edition. George F.
Luger, 2005.
A First Book of Visual C++. Gary J.
Bronson, 2000.
An Introduction to Object-Oriented
Programming with Java, 3rd edition
(Java 1.5) update. C. Thomas Wu,
2004.
Mathematical Structures for Computer
Science, 5th edition. Judith L.
Gersting, 2003.
Mastering the Requirements Process,
2nd edition. Suzanne Robertson and
James Robertson, 2006.
Data Management: Databases and
Organizations, 5th edition. Richard
T. Watson, 2006.
Software Quality Engineering:
Testing, Quality Insurance, and
Quantifiable Improvement, 1st
edition. Jeff Tian, 2005.
Artificial Intelligence: A Modern
Approach, 2nd edition. Stuart
Russell and Peter Norvig, 2003.
Software Architecture in Practice,
2nd edition. Len Bass, Paul
Clements, and Rick Kazman, 2003.
Unit Testing in Java: How Tests
Drive the Code, 1st edition.
Johannes Link and Peter Frohlich,
2003.
Practical PostgreSQL, 1st edition.
John C. Worsley and Joshua D. Drake,
2002.
PSP: A Self-Improvement Process for
Software Engineers, 1st edition.
Watts S. Humphrey, 2005.
TSPi: Introduction to the Team
Software Process, 1st edition.
Watts S. Humphrey, 2000.
I guess that's all I have for now. If you can get these things down, your skill set should be pretty solid, and you'll be on your way towards being another member of the software engineering world. I'm not sure that anything you do on your own will give you the same level of knowledge as college courses, but I'm sure this is a good start. This is a hefty list; don't be surprised if obtaining these skills takes a couple of years.
As far as your graphic design skills, depending on the type of job you find yourself in, they may be more important than your programming skills. On top of either skill sets, make sure your soft skills are polished and that you are confident in your work.
Don't create websites by exporting to web from your design programs. If you see yourself creating slices and mouseover effects in Fireworks STOP and hit yourself in the head with something heavy and blunt.
Learn XHTML and CSS and learn them well. Try to be as semantic as possible.
Pick an all inclusive framework and build yourself a web app like a blog. As much as I love ASP.NET it is not all inclusive. It is massive. It will throw you in every direction. The same can be said of Java. Try something simple like Django or Rails.
Practice, practice, practice, and realize that all that you know is crap and that you need to get better.
Go back to 4 and do it till you die.
Ok, this may not be popular - but is drawn from my own experience at being a "self taught" programmer. The bottom line for getting a job at a company as a "programmer/web developer" is about "0%" without some type of degree/certification/on-the-job experience.
You may have noticed "the problem" with that statement - without a degree or certification, how do you get "on-the-job experience"? Welcome to "the real world".
My path to becoming a developer started with "the desire" ... and getting a job doing something else (Semiconductor manufacturing if you must know). I learned programming on my own as a "hobby" and continually looked for ways to apply it to my job tasks to improve my "job performance". I eventually applied for positions that would bring me closer to "programming" to make better use of my growing skills until I had enough "job experience examples" to apply for a programmer position.
That took "8 years". Regardless of what you think about college, getting "any" degree related to computer science at one would have cut that in half. You can do it on your own, but until you have some outstanding examples of how you used your programming skills to solve "real business" problems, you won't be considered over anyone with a degree "just out of school". When you finally do make it, you will notice that the "just out of school" folks who don't know jack about solving "business problems" will probably start with a better salary than yours.
The environment is probably better now than when I started (25 years ago - :-)) but the same general principle applies - the degree may not mean you know how to program, but it will get you past the "HR" screening process so you can get the job. :-)
Good luck ...
Create a project that would actually be useful and non-trivial for you: A forum or message board, or a job posting site, for instance.
But here's the important part: Give yourself a firm deadline. You can do quite a lot in, say, 4 weeks, and if you keep to a schedule like
database backend in week 1
login system in week 2
messaging in week 3
and so on, you can broadly cover many related subjects. Your project won't be pretty, but if you start out being a perfectionist, you'll never finish it, and will end up knowing only the first half of the technology in your project really well.
As you get more experience, you can go back and polish things up or rewrite stuff you did wrong, and then you have a portfolio that accurately reflects your current skills.
Learning HTML, XHTML, CSS, Flash, and Java plus several graphical programs is a pretty tall order. You'll overwhelm yourself trying to do that. Pick one and learn it then move onto the next. Grab a book or search the Stack Overflow archives for recommended online tutorials.
The best way to learn is to pick a project and just work on it. Then learn on demand as you find a need. The end product won't be the highest quality, but you'll learn how everything works together.
For serious web developer it is very crucial to understand how websites work inside out.
As you are starting from scratch I strongly recommend W3Schools.
With this website you can learn from Very Good Tutorials, then Try It Yourself and Test your skills.
Here are the steps for an absolute beginner:
html
css
JavaScript (Client Side Scripting)
PHP (Server Side Scripting)
SQL (DataBase applications)
DOM(Document Object Model)
AJAX
Drupal/Joomla/Plone (Content Management Systems)
NOTE: Type the code rather than cut-paste or using tools like Dreamweaver/FrontPage.Use the tools only after you are very comfortable with manual coding.(Believe me this helps a lot)
Enjoy!!!
The best I could suggest is that you create a fake need, for example create a simple file read / write app, or something that can toss information onto a database and retrieve it.
A more advanced project you could start on after would be a tagboard of sorts, with Create/Update/Read/Delete (CRUD) functionality, and add features to it in order to get practice with cookies, login, more database functionality, etc. You could also try using an image editor that just draws a clock showing the current server time the request was recieved as practice with images.
I would recommend learning html and css first. That is the cornerstone of anything you'll do on the web. For graphics, learn photoshop. Once you can make basic html websites, I would then choose to pursue either asp.net or flash. There are good jobs in both fields. I would say pick asp.net if you like programming, and flash if you like the visual aspects of web development more. As an asp.net developer I would say 90% of my day is doing database related work with MS SQL server. Really focus on databases. Finally, if you develop with asp.net, you should program in C# rather than vb.net. I started as a vb.net programmer and had to switch to C#, simply because most of the professional world uses it, hence it will be easier getting a job.
Look into local Code camps and user groups, create a project and build it, start by lerning HTML, CSS and javascript, then look at learning PHP is a great starter language for doing beginning web development the code side.
as far as getting a job without a degree, start a little lower on the food chain, I started in the QA lab, from there you can learn from the development side good practices and the do's and don't. Also as a QA person you learn in a hurry who are good developers and who are not simply by the work they produce.
W 3 Schools is a neat beginner/novice reference and tutorial site.
The site covers most technologies used in web-development.
I come from a fairly strong OO background, the benefits of OOD & OOP are second nature to me, but recently I've found myself in a development shop tied to a procedural programming habits. The implementation language has some OOP features, they are not used in optimal ways.
Update: everyone seems to have an opinion about this topic, as do I, but the question was:
Have there been any good comparative studies contrasting the cost of software development using procedural programming languages versus Object Oriented languages?
Some commenters have pointed out the dubious nature of trying to compare apples to oranges, and I agree that it would be very difficult to accurately measure, however not entirely impossible perhaps.
Most all of these questions are confounded by the problem that individual programmer productivity varies by an order of magnitude or more; if you happen to have an OO programmer who is one of the gruop at productivity x, and a "procedural" programmer who is a 10x programmer, the procedural programmer is liable to win even if OO is faster in some sense.
There's also the problem that coding productivity is usually only 10-20 percent of the total effort in a realistic project, so higher productivity doesn't have much impact; even that hypothetical 10x programmer, or an infinitely fast programmer, can't cut the overall effort by more that 10-20 percent.
You might have a look at Fred Brooks' paper "No Silver Bullet".
After poking around with google I found this paper here. The search terms I used are Productivity object oriented.
The opening paragraphs goes on to say
Introduction of object-oriented
technology does not appear to hinder
overall productivity on new large
commercial projects, but it neither
seems to improve it in the first two
product generations. In practice, the
governing influence may be the
business workflow and not the
methodology.
I think you will find that Object Oriented Programming is better in specific circumstances but neutral for everything else. What sold my bosses on converting my company's CAD/CAM application to a object oriented framework is that I precisely showed the exact areas in which it will help. The focus wasn't on the methodology as a whole but how it will help us sold some specific problem we had. For us was having a extensible framework for adding more shapes, reports, and machine controllers, and using collections to remove the memory limitation of the older design.
OO or procedural offer to different way to develop and both can be costly if badly managed.
If we suppose that the works are done by the best person in both case, I think the result might be equal in term of cost.
I believe the cost difference will be on how you will be the maintenance phase where you will need to add features and modify current features. Procedural project are harder to have automatic testing, are less subject to be able to expand without affecting other part and is more harder to understand the concept part by part (because cohesive part aren't grouped together necessary).
So, I think, the OO cost will be lower in the long run compared to Procedural.
i think S.Lott was referring to the "unrepeatable experiment" phenomenon, i.e. you cannot write application X procedurally then rewind time and write it OO to see what the difference is.
you could write the same app twice two different ways, but
you would learn something about the app doing it the first way that would help you in the second way, and
you may be better at OO than at procedural, or vice-versa, depending on your experience and the nature of the application and the tools chosen
so there really is no direct basis for comparison
empirical studies are likewise useless, for similar reasons - different applications, different teams, etc.
paradigm shifts are difficult, and a small percentage of programmers may never make the transition
if you are free to develop your way, then the solution is simple: develop things your way, and when your co-workers notice that you are coding circles around them and your code doesn't break nearly as often etc. and they ask you how you do it, then teach them OOP (along with TDD and any other good practices you may use)
if not, well, it might be time to polish the resume... ;-)
Good idea. A head-to-head comparison. Write application X in a procedural style, and in an OO style and measure something. Cost to develop. Return on Investment.
What does it mean to write the same application in two styles? It would be a different application, wouldn't it? The procedural people would balk that the OO folks were cheating when they used inheritance or messaging or encapsulation.
There can't be such a comparison. There's no basis for comparing two "versions" of an application. It's like asking if apples or oranges are more cost-effective at being fruit.
Having said that, you have to focus on things other folks can actually see.
Time to build something that works.
Rate of bugs and problems.
If your approach is better, you'll be successful, and people will want to know why.
When you explain that OO leads to your success... well... you've won the argument.
The key is time. How long does it take the company to change the design to add new features or fix existing ones. Any study you make should focus on that area.
My company had a event driven procedure oriented design for a CAM software in the mid 90's created using VB3. It was taking a long time to adapt the software to new machines. A long time to test the effects of bug fixes and new features.
With VB6 came along I was able to graph out the current design and a new design that fixed the testing and adaptation problem. The non-technical boss grasped what I was trying doing right away.
The key is to explain WHY OOP will benefit the project. Use things like Refactoring by Fowler and Design Patterns to show how a new design will lower the time to do things. Also include how you get from Point A to Point B. Refactoring will help with showing how you can have working intermediate stages that can be shipped.
I don't think you'll find a study like that. At least you should define what you mean by "cost". Because OOP designing is somehow slower, so on the short term development is maybe faster with procedural programming. On very short term maybe spaghetti coding is even more faster.
But when project begins growing things are opposite, because OOP designing is best featured to manage code complexity.
So in a small project maybe procedural design MAY be cheaper, because it's faster and you don't have drawbacks.
But in a big project you'll get stick very quickly using only a simple paradigm like procedural programming
I doubt you will find a definitive study. As several people have mentioned this is not a reproducible experiment. You will find anecdotal evidence, a lot of it. Some people may find some statistical studies, but I would examine them carefully. I am not aware of any really good ones.
I also will make another point, there is no such thing as purely object oriented or purely procedural in the real world. Many if not most object methods are written with procedural code. At the same time many procedural programs use OO methodologies such as encapsulation (also call abstraction by some).
Don't get me wrong, OO and procedural programs look and are different, but it is a matter of dark gray vs light gray instead of black and white.
This article says nothing about OOP vs Procedural. But I'd think that you could use similar metrics from your company for a discussion.
I find it interesting as my company is starting to explore the ROWE initiative. In our first session, it was apparent that we don't currently capture enough metrics on outcomes.
So you need to focus on 1) Is the maintenance of current processes impeding future development? 2) How are different methods going to affect #1?
Like most developers, I'm a business developer, which in essence consists of slapping a UI onto some back-end data store. (We all know there's a lot more to it than that, but that's usually what it boils down to.)
I understand that game development is very different from business development, but I'm having a hard time explaining it to a friend of mine. I was hoping the SO community could help me out here.
To me, modern game developers deal a lot with manipulating 3-dimensional graphics. In gaming code (and I'm guessing here), you're assembling polygons (or something like that), rotating 'em, etc. This involves a different way of thinking from manipulating relational data (for instance). I don't know, really. I just know it's different.
EDIT:
I should stress that by "development" I mean "programming," not all of the aspects that go into creating a game or piece of business software. I'm sorry I didn't make that clear originally.
Thanks!
I'm in game development but came from business development long ago. Game development is very rigorous in mathematics if you work on the physics or graphics side. Even AI can need quite a bit of mathematics for the low-level stuff. The hardware usually takes care of a lot of the polygon manipulation math as far as drawing on the screen goes. There is also a lot of involvement with generating the in-game data with (often) many tools that are run in a pre-processing step, and that too can be math-intensive if you are generating visibility data.
In terms of programming domains, amongst other things, we deal with:
Graphics programming (including shader development)
Animation
Physics simulation
AI and gameplay
Audio
Networking (typically fairly low-level stuff)
Some of these involve pretty serious maths and algorithms knowledge. On top of all that, we face extremely tough speed constraints, and typically have to be very careful with memory usage too. We face constantly changing hardware, and since we're trying to push hardware to the limit, this can be pretty tough - you can't just abstract it away. Most game development is still quite low-level C++ work. We probably deal with databases less than most other programmers nowadays (although online games are changing this)!
Programmers are often the minority on modern game projects: it's all about content creation (animation, modelling, texturing, audio and design). This means many game programmers are dedicated to making the content creation process efficient, rather than working on the game code itself. This work may have more relaxed speed and memory constraints, although it does have to deal with massive data sets.
Making the game 'fun' is one of the hardest things to do - in business terminology, it "means extremely unstable requirements" as the designers constantly change their mind about how things should work, to chase down that elusive fun factor.
Finally, games are generally a ship-once, no chance to fix stuff kind of deal. This actually means there's very little code maintenance involved, so traditionally there may have been less attention paid to code quality issues. This is changing now with the growth in post-launch content addition, online gaming and the sheer size of modern projects.
Overall it's an incredibly exciting field to be in, the downside is that it's often less well paid (because it's a very tough business financially for developers, and because it's popular, there's always a fresh supply of people looking for jobs).
Just some random thoughts about what is different in game development. Note that there might be some sarcasm in it, though I tried to suppress the urge.
Unless you're a lucky employee of one of those new-style studios (like Eidos Montreal or Blizzard), there is always a deadline to fear that is much too short. In business programming, you mostly make the deadline up for yourself.
A business application serves some specific need. A game's intent is to entertain people. You can't really predict if a game will fail until it's out.
Performance is essential, in every aspect of the game. Writing code that is good to maintain is second priority. In business programming, good code that works is top priority.
For a business application, a shiny UI is a bonus. For a game, it is a must.
Debugging games is much harder, because there is always some hardware dependence which results in bugs that can only be reproduced on some machines, none of which is in your company. And a game sucks up much more performance than a typical business application.
You have people dedicated to creating the art, story, music, sound, background and design, none of which necessarily needs programming knowledge (scripting is a little different), i.e. you have a lot of content which is what the users (players) will see. Nobody cares about how good your code is, unless performance is bad or there are bugs. The others get the praise.
For larger games, you have programmers dedicated just to 3D graphics, networking, audio, tools, scripting, physics and so on. Most of them are highly specialized and each of them can lead the game into a disaster. You'll only need advanced math skills if you're the graphics or physics guy. Well, or AI.
Most games are fire-and-forget, apart from some bugfixes, unless it's one of the more successful games, which get an expansion pack or a sequel.
Security is an important issue for online games, since there are much more annoying people trying to to put people off than there are for business applications, many of which are for (more or less) internal uses at the customer.
You are expected to work much more than when writing business applications.
To land a job for an AAA title, you need to have worked on at least three shipped AAA titles (no, no typo here, ever read some job descriptions at Blizzard or LucasArts? :P)
But here come the good things:
You can pretend to work when you're playing games.
And finally, programming games is fun. Priceless.
Business development is generally much more forgiving.
The reason is basically this; usually, people ARE PAID to use business software. People PAY to use game software.
This may sound like it's not answering your question, but it really is. When my boss says "use microsoft word for that document", they're providing the software, and I'm obligated to use micosoft word. And so, when using it, when it decides to renumber all my chapter headings "just because" or a save to disk takes 30 seconds while it resolves OLE references (it's JUST ONE FREAKING EXCEL SPREADSHEET, for heaven's sake!), I just grit my teeth and remind myself I'm getting paid to do this.
Whereas, if I'm in a game, I'm expecting entertainment. I'm expecting the experience to work properly, and smoothly, and cleanly, with no major stutters or problems.
Again, getting down to why this is an issue for programming; those loops and structures in the game had better be DAMN good to make sure there is no major slowdown, no stuttering in the game engine, nothing that makes the consumer who just spent X amount of his hard-earned dollars say "this is a piece of crap" and walk away. With business software, you can get away with that sort of thing; in some ways, it's almost expected. Again, look at the performance of Microsoft Word; if it were a game, it would be laughed out of existence.
I know I sound like I'm picking on Microsoft Word, and I generally am, because I find it to be hideous, but the point is true for so many pieces of software. CAD software is another example. Same basic things going on as in games, but in general it's slow and hard to work with without a lot of training.
The difference comes down to polish, and the level of polish that's expected. Yes, there's generally more flexibility in business software than there is in games; but moreover and more importantly from a coding perspective, the code has GOT to work efficiently and cleanly in a game; business software is, generally, more forgiving of sloppy code.
In a business app, unoptimized and slow algorithms are generally accepted; and while they're never preferable, frequently the business decision gets made to add another feature instead of improving the performance. But in games, performance IS a feature, and one which is make-or-break.
One should have infinite loops, one shouldn't.
One should have infinite loops, one shouldn't. - Rich Bradshaw
Rich is right. Fundamentally, from a coding standpoint, a game loop creates a "frame" of action in which actions are taken based on the state of the game such as controller input, object collisions, etc. This loop repeats infinitely until some state of some game element or input tells it to stop or "quit." This approach keeps the CPU and graphics card pretty busy, hence the market for gamer machines with fast processors and even faster graphics cards.
Business applications do not have an active loop. Instead, they sit idle waiting for an event such as a click, a message from a web service client, an HTTP GET request, etc. Then they respond to the event.
Sure, gaming is generally more geometrically intensive than business applications, but that is not entirely true. Consider image editing, CAD and graphics tools. For many, these are business applications. But for the most part, a business application has to do with querying data, displaying that data, accepting user input, and modifying the data based on user input. In many cases, the business application does this across the network or even the Internet, but it's an apt nutshell.
The skillset and mindset of a business application developer and the game developer is often different. The game developer has a limited number of input constructs to consider in terms of creating a user experience with an unlimited choice of context or "world" if you will. The business developer is the opposite, with a limited set of potential contexts, usually the web page or the basic window, and an unlimited (or nearly so) set of input and data display combinations to create a user experience entirely different than the game developer sets out to achieve.
One big difference between business development and game development is the number of disciplines involved. Most business software is created by a team of developers, who all have the same basic skillset. In contrast, a game is created by a team of game designers, visual artists, 3d modelers, animators, musicians, and developers.
Good points about mathematics and integration of artists and other specialists in the team. In addition, I'd say that:
Game development, to some extend, will be more hardware dependent. In many cases, games are built simultaneously to several platforms and consoles (not to mention cellphones), with different architectures. That is abstracted up to a certain extent, but developers cannot completely avoid this fact.
Game development is often more performance sensitive, or at least the performance requirements are different. You're dealing with real-time experience, so a lot of time is spent optimizing those pesky fps.
In many cases, game development does not care as much about reuse and maintainability. The game engine will probably be reused, but the application code base will probably not live to see v2.0. In the last stretch of a project, there is a lot of quick and dirty debugging going on. If it looks fine to the end user, there's no added value in making an elegant fix two days before the release.
Let's start from the goal - the goal of game development is to create entertaining product. It should be accurate to the extend that it looks good and runs smoothly. The goal of a business software solution is to model a work process. It should be a tool which works fast enough. A stable product, which executes absolutely accurately and secure the tasks it should do.
Since we target different goals, we use different approaches to build a game and a business software. Let's move to the requirements. For a game, the requirements are determined by the game designer. For a software product the business defines the process and the requirements. For a game the requirements are not final - shall we have small cartoon figures or real human models - this does not matter for the game engine for example. But for a software product, the requirements should be strictly followed and cleared to the maximum possible detail before development.
From the different requirements come different software design and development approach. For a game the performance and gameplay are critical and the qualiity of the graphics and sounds (for example) could be reduced just to be compatible with weaker hardware. Also the physical model could be simplified just to run smoother and improve the gameplay. For the business software everything should be exact and cutting features means that your product will not be as functional as designed anymore.
For a game, the security is not important - there is no critical customer data which should be saved. For a business software a good security system should be supplied - starting from data encryption (while saving on data storage or transferring through network) moving through backup system and mentioning (but not last) the compatibility with previous versions.
I could continue with other aspects but I guess this is already too much for one post...
Business software (that isn't shrink-wrap software) can generally be much more poorly written but still considered a commercial success due to the bizarre disconnect between the quality of the product and saleability of the product. Game software, on the other hand, has to actually be good to survive the marketplace.
The bar for quality in specialized business software is generally much lower.
Business software has to be reliable, maintainable, consistent, not be too annoyingly slow, and can build on lots of already written stuff, such as databases, controls, forms etc.
A games programmer often starts with a blank sheet - hardware reference manuals, some documentation about the hardware and usually thin vendor libraries around some advanced hardware that's completely different to the last job.
From this they have to build what you see - and make most of it work within a 20ms time period, reliably, and often within a ridiculously short time period, facing changing requirements and often a very hard deadline, working untold numbers of hours for a comparative pittance.
That's not to mention often having to master some fairly complex mathematics and physics....
Performance is really the difference, from what I can tell.
Technologywise, games are usually Windows/C++ driven.
Game programming has more in common with scientific programming. You are modeling behavioral systems and anticipating results based upon a limited set of input.