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.
Related
We have been trying now for a while to assist the management (of a customer) with the implementation of a a new system that is custom developed by ourselves, to their requirements. Their old system is text based (DOS) and their employees have been using it for years. The new system is Windows GUI and have many advanced features which will make their lives easier and their organisation more efficient. The problem is that the staff do not want to adapt to the new GUI environment and they are now resorting to be unfriendly and as unhelpful as possible, often placing serious obstacles in our way. The management is adamant that implementation must proceed. The system runs trouble free. We have been consistently friendly and helpful with all parties.
Any advise would be greatly appreciated! Have you encountered something like this before and did you manage to turn it round?
Note:This question is intended to help Programmers etc. with implementation difficulties by sharing experiences and factual solutions that worked. It is not intended to be subjective and indeed Programming techniques may help to solve the problem.
Use the tool
Somebody needs to really understand how the existing tool works. Not just well enough to walk through it; but well enough to do it for real. Why not take 2 weeks and go and do their job with them? That will both improve your understanding of the tool, and may foster a better working relationship with them. And while you're there, perhaps buy the drinks once or twice - it sounds corny, but anything that lowers the hostility, and lets you communicate.
User experience
Getting a good developer (or better: designer) who understanding user-experience is probably key. You can't just completely change their tooling and expect their productivity to remain the same.
Keyboard use:
Think of tools like Visual Studio, AutoCAD, etc - in most cases you don't need the mouse, and "die hard" types wouldn't notice if you took their mouse away. Try to respect this; provide shortcuts / chords (ideally the same as the existing system).
Terminology:
Keep it the same. Don't invent new terms for things.
Talk to them?
This may or may not be possible, but getting a few key users "on board" early can be pivotal; especially if you genuinely empower them to help with the user experience.
Find the faults
In the existing system. Take away their existing pain points and they may forgive you a lot.
Unfortunately it sounds like a case of needing to close the barn doors after the horses have bolted. You really need to get grass roots buy-in on the need for an improved system before beginning the project and maintain that relationship during the development.
By having champions of the system at the "coal face" level in the business would a) make sure you meet not only the management requirements but also the users goals which is all important in a successful system and b) the users get a system to which they have been a development party not just had a system thrust on them.
Getting people to moan about the short comings of an existing system is easy. Describing possible new systems before its create in way which allows the users to comment enables them to feel some control and gives you vital feedback. Be absolutely sure to identifier those killer gripes about the old system and make sure those are addressed in the new system.
Of course this all a bit late for you. The way forward is to create a review forum with the most vocal opponents and put them in a room with you and management. Get them to defend their reasons for not wanting the new system. If you can't show how your new system is better then perhaps it isn't. If you can see how the new system might be slightly improved (the movement may only need to be small) then do that, it may go a long way to get back the feeling of involvement you missed out on before.
I would sit together with the staff or a couple of the more loud mouthed opposers, go through what they find lacking with the system and suggest some of these changes to be incorporated in a future release(s). That way they will pay more attention to your the system and also feel more a part of the process instead of just being handed something like some peon. In addition it would also help avoid any misunderstandings about the system.
Get one / more of the user to be your champion by involving them in the development process. Make sure to choose the right ones. Hopefully one that you can reason with. When launching, do a launch event. Make it a big deal. Not necessarily applied to an application, but I've seen it worked in my previous work environments. If this is too late (you went ahead without any involvement from the actual users before), well... there is always things called staff turnover, lol. Out with the old and in with the new. Make the new users your buddy :).
You have to show some kind of benefit for making the change. A demo / mockup can be useful for this. Choose a manager to demo it to and wait. Let it become his idea. Then it might move forward. Being to pushy can cause a negative knee-jerk reaction which might block further consideration of the idea.
It is sad that software often gets replaced by a management decision without any user involvement and then people wonder why the system is rejected.
I've witnessed this first hand. A guy I once worked was told to develop a new version of an application "in secret". At the end of 6 months development it was shown to the users. It didn't meet their requirements and they were angry they hadn't been involved. Needless to say the software didn't make it into production and the developer left shortly after (I felt sorry for him as he had wasted 6 months effort and actually did a real good job considering the circumstances).
The chances are that the software is inferior to the previous application- perhaps data entry is actually slower (you will be biased as you wrote it- everyone likes to think their software is better).
Re-engage with the users, do some analysis and work out what is bad about the old system. If the new system can address the grips the users have with the old system you might be able to turn this around.
Edit- who was involved in engaged with your developers? Presumably the managers at the client, who probably never use the system? This is another big mistake people tend to make- managers driving requirements.
If the old system is perfect, then it never needed to be replaced in the first place!
For example, can an experienced coder with limited C#.NET experience be successfully paired with an experienced C#.NET coder with the secondary aim of getting the former up to speed with C#.NET?
Absolutely. Sharing knowledge is one of the points of pair-programming (along with the useful dynamic of having one person type for a bit and the other review as they do it).
In my experience, it's one of the most effective ways of doing so - and allows the less experienced coder still to usefully contribute (it takes less experience to review what an expert is doing and make sensible comments/interventions than to do the entire job).
That depends on the personal chemistry between them. If the more experienced programmer is willing and able to share his knowledge, and let the less experienced programmer participate in the development through writing code and discussions, I would say that it is a very efficient way of learning.
Yes, I find good pair programming is always two way, it's essentially a piece of social engineering masquerading as an IT innovation.
Yes, this will work. If 1) the programmer with limited experience is receptive to learning C# and 2) the other programmer is willing to teach C#.
When the skill mismatch is high, then it does become more of a teacher/student relationship. This isn't bad, but can waste time of the skilled person.
However, even if it's impractical or a waste, it can be very useful to have a very occasional pair session! Even if the student is overwhelmed or it's awkward, sometimes it's useful for "students" to see how people of top level work and think. It helps give them an idea of the problems/skills/methods of high quality work. Think of it as a high school student visiting a research laboratory. It's a waste for the pro scientists to teach the high school student, but the 1 hour visit can help focus the student and give them a glimpse of the ultimate goals...
I remember why I chose Emacs as my editor. I just happened to sit near an expert user, and literally rudely peering over his shoulder I watched him rearrange and navigate code super-quickly. I only watched for less than a minute and I never talked to him.. he may have not even noticed I was watching! But I was floored, and decided to learn Emacs. Ten years later I still don't have as much skill as that expert, but I don't regret my decision to change editors, since I got a glimpse of what was possible.
Personally, I think that would work well and is one of the goals of pair-programming but how successfully will depend on the two programmers. If programmer 1 (the one learning C#) was putting in some extra time to truly get up to speed and programmer 2 (the other one) has the patience and desire to teach it should be good for both.
You can certainly do this - we've done it in the past. But you have to accept that you trade off the "code quality" benefits against training benefits. There's no free training ride, I'm afraid.
It works to some extent. Usually it's one leading the other... so it's not much pair programming in that sense.
It depends heavily on the experienced coder's skill to teach and the other coder's skill to learn quickly.
Yes, but only if the better person is patient and willing to teach and the worse person is willing to learn. I've pair programmed with people not as good as me and it was tedious, but I think they learnt from it. I've pair programmed with people that are better than me and I certainly learnt from it. Depends on the people really.
It can be effective with the following caveat: You must switch partners.
I've actually been in this situation and, if the gap is large, it can be very taxing for both members of the pair. Best to switch partners after a few hours, with the time varying according to your tolerance and the size of the gap. If that option isn't available, mix in some solo programming.
There's a saying that a team's strength is as good as its weakest link. Pairing the strongest one with the weakest one has traditionally been the best strategy because the weakest learning from the strongest potentially ensures most amount of learning. If there is a worry of the strongest being uninterested, then replace the strongest with someone who'd really be the strongest.
It all depends on the personality of the developers there is no hard and fast rule.
One thing that is certain is that the experienced developer will be less productive when working with an inexperienced developer. I personally think there needs to be a good match of abilities when pair programming. It is however a very good way of getting inexperience developers up to speed.
Although its a good idea but practically it may not be useful. To train somebody you can organize training and assign mentor who can help and guide. The mentor can assign work from the real project and may monitor.
Pair programming should be between relatively experienced people, if you want to get the benefits of this concept. In my view pair programming with an inexperienced person will have loss of productivity and not sure how much the person will pickup when somebody is constantly checking on him. Assigning a task and giving chance to develop it independently and then review it will provide good self learning.
Yes, but the approach to make it effective may not be clear at first. The task that is being pair programmed on should be the task of the less experienced programmer (We will call him Michael). I would also have Michael start the pair programming session so as to explain what the objective of the session is. This approach puts Michael in the drivers seat where the more experienced programmer (We will call him Bill) will serve more of a mentoring role.
Typically Bill will either take or be given more complex tasks to work on. This approach allows Michael to work on tasks that are more suited to his experience level. I would recommend switching off at 30 minute to hour intervals at first such that Michael can get used to the process of giving someone else control. You can slowly shorten these switch offs to 15 minute intervals or whatever works best for the two developers.
I think that the final results you get depend on the guys that are doing this. In this case, you'd probably end up with one leading the other (and where the other is just paying attention to understand the language features the first one is using).
It depends on how much skills impedance mismatch we're talking about.
Two good programmers in different languages can grow-up quickly with it, obviously at the cost of a little slowdown of the one expert in the current project's language.
If the difference is too big (for example, a veteran and a rookie), instead, it might be preferable to start with some other kind of approach, to avoid the risk of getting highly counterproductive.
Always beware the extreme pair programming !
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 9 years ago.
Improve this question
I guess, the following is a standard problem on every school or university:
It is Your job to teach programming. Unfortunately, some of the students
are semi-professionals and have years of experience while others do not even know the basic concepts, e.g. the concept "typed variable".
As far as I know, this leads to one of the following situations:
Programming is tought from its very basics. The experienced students get bored and discontinue to visit the lectures. As a consequence, they will miss even the stuff they do not already know.
Teachers and professors claim that they require basic knowledge (whatever that means). Inexperienced students cannot follow the lectures and a lot of them will focus on unimportant stuff (e.g. understanding every detail of a complex example while not getting the concept behind the example). Some of them will give up.
Universities invent an artificial programming language to give experienced programmers and newbies "equal chances". Most students will get frustrated about the "useless language".
Is there a fourth solution, which is better than those above?
IMO this is a problem based on the placement of the students, not something you should be too interested in dealing with on your end as a teacher.
If the course is an introduction to programming a computer, then you really need to start with the basics. If you have a classroom full of professionals who know how to program and they don't show, it was either a problem with your course description, or the school forcing them to take the class as a pre-req without allowing them to test out.
Your job should be to describe what you want to teach in the course description, and teach it. If students enroll who are overqualified, that's their problem. I think the only thing you really need to avoid is trying to make the course too advanced for beginners if your course really is for beginners.
I think the best way to keep it interesting is to bring up practical and interesting exercises along the theory. Taking a problem-solution approach is great (with interesting, funny, exciting, real-world problems). This requires the professor himself to have hands-on experience, work with new technologies and know them pretty well and not just teach what he had learned a couple decades ago.
The thing is, programming should be learned by practice. The instructor should focus on motivating students to code and try to solve problems themselves. This can be done by assigning a complete life-like project at the beginning of the course and working through the subproblems that occur in the project in the class. This way, students will have an idea why some specific feature in the programming language exists and where it might be useful.
Just a thought though. Not tried it! ;)
I recently attended a course in which there was a very wide spectrum of experience in programming among the students. They still managed to keep the experienced programmers in the class interested by having an exercise program in which they timed the practical parts of the exercises (the programming part), and posted the results in a high score chart. At the end of each lecture, the professor gave some pointers as to how we could improve our times even more. As we all know, all engineers love competing for topping such lists, so we kept showing up, and even learned a new thing or two.
The inexperienced students managed to complete the exercises too, even if they didn't care too much about their times.
Don't know if your course is one that can implement this solution, but if it is, you should really consider it.
I think there are a couple if things you can do to help bridge the gap between advanced and beginner students and to keep everyone interested and involved in the course.
Advanced Workshops
If it can be arranged (using PHD students etc.) run an optional weekly workshop which anyone can attend, but which is aimed at the more experianced students. Set a code task / challange each week and then at the workshop go through various solutions to the problem and discuss the implications and the theory behind the different choices.
This provides an interesting challange for the more experianced coders as they have something to get thier teeth into. It opens some debate and can help intermediate people grasp interesting concetps and if you get people to present thier solutions, it introduces an open reviewing style which is beneficial. It also helps the beginners in that you don't have to present them with really advanced concepts in the main lecture series just to keep the experienced people interested.
Student Involvement
Experienced people generally are experienced because they enjoy coding etc. and a lot of people love to share their knowledge. A really good way to use this, and to help both beginners and advanced students is to get the more advanced students involved in the teaching. If you run classes/labs where students complete exercises, try getting volunteers from the more experienced students to act as mentors/ supervisors for the labs. When the beginners struggle they can help out by explaining fine details or subtleties etc.
This can really help the beginners, as there are never usually enough staff available for everyone to be able to ask individual questions. It can also really benefit the more advanced people, as having to explain concept which you "know" is a great way to reinforce them in your own mind, and even to discover that you have subtle misunderstandings in your own knowledge.
Don't assume more than you need to; try to select programming environments which don't have too much intellectual baggage. You may think a C "Hello world" program is simple, but that requires understanding source files, compilation, static typing and block structuring. There are not easy concepts for a beginner. In comparison, typing "print 'hello world'" into a Python shell avoids them. Declarations, compound types, object orientation, pointers, floating point, recursion, modularity, threads, callbacks, modularity, networking, databases and so on are all major concepts which require effort to learn. And, there are plenty of fun things to be done without them. Your goal should be to get everyone in the group doing programming exercises as soon as possible.
Mixed ability teaching is hard; stream it by splitting the group up if you can. Maybe publish a quiz of basic concepts, and have an optional basic concepts section for those who didn't get 100%. Some people think they are experienced programmers but have misunderstood basic ideas.
If the course time available is too short to let people try lots of exercises, then I'd drop the more advanced material before I dropped practical work.
In one course I took, a large part of the course grade was derived from a end-of-term project which was announced in advance with extra credit available for assorted add-ons and frills. Sufficiently experienced student could start working on it while their less prepraed brethren were being taught the basics.
But as Dave Markle says, part of this is a matter of getting the right students into your class: you really want a cohort that is fiarly well matched at the start.
If you have many experienced students or this is an upperclassmen/graduate level-course, you should focus on integration into existing ecosystem. Being able to understand and integrate into an existing project rather than to always work from scratch is the most important skills you can give to give to those students.
Thus, programming assignments should come from real world scenarios. E.g., assign them tasks in an open source project. This can also make it more interesting, especially as their work may become part of a real world project.
If it's really beginners, tough luck, you will have to stick to the basics though if the students are non-CS majors, you can create problems from their own domains (e.g., engineering, chemistry, etc.)
I think your could be toast.
After some point, the difference is just to wide. It will take the whole year to get the beginners to the point that they can even understand stuff that wont bore the more advanced people.
However this clearly depends on the topic and setting. For some combinations of those the solution is teach to the level that the class is billed for. Those that are to advance will get board and quit, those that are to inexperienced with fall behind and quit. Don't worry about it to much as neither should have taken the class anyway. If on the other hand they need to take the class then some one further up the ladder messed up.
Sitting in your chair watching someone talk is boring (even if you talk well).
Things are interesting if you can achieve something, when you can manipulate the world and have a moment of success. So add as many practical exercises as you can and make really sure that they can do them in time and that they can do them successfully in time.
Nothing is more frustrating than to hear: "Well, I'm sorry that you couldn't complete it. You can find a solution here. Let's copy that and pretend it did work and move on." Examples during a course are simple and the people in front of you know that. So if they can't even solve the simple examples you bring along for them, what are they going to think?
I always think it is best to learn through practice. At the beginning of the course especially it is incredibly boring to teach language syntax in a lecture. It is far better to require your students to complete some work on their own or in a lab with assistants. This allows the more experienced students to get through the work quickly.
Once this is done you can have a lecture where you discuss some of the solutions to problems. Why they are good and why they are bad.
This works especially well if you also structure your course in such a way that students are always building on their rpevious work. The first week can be something simple like calculate how many days old I am from my birthday. A problem that is relatively simple mathematically but has a few weird cases. This might take several hours for someone inexperienced. Especially if they are learning syntax at the same time. But it gives them a simple goal to work toward.
After this you can expend on it. eg: take lasts weeks program and add functionality that allows it to batch process a file. This teaches people the importance of restructuring and refactoring, and can be expanded week after week. You may even want to distribute a good piece of work from the previous week for those that are falling behind to use. Obviously you will need to make sure people don't get too far behind, but this is a nice way to make sure that everyone feels that they have a fair shot at it even if their previous week's work wasn't too good. Those who are doing well will end
The key is to keep your lecture sessions relatively high level, and have people learn the syntax on their own, or with lab assistants. You can teach them different ways of thinking about a problem but the actual act of writing code is much easier to learn by doing it.
I once through a scheduling nightmare ended up teaching a beginner class and an advanced class in the same classroom at the same time. What I did was divide my time between the two levels by starting out giving the advanced group an assignment to do in class while I worked with the beginners and then giving the beginners an assignment while I worked with the advanced. You could do something similar (only having the groups self-select into the group they wanted to be in). Prepare some extra material for the more advanced ones and you are off to the races.
Another strategy is to keep everything at the beginner level, but offer the more advanced students some other material to do for extra credit (or even as substitution for some of the simpler tasks you require of the beginners). Discuss the more advanced assignments with them outside of class or individually while the class is working on practical work in the lab.
Keeping the lectures interesting with plenty of real world examples is helpful too. I tended to lecture as little as possible though and present the material more through class discussion and practical exercises and through asking leading questions. Making them find the information to answer your questions (and class participation was part of the grade) will make them pay more attention.
I also ended each semester with a course project that I only described what they had to do in order to get a B. An A would involve doing work beyond that including work in an area not covered in class. The more advanced students can then really shine by looking for really cool new things to do and even the beginners usually find a way to do something not covered by the course. It's amazing how much extra effort they will go to when they don't know how much more they have to do to get an A. Other instructors would be amazed at the quality of the end of the course projects I got and several of them started using the same method.
It may be better to break up a few areas of concern with what some would call, "Introductory Programming":
1) Introduction to personal computers and modern computing. Assuming that the course's software runs on windows, there may be some that need to cover the basics of a computer, e.g. what is a hard drive, keyboard, mouse, monitor, CPU, motherboard, etc. Note that this has nothing to do with even one line of code other than naming operating systems potentially. For some people this may be new to them and thus having a course that covers the basics, may well be worth it. Also in this course would be ways to use a mouse and all its various buttons, what are the various kinds of cables and connections people have, what are drivers, what are patches, what are parts of a network, e.g. firewall, router, load balancers, etc. The idea here isn't to get into how to configure a firewall perfectly, but rather that the person understands what various hardware components are for and possibly how to configure a home wireless network as the most complicated concepts taught.
2) Principles of programming. This would start with the idea of what are the steps are there to execute a sequence of commands. Things like printing and performing Mathematical operations, e.g. converting from Imperial to metric,would be covered with possibly sorting being the most complicated example, viewed from a variety of different algorithms and an understanding at a basic level of big-O notation.
3) Introduction to Data Structures and Advanced Programming. Now, let's introduce the concept of a relational database and how databases work in general and have projects with real world application, e.g. have each student take a list of something they have like DVDs or CDs and put these into a database schema to efficiently store all this data. Also, the idea of floating point arithmetic and its limitations, e.g. that a computer doesn't store the whole value of pi but rather an approximation that should be good enough in most cases.
4) Introduction to Parallel Programming and Operating Systems. Here you would have some in depth work in building an Operating System and handling how to write code that can run concurrently or in Parallel and how efficient are various programs under different circumstances.
That is how I could see someone breaking up programming so that it isn't where someone can learn in a week enough to pass the final without looking at anything else.
I have frequently been in this situation, first on the student side of things, and then on the teaching side.
Most schools force those sort of courses and their curriculum. This is silly, but such is life. If your school does allow it, I would suggest offering students attendance waiver if they pass an early screening test. It is in your interest and the interest of the freshmen to not sit in a class where a significant portion of the population is bored. Even being in a room with tons of people starting at their laptops harms discourse. Everyone is required to attend tests and submit assignments, but they at least don't have to show up.
Once you work with the novices, figure out if they're majors or nonmajors. Nonmajors will resent being in a CS course, you have to try and make it approachable for them. E.g., use examples from physics or chemistry or math rather than from building an interactive gui system.
If they're CS majors, they'd better damned be interested :)
My opinion is that teaching sample programs is dead-boring for most people. Searching, sorting, classification of 7-bit ascii input, using unix & make, opening a file, writing a file...
These are boring problems. Regardless of their importance/usefulness, these are tools. Unfortunately, tools are what's taught in intro courses, not problems.
But you need tools to be able to solve a problem. So it's a kind of chicken-egg problem.
Real world examples of code the student can imagine themselves doing out of their free time.
I remember a teacher telling me to use const values it was the tax of something. I only had to use the value in two places. She asked what if i need to change it i said its only in two places and i'll change it by hand also i couldnt imagine the gov ever changing the tax %.
I cant think of an non complex example where i would use a const so i wouldnt try teaching them to use that but for arrays i would simply write a guessing game then when the player wins the game, it plays back all the guesses in the same order to them. There is no easy way to do that w/o arrays and i could see how keeping track of someones steps/guesses would be useful (bragging rights to how quickly a person guessed it).
On the first day give the syllabus (what they will learn) and required basic knowlege (things you must know or else not take this class) and stick with it. After these all you can do is teach well (explain things well, answer questions, give a joke or two now and then etc). Caring who attends class, whether or not the field is boring, whether student lied about pre-requisites or not, who listens and the other yada yada is beyond your controls. Besides, you should expect adults to be adults. If students skip class and ace test, maybe that is best for them. If they skip class and bomb tests, well maybe they are in the wrong place.
I hated when professors had this mentality when I was in college. Now as a working professional I understand it.
Center the programming exercises around either sports or movies.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I have written presumably some of the first code to modify the memory of a popular new MMORPG in such a way as to create a macro framework, allowing for advanced automated reactions, skill/level gain, large scale data retrieval, and botting.
It's my supreme pleasure to automate tasks in this way, I can't help but think of any manual approach as "broken". In fact I find myself rather unable to complete even single player games before dissecting their mechanics and gaming them, in a specifically read-only (not cheats, per se) mouse and keyboard input only fashion. Supplementing my advancement toward a game related goal with my own programming knowledge seems natural, it's really not fun otherwise, like ignoring your firearm in an FPS.
Since I love this form of reverse engineering I assume others do as well, they'd appreciate the end result at least. I tend to feel a project should somehow "ship": be sold, open sourced, or freely distributed. "Happiness only real when shared." Otherwise it's just me and my timesink.
The problem is that there are several moral stances involved with a project of this nature:
An evil is released upon the virtual world. Those with the program have an advantage, the game is unbalanced, you've got to use, simply to be on equal footing. It's no longer about the game, but the tools, an arms race. It's like every other MMORPG. Therefore, keep the code private.
The above is inevitable, so release a peremptory free distribution to give players equal access to the advantage and potentially deny someone else a more evil™ (e.g. elitist, commercial, etc.) release. Between evils the least is selected, though its necessity is disagreeable.
Sell the program, reap the benefit of your proclivity, it's work for which you deserve recompensation, fair trade (and regardless of ToS violations). Follow the likes of WoWGlider. Is it better in fewer hands?
Keep the code private. Respect at least this much of the company's Terms of Service you agreed to.
What is a morally defensible approach? What haven't I considered? In my experience ToS agreements are a largely ineffective form of dissuasion, and the gaming of MMORPGs (and subsequently results described in #1) is indeed inevitable, but there's something to be said in not pulling the trigger yourself - or is it not so bad?
I did a poor job on the original phrasing/titling of this question, I was really looking to see if there were special circumstances when it could be morally defensible, not whether or not it would normally be, in hope my code could have constructive purposes.
As a new user I didn't realize 99% of the responses would be immediate, before my update. That said, I still received some very helpful answers regarding commercialization and the original question merited the answers provided, so: well done on that front.
I do have my answer: despite the inevitability of bots, don't pull the trigger yourself! Be the change, etc. (#3 was never on the table for me personally, but elicited some brilliant answers.)
You need to tread very lightly.
MMOGlider was a popular WoW bot up until recently. I wrote an addon for it in C# called GliderTools (GliderTools.net) which made a decent bit of money.
Blizzard recently sued MMOGlider for $6 million dollars and won. There is legal precedent now against the writing of bots and commercially selling them. The monetary damages associated with doing this are staggering. It worth noting that the crime Blizzard was able to get MMOGlider on wasn't "botting" but instead, copyright infringement. They claimed that because the bot client had to access and copy certain parts of the running games memory that this constituted copyright infringement.
Considering MDY (creators of MMOGlider) made less than $2 million dollars, they have a heavy price tag on their heads. Michael Donnelly the original creator and founder of MDY was not protected under his LLC license and he is personally liable for those $6 million dollars. This kind of debt does NOT go away with bankruptcy. He has it for life. Once you add on legal fees, appeal, etc this is a dangerous game.
I personally love writing bots. To me a game isn't fun unless I've dissembled it, wrote a patcher for it or automated it in some way. This what makes the game fun for me, not the game itself. Seeing your bot run autonmously for the first time is a real high. However, if you make a commercial product and sell it to others it becomes a different matter.
So, if you decide to make a bot I strongly suggest you either release it from outside the United States or keep it private among friends.
Earning money on annoying million of other players, on something that's close to be taken for illegal won't look good on your resume either.
Use your skills for good™, not evil.
Personally I see botting software for populare games, is like writing botnet worms.
You waste other people's time and efforts (and often money).
Would you write a virus to earn money?
I've been building (but never selling) bots for online poker and chess for over a decade (insert promotional web link here) so this question caught my attention. I agree with #Simucal in that you need to tread lightly, especially where MMORPG's are concerned. Blizzard in particular has a draconian stance towards automation.
4.5 million copies of EULA-compliant spyware
Then again, the idea that a private company's TOS/EULA = LAW is a bit of herdthink. The moreso when that company markets to a worldwide audience across international borders. This introduces additional complexities into the TOS/EULA, which is already a vague piece of legalistic verbiage in the first place. The common practice is to structure the TOS/EULA to make it as aggressive, all-encompassing, and wide-reaching as possible. This is just good legal sense. It doesn't necessarily mean that every line of the TOS is legally binding. A TOS is a deterrent and the company will insert whatever language they think they can get away with, and hope it holds up when/if it's tested in court.
Nothing wrong with this.
At the same time, building a bot is, in and of itself, neither morally or ethically wrong. There's a very strong and convincing argument to be made that provided your bot doesn't actually "hack the servers", you have every right to run whatever piece of software you like on your machine in the privacy of your home. This is especially the case when the servers are inundated with bots anyway, so by not running a bot you put yourself at a disadvantage. Everquest PVP (for example) has been dominated by botting pretty much since the beginning.
Anywhere, there are two important criteria to consider:
Does the bot depend on information which other player's don't have?
Does the bot enable superhuman reactions, stamina, or coordination?
This puts wallhacks (unfair information) and aimbots (superhuman reaction) firmly in the "unfair/cheating" category. On the other hand, a simple farmbot is most probably NOT cheating, because the bot doesn't have access to any insider information and it doesn't allow you to do something you couldn't otherwise have done. You could, if you wanted to, sit there for 10 hours a day and farm ore or roots or whatever. It's not much fun, but you could easily do so.
This is a good acid test for whether your use of automation has crossed the line. Trying to cheat people is a bad idea. But writing a bot to essentially ward off carpal tunnel is understandable, and it can actually be a rewarding project.
But again, I wouldn't advise actually selling a bot. Because if you make any money on it, you open yourself up to the sort of retaliation #simucal mentioned.
Just because other people will make similar bots does not make it morally OK.
These games are, at the end of the day, supposed to be fun. As you said, bots turn the game into an arms race, especially if the game has any competitive component.
Here's an example from my experience with World of Warcraft: I wanted a specific item crafted. The materials for this were hideously expensive on my server; the large number of rich players (who may or may not have gotten their gold legitimately) had pushed the prices up to a point where I couldn't afford it.
My only option was to farm the materials myself. Many of these required killing huge numbers of monsters for days at a time. One particular item had something like a sub 1% chance to drop. And almost every single farming spot was being run continuously by bots.
It's hard to compete against something that doesn't sleep or take breaks. You can't simply wait for them to go away because they don't. Because I played by the rules, my goal was made far harder than it should have been.
It's hard to have fun in the game if there are people willing to ruin your experience out of laziness and greed.
So no, I'd say it's not morally defensible. You know full well that what you create is going to harm people.
The real question is, do you have a problem with that?
If you've described your true feelings here, then the fun was in solving the problem, not in creating a product. If others appreciate this kind of thing they'll do it themselves.
In my opinion, you cannot have a morally defensible position when in order to being solving the problem interesting to you, you agreed to terms and conditions prohibiting you releasing your work.
The problem with this is that it reduces most of the game down to just one thing: end-content.
Take World of Warcraft for instance, I love playing that, and I love leveling up a character. Sure, there are some tedious points in the process, but by and large, it's fun.
Now, if I had installed a bot and just put it to work leveling up my character, at least doing all the repetetive work and leaving me with just visiting a trainer NPC and getting my new skills once in a while, then all I had left was the things I could do at level 80.
Additionally, all the skills I, as a person (not my character) should've learned along the way goes out the window.
There are two types of people that are beyond good in Counterstrike, as an example, it's the people that use bots, and it's the people that have just played so much that they are that good.
Once you resolve to using bots, you're pretty much doomed to keep using them, and trying to automate your end-content playing as well, since you really don't have the experience to play at that level.
So basically, you're reducing the whole game down to a programming contest.
Even if you keep you code only to yourself, all you've proven is that you can program. You've yet to prove that you can play the game.
So in the end, what actually is the point of you playing that game then?
As others have said, there's many options available to you if all you want to do is create software to automate things.
Having said that, I share some of your joy of controlling my environment. I use regularly quite a lot of addons in World of Warcraft, but they don't give me an advantage over others in the same way a bot would. They might make it easier for me to organize my inventory, let me keep notes inside the game, or just prettify the user interface, but in the end, it's still me that pushes the buttons in response to game events.
And that's what gaming is about for me.
Progression requires unethical choices. My advice is Go Ahead and "reap the benefit of your proclivity, it's work for which you deserve recompensation [...]". Why are you ever worried about this? Release the hounds and let others fight it if they can. Take a history book to see thousands of similar decisions made. It pushes humankind forward.
I'm a big multiplayer gamer myself, and played so many MMORPG.
When I see someone cheating in an online game only one sentence is out of my mouth "What a wank*r!"
Morally it's wrong to mess up other people's fun, and if you try to make money out of it it's not any better than running a SPAM company.
To be honest personally I don't care about farming bots, playing a game which requires constant farming sounds stupid to me anyway. But still there lots of people out there who cares, and you these tools definitely spoiling their fun.
I understand it's a fun challenge, keep it private have your fun, tell your friends and show off, but do not kill other people's fun.
In my opinion a ToS holds no one back [...]
So, by using the MMO, you agree to the ToS; but it's OK to break the rules, because you don't agree with the ToS? Nice doublethink, but the court would probably ROFL at such argumentation.
You see, the basic idea of ToSes everywhere is "it's our way or the highway" - by using the service, you agree to play by the service's rules; if you don't like the rules, nobody is forcing you to use that service, you can freely walk away.
Also, don't try to be "clever" and release the bot in Elbonia just because its jurisdiction allows that: the ToS probably states that server's jurisdiction applies (which can bite you if you ever decide to visit the country in question, or even another country which has extradition agreements with it).
Disclaimer: IANAL
If you been following the Blizzard versus MDY case, and the recent outcome, I would strongly recommend you to keep code in private if you're located in the US, or any country with Intellectual Property laws.
Also #3 , selling it will only get you into trouble. MDY went bankrupty, is not allowed to sell their product anymore, had to hand over the source code, and pay Blizzard 6 million USD in damage.
The author, Michael Donnelly, is likely to end up in dept for the rest of his life.
I recommend you keep it private.
As opposed to Blizzard and WoW, take a look at Ultima Online and OSI as to they allowed 3rd party tools, and even supported them (Tugsoft's UOAssist).
To me it's morally fine, if the game is designed in such a way that grinding one thing only leads to grinding another thing, and if the grinding in general is done in really unpleasant manner then, hey, why not? If it's allowed, everyone has an equal chance, as everyone can use the particular supported 3rd party product, this is a chicken-egg question.
It's mostly forbidden because it reduces the time you need to spend in the game, effectively reducing the time you're paying them for their service, so, greed or fun?
As a sidenote, I'm all against unattended macroing, it's a huge difference between attended and unattended.
Yes, it is fun to reverse engineer games and to do automation. From your question it sounds like you're asking where to go from there.
A) It violates the ToS, so you shouldn't use it yourself.
B) It violates the ToS, so you shouldn't sell it.
My impression is you're looking for an OK to do one of those two things, while admitting that the fun was in writing it. I would suggest you take the entertainment value from writing things for what is, and assume your "fun" time is not worth any money. Particularly at the expense of others.
The ToS holds no one back? Check with Blizzard, they are not pleased by such things It's definitely in their ToS not to run any programs that mess with WoW). The companies running these MMO's try pretty hard to stop such programs because they lead to unfair advantages and ruins the economies.
If you like doing these kinds of things, you can also look at non-MMOs. There are plenty of games (e.g. TES:Oblivion and Fallout 3) that have very active modding communities which are tolerated and even supported by the game developers.